Verwendung von Flux zur Implementierung von GitOps auf AWS

  • 399-Ansichten
  • 18-Minutenlesung
Hadi Bahadori
  • 8. April 2024
0 Aktien
0
0
0
0
0
Aktien
0
0
0
0

Einführung

Viele Unternehmen setzen Kubernetes produktiv ein, sind aber oft unsicher, wie sie Continuous Deployment, hohe Sicherheit, Berechtigungsisolation und Auditing realisieren können – und gleichzeitig die Agilität ihres Geschäftsbetriebs mit mehreren parallel laufenden Kubernetes-Clustern in unterschiedlichen Phasen gewährleisten. GitOps ermöglicht Continuous Deployment auf Basis von Kubernetes-Clustern und erfüllt dabei die Anforderungen von Unternehmen wie Sicherheit und Berechtigungsisolation.

In diesem Blogbeitrag implementieren wir GitOps in einer Amazon-EKS-Umgebung mit AWS CodeCommit, AWS CodePipeline und Flux. Wir zeigen detailliert, wie Sie einen GitOps-Workflow einrichten, der die Produktionsanforderungen in dieser Amazon-EKS-Umgebung erfüllt, und demonstrieren, wie Microservices-Anwendungen Continuous Integration und Continuous Delivery in einer GitOps-basierten CI/CD-Pipeline realisieren.

Voraussetzungen
  • AWS-Erfahrung
  • AWS-Konto

Was ist GitOps?

GitOps ist eine Methode zur kontinuierlichen Bereitstellung von Cloud-Anwendungen. Sie konzentriert sich auf eine entwicklerzentrierte Benutzererfahrung und nutzt die Infrastruktur mithilfe von Tools, mit denen Entwickler bereits vertraut sind – darunter Git und Continuous-Deployment-Tools.

Die Grundidee von GitOps besteht darin, ein Git-Repository zu führen, das stets eine detaillierte Beschreibung der Produktionsinfrastruktur enthält, sowie einen automatisierten Prozess, der die Produktionsumgebung an den im Repository beschriebenen Zustand anpasst. Um eine neue Anwendung bereitzustellen oder eine bestehende zu aktualisieren, muss lediglich das Repository aktualisiert werden. Der automatisierte Prozess kümmert sich um den Rest. Es ist, als hätte man einen Tempomat für die Verwaltung der Produktionsanwendungen.

Warum GitOps verwenden?

Git ist die einzige verlässliche Quelle für den Systemzustand. Es unterstützt wiederholbare und automatisierte Bereitstellungen, Clusterverwaltung und Überwachung. Entwickler nutzen die im Unternehmen etablierten Git-Workflows für Builds, Tests, Scans und andere Schritte der kontinuierlichen Integration. Sobald der aktuelle Systemzustand im Master-Branch des Git-Repositorys gespeichert ist, wird die GitOps-Toolchain verwendet, um die Bereitstellung zu überprüfen, Warnmeldungen anzuzeigen und Fehler zu beheben. Basierend auf den Kernprinzipien von GitOps sind wir überzeugt, dass GitOps die beste Methode für die kontinuierliche Bereitstellung von Kubernetes-Clustern ist. Der Prozess verläuft wie folgt:


Amazon EKS-basierte Best Practices für GitOps

Die gesamte CI/CD-Pipeline wird gemäß den Best Practices in der folgenden Abbildung dargestellt.


Im AWS CodeCommit-Repository befinden sich drei Code-Repositories. Eines davon ist… flux-repo ist das Konfigurations-Repository für Flux CD, das zur Definition von Ressourcen verwendet wird, die mit Fluss Das zweite Repository ist microservices-repo, in dem die Konfigurationen und Bereitstellungsdateien der Microservices-Anwendungen gespeichert sind. Das dritte Repository ist die Quellcode-Anwendung für Geschäftsdienste. In diesem Beitrag wird ein Frontend-Projekt als Beispiel verwendet. Für die kontinuierliche Integration in der Pipeline nutzen wir AWS CodePipeline. CI/CD Wir haben das Docker-Image verwendet in Amazon ECR Wir haben immer wieder gespeichert und die Flux CD-Engine schließlich als Pod in der Amazon EKS-Umgebung bereitgestellt.

Der grundlegende Arbeitsablauf ist:
  • Die Programmierer schreiben den Code und laden den fertigen Code in das App-Repository hoch.
  • Codeänderungen im App-Repository lösen AWS CodePipeline aus.
  • AWS CodePipeline bearbeitet und verpackt den Code, generiert Container-Images und lädt diese in das Container-Image-Repository/Amazon ECR hoch.
  • Die Flux CD-Engine, die in der EKS-Umgebung läuft, scannt regelmäßig das ECR-Container-Image-Repository und ruft Container-Image-Metadaten für Anwendungen ab.
  • Die URL des neuen Container-Images wird automatisch mit der im microservices-repo gespeicherten Anwendungsbereitstellungsdatei über git commit/push synchronisiert, sobald eine neue Version des Container-Images erkannt wird.
  • Flux lädt regelmäßig Anwendungskonfigurationen und Bereitstellungsdateien aus dem Flux-Repository herunter. Da das Flux-Repository auf das Microservices-Repository verweist, prüft Flux die Übereinstimmung des Ausführungszustands der Cluster-Workloads mit den in den Microservices-Repository-Dateien beschriebenen Erwartungen. Bei Abweichungen synchronisiert Flux den EKS-Cluster automatisch, um sicherzustellen, dass die Workloads im erwarteten Zustand ausgeführt werden.

