La plateforme Socles DevOps

1 Vue d'ensemble

Le dossier socles-devops/ n'est pas un mono-repo : c'est un agrégat de 11 dépôts Git indépendants hébergés sur GitLab, rangés en quatre sous-groupes. La plateforme fait circuler un artefact (image + chart Helm) depuis le code applicatif jusqu'au cluster, en passant par une chaîne d'outils bien précise.

2 Les briques & les dépôts

Quatre sous-groupes GitLab sous gitlab.com/socles-devops :

3 Du commit au déploiement en prod

Le parcours réel, avec les vrais noms (exemple personal-site) :

1. Commit sur main

   Un merge dans projects/personal-site déclenche le pipeline GitLab CI.

2. CI — security → lint → test → build

   Les stages consomment les Components/ : security-gitleaks, security-trivy-fs, code-ruff, code-semgrep, tests pytest, helm lint.

3. Build & push vers Harbor

   Images poussées vers harbor-dev.zephyr-gestion.fr/library/personal-site-{frontend,backend}:<IID>.<sha>, chart Helm empaqueté et poussé en OCI vers oci://harbor-dev.../library/personal-site:<major.minor.IID>. Puis security-trivy-image scanne les images (bloquant sur CRITICAL).

4. Kargo Warehouse détecte le freight

   Le Warehouse personal-site s'abonne au chart OCI et aux deux images (NewestBuild, en excluant latest). Un nouveau freight apparaît.

5. Stage dev — auto-promotion

   autoPromotionEnabled: true. Kargo met à jour la version dans environments/dev/applicationsets/projects-helm.yaml (repo infra/argocd) et ouvre une MR. Aucun merge automatique.

6. Stage prod — manuel

   autoPromotionEnabled: false. Sur promotion, Kargo réplique le chart et les images de harbor-dev vers harbor (prod), puis ouvre une MR sur environments/prod/applicationsets/projects-helm.yaml.

7. ArgoCD synchronise

   Une fois la MR mergée, la root-app → l'ApplicationSet projects-helm resync et déploie la nouvelle version du chart sur le cluster. Fin du voyage.

4 ArgoCD & ApplicationSets

Pattern App-of-Apps : bootstrap/<env>/root-app.yaml pointe vers environments/<env>/applicationsets/. Chaque ApplicationSet est une liste statique d'éléments avec un syncWave.

Convention : dev et prod ont chacun leurs ApplicationSets et peuvent porter des versions différentes. Jamais de latest : on promeut des versions explicites.

5 Promotion Kargo

Kargo orchestre la remontée d'un freight à travers des Stages :

Les credentials Kargo (git + Harbor) sont des *.sealed.yaml (Sealed Secrets), chiffrés pour le contrôleur du cluster. Ils ne vivent jamais en clair dans Git.

6 Ajouter un nouveau projet

Modèle : personal-site. Voici le chemin complet pour brancher un projet my-app de bout en bout. (Ce dépôt map-platform a suivi exactement ces étapes.)

6.1 — Structure du dépôt applicatif

projects/my-app/
├── frontend/            # + backend/ si API (voir personal-site)
│   ├── index.html
│   ├── Dockerfile       # nginx non-root, EXPOSE 8080
│   └── nginx.conf
├── helm/my-app/
│   ├── Chart.yaml       # name: my-app, version: 0.1.0
│   ├── values.yaml
│   └── templates/       # deployment, service, ingress, _helpers.tpl
├── .gitlab-ci.yml       # include des Components/
├── .gitlab/             # templates issue/MR
├── CONTRIBUTING.md · README.md · .gitleaks.toml · .gitignore

6.2 — Brancher la CI sur les Components

include:
  - component: $CI_SERVER_FQDN/socles-devops/Components/security/security-gitleaks@1
  - component: $CI_SERVER_FQDN/socles-devops/Components/security/security-trivy-fs@1
  - component: $CI_SERVER_FQDN/socles-devops/Components/code/code-ruff@1
  # + build/push image, helm package/push, trivy-image

variables:
  HARBOR_REGISTRY: "harbor-dev.zephyr-gestion.fr"
  HARBOR_PROJECT:  "library"
  BUILD_TAG: "${CI_PIPELINE_IID}.${CI_COMMIT_SHORT_SHA}"

Utilise la ligne majeure @1 (comme personal-site), pas des tags figés anciens.

6.3 — Déclarer l'app dans ArgoCD (repo infra/argocd)

Créer les values environments/dev/apps/values/my-app.yaml puis ajouter un élément dans environments/dev/applicationsets/projects-helm.yaml :

- name: my-app
  namespace: my-app
  syncWave: "21"
  chart: my-app
  version: 0.1.0-<short-sha>      # Kargo la mettra à jour ensuite
  valuesFile: environments/dev/apps/values/my-app.yaml

6.4 — Config Kargo (optionnel mais recommandé)

Créer environments/dev/manifests/kargo/my-app/ (project, project-config, warehouse, stage-dev, stage-prod, namespace) et référencer le dossier dans projects-manifests.yaml. Calquer sur kargo/personal-site/.

6.5 — Secrets applicatifs

1. Dépôt créé sous projects/my-app, structure conforme
2. .gitlab-ci.yml branché sur les Components @1
3. Images + chart poussés vers Harbor au merge sur main
4. Values + élément d'ApplicationSet ajoutés (dev, puis prod)
5. Kargo warehouse + stages configurés
6. Secrets scellés, jamais en clair
7. Tout passe par MR — jamais de push direct sur main

7 Cas emma-website : CI-only, hors GitOps

emma-website illustre un mode alternatif assumé : le projet est couvert par la CI mais n'est pas onboardé sur la chaîne GitOps. C'est un choix délibéré, utile à connaître pour ne pas croire qu'il est déployé comme personal-site.

Pour l'onboarder un jour : aligner la structure sur backend/+frontend/, repasser les Components en @1, ajouter values + ApplicationSet + Kargo (cf. §6).

8 Points de vigilance & anti-patterns

Écarts réellement observés entre l'état actuel et les bonnes pratiques prod. Aucun secret n'est reproduit — seuls les faits de configuration.