Architecture de référence¶

Vue d'ensemble¶

L'architecture CI/CD combine deux composants complementaires : Gitea Actions pour l'integration continue (build, test, scan, push) et Flux v2 pour le déploiement continu via GitOps (reconciliation, sync, drift detection).

graph LR
    Dev["Developpeur<br/>git push"] --> CI
    subgraph CI["Gitea Actions - CI"]
        W["Workflow"] --> Build["Build (compile, image)"]
        W --> Test["Test (unit, integration)"]
        W --> Scan["Scan (Trivy, SonarQube)"]
        W --> Push["Push (Harbor)"]
        Push --> Update["Update manifests<br/>(image tag)"]
    end
    Update --> CD
    subgraph CD["Flux v2 - CD/GitOps"]
        Source["source-controller<br/>(GitRepository)"] --> Kustomize["kustomize-controller<br/>(Kustomization)"]
        Kustomize --> K8s["Cluster K8s"]
        Notif["notification-controller<br/>(Alert + Provider)"]
        Kustomize --> Health["Health Checks"]
    end

Gitea Actions — Composant CI¶

Architecture du runner¶

Le runner Gitea Actions (act runner) est un agent qui se connecte au serveur Gitea via gRPC pour recevoir et exécuter les jobs.

graph TD
    subgraph Gitea["Serveur Gitea"]
        Dispatcher["Actions Dispatcher<br/>(file de jobs)"]
    end
    Dispatcher -->|gRPC TLS| Runner
    subgraph Runner["act runner (registration)<br/>Labels: ubuntu-latest, self-hosted"]
        Job1["Job container<br/>(ubuntu:latest)<br/>conteneur ephemere par job"]
        Job2["Job container<br/>(node:20)<br/>un autre job en parallele"]
    end

Composants cles¶

Workflow dispatch¶

graph TD
    A["Evenement Git (push, PR, tag)"] --> B["Gitea cherche .gitea/workflows/*.yaml"]
    B --> C["Filtre sur les conditions<br/>(branches, paths, events)"]
    C --> D["Cree un ActionRun avec<br/>les jobs a executer"]
    D --> E["Dispatcher assigne les jobs<br/>aux runners par label"]
    E --> F["Runner tire le job, cree le conteneur,<br/>execute les steps"]
    F --> G["Runner renvoie le resultat<br/>(logs, status, artifacts)"]

Flux v2 — Composant CD/GitOps¶

Architecture des controllers¶

Flux v2 est compose de controllers indépendants qui s'exécutent dans le cluster Kubernetes. Chaque controller a une responsabilité unique.

graph TD
    subgraph K8s["Cluster Kubernetes"]
        subgraph flux["Namespace flux-system"]
            source["source-controller<br/>(GitRepository, HelmRepository,<br/>OCIRepository)"]
            kustomize["kustomize-controller<br/>(Kustomization)"]
            helm["helm-controller<br/>(HelmRelease)"]
            notif["notification-controller<br/>(Alert, Provider, Receiver)"]
            imgref["image-reflector-controller<br/>(ImageRepository, ImagePolicy)"]
            imgauto["image-automation-controller<br/>(ImageUpdateAutomation)"]
        end
        subgraph app["Namespace application (cible)"]
            resources["Deployment, Service,<br/>ConfigMap, Secret...<br/>(synchronises depuis Git)"]
        end
    end
    source --> kustomize
    source --> helm
    kustomize --> resources
    helm --> resources
    imgref --> imgauto

Controllers et CRD¶

Reconciliation¶

Flux reconcilie en permanence l'état du cluster avec l'état declare dans Git :

Health checks¶

Flux evalue la sante des ressources déployées via les health checks Kubernetes natifs :

Flux complet : du push au déploiement¶

graph LR
    Push["git push<br/>(code)"] --> Gitea["Gitea Actions<br/>Build image<br/>Test<br/>Scan Trivy"]
    Gitea -->|Push image| Harbor["Harbor<br/>(registre)<br/>app:v1.2.3"]
    Gitea -->|Update tag| Manifests["Depot manifests<br/>image: v1.2.3"]
    Manifests --> Flux["Flux v2<br/>GitRepository poll<br/>Kustomization sync"]
    Flux --> K8s["Cluster K8s<br/>(production)<br/>app:v1.2.3"]

Étapes détaillées¶

1. Le développeur pousse du code sur la branche main
2. Gitea declenche le workflow .gitea/workflows/ci.yaml
3. Le runner execute : build → test → scan Trivy → push image vers Harbor
4. Le workflow met a jour le tag d'image dans le dépôt de manifestes (commit automatique)
5. Flux source-controller détecte le changement dans le GitRepository (poll ou webhook via Receiver)
6. Flux kustomize-controller applique le nouvel état desire sur le cluster
7. Les Pods sont recrees avec la nouvelle image

Alternative : image automation¶

Flux peut aussi détecter automatiquement les nouvelles images dans Harbor sans commit CI :

graph LR
    CI["Gitea Actions<br/>Build + Push"] -->|Push image| Harbor["Harbor<br/>app:v1.2.3"]
    Harbor --> ImgRef["image-reflector<br/>scan registre"]
    ImgRef --> ImgAuto["image-automation<br/>commit tag dans Git"]
    ImgAuto --> Git["Depot manifests<br/>(commit auto)"]
    Git --> Flux["kustomize-controller<br/>sync cluster"]

Dimensionnement¶

Gitea Actions runners¶

Flux v2 controllers¶