Nachdem wir das Konzept von GitOps und die CI/CD-Pipeline-Architektur erläutert haben, werden wir anhand eines Fallbeispiels die folgenden vier Module durchgehen:

  • Bereitstellung von Cloud-Infrastruktur mittels Infrastructure as Code (IaC)
  • Flux CD auf einem AWS EKS-Cluster bereitstellen
  • Implementieren Sie GitOps-Workflows mit Flux CD
  • Automatisierte Bereitstellung auf Basis von Images mithilfe von GitOps-Workflows

1. Bereitstellung von Cloud-Infrastruktur mit IaC

Ein Grundprinzip von DevOps ist, dass Infrastruktur und Code gleichwertig sind. Infrastructure as Code (IaC) nutzt Code, um die Bereitstellung von Cloud-Infrastruktur und die Verwaltung von Cloud-Umgebungen zu ermöglichen. Entwickler definieren die Infrastruktur mithilfe von Konfigurationsdateien oder Code und erstellen sie, um Konsistenz und Reproduzierbarkeit zu gewährleisten. Mit IaC verwalten sie auch den Ressourcenlebenszyklus, beispielsweise durch das Speichern von Infrastrukturdefinitionen in Versionskontrollsystemen und den Einsatz von Continuous Integration/Deployment (CI/CD), das mit der Programmierung konsistent ist. So können Änderungen an der IaC-Definition vorgenommen und die Umgebungen (z. B. Entwicklung, Test, Produktion) mit den IaC-Codeänderungen koordiniert werden. Darüber hinaus ist im Fehlerfall ein automatisches Rollback möglich, und die Drifterkennung hilft, Abweichungen vom erwarteten Zustand zu identifizieren.

In der Cloud können Softwareentwickler das AWS Cloud Development Kit (CDK) nutzen, um ihr Infrastrukturmodell mit Python, Java und TypeScript zu erstellen. Das CDK bietet erweiterte Komponenten, sogenannte Constructs, die Cloud-Ressourcen mit gültigen Standardwerten vorkonfigurieren. Darüber hinaus können Entwickler eigene, benutzerdefinierte Constructs erstellen und teilen, um sie an die Bedürfnisse ihres Unternehmens anzupassen. All dies beschleunigt Projekte.

1.1 Erstellen eines Projekts mit der CDK CLI

Ein TypeScript CDK-Projekt mit cdk init Create erstellt die Ordnerstruktur und installiert die vom TypeScript CDK-Projekt benötigten Module.

cdk init --language typescript

1.2 Erstellen eines EKS-Clusters mit EKS Blueprints

EKS Blueprints helfen Ihnen beim Aufbau vollständiger EKS-Cluster, die mit der benötigten Betriebssoftware für die Bereitstellung und Ausführung von Workloads ausgestattet sind. Mit EKS Blueprints beschreiben Sie die Konfiguration für den gewünschten Zustand Ihrer EKS-Umgebung, z. B. das Control Panel, Worker-Knoten und Kubernetes-Add-ons, als IaC-Blueprint. Sobald Sie einen Blueprint konfiguriert haben, können Sie ihn verwenden, um mithilfe kontinuierlicher Automatisierung konsistente Umgebungen über mehrere AWS-Konten und -Regionen hinweg bereitzustellen.

Mit EKS Blueprints können Sie ganz einfach einen EKS-Cluster mit Amazon EKS-Plugins sowie einer Vielzahl beliebter Open-Source-Plugins einrichten, darunter Prometheus, Karpenter, Nginx, Traefik, AWS Load Balancer Controller, Fluent Bit, Keda, ArgoCD und viele mehr. EKS Blueprints unterstützt Sie außerdem bei der Implementierung der erforderlichen Sicherheitskontrollen, um Workloads mehrerer Teams auf einem Cluster auszuführen.

Verzeichnis Schnellstart Erstellen Sie die folgenden Codes und führen Sie sie anschließend aus, um die Projektabhängigkeiten zu installieren.

mkdir quickstart
cd quickstart
npm install @aws-quickstart/eks-blueprints

lib/quickstart-stack.ts Öffnen Sie den Code und geben Sie ihn ein. EKS-Baupläne Fügen Sie Folgendes hinzu.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as blueprints from '@aws-quickstart/eks-blueprints';
import { KubernetesVersion } from 'aws-cdk-lib/aws-eks';
export class QuickstartStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const account = props?.env?.account!;
const region = props?.env?.region!;
const clusterProvider = new blueprints.GenericClusterProvider({
version: KubernetesVersion.V1_23,
managedNodeGroups: [
{
id: "default-ng",
desiredSize: 2,
minSize: 1,
maxSize: 2,
}
]
});
const cluster = blueprints.EksBlueprint.builder()
.clusterProvider(clusterProvider)
.account(account)
.region(region)
.addOns(
new blueprints.AwsLoadBalancerControllerAddOn,
)
.teams();
}
}

Im vorherigen Schritt haben wir einen EKS-Cluster erstellt, seine NodeGroup definiert und das AwsLoadBalancerController-Plugin hinzugefügt.


