Multicloud-Bereitstellung für GitOps mit GitLab: Eine Demo
Wie Multicloud-Kompatibilität GitOps-Workflows unterstützt. Diese Demo zeigt, wie du Anwendungen mit einem gemeinsamen Workflow auf drei Kubernetes-Servern bereitstellst.
GitOps-Workflows verwenden ein Git-Repository als eine einzige Quelle der Wahrheit, um die Zusammenarbeit zu ermöglichen und Infrastrukturteams zusammenzubringen, um die Softwareentwicklung und -bereitstellung zu beschleunigen. Wenn Betriebsteams GitOps-Workflows verwenden, gibt es Vorteile, die über die Versionskontrolle hinausgehen, wenn GitLab als zentrales Repository verwendet wird. Teams verwenden GitLab wegen der kollaborativen Plattform, der einfachen Bereitstellung von Infrastruktur und der Multicloud-Kompatibilität.
Diese Demo zeigt, wie du Anwendungen mit einem gemeinsamen Workflow auf drei Kubernetes-Servern bereitstellst. Die Teams lernen, wie man Anwendungen mit Auto-DevOps, das auf GitLab CI basiert, mit Helm und Kubernetes erfolgreich bereitstellt.
Im ersten Schritt öffnest du die Datei README.md der Gruppe gitops-demo mit der Struktur der Gruppe gitops-demo. Es gibt einige Projekte und zwei Untergruppen: Infrastruktur (infra) und Anwendungen (apps).
Für diese Demo gibt es vier Anwendungen: my-asp-net-app1; my-spring-app2; my-ruby-app3; my-python-app4 und drei Kubernetes-Cluster, die jeweils einer anderen Cloud-Umgebung entsprechen: Microsoft Azure (AKS), Amazon (EKS) und Google Cloud (GKE).
Wenn du auf die Kubernetes-Schaltfläche in der linken Ecke klickst, wird angezeigt, dass alle Cluster bei GitLab registriert sind. Die Umgebungsbereiche stellen dar, welche Anwendung in jeder Cloud bereitgestellt wird.
Auto-DevOps bei der Arbeit
Das erste Beispiel ist eine ASP.NET-Anwendung, die einer „Hello, World“-App entspricht. Für die Bereitstellung dieser Anwendung, die sich in der CI-Datei der Anwendung befindet, gibt es ein paar spezifische Änderungen.
Im ersten Schritt importierst du die wichtigste Auto-DevOps-Vorlage, indem du einige Variablen festlegst. Dann ist es wichtig, ein paar Befehle für Phasen zu überschreiben, die eher auf .NET-Code anwendbar sind, und schließlich die Umgebung automatisch so einzustellen, dass die Produktion in AKS bereitgestellt wird.
include:
- template: Auto-DevOps.gitlab-ci.yml
variables:
DEPENDENCY_SCANNING_DISABLED: "true"
test:
stage: test
image: microsoft/dotnet:latest
script:
- 'dotnet test --no-restore'
license_management:
stage: test
before_script:
- sudo apt-get update
- sudo apt-get install -y dotnet-runtime-2.2 dotnet-sdk-2.2
production:
environment:
name: aks/production
url: http://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
Die Pipeline wird automatisch ausgeführt und erfolgreich bereitgestellt. Wenn du dir die Pipeline ansiehst, kannst du sehen, wie die Bereitstellung funktioniert.
Die Phasen der Pipeline vom Build bis zur Produktion für die ASP.NET-Anwendung.
Ein kurzer Blick in die Pipeline zeigt, dass alle Jobs erfolgreich ausgeführt wurden. Die Auto-DevOps-Funktion hat die Build-Phase gestartet, in der ein Docker -Container erstellt und in die integrierte Docker-Registry hochgeladen wird. Die Testphase ist umfangreich und umfasst Container-Scanning, Lizenzverwaltung, SAST und Unit-Tests. Tiefere Einblicke in die Testergebnisse erhältst du auf den Registerkarten „Sicherheit“ und „Lizenz“. Die Anwendung wird in der letzten Phase der Pipeline in der Produktion bereitgestellt.
Im AKS-Cluster
Die ASP.NET-Anwendung wird im AKS-Cluster bereitgestellt. Gehe zu „Operations“ > „Environments“, um die für diese Anwendung konfigurierte Umgebung anzuzeigen. Metriken wie HTTP-Fehlerraten, Latenzraten und Durchsatz sind verfügbar, da Prometheus bereits in die Kubernetes-Cluster von GitLab integriert ist.
Die Umgebung kann direkt gestartet werden. Klicke auf die Live-URL, um die Anwendung zu sehen, die auf AKS ausgeführt wird. Es gibt nicht viel zusätzlichen Code, der über das hinausgeht, was bereits in GitLab konfiguriert ist und der Anwendung mitteilt, wie sie bereitgestellt werden soll. Die Auto-DevOps-Funktion erstellt ein Helm-Diagramm und stellt es in Kubernetes und AKS bereit.
In der Demo erfährst du, wie du die Spring-Anwendung ähnlich wie die ASP.NET-Anwendung mithilfe einer Dockerfile konfigurierst. Die Dockerfile wird im Repository-Stammverzeichnis abgelegt.
ROM maven:3-jdk-8-alpine
WORKDIR /usr/src/app
COPY . /usr/src/app
RUN mvn package
ENV PORT 5000
EXPOSE $PORT
CMD [ "sh", "-c", "mvn -Dserver.port=${PORT} spring-boot:run" ]
Die Spring-Anwendungsbereitstellung unterscheidet sich in einer Hinsicht von der ASP.NET-Anwendung: Sie benötigt keine Überschreibungen für die Auto-DevOps-Vorlage, da sie die Standardvorlage verwendet und anstelle von AKS in GKE bereitgestellt wird. Der Workflow für die Anwendungsbereitstellung ist identisch – unabhängig davon, in welcher Cloud die Anwendung bereitgestellt wird. Dies macht Multicloud einfach.
Es ist wichtig, in dieser Umgebung eine ähnliche Build-, Test- und Produktionsausführung durchzuführen. Durch diesen Schritt können Teams die gleichen Metriken, die Fehlerraten, Latenzen und Durchsätze erhalten. In diesem Fall wird die Anwendung automatisch in einem Container auf Kubernetes im GKE-Cluster ausgeführt.
Das letzte Beispiel ist eine Python-Anwendung, die auf EKS bereitgestellt wird. Die Komponenten ähneln den vorherigen Beispielen und verwenden gitlab-ci.yml, um die Produktionsumgebung in EKS zu ändern und eine Dockerfile, um das Helm-Diagramm vorzubereiten. Es gibt auch ein paar Überschreibungen.
include:
- template: Auto-DevOps.gitlab-ci.yml
test:
image: python:3.7
script:
- pip install -r requirements.txt
- pip install pylint
- pylint main.py
production:
environment:
name: eks/production
url: http://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
Die GitLab-CI-Datei teilt der Anwendung mit, dass sie auf EKS bereitgestellt werden soll.
FROM python:3.7
WORKDIR /app
ADD . /app/
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "/app/main.py"
Die Dockerfile bereitet das Helm-Diagramm vor.
Die Pipeline läuft wie in den anderen Beispielanwendungen mit Build-, Test- und Produktionsphasen. Sobald die Anwendung in EKS bereitgestellt wurde, kannst du den Live-Link aufrufen, um die Python-Anwendung in deinem Browserfenster zu öffnen.
GitLab ist eine echte Multicloud-Lösung, mit der Unternehmen entscheiden können, welchen Cloud-Anbieter sie nutzen wollen, ohne unterschiedliche Workflows und unter Beibehaltung guter GitOps-Praktiken. All dies ist eine einheitliche Schnittstelle mit demselben Workflow, was die Bereitstellung in jeder größeren Cloud, in der Kubernetes mit GitLab integriert ist, einfach macht.
Zu einer guten GitOps-Praxis gehört es, ein Git-Repository zur einzigen Quelle der Wahrheit für den gesamten Code zu machen. Obwohl jedes Git-Repository für ein gutes GitOps-Verfahren ausreichen könnte, gibt es nur wenige DevOps-Tools, die wirklich die Kernpfeiler von GitOps umfassen: Zusammenarbeit, Prozesstransparenz und Versionskontrolle.
Tools wie Epics, Issues und Merge Requests, die das Herzstück von GitLab bilden, fördern die Kommunikation und Transparenz zwischen Teams. Infrastrukturteams können Code mit Terraform- oder Ansible-Vorlagen in GitLab erstellen und mithilfe der GitLab CI in der Cloud bereitstellen. GitLab ist eine echte Multicloud-Lösung, die es Teams ermöglicht, eine Anwendung mit GitLab CI und Kubernetes für jeden beliebigen Cloud-Service bereitzustellen, ohne dass sie ihre Workflows wesentlich erweitern müssen.
Bist du bereit?
Sieh dir an, was dein Team mit einer einheitlichen DevSecOps-Plattform erreichen könnte.