Sys Labs – 8 Argo CD

Docs: 8.1 Was ist Argo CD

Mon, 01 Jan 0001 00:00:00 +0000

Inhalt

Argo CD Architektur
Argo CD Kernkonzepte

Argo CD

Argo CD ist ein Teil des Argo Projects und gehört zur Cloud Native Computing Foundation (CNCF) . Das Projekt ist vollständig Open Source und hauptsächlich in Go implementiert.

Wie der Name schon sagt, kümmert sich Argo CD um den Continuous-Delivery-Aspekt von CI/CD. Die Continuous Integration wird von einem CI-Tool wie GitLab CI/CD, Jenkins, Tekton oder GitHub Actions übernommen. Der Kern von Argo CD besteht aus einem Kubernetes-Controller, der kontinuierlich den Live-Zustand (live-state) mit dem Soll-Zustand (desired-state) vergleicht. Der Live-Zustand wird über die Kubernetes-API abgegriffen, und der Soll-Zustand wird in Form von Manifesten in YAML oder JSON in einem Git-Repository persistiert. Argo CD hilft dabei, Abweichungen der Zustände aufzuzeigen, die Abweichungen darzustellen oder den Soll-Zustand autonom wiederherzustellen.

Argo CD wird auf einer Kubernetes-basierten Container-Plattform bereitgestellt und betrieben. Es ist möglich, mehrere Kubernetes- und OpenShift-Cluster an eine Argo CD-Instanz anzubinden.

Argo CD ist ein deklaratives GitOps-Continuous-Delivery-Tool für Kubernetes.

GitOps ist eine Methode für das Kubernetes-Cluster-Management und die Applikationsbereitstellung. Es funktioniert, indem es Git als Single Source of Truth für deklarative Infrastruktur und Applikationen nutzt. Mit GitOps kann der Einsatz von Software-Agenten vor jeglicher Abweichung zwischen Git und dem, was in einem Cluster läuft, warnen. Wenn es einen Unterschied gibt, aktualisieren Kubernetes-Reconciler den Cluster automatisch oder führen je nach Fall einen Rollback durch. Mit Git im Zentrum Ihrer Delivery-Pipelines nutzen Entwickler vertraute Tools, um Pull Requests zu erstellen, was sowohl die Applikationsbereitstellung als auch operative Aufgaben in Kubernetes beschleunigt und vereinfacht.

Die Verwaltung von Kubernetes-Ressourcen mit einem GitOps-Ansatz bringt folgende Vorteile:

Die Definition der Manifeste erfolgt deklarativ und ein Tool stellt den Abgleich zwischen Soll- und Live-Manifesten sicher. Die Unterschiede zwischen den gewünschten Konfigurationen und den tatsächlich angewendeten Manifesten sind jederzeit leicht ersichtlich.
Rollbacks auf ältere Versionen sind mit git revert oder über das verwendete GitOps-Tool problemlos möglich (vorausgesetzt, die Applikation unterstützt dies ebenfalls).
Manuelle Anpassungen direkt auf der Container-Plattform sind sofort sichtbar und können automatisch überschrieben werden (Self-Healing).
Die Git-Commit-Historie ist gleichzeitig ein detailliertes Audit-Log.
Die Entwickler beschreiben die Infrastruktur in bereits bekannten Formaten und Tools wie YAML und Git.

Argo CD folgt dem GitOps-Muster und nutzt Git-Repositories als Single Source of Truth, um den gewünschten Applikationszustand zu definieren.

Warnung

Argo CD bietet einen Mechanismus, um die Parameter von Argo CD-Applikationen zu überschreiben. Die Funktion The Argo CD parameter overrides dient hauptsächlich der Bequemlichkeit von Entwicklern und ist für den Einsatz in Dev/Test-Umgebungen gedacht, nicht für Produktionsumgebungen.

Viele betrachten diese Funktion als Anti-Pattern für GitOps. Verwenden Sie diese Funktion also nur, wenn keine andere Option verfügbar ist!

Kubernetes-Manifeste können auf verschiedene Arten spezifiziert werden:

kustomize Applikationen
helm Charts
jsonnet Dateien
Einfaches Verzeichnis mit YAML/JSON-Manifesten
Jedes beliebige benutzerdefinierte Konfigurationsmanagement-Tool, das als Konfigurationsmanagement-Plugin eingerichtet ist

Argo CD automatisiert das Deployment der gewünschten Applikationszustände in den angegebenen Zielumgebungen. Applikations-Deployments können Updates von Branches oder Tags verfolgen oder an eine bestimmte Version von Manifesten bei einem Git-Commit gepinnt werden. Weitere Details zu den verschiedenen verfügbaren Tracking-Strategien finden Sie in der Dokumentation zu Tracking-Strategien.