Obwohl die Bereitstellung eines Stacks mit dem CDK-Befehlszeilentool praktisch ist, empfehlen wir die Einrichtung einer automatisierten Pipeline für die Bereitstellung und Aktualisierung Ihrer EKS-Infrastruktur. Dies vereinfacht die Bereitstellung von Entwicklungs-, Test- und Produktionsumgebungen in verschiedenen Regionen.

CodePipelineStack ist ein Framework für die kontinuierliche Bereitstellung von AWS CDK-Anwendungen. Sobald der Quellcode einer AWS CDK-Anwendung in Git hochgeladen wird, erstellt, testet und führt der Stack automatisch neue Versionen aus. Beim Hinzufügen neuer Stufen oder Stacks konfiguriert sich CodePipelineStack automatisch neu, um diese neuen Stufen oder Stacks bereitzustellen.

Als Nächstes führen wir den Befehl cdk deploy aus, um den Stack bereitzustellen.

Zum Schluss haben wir mit einem Befehl überprüft, ob der Application Load Balancer erfolgreich installiert wurde.

$ kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
aws-load-balancer-controller-6bd49cfb7-2cvlk 1/1 Running 0 5m31s
aws-load-balancer-controller-6bd49cfb7-7lcwd 1/1 Running 0 5m31s
aws-node-9hsvz 1/1 Running 0 99m
coredns-66cb55d4f4-gdcqg 1/1 Running 0 106m
coredns-66cb55d4f4-gmzjt 1/1 Running 0 106m
kube-proxy-wr5jn 1/1 Running 0 99m

1.3 Zusammenfassung

In diesem Abschnitt haben wir das Konzept von IaC vorgestellt und einen benutzerdefinierten EKS-Cluster mit CDK erstellt, während wir das AWS Application Load Balancer-Plugin installiert haben. Dies ist eine Voraussetzung für den zukünftigen Zugriff auf Microservices-Webseiten. Nachfolgend finden Sie eine Zusammenfassung dieses Abschnitts:

  • Ein CDK-Projekt wurde mit cdk init gestartet.
  • Durch Hinzufügen des AWS Application Load Balancer-Plugins konnte schnell ein EKS-Cluster mit EKS Blueprint definiert werden.

2. FluxCD auf einem Amazon EKS-Cluster bereitstellen

Flux CD ist ein Continuous-Delivery-Tool, das von Weaveworks entwickelt und als Open Source für die CNCF veröffentlicht wurde. Es ist heute aufgrund seiner einfachen Einrichtung und der Fähigkeit, Kubernetes-Änderungen zu erkennen, weit verbreitet. Eine seiner wichtigsten Funktionen ist die deklarative Verwaltung von Kubernetes-Deployments. Flux CD synchronisiert die im Quellcode-Repository gespeicherten Kubernetes-Manifestdateien mit dem Kubernetes-Cluster durch regelmäßiges Abfragen des Repositorys. So stellt Flux CD sicher, dass der Kubernetes-Cluster stets mit der im Quellcode-Repository definierten Konfiguration übereinstimmt, ohne dass der Betriebsstatus von kube ctl oder die Überwachung von Workloads mit zusätzlichen Tools und Diensten berücksichtigt werden muss. Installieren wir also Flux.

2.1 Installation der Flux CLI

Flux CLI ist eine ausführbare Binärdatei für alle Plattformen, die Sie von der GitHub-Releaseseite herunterladen können.

curl -s https://fluxcd.io/install.sh | sudo bash

2.2 AWS CodeCommit-Zugangsdaten vorbereiten

Wir müssen einen Benutzer anlegen und CodeCommit als Git-Quelle verwenden sowie die von AWS CodeCommit benötigten Zugriffsrechte über HTTPS-Git-Anmeldeinformationen bereitstellen.

2.3 Flux auf dem Cluster installieren

Klonen Sie den vorbereiteten GitOps-Code. Die Projektstruktur sieht wie folgt aus:

.
├── apps // Define Application
│ ├── base // Application Infrastructure Layer
│ └── overlays // Application Overlays Layer
├── clusters // Cluster configuration portal
│ └── dev-cluster
├── infrastructure // Infrastructure Shared Components
│ ├── base // Infrastructure Infrastructure layer
│ └── overlays // Infrastructure Overlays layer
└── README.md

Installieren Sie Flux auf Ihrem Kubernetes-Cluster und konfigurieren Sie es für die Verwaltung aus einem Git-Repository mit Flux-Bootstrapping. Sind Flux-Komponenten im Cluster vorhanden, führt der Bootstrapping-Befehl bei Bedarf Aktualisierungen durch. Das Bootstrapping ist selbstverständlich ohne Berechtigungen und kann bedenkenlos mehrmals ausgeführt werden. Ersetzen Sie Benutzername und Passwort im folgenden Befehl durch Ihre HTTPS-Git-Zugangsdaten für AWS CodeCommit.

flux bootstrap git \ 
--url=https://git-codecommit.us-west-2.amazonaws.com/v1/repos/gitops \ 
--username=__replace_with_your_Git_credential_username__ \ 
--password=__replace_with_your_Git_credential_password__ \ 
--token-auth=true \ 
--path="./clusters/dev-cluster" \ 
--components-extra=image-reflector-controller,image-automation-controller

