Architecture
Diagramme d'architecture de déploiement GitOps avec workflow Git développeur, pipeline CI/CD construisant et poussant des images de conteneurs, ArgoCD ou Flux détectant les changements de manifestes Git, détection de dérive, synchronisation automatique du cluster et déploiement par mise à jour progressive vers Kubernetes. Ce modèle représente le paradigme GitOps où Git est la source unique de vérité pour le code applicatif et l'état de l'infrastructure, permettant des déploiements déclaratifs, auditables et reproductibles. Critique pour les équipes adoptant les pratiques GitOps pour les déploiements Kubernetes.
Code FlowZap complet
Developer { # Developer
n1: circle label:"Code Change"
n2: rectangle label:"Git Push to Main"
n3: rectangle label:"Open Pull Request"
n4: rectangle label:"Merge After Review"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Feature Branch"]
n3.handle(right) -> n4.handle(left) [label="Approved"]
n4.handle(bottom) -> CICD.n5.handle(top) [label="Trigger"]
}
CICD { # CI/CD Pipeline
n5: rectangle label:"Run Tests and Lint"
n6: rectangle label:"Build Container Image"
n7: rectangle label:"Push to Registry"
n8: rectangle label:"Update Manifest in Git"
n5.handle(right) -> n6.handle(left) [label="Tests Pass"]
n6.handle(right) -> n7.handle(left) [label="Tag: sha-abc123"]
n7.handle(right) -> n8.handle(left) [label="Update Image Tag"]
n8.handle(bottom) -> GitOps.n9.handle(top) [label="Commit Manifest"]
}
GitOps { # GitOps Controller (ArgoCD/Flux)
n9: rectangle label:"Detect Git Diff"
n10: rectangle label:"Compare Desired vs Live"
n11: diamond label:"Drift Detected?"
n12: rectangle label:"Sync to Cluster"
n13: rectangle label:"State Already Synced"
n14: rectangle label:"Health Check"
n9.handle(right) -> n10.handle(left) [label="Poll/Webhook"]
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left) [label="Yes"]
n11.handle(bottom) -> n13.handle(top) [label="No"]
n12.handle(right) -> n14.handle(left) [label="Apply"]
n14.handle(bottom) -> Cluster.n15.handle(top) [label="Deploy"]
}
Cluster { # Kubernetes Cluster
n15: rectangle label:"Rolling Update Deployment"
n16: rectangle label:"New Pods Created"
n17: rectangle label:"Old Pods Terminated"
n18: rectangle label:"Service Routes Traffic"
n19: circle label:"Deployment Complete"
n15.handle(right) -> n16.handle(left) [label="Scale Up"]
n16.handle(right) -> n17.handle(left) [label="Healthy"]
n17.handle(right) -> n18.handle(left) [label="Cutover"]
n18.handle(right) -> n19.handle(left)
}
Pourquoi ce workflow ?
Manual deployments and imperative scripts are error-prone, hard to audit, and impossible to reproduce. GitOps makes Git the single source of truth for infrastructure state, enabling declarative deployments where every change is version-controlled, peer-reviewed, and automatically applied to the cluster.
Comment ça fonctionne
- Step 1: A developer pushes code changes and opens a pull request.
- Step 2: The CI/CD pipeline runs tests, builds a container image, and pushes it to the registry.
- Step 3: The pipeline updates the Kubernetes manifest in Git with the new image tag.
- Step 4: ArgoCD or Flux detects the Git change and compares desired state with live cluster state.
- Step 5: If drift is detected, the controller automatically syncs the cluster to match Git.
- Step 6: Rolling updates deploy new pods, health checks verify them, and old pods are terminated.
Alternatives
Imperative CI/CD pipelines (Jenkins) push changes directly to clusters without drift detection. Helm charts provide templating but not continuous reconciliation. This template shows the full GitOps workflow with ArgoCD/Flux.
Key Facts
| Template Name | Architecture de déploiement GitOps |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.
Architecture
Diagramme d'architecture de découverte de services avec registre Consul ou Eureka, équilibrage de charge côté client, heartbeats de vérification de santé, et enregistrement/désenregistrement automatique des instances. Ce modèle visualise comment les microservices se localisent dynamiquement sans endpoints codés en dur, permettant une mise à l'échelle élastique et une infrastructure auto-réparatrice. Clé pour les équipes plateforme construisant une communication inter-services résiliente.