Für einen kurzen 10-minütigen Überblick über Argo CD sehen Sie sich die Demo an, die beim Sig Apps Community Meeting präsentiert wurde:

Argo CD Architektur

Die Kernkomponenten von Argo CD sind der API-Server, der Repository-Server und der Application Controller.

Bild- und Komponentenbeschreibung Quelle: https://argo-cd.readthedocs.io/en/stable/

API-Server

Der API-Server ist ein gRPC/REST-Server, der die API bereitstellt, welche von der Web-UI, der CLI und den CI/CD-Systemen konsumiert wird. Er hat die folgenden Aufgaben:

Applikationsmanagement und Statusberichte
Aufrufen von Applikationsoperationen (z. B. Sync, Rollback, benutzerdefinierte Aktionen)
Verwaltung von Repository- und Cluster-Anmeldeinformationen (gespeichert als K8s Secrets)
Authentifizierung und Delegierung der Authentifizierung an externe Identity Provider
Durchsetzung von RBAC
Listener/Forwarder für Git-Webhook-Ereignisse

Repository-Server

Der Repository-Server ist ein interner Dienst, der einen lokalen Cache des Git-Repositories mit den Applikationsmanifesten pflegt. Er ist für die Generierung und Rückgabe der Kubernetes-Manifeste verantwortlich, wenn ihm die folgenden Eingaben zur Verfügung gestellt werden:

Repository-URL
Revision (Commit, Tag, Branch)
Applikationspfad
Templatespezifische Einstellungen: Parameter, Ksonnet-Umgebungen, Helm values.yaml

Application Controller

Der Application Controller ist ein Kubernetes-Controller, der fortlaufend die laufenden Applikationen überwacht und den aktuellen Live-Zustand mit dem gewünschten Zielzustand (wie im Repo angegeben) vergleicht. Er erkennt den OutOfSync-Zustand von Applikationen und leitet optional Korrekturmassnahmen ein. Er ist für den Aufruf aller benutzerdefinierten Hooks für Lifecycle-Ereignisse (PreSync, Sync, PostSync) verantwortlich.

Argo CD Kernkonzepte

Folgende Kernkonzepte existieren in Argo CD:

Cluster: Vorkonfigurierte Kubernetes-Cluster (einschliesslich OpenShift)
Repositories : Vorkonfigurierte Git-Repositories, einschliesslich der Anmeldeinformationen (SSH, Benutzername/Passwort).
Applikationen (Applications) : Eine Gruppe von Kubernetes-Ressourcen, abgebildet in einem Git-Repository. Gewöhnlich die Kubernetes-Ressourcen, die in einem Kubernetes-Namespace angewendet werden. Dargestellt als CRD .
Projekte (Projects) : Eine logische Gruppierung von Argo CD-Applikationen. Auf Projektebene können verschiedene Restriktionen definiert werden. Nützlich, wenn mehrere Teams mit derselben Argo CD-Instanz arbeiten.

Docs: 8.2 GitLab Repo aufsetzen

Mon, 01 Jan 0001 00:00:00 +0000

Inhalt

Git Repo aufsetzen

Git Repo aufsetzen

Für dieses Lab werden wir das Puzzle interne Argo CD, GitLab und OpenShift verwenden. Die Argo CD Anbindung ist Puzzle spezifisch und in unseren Docs dokumentiert.

Argo CD verwendet als Single Source of Truth ein Git Repo, deshalb müssen wir für dieses Lab zuerst ein neues Git Repo im GitLab BBT Projekt erstellen.

Nenne das Projekt <username>-argocd-lab.

Wenn das leere Repo erstellt ist, kann es dann lokal geklont werden und im bevorzugten Editor geöffnet werden.

Docs: 8.3 Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Deployment erstellen

Damit Argo CD alles findet, müssen im Repo die richtigen Ordner und Dateien angelegt werden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


.
├── argocd
│   └── values.yaml
└── deployments
    ├── base
    │   ├── kustomization.yaml
    │   ├── deployment.yaml
    │   └── service.yaml
    └── overlays
    └── dev
    └── kustomization.yaml

Der argocd-Ordner enthält die Argo CD-Konfiguration und der deployments Ordner enthält die kustomize basierten Manifeste.

Für dieses Lab werden die gleichen Ressourcen verwendet wie im OpenShift Lab. Hier werden wir sie jedoch nicht von Hand anwenden, sondern via Argo CD.

Jetzt kannst du die Dateien im Ordner deployments/base abfüllen mit den folgenden Manifesten:

deployments/base/deployment.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
 app: example-web-go
 name: example-web-go