Verwenden Sie `git pull`, um die vom Bootstrapper vorgenommenen Aktualisierungen zu überprüfen. Drei neue Dateien erscheinen im Verzeichnis `clusters/dev-cluster/flux-system` des Git-Repositorys:

  • gotk-components.yaml: Definiert sechs Flux-Controller: helm, Kustomize, source, notification, image automation und image reflector.
  • gotk-sync.yaml: Git Flux-Quelle, Quellcode-Controller überwacht Änderungen im Cluster, den Code im GitOps-Repository und committet die entsprechenden Änderungen.
  • kustomization.yaml: Multi-Cluster-Konfiguration.

Überprüfen Sie mit `flux get kustomizations --watch`, ob Flux erfolgreich installiert wurde. Die Ausgabe sollte in etwa so aussehen:

$ flux get kustomizations --watch
NAME REVISION SUSPENDED READY MESSAGE 
flux-system master/83b7e66 False True Applied revision: master/83b7e66
infrastructure master/83b7e66 False True Applied revision: master/83b7e66

Überprüfen Sie die von flux-system bereitgestellten Komponenten mit kubectl -n flux-system get pod,services. Die Ausgabe sieht wie folgt aus:

$ kubectl -n flux-system get pod,services
NAME READY STATUS RESTARTS AGE
pod/helm-controller-88f6889c6-sblvd 1/1 Running 0 11m
pod/image-automation-controller-6c5f7bbbd9-8xskk 1/1 Running 0 11m
pod/image-reflector-controller-78949bb4b4-bqn4m 1/1 Running 0 11m
pod/kustomize-controller-784bd54978-s82dq 1/1 Running 0 11m
pod/notification-controller-648bbb9db7-627zs 1/1 Running 0 11m
pod/source-controller-79f7866bc7-gdt95 1/1 Running 0 11m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/notification-controller ClusterIP 172.20.60.72 <none> 80/TCP 11m
service/source-controller ClusterIP 172.20.133.44 <none> 80/TCP 11m
service/webhook-receiver ClusterIP 172.20.196.178 <none> 80/TCP 11m

2.4 Zusammenfassung

In diesem Abschnitt haben wir den Befehl `flux bootstrap` verwendet, um Flux auf einem Kubernetes-Cluster zu installieren, und drei wichtige Konfigurationsdateien vorgestellt: `gotk-components.yaml`, `gotk-sync.yaml` und `kustomization.yaml`. Nachfolgend eine Zusammenfassung dieses Abschnitts:

  • Installation des Flux-Clients
  • Erstellen eines IAM-Benutzers und CodeCommit-Anmeldeinformationen
  • Installieren Sie Flux auf einem Amazon EKS-Cluster und aktivieren Sie die automatische Image-Aktualisierungsfunktion.

3. Implementieren Sie GitOps-Workflows mit Flux CD

Bei GitOps CI/CD-Pipelines werden Konfigurations- und Zustandsänderungen an EKS-Clustern und den darauf laufenden Workloads durch Codeänderungen in Git (generiert durch `git push` oder `git pull`-Requests; GitOps empfiehlt Pull-Requests) ausgelöst. Die traditionelle CI/CD-Pipeline arbeitet mit der CI-Engine und führt den `kubectl`-Befehl `create/apply` oder `install/upgrade` aus, um den Cluster bereitzustellen. GitOps ermöglicht somit eine effizientere und kompaktere CI/CD-Pipeline.

Wir werden eine konkrete Anwendung – “Sock Shop” – und praktische Übungen demonstrieren, um zu zeigen, wie man Continuous Integration und Continuous Delivery in einer GitOps CI/CD-Pipeline erreicht.

3.1 Über den Sockenladen

Wir verwenden den benutzerseitigen Teil eines Online-Sockenshops als Beispiel. Er basiert auf Spring Boot, Go Kit und Node und ist in Docker-Containern verpackt. Wie eine “Microservice Standard Demo” zeigt:

  • Bewährte Vorgehensweisen für die Bereitstellung von Microservices (einschließlich Beispielen für Fehler)
  • Plattformübergreifende Bereitstellungsfunktionen
  • Vorteile der kontinuierlichen Integration/Bereitstellung
  • Die komplementäre Natur von DevOps und Microservices
  • Eine testbare “echte” Anwendung für verschiedene Orchestrierungsplattformen

Das Projekt „Socks Store“ besteht aus acht Frontend- und Backend-Microservices. Das Frontend einer Webseite wurde mit NodeJS erstellt und trägt den Projektnamen „front-end here“. Es greift über HTTP-Anfragen auf verschiedene Backend-Dienste zu, darunter Bestellwesen, Zahlung, Benutzerverwaltung, Produktverwaltung und Warenkorb. Die Daten der Backend-Dienste werden in MongoDB und MySQL gespeichert.

Die Referenzarchitektur sieht wie folgt aus:


3.2 Über Kustomize

