CI/CD Strategie: Gitea Actions & ArgoCD

Diese Strategie trennt den Build-Prozess (CI) strikt vom Deployment-Prozess (CD).

Der Workflow

1. Code Change (CI):

   • Du pushst Code in ein App-Repo (z.B. stabify/whoami).
   • Gitea Actions springt an.
   • Der Code wird getestet und ein Docker Image gebaut.
   • Das Image wird in die Container Registry gepusht (z.B. harbor.stabify.de/library/whoami:v1.0.1).

2. Config Change (GitOps):

   • Um das neue Image zu deployen, änderst du den Tag im GitOps Repo (stabify/gitops).
   • Datei: apps/whoami/overlays/production/kustomization.yaml -> newTag: v1.0.1.
   • Du commitest und pushst diese Änderung.

3. Deployment (CD):

   • ArgoCD (läuft im Cluster) bemerkt den neuen Commit im GitOps Repo.
   • ArgoCD vergleicht IST-Zustand (Cluster) mit SOLL-Zustand (Git).
   • ArgoCD führt das Update durch (Rolling Update).

---

Repository Struktur (Simuliert in diesem Ordner)

1. repo-app-source

Hier liegt der Quellcode deiner Anwendung.

• Enthält den Source Code (Go, Node, Python...).
• Enthält das Dockerfile.
• Enthält die .gitea/workflows/ci.yaml Pipeline Definition.

2. repo-gitops

Hier liegt der Zustand deines Clusters.

• bootstrap/: Der Einstiegspunkt für ArgoCD ("App of Apps").
• cluster/production/: Definiert, WELCHE Apps auf dem Produktions-Cluster laufen sollen.
• apps/: Enthält die eigentlichen K8s Manifeste (Deployments, Services, Ingress).
  • Wir nutzen Kustomize (Base/Overlay Struktur).
  • Base: Allgemeine Definition der App.
  • Overlay: Umgebungsspezifische Anpassungen (z.B. Hostnames, Replicas, Image Tags für Prod).

Vorteile dieser Struktur

• Sicherheit: CI Server braucht keinen Cluster-Zugriff.
• Übersicht: Das GitOps Repo ist die "Single Source of Truth".
• Wiederherstellbarkeit: Cluster kaputt? Einfach ArgoCD installieren, auf das Repo zeigen, warten -> Fertig.