spec:
 replicas: 1
 selector:
 matchLabels:
 app: example-web-go
 template:
 metadata:
 labels:
 app: example-web-go
 spec:
 containers:
 - image: quay.io/acend/example-web-go:latest
 name: example-web-go
 resources:
 requests:
 cpu: 10m
 memory: 16Mi
 limits:
 cpu: 20m
 memory: 32Mi

deployments/base/service.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


apiVersion: v1
kind: Service
metadata:
 labels:
 app: example-web-go
 name: example-web-go
spec:
 ports:
 - port: 5000
 protocol: TCP
 targetPort: 5000
 selector:
 app: example-web-go
 type: ClusterIP

Kustomize

Damit Argo CD alle Ressourcen anziehen kann, verwenden wir Kustomize .

Dafür definierst du im deployment/base/kustomization.yaml alle Dateien, die im base Ordner sind, als Ressource:

1
2
3
4
5
6


apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
 - deployment.yaml
 - service.yaml

Danach passe deployment/overlays/dev/kustomization.yaml so an, dass die base angezogen wird:

1
2
3
4
5


apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
 - ../../base

Argo CD

Wenn du das jetzt committen würdest, würde noch nichts passieren und das liegt daran, dass die Argo CD Konfiguration noch leer ist. Alle möglichen Konfigurations Möglichkeiten sind auf docs.puzzle.ch dokumentiert. Passe argocd/values.yaml folgendermassen an:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


environments:
- namespace: pitc-bbt-<username>-dev
 name: <username>-dev

 spoc: bbt_AT_puzzle_ch
 sla: nonprod
 customer: pitc

 argocd:
 kustomize:
 path: overlays/dev

Mit all diesen Änderungen kannst du jetzt alles im Repo committen.

1
2
3


git add argocd deployments
git commit -m "create new deployment"
git push

Nachdem alles committet ist, sollte innerhalb von wenigen Minuten die Applikation auf Argo CD auftauchen und kurz später auch im OpenShift .

Prod

Für fast alle Applikationen will man mehr als eine Umgebung deployen. In diesem Beispiel hast du bis jetzt eine dev Umgebung erstellt. Als nächstes kommt noch eine Prod Umgebung dazu. Dafür müssen zwei Sachen angepasst werden.

Argo CD Konfiguration erweitern:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


environments:
- namespace: pitc-bbt-<username>-dev
 name: <username>-dev

 spoc: bbt_AT_puzzle_ch
 sla: nonprod
 customer: pitc

 argocd:
 kustomize:
 path: overlays/dev
- namespace: pitc-bbt-<username>-prod
 name: <username>-prod

 spoc: bbt_AT_puzzle_ch
 sla: nonprod
 customer: pitc

 argocd:
 kustomize:
 path: overlays/prod

deployment/overlays/prod/kustomization.yaml erstellen mit diesem Inhalt:

1
2
3
4
5


apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
 - ../../base

Wenn du diese Änderungen dann committest, sollte innerhalb von ein paar Minuten die neue Umgebung hochkommen.

Route

Jetzt hast du eine Applikation in zwei Umgebungen deployed, aber keine von beiden ist erreichbar. Dazu kommt noch, dass nicht beide Umgebungen die gleiche Route verwenden können.

Als erstes erstelle die Route im base Ordner:

route.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


apiVersion: route.openshift.io/v1
kind: Route
metadata:
 name: example-web-go
spec:
 # Wird dann später via Kustomize überschrieben
 host: placeholder
 port:
 targetPort: 5000
 to:
 kind: Service
 name: example-web-go
 weight: 100
 wildcardPolicy: None
 tls:
 insecureEdgeTerminationPolicy: Redirect
 termination: edge

Danach muss die Route im deployment/base/kustomization.yaml angezogen werden:

1
2
3
4
5
6
7


apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
 - deployment.yaml
 - route.yaml
 - service.yaml

Und am Schluss muss noch die Route je nach Umgebung gepatched werden:

deployment/overlays/dev/kustomization.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
 - ../../base

patches:
- target:
 version: v1
 kind: Route
 name: example-web-go
 patch: |-
 - op: replace
 path: /spec/host
 value: <username>-dev.ocp-internal.cloudscale.puzzle.ch 

deployment/overlays/prod/kustomization.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
 - ../../base

patches:
- target:
 version: v1
 kind: Route
 name: example-web-go
 patch: |-
 - op: replace
 path: /spec/host
 value: <username>-prod.ocp-internal.cloudscale.puzzle.ch 

Wichtig

Diese Route ist nur im Puzzle-internen Netz erreichbar

Da wir die Applikation jetzt deployed haben, sollten wir Änderungen nicht mehr direkt auf main committen, sondern einen Pullrequest erstellen und den dann mergen.