Neben der Einrichtung von GitOps-Workflows ist auch die Konfiguration von Kubernetes unerlässlich. Mit zunehmender System- und Umgebungskomplexität wird die traditionelle, YAML-basierte Ressourcenverwaltung immer schwieriger. Komplexe Anwendungsfälle, mehrere Umgebungen (Entwicklung, Test, Vorabversion, Produktion) und eine große Anzahl von YAML-Ressourceninventaren müssen verwaltet werden. Helm löst zwar einige Probleme, wie die einheitliche Verwaltung verteilter Ressourcendateien, Anwendungsverteilung, Upgrades und Rollbacks, erschwert aber den Umgang mit kleineren Unterschieden zwischen Umgebungen. Zudem erfordert es die Beherrschung der komplexen DSL (Template Syntax), was eine hohe Einstiegshürde darstellt. Aus diesem Grund wurde das deklarative Konfigurationsmanagement-Tool Kustomize entwickelt. Kustomize unterstützt Teams bei der Verwaltung großer Mengen von YAML-Kubernetes-Ressourcen über verschiedene Umgebungen und Teams hinweg. Dies ermöglicht es Teams, kleinere Unterschiede zwischen Umgebungen effizient zu handhaben, Ressourcenkonfigurationen wiederverwendbar zu machen, den Aufwand für Kopieren und Ändern zu reduzieren und Konfigurationsfehler deutlich zu minimieren. Der gesamte Anwendungskonfigurationsprozess erfordert keine zusätzlichen Kenntnisse der Template Syntax.

Kustomize löst die oben genannten Probleme auf folgende Weise:
  • Kustomize verwaltet die Anwendungskonfiguration über verschiedene Umgebungen hinweg mittels Base & Overlays.
  • Kustomize verwendet Patch, um die Basiskonfiguration und -implementierung wiederzuverwenden, und die Quellcode-Wiederverwendung wird durch den Differenzabschnitt zwischen der Overlay-Beschreibung und der Basis-Anwendungskonfiguration erreicht.
  • Kustomize verwaltet native Kubernetes-YAML-Dateien, ohne dass die Syntax einer DSL erlernt werden muss.

Laut der offiziellen Website hat sich Kustomize zu einem nativen Konfigurationsmanagement-Tool für Kubernetes entwickelt, mit dem Benutzer Anwendungseinstellungen ohne Vorlagen anpassen können. Kustomize nutzt native Kubernetes-Konzepte, um die Erstellung und Wiederverwendung von Quellkonfigurationen (YAML) zu unterstützen. Benutzer können eine Anwendungsbeschreibungsdatei (YAML) als Basis (Base YAML) verwenden und anschließend mithilfe von Overlays die benötigte Beschreibungsdatei für die endgültig bereitgestellte Anwendung generieren.


3.3 Multi-Cluster-Konfiguration

Wir verstehen das Konfigurationsmanagement-Tool Kustomize und nutzen Kustomization (Basis, Overlays), um die Transformation von Multi-Cluster-Bereitstellungen zu ermöglichen.

Wir haben im Microservice-Projekt zwei Verzeichnisse erstellt: das Basisverzeichnis zum Speichern der vollständigen Quellkonfigurationsdateien (YAML) und das Overlays-Verzeichnis zum Speichern verschiedener Umgebungen oder differenzieller Clusterkonfigurationen.

In diesem Fall heißt die vollständige Konfigurationsdatei für den Microservice beispielsweise full-demo.yaml und wir kopieren sie in den Hauptordner.

cp deploy/kubernetes/complete-demo.yaml deploy/kubernetes/base/complete-demo.yaml

Anschließend referenzieren wir die Datei über kustomization.yaml:

# deploy/kubernetes/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./complete-demo.yaml

Für die Entwicklungsumgebung gilt: Falls abweichende Anforderungen bestehen, wie z. B. die Änderung der Anzahl der Service-Ports und Kopien, konfigurieren Sie die abweichenden Einstellungen einfach in der Datei overlays/development/kustomization.yaml, ohne die bestehende Datei full-demo.yaml zu kopieren und zu ändern.

3.4 Bereitstellung von Microservices mit dem GitOps-Workflow

Nach der Implementierung der Multi-Cluster-Unterstützung für Microservices muss Flux wissen, dass sich die Microservices-Konfiguration geändert hat. Daher registrieren wir die CodeCommit-URL des Microservices-Repositorys (microservices-repo) im Flux-Repository (flux-repo).

3.4.1 Hinzufügen der Adresse des Microservices-Repositorys

Wir kehren zum Flux-Repository im Ordner application layer/applications zurück:

.
├── base
│ ├── kustomization.yaml
│ └── sock-shop
│ ├── kustomization.yaml
│ ├── namespace.yaml
│ ├── rbac.yaml
│ └── tenant.yaml
└── overlays
└── development
├── kustomization.yaml
└── sock-shop
└── kustomization.yaml

Öffnen Sie die Datei tenant.yaml im Verzeichnis apps/base/sock-shop/ und ersetzen Sie MICRO_SERVICES_REPO durch die Microservices-URL: https://git-codecommit.xxx.amazonaws.com/v1/repos/microservices-repo.

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
name: sock-shop-tenant
namespace: sock-shop
spec:
interval: 1m
url: __MICRO_SERVICES_REPO__
ref:
branch: main
secretRef:
name: microservices-basic-access-auth
......

3.4.2 Hinzufügen von CodeCommit-Anmeldeinformationen

Suchen Sie das Konto und das Passwort für «AWS CodeCommit-Anmeldeinformationen vorbereiten». Konvertieren Sie den Datenwert vor dem Ausführen des Befehls in Base64-Kodierung.

Öffnen Sie anschließend die Datei base/sock-shop/basic-access-auth.yaml und ersetzen Sie BASE64_USERNAME und BASE64_PASSWORD durch die generierte Base64-Kodierung:

