Blog Flux in der Praxis: Installation & Konfiguration

Nachdem wir uns in den letzten beiden Artikeln ArgoCD näher angeschaut haben, widmen wir uns nun Flux, dem zweiten GitOps-Tool im CNCF-Ökosystem.

Auch hier wollen wir einen Blick auf die Installation und das Deployment werfen – wie schon in den vorangegangenen Artikeln anhand einer simplen Demo-Helm-Applikation mit Frontend und Backend in GitLab, die bereits erfolgreich ins Cluster deployed wurde.

Voraussetzungen

Falls ihr auch jetzt direkt mit ausprobieren wollt, benötigt ihr Folgendes:

• Ein Git-Repository mit Source-Code sowie Helm-Charts für frontend und backend
• Eine GitLab Pipeline, in der die Images gebaut und in die GitLab Container Registry gepusht werden
• Ein Kubernetes-Cluster mit Zugriff und einem Namespace demo-app

Installation der Flux CLI & Flux Bootstrap

Bevor wir Flux nutzen können, installieren wir zuerst die CLI – unter macOS beispielsweise via:

brew install fluxcd/tap/flux

Alternative Installationsmöglichkeiten findet ihr hier.

Anders als ArgoCD wird Flux in unserem GitLab-Repository initialisiert. Beim Bootstrap richtet Flux alles ein, um dieses Repository regelmäßig synchronisieren zu können.

Bevor wir mit dem Bootstrappen beginnen können, benötigen wir zunächst ein Personal Access Token (PAT) mit dem Scope api.
Dieses erstellen wir im GitLab Projekt unter Settings → Access Tokens.

Nachdem wir dieses in unserem Terminal via

export GITLAB_TOKEN=<PAT-Passwort>

verfügbar gemacht haben, können wir Flux bootstrappen mit:

flux bootstrap gitlab   --owner=<Name unserer GitLab Group>   --repository=<Name unseres GitLab Repositories>   --branch=main   --path=infrastructure \ # Hier legen wir fest, in welchem Verzeichnis Flux seine Ressourcen im Repository ablegt
  --hostname=<GitLab URL> \ # Solltet ihr gitlab.com nutzt, wird kein Hostname benötigt
  --token-auth

Flux legt nun im angegebenen Verzeichnis einen Ordner flux-system für die benötigten Konfigurationen an und installiert alle nötigen Komponenten im Cluster.

In unserem Repository finden wir im flux-system-Ordner mehrere YAML-Dateien:

• gotk-components.yaml – installiert die Flux-Komponenten (Source Controller, Kustomize Controller, Helm Controller, Notification Controller)
• gotk-sync.yaml – enthält eine GitRepository- und eine Kustomization-Ressource, die dafür sorgen, dass Flux das Repository regelmäßig synchronisiert und sich somit selbst verwaltet
• kustomization.yaml – bindet die beiden oben genannten Dateien über Kustomize ein

Ein Blick in unser Cluster zeigt uns die installierten Komponenten:

• Source Controller: Bindet Git-Repos, Helm-Repos oder Buckets als Quelle ein
• Kustomize Controller: Wendet Kustomize-Patches und Overlays auf Ressourcen an
• Helm Controller: Verwaltet HelmReleases
• Notification Controller: Optional für Alerts und Events

Wie wir in den angelegten Ressourcen sehen können, nutzt Flux Kustomize als integralen Bestandteil seines GitOps-Workflows.
Der Kustomize Controller liest regelmäßig die im Git hinterlegten Kustomization-Definitionen, rendert sie und sorgt dafür, dass der Zustand im Cluster mit der im Repository beschriebenen Konfiguration übereinstimmt.

Deployment unserer Applikation

Nach dem Bootstrap sind alle relevanten Komponenten installiert – und wir können uns nun an das Deployment unserer Demo-Helm-Applikation machen. Hierfür bedarf es der folgenden Schritte:

