Passer au GitOps

01Pourquoi le GitOps

Bonus : plus besoin de distribuer des kubeconfig à toute l'équipe pour déployer. Une merge request relue suffit.

02Organiser son dépôt

boutique-deploiement/
├── base/                  # ce qui est commun à tous les environnements
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── kustomization.yaml
└── overlays/
    ├── recette/           # ce qui change pour la recette
    │   └── kustomization.yaml
    └── production/
        └── kustomization.yaml

Un dépôt dédié au déploiement, séparé du code de l'application, évite qu'un commit de documentation ne relance un déploiement, et permet de donner des droits différents.

03Un dossier par environnement

Kustomize, intégré à kubectl et à Argo CD, applique des variations à une base commune sans la dupliquer :

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: mon-equipe
resources:
  - ../../base
images:
  - name: registry.gitlab.com/mon-equipe/boutique
    newTag: "1.4.3"
replicas:
  - name: boutique
    count: 3
patches:
  - target: { kind: Ingress, name: boutique }
    patch: |
      - op: replace
        path: /spec/rules/0/host
        value: boutique-mon-equipe.demo.k8s.exemple.fr

Pour vérifier le résultat avant de pousser : kubectl kustomize overlays/production affiche les manifestes finaux.

04L'application Argo CD

Argo CD a besoin de savoir quel dépôt suivre, quel dossier et vers quel namespace. Sur notre plateforme, l'administrateur crée cette déclaration à votre demande et donne à Argo CD une clé de lecture sur votre dépôt :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: boutique-production
  namespace: argocd
spec:
  project: mon-equipe
  source:
    repoURL: git@gitlab.exemple.fr:mon-equipe/boutique-deploiement.git
    targetRevision: main
    path: overlays/production
  destination:
    name: demo
    namespace: mon-equipe
  syncPolicy:
    automated: { prune: true, selfHeal: true }

Avec prune, un fichier supprimé du dépôt supprime l'objet du cluster ; avec selfHeal, une modification manuelle est annulée. Vous gardez Rancher et kubectl pour regarder, déboguer et lire les journaux ; pour changer, c'est Git.

05Le cycle de travail

1. La chaîne d'intégration continue construit l'image et la pousse avec un tag immuable, par exemple l'empreinte courte du commit.
2. Elle ouvre une merge request sur le dépôt de déploiement, qui change newTag.
3. Un collègue relit et fusionne.
4. Argo CD voit la fusion et applique, en général en moins de trois minutes.
5. Problème ? git revert du commit fautif : Argo CD remet l'ancienne version.

Renovate, qui met déjà la plateforme à jour, peut aussi surveiller vos images de base et vos dépendances et ouvrir les merge requests correspondantes. Le travail de veille se fait seul ; il vous reste à relire.

06Et les secrets ?

Jamais en clair dans le dépôt, même privé. Trois approches, de la plus simple à la plus outillée :

• Créés à la main avec kubectl create secret (chapitre 04) et simplement référencés par les manifestes. Simple, mais hors de Git.
• Chiffrés dans Git avec SOPS, comme le fait la plateforme elle-même pour ses propres secrets.
• Lus dans un coffre (Vault, OpenBao, Infisical) par un opérateur qui les synchronise dans le cluster.

Parlez-en avec l'administrateur avant de choisir : c'est le genre de décision qu'on prend une fois pour toute la plateforme.

C'est la fin de ce guide. Vous savez déployer, exposer, configurer, dépanner et livrer par Git : de quoi faire de la plateforme votre terrain de jeu, et laisser à d'autres les nuits de mise à jour.