---
apiVersion: v1
kind: Secret
metadata:
name: microservices-basic-access-auth
namespace: sock-shop
type: Opaque
data:
username: __BASE64_USERNAME__
password: __BASE64_PASSWORD__

3.4.3 Bereitstellung

Durch Hinzufügen der Git-URL des Microservices zum Flux-Konfigurations-Repository scannt Flux automatisch seine Konfigurationsänderungen. Sobald der Code committet wurde, prüft Flux, ob Microservices im Cluster bereitgestellt sind und ob diese mit der Git-Repository-Definition übereinstimmen. Andernfalls stellt Flux die Microservices automatisch im Cluster bereit.

Nach der Codeausführung führen Sie den Befehl `flux get kustomizations -watch` aus und warten Sie, bis Flux aktualisiert ist. Die Bereitstellung ist abgeschlossen, sobald der Status aller Anpassungen „READY“ lautet.

Suchen Sie nach Pods und Diensten im unten dargestellten Sock-Store-Namensraum:

$ kubectl get pod,service -n sock-shop
NAME READY STATUS RESTARTS AGE
pod/carts-b4d4ffb5c-z4jrj 1/1 Running 0 5m28s
pod/carts-db-6c6c68b747-jl5pd 1/1 Running 0 5m28s
pod/catalogue-759cc6b86-qdmvc 1/1 Running 0 5m28s
pod/catalogue-db-96f6f6b4c-zgp5z 1/1 Running 0 5m28s
pod/front-end-5c89db9f57-cvbdl 1/1 Running 0 5m28s
pod/orders-7664c64d75-lqwbm 1/1 Running 0 5m28s
pod/orders-db-659949975f-qv7pl 1/1 Running 0 5m28s
pod/payment-7bcdbf45c9-szrfq 1/1 Running 0 5m28s
pod/queue-master-5f6d6d4796-nkktx 1/1 Running 0 5m28s
pod/rabbitmq-5bcbb547d7-gzhn4 2/2 Running 0 5m28s
pod/session-db-7cf97f8d4f-9mz6v 1/1 Running 0 5m28s
pod/shipping-7f7999ffb7-95rlc 1/1 Running 0 5m27s
pod/user-68df64db9c-kh247 1/1 Running 0 5m27s
pod/user-db-6df7444fc-jlkp9 1/1 Running 0 5m27s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/carts ClusterIP 172.20.33.124 <none> 80/TCP 5m29s
service/carts-db ClusterIP 172.20.75.163 <none> 27017/TCP 5m29s
service/catalogue ClusterIP 172.20.92.254 <none> 80/TCP 5m29s
service/catalogue-db ClusterIP 172.20.242.255 <none> 3306/TCP 5m29s
service/front-end LoadBalancer 172.20.55.188 k8s-sockshop-frontend-12345678910-012345678910abc.elb.us-east-1.amazonaws.com 80:30001/TCP 5m29s
service/orders ClusterIP 172.20.8.252 <none> 80/TCP 5m29s
service/orders-db ClusterIP 172.20.40.212 <none> 27017/TCP 5m29s
service/payment ClusterIP 172.20.6.218 <none> 80/TCP 5m29s
service/queue-master ClusterIP 172.20.153.80 <none> 80/TCP 5m29s
service/rabbitmq ClusterIP 172.20.99.37 <none> 5672/TCP,9090/TCP 5m29s
service/session-db ClusterIP 172.20.37.111 <none> 6379/TCP 5m29s
service/shipping ClusterIP 172.20.43.252 <none> 80/TCP 5m29s
service/user ClusterIP 172.20.220.174 <none> 80/TCP 5m29s
service/user-db ClusterIP 172.20.70.57 <none> 27017/TCP 5m29s

Greifen Sie auf den DNS-Namen des AWS Load Balancers zu.


3.5 Zusammenfassung

In diesem Abschnitt haben wir die Microservice-Business-Anwendung „Sock Shop“ vorgestellt und ihre Multi-Cluster-Konfiguration abgeschlossen. Außerdem haben wir einen standardmäßigen GitOps-Workflow auf Basis von Flux erstellt, der den Zielcluster automatisch mit Änderungen in den Konfigurationsdateien synchronisiert, um die Bereitstellung des Microservices auf dem EKS-Cluster abzuschließen. Darüber hinaus haben wir das praktische Konfigurationsmanagement-Tool K8s-Kustomize vorgestellt und gezeigt, wie Anwendungsressourcendateien verwaltet werden. Hier ist eine Zusammenfassung dieses Abschnitts:

  • Wir stellen Ihnen den Sockenladen vor
  • Lernen Sie ein Konfigurationsmanagement-Tool kennen – Kustomize (Basis, Overlays) – und wie Sie Multi-Cluster-Microservice-Bereitstellungen ändern.
  • Erstellen Sie einen GitOps-Workflow und stellen Sie Microservices bereit.

4. Automatisierte imagebasierte Bereitstellung mit GitOps-Workflows

Wir haben den Front-End-Mikroservice „Sock Shop“ als Beispiel gewählt, um den detaillierten Prozess von Codeänderungen, Image-Erstellung und benutzerdefinierter Veröffentlichung mit einem GitOps-Workflow zu demonstrieren.

4.1 Definition von CodePipeline CI