1. GitRepository als Source anlegen

Damit Flux weiß, wo unsere Helm Charts liegen, legen wir im flux-system-Ordner die Datei gitrepository.yaml an:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: demo-app
  namespace: flux-system
spec:
  interval: 1m
  url: <Pfad zu unserem Repository>
  ref:
    branch: main
  secretRef:
    name: flux-system

Diese Datei referenzieren wir dann in unserer kustomization.yaml, die als zentraler Einstiegspunkt für die Synchronisation dient:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- gotk-components.yaml
- gotk-sync.yaml
- gitrepository.yaml

Nachdem wir diese Anpassungen gepusht und einige Momente abgewartet haben, finden wir in unserem Cluster in den GitRepositories neben dem bereits von Flux bei der Initialisierung angelegten Repository auch unser GitRepository mit dem Namen demo-app.

2. Secret anlegen

Unser Personal Access Token beinhaltet zwar alle Berechtigungen, die wir für unser Deployment benötigen.
Allerdings: Es liegt im Namespace flux-system und ist damit für unsere Applikation im Namespace demo-app nicht nutzbar.

Wir müssen daher ein weiteres Secret im richtigen Namespace anlegen.
In der Praxis wird hierfür in der Regel ein separates Token genutzt, das beispielsweise nur den Zugang zur GitLab Registry zum Pullen der Images erlaubt.

Für unsere Demo-Zwecke nutzen wir jedoch das bereits zu Beginn angelegte Token mit api-Scope und erstellen unser Secret im Terminal via:

kubectl create secret docker-registry regcred   --namespace=<Unser Namespace>   --docker-server=<URL unserer Registry>   --docker-username=<GitLab Username>   --docker-password=<<GitLab PAT-Passwort>   --docker-email=flux-demo@example.com

Nun hat Helm die Berechtigungen, Images aus unserer GitLab Registry zu ziehen.

3. HelmRelease anlegen

Im letzten Schritt machen wir uns nun an das konkrete Deployment.
Hierfür benötigen wir für Backend und Frontend jeweils ein HelmRelease in unserem flux-system-Ordner.

frontend.helmrelease.yaml

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: demo-app-frontend
  namespace: flux-demo
spec:
  interval: 1m
  chart:
    spec:
      chart: ./charts/frontend # Pfad zum Helm-Chart
      sourceRef:
        kind: GitRepository
        name: demo-app
        namespace: flux-system
  values: # Hier können wir die Werte mitgeben, die unser Helm-Chart benötigt
    image:
      repository: <Pfad zum Frontend Image in unserer GitLab Registry>
      tag: <Tag>
    imagePullSecrets:
      - name: regcred

backend.helmrelease.yaml

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: demo-app-backend
  namespace: flux-demo
spec:
  interval: 1m
  chart:
    spec:
      chart: ./charts/backend 
      sourceRef:
        kind: GitRepository
        name: demo-app
        namespace: flux-system
  values: 
    image:
      repository: <Pfad zum Backend Image in unserer GitLab Registry>
      tag: <Tag>
    imagePullSecrets:
      - name: regcred

Nun müssen wir beide Dateien noch in unserer kustomization.yaml referenzieren:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- gotk-components.yaml
- gotk-sync.yaml
- gitrepository.yaml
- frontend.helmrelease.yaml
- backend.helmrelease.yaml

Nach dem Push und einer kurzen Wartezeit sehen wir die frisch deployten Pods in unserem Cluster.

Fazit

Wie wir sehen konnten, lassen sich Anwendungen mit Flux einfach und strukturiert deployen.
Auch der Zugriff auf private Container-Registries (in unserem Fall GitLab) lässt sich dabei problemlos einrichten.

Im nächsten Schritt – und damit im nächsten und letzten Artikel dieser Serie – beschäftigen wir uns näher mit Deployments in verschiedene Umgebungen und werfen einen Blick auf den Image Automation Controller.