Das Frontend ist ein reiner Node.js-Frontend-Dienst zur Unterstützung der Docker-Image-Paketierung (Details dazu finden Sie im Abschnitt „Sock Shop Architect“ in Kapitel 3.1). Um den in CodePipeline ausgeführten CI-Prozess zu definieren, fügen Sie dem Quellcode des Frontend-Projekts eine buildspec.yml-Datei hinzu.

version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws --version
- AWS_ACCOUNT_ID=`echo $REPOSITORY_URI|cut -d"." -f1`
- AWS_DEFAULT_REGION=`echo $REPOSITORY_URI|cut -d"." -f4`
- echo $AWS_ACCOUNT_ID $AWS_DEFAULT_REGION
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $REPOSITORY_HOST
- COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
- IMAGE_TAG=main-$COMMIT_HASH-$CODEBUILD_BUILD_NUMBER
- echo $IMAGE_TAG
build:
commands:
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $REPOSITORY_URI:latest .
- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker images...
- docker push $REPOSITORY_URI:latest
- docker push $REPOSITORY_URI:$IMAGE_TAG

Dieser CI-Prozess erstellt automatisch ein Image und lädt es in das ECR-Repository weaveworksdemos/front-end hoch, sobald sich der Frontend-Code ändert. Das Image-Tag-Format lautet [Branch]-[Commit]-[Build-Nummer].

4.2 Automatische Bildaktualisierung

In agilen Umgebungen mit Continuous Integration, beispielsweise beim Testen der Entwicklung, kann die Aktualisierung des GitOps-Repositorys oder die Verwaltung neuer Service-Images mithilfe von Skripten sehr aufwendig sein. Glücklicherweise bietet Flux eine praktische Funktion zur automatischen Image-Aktualisierung, die Ihnen diese Arbeit abnimmt. Um sie zu nutzen, müssen Sie lediglich die Image-Update-Komponente in Ihrer Konfiguration aktivieren. Falls Sie dies noch nicht getan haben, fügen Sie einfach die Parameter `--components-extra=image-reflector-controller,image-automation-controller` beim Durchlaufen des Flux-Bootstrap hinzu, um die Funktion zu aktivieren.

Um bildbasierte automatische Aktualisierungen zu erreichen, müssen wir die folgenden Schritte durchführen:

  • Registrieren Sie das Front-End-Microservice-Image-Repository, damit Flux den ECR-Image-Repository-Reporter im Front-End-Projekt regelmäßig scannen kann.
  • Konfigurieren Sie die Zugangsdaten für den Zugriff auf das Image-Repository. Flux benötigt Zugangsdaten für den Zugriff auf das ECR-Image-Repository, um Image-Informationen zu lesen.
  • Legen Sie die Image-Aktualisierungsrichtlinie fest. In den meisten Fällen möchten wir nicht, dass jede Änderung an den Image-Versionen jedes Mal einen CD auslöst. Stattdessen soll nur der Code des angegebenen Branches (Root-Branch) einen CD auslösen. Um diese Anforderung zu erfüllen, ist eine spezielle Aktualisierungsrichtlinie erforderlich.

Als Nächstes werden wir die oben genannten Schritte nacheinander durchführen.

4.2.1 Hinzufügen einer Image-Richtlinie zum Frontend eines Git-Repositorys

Im Projekt „microservices-repo“ verwenden wir Kustomization-Overlays in der Entwicklungsumgebung, um das Microservice-Frontend durch eine angepasste und aktualisierte Version zu ersetzen. Bearbeiten Sie die Datei „deploy/kubernetes/overlays/development/kustomization.yaml“. (Hinweis: Ersetzen Sie „ACCOUNT_ID“ durch Ihre „ACCOUNT_ID“).

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
images:
- name: weaveworksdemos/front-end
newName: __ACCOUNT_ID__.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end # {"$imagepolicy": "sock-shop:sock-shop-front-end:name"}
newTag: latest # {"$imagepolicy": "sock-shop:sock-shop-front-end:tag"}

4.2.2 Registrierung des Front-Ends eines Microservice unter Flux-repo

Erstellen Sie im Flux-Repo-Projekt eine neue Datei apps/overlays/development/sock-shop/registry.yaml und ersetzen Sie ACCOUNT_ID durch Ihre ACCOUNT_ID.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
name: sock-shop-front-end
namespace: sock-shop
spec:
image: __ACCOUNT_ID__.dkr.ecr.xxxx.amazonaws.com/weaveworksdemos/front-end
interval: 1m0s

4.2.3 Konfigurieren von Zugangsdaten für Amazon ECR

In Flux gibt es zwei Methoden für Amazon ECR-Anmeldeinformationen.

  • Automatischer Authentifizierungsmechanismus (Image Reflector Controller ruft die Anmeldeinformationen selbst ab, nur für: Amazon ECR, GCP GCR, Azure ACR)
  • Regelmäßiges Abrufen der Anmeldeinformationen (die im Cluster über Secret gespeichert sind) mit CronJob
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- gotk-components.yaml
- gotk-sync.yaml
patches:
- patch: |-
- op: add
path: /spec/template/spec/containers/0/args/-
value: --aws-autologin-for-ecr
target:
version: v1
group: apps
kind: Deployment
name: image-reflector-controller
namespace: flux-system

4.2.4 Festlegen der Image-Aktualisierungsrichtlinie

Fügen Sie die Datei gitops/apps/overlays/development/sock-shop/policy.yaml hinzu. Die folgenden Regeln beziehen sich auf Image-Versionen wie master-d480788-1, master-d480788-2 und master-d480788-3.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
name: sock-shop-front-end
spec:
imageRepositoryRef:
name: sock-shop-front-end
filterTags:
pattern: '^main-[a-fA-F0-9]+-(?P<buidnumber>.*)'
extract: '$buidnumber'
policy:
numerical:
order: asc

Fügen Sie die Datei gitops/apps/overlays/development/sock-shop/image-automation.yaml hinzu. Die Flux-Bildautomatisierung gibt ein Git-Repository für die Anwendungskonfiguration an, einschließlich Branch, Pfad und weiterer Informationen.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
name: sock-shop-front-end
spec:
git:
checkout:
ref:
branch: main
commit:
author:
email: [email protected]
name: fluxcdbot
messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}'
push:
branch: main
interval: 5m0s
sourceRef:
kind: GitRepository
name: sock-shop-tenant
namespace: sock-shop
update:
path: ./deploy/kubernetes/overlays/development
strategy: Setters

4.3 Veröffentlichung und Genehmigung

Wir überprüfen den gesamten automatischen Image-Update-Prozess, indem wir den Frontend-Quellcode modifizieren.

4.3.1 Aktualisieren Sie den Frontend-Code

Ändern Sie die Fußzeile im Frontend und bearbeiten Sie die Datei: front-end/public/footer.html.


4.3.2 CodePipeline prüfen

Codeänderungen im Frontend lösen automatisch die Ausführung von CodePipeline aus.


4.3.3 Bestätigung der Änderung der ECR-Image-Version

Nachdem CodePipeline abgeschlossen ist, melden Sie sich in der Amazon ECR-Konsole an, um die Image-Version weaveworksdemos/front-end zu überprüfen:


4.3.4 Überprüfung der Flussbildinformationen

Überprüfen Sie mithilfe der Flux CLI, ob ImageRepository und ImagePolicy erfolgreich die neueste Version abgerufen haben.

$ flux get images all --all-namespaces
NAMESPACE NAME LAST SCAN SUSPENDED READY MESSAGE 
sock-shop imagerepository/sock-shop-front-end 2022-09-18T14:46:45Z False True successful scan, found 20 tags
NAMESPACE NAME LATEST IMAGE READYMESSAGE 
sock-shop imagepolicy/sock-shop-front-end 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24 True Latest image tag for '267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end' resolved to: master-1f49071-24
NAMESPACE NAME LAST RUN SUSPENDED READY MESSAGE 
sock-shop imageupdateautomation/sock-shop-front-end 2022-09-18T14:43:51Z False True no updates made; last commit 1ff6d91 at 2022-09-18T14:34:40Z

4.3.5 Der Quellcode von Microservices wird automatisch aktualisiert

Flux hat die Frontend-Image-Version automatisch aktualisiert. Der letzte Commit wurde von fluxcdbot durchgeführt und das Image-Tag erfolgreich auf die neueste Version geändert: master-1f49071-24.


4.3.6 Überprüfen der Pod-Image-Version

Überprüfen Sie den Pod-Namen mit `kubectl get pod -n sock-shop | grep front-end`. Prüfen Sie die Pod-Details mit `kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image`. Um zu überprüfen, ob die Image-Version aktualisiert wurde, wird Folgendes angezeigt:

$ kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image:
Image: 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24

4.3.7 Überprüfen Sie, ob die statische Seite auf dem neuesten Stand ist.


4.4 Zusammenfassung

In diesem Abschnitt haben wir den gesamten automatisierten Bereitstellungsprozess auf Basis von Images detailliert beschrieben. Kurz gesagt, nutzen wir die kontinuierliche Überwachungsfunktion von Flux für Image-Repositories. Wird eine Änderung der Image-Version erkannt, wird die Image-Konfiguration im Git-Repository automatisch angepasst und die automatisierte Bereitstellung durch Anbindung an den im vorherigen Abschnitt beschriebenen Standard-GitOps-Workflow abgeschlossen. Zusammenfassend lässt sich dieser Abschnitt wie folgt darstellen:

  • Führen Sie den CI-Prozess über CodePipeline aus, um eine kontinuierliche Integration des Frontend-Codes zu erreichen.
  • Suchen und bearbeiten Sie die Geschäftskonfigurationsdatei mit Flux-Anmerkungen.
  • Konfigurieren Sie die Flux-Image-Update-Richtlinie, um Flux die Überwachung bestimmter Image-Versionen zu ermöglichen und die Bereitstellung vollständig zu automatisieren.

Ergebnis

Dieser Artikel beschreibt die Verwendung von FluxCD zur Automatisierung der Bereitstellung von Microservices in einem Amazon-EKS-Cluster in der Cloud und stellt Best Practices für GitOps-Pipelines vor. GitOps ist eine Methode für Continuous Delivery, die eine Reihe bewährter Vorgehensweisen umfasst. Solange die GitOps-Grundlagen beachtet werden, gibt es keine festen Grenzen für die Entwicklung von CI/CD-Tools.

In diesem Artikel:
,
Beitrag verfasst von:
Folgen
Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Vorheriger Artikel
Nächster Artikel
Das könnte Ihnen auch gefallen