Heute habe ich gelernt, dass man mit dem Befehl git restore eine bestimmte Datei in ihren ursprünglichen Zustand zurückversetzen kann – auch nach mehreren Commits – oder eine Datei mit einem anderen Branch synchronisieren kann.

Der Befehl git restore ermöglicht es, eine Datei auf einen früheren Zustand zurückzusetzen oder sie mit einem anderen Branch abzugleichen. Das ist besonders nützlich, wenn man Änderungen verwerfen und eine Datei mit der Version aus einem anderen Branch – zum Beispiel main – in Einklang bringen möchte.

In diesem Beispiel möchte ich alle committeten Änderungen im aktuellen Branch für eine bestimmte Datei verwerfen und sie mit der Version aus dem main-Branch angleichen:

git restore --source=main -- main.tf

• git-restore Dokumentation
• Das Titelbild steht unter der Creative Commons Attribution 3.0 Unported-Lizenz; Quelle: Wikimedia Commons

Was ist Kaniko?

Kaniko ist im Wesentlichen ein Docker-Image-Builder. Diese Einführung mag unbefriedigend erscheinen, aber genau darum geht es bei Kaniko: Images erstellen und in eine Registry pushen – sei es Dockerhub, ECR, ACR oder eine eigene Container-Image-Registry.

Wie funktioniert es?

Die Nutzung ist denkbar einfach. Zunächst wird das Dateisystem des Basis-Images extrahiert. Anschließend wird jede Anweisung (COPY, ADD, RUN) im Dateisystem des Basis-Images ausgeführt. Dabei wird ein Snapshot des aktuellen Dateisystemzustands erstellt, neu hinzugefügte oder geänderte Dateien werden dem Basis-Image hinzugefügt, und die Image-Metadaten werden aktualisiert. Äußerst nützlich – oder? Nicht, bis man gelernt hat, es zu verwenden.

Anwendungsfälle

Kaniko erstellt Docker-Images innerhalb eines Containers oder Kubernetes-Clusters. Wenn eines der folgenden Probleme bekannt vorkommt, hilft dieser Artikel dabei, es zu lösen:

• Beim Erstellen von Images auf einer gemeinsam genutzten Maschine oder einem geteilten Runner lässt sich das Risiko von Sicherheitsverletzungen reduzieren. Es gibt verschiedene Methoden zum Erstellen von Images: Bash-Skripte, Ansible-Playbooks oder Skripte im CI/CD-System, die etwas wie docker build -t beispiel:v0.0.1 -f MeinDockerfile ausführen. Dieser Befehl kann aus der Shell oder einem Container heraus (Docker in Docker) ausgeführt werden. Keine dieser Methoden ist für gemeinsam genutzte Umgebungen geeignet. Stellen Sie sich vor, ein anderer Nutzer, Entwickler oder eine andere Pipeline erhält Zugriff auf den Code, greift auf kritische Datenbankdaten zu oder stiehlt Zugangsdaten oder Schlüssel aus einer anderen Quelle. Dies kann zur Katastrophe führen: Code kann von Unbefugten eingesehen, Datenbankdaten können geleakt, oder Schlüssel können gestohlen werden. Das ist der schlimmste Albtraum für jedes Sicherheits- und Betriebsteam.

• Kürzere Build-Zeiten sind ein weiterer interessanter Vorteil. Server (Runner) bereiten DevOps-Teams häufig Kopfzerbrechen, wenn Build-Prozesse lange laufen. Ein großes Codebase mit vielen Abhängigkeiten aus dem Internet kann den Tag verderben. Kein DevOps- oder SRE-Team möchte ein weiteres Ticket erhalten mit dem Inhalt: “Unsere Build-Pipelines sind langsam. Wir sind in einer Feuerwehrsituation und Hotfixes müssen sofort in die Produktion.”

• Bei begrenztem Infrastrukturbudget wird oft vollständig auf den Kubernetes-Cluster gesetzt – von der Datenbank bis zur Umgebung für das Erstellen von Docker-Images. (Profi-Tipp: Nichts auf Kubernetes deployen, was nicht sein muss. Darüber werde ich in Zukunft schreiben. Datenbanken können auf Kubernetes laufen – aber tun Sie es besser nicht.)

Kaniko hilft, diese Probleme zu lösen. Kein Superheld – aber es kann uns zum Helden im Unternehmen machen.

Das Problem

Was wir hatten

Ich nutze diese Gelegenheit, um zu beschreiben, wie unsere CI/CD-Infrastruktur bei Alibaba Travels aufgebaut war und was wir getan haben, um sie zuverlässiger zu machen. Es handelte sich um eine veraltete Infrastruktur, die erneuert oder umstrukturiert werden musste. Wir haben bereits mehrere Projekte in diese neue Struktur migriert – in Staging-, Entwicklungs- und anderen Nicht-Produktionsumgebungen – aber es bleibt noch viel zu tun.

Zurück zum eigentlichen Thema: Wir haben Projekte aus verschiedenen Tech-Stacks. Wir nutzen alles von Dotnet Core über Nodejs bis Python. Zuvor nutzten alle Projekte einen gemeinsamen Runner, der auf GitLab Continuous Integration lief. Auf diesem leistungsstarken Server waren mehrere Shell- und Docker-Runner installiert (sie sind zur Risikominimierung noch verfügbar, aber die Migration ist geplant). Projekte, die ihren Build-Prozess in Docker ausführen, haben Zugriff auf den Docker-Socket, und alle Prozesse innerhalb dieses Runners können sich gegenseitig sehen – und sogar Shell-Zugriff auf andere Container gewähren.

Die Gefahrenzone

Dies kann dazu führen, dass Daten und möglicherweise auch Code ausgelesen werden. Shell-Runner sind ebenfalls verfügbar und bieten Shell-Zugriff auf den Runner – mit allen Rechten des gitlab-runner-Benutzers. Mehrere Gründe haben uns dazu bewogen, unsere Runner auf Kubernetes zu migrieren: bessere Ressourcenkontrolle pro Projekt, bessere Netzwerkkontrolle, Isolation zwischen Containern und mehr.

Einen Schritt weiter

Nach dem Einrichten mehrerer Kubernetes-Runner lief alles reibungslos – aber ein neues Problem entstand. Es ist nicht möglich, den Docker-Socket des Hosts in den Container zu mounten. Das Risiko ist zu groß: Der Container würde Zugriff auf alle Container des Hosts erhalten. Dedizierte Maschinen wären eine Lösung, aber kostspielig. Kann man einen einzigen Docker-Socket in mehrere Container einbinden? Außerdem muss der Security Context berücksichtigt werden, was weitere Sicherheitslücken schafft.

Das ist die Katastrophe.

Die Lösung

Was wir brauchen

Kaniko hilft uns, diese Lücken zu schließen. Nach der Implementierung von Kaniko dauerte das Erstellen eines Docker-Images aus einer DotNet-Anwendung 21 Minuten. Ohne den Kubernetes-Runner dauerte der Prozess dreieinhalb Minuten. Für eine Node.js-Anwendung stieg die Zeit auf 45 Minuten. Auf unseren gemeinsamen Runnern dauerte es 11 Minuten.

Was wir gemacht haben

Wir wollten es zuverlässiger machen, aber unsere Lösung brauchte deutlich mehr Zeit.

Caching

Caching hat das Problem für mich gelöst. Zunächst muss Caching aktiviert werden (Flag --cache=true). Es gibt zwei Caching-Optionen:

• Cache in einem lokalen Verzeichnis (--cache-dir)
• Cache in einem bestimmten Repository (--cache-repo-Flag)
  Da wir viele Ressourcen in unserer Registry haben, haben wir uns für die Repository-Option entschieden.

Nicht vergessen: COPY- und RUN-Anweisungen können gecacht werden, wenn das Flag --cache-copy-layers=true gesetzt ist.
Hinweis: Beide Caching-Methoden sind nur verfügbar, wenn --cache=true gesetzt ist.

Dockerfile

Dieses Dockerfile sieht auf den ersten Blick in Ordnung aus – und der Entwickler ist zufrieden damit:

FROM mcr.microsoft.com/dotnet/sdk:6.0
RUN apt update && apt install libgnutls30 && apt install ca-certificates && update-ca-certificates
WORKDIR /app
ENV ASPNETCORE_ENVIRONMENT=Production
ENV ASPNETCORE_URLS=http://+:80
COPY . ./
RUN dotnet restore   src/app/app.csproj --configfile src/app/nuget.config
RUN dotnet publish src/app/apptifier.csproj -c Release -o /app/out
FROM mcr.microsoft.com/dotnet/sdk:6.0
WORKDIR /app
COPY --from=build-env /app/out .
EXPOSE 80
ENTRYPOINT ["dotnet","app.dll"]

Es sieht normal aus – aber ich halte es für eine weitere Katastrophe. Erklärung:

• COPY-Anweisungen sollten in kleinere Teile aufgeteilt werden. In diesem Fall habe ich geändert, dass jedes Modul der Anwendung separat kopiert wird.
• Zwei RUN-Anweisungen können zusammengeführt werden.
• Der apt-Befehl löscht keine gecachten Pakete. In dieser Situation nicht kritisch, aber wir haben es trotzdem bereinigt.

Das Reduzieren der Zeilen im Dockerfile funktioniert für Kaniko nicht gut. Mehr Zeilen zu schreiben ist in Ordnung. Hier ist die überarbeitete Version:

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env

WORKDIR /app
ENV ASPNETCORE_ENVIRONMENT=Production
ENV ASPNETCORE_URLS=http://+:80

COPY src/Module1 ./src/Module1
COPY src/Module2 ./src/Module2
COPY src/app ./src/app

COPY tests/app.Test ./tests/Iapp.Test.Test
COPY tests/app.integrity.Test ./tests/app.integrity.Test

COPY app.sln ./
RUN dotnet publish --configfile src/app/nuget.config src/app/app.csproj -c Release -o /app/out --nologo -verbosity:quiet

FROM mcr.microsoft.com/dotnet/sdk:6.0

WORKDIR /app
COPY --from=build-env /app/out .

EXPOSE 80

ENTRYPOINT ["dotnet","app.dll"]

Dieselbe Methode habe ich auch für andere Projekte angewandt.

Snapshot

Zu Beginn dieses Beitrags habe ich erwähnt, dass Snapshots eine Methode zur Speicherung von Image-Schichten und deren Zuständen sind. Mit --single-snapshot=true wird nur ein einziger Snapshot am Ende des Prozesses erstellt – sehr schnell, aber nicht cache-freundlich. Alternativ kann --snapshotMode genutzt werden, um die richtige Snapshot-Methode sicherzustellen. Die folgende Tabelle stammt direkt aus der offiziellen Dokumentation:

Aus bestimmten Gründen habe ich mich für redo entschieden.

Ergebnis

Zunächst hat es etwas länger gedauert als der ursprüngliche docker build-Befehl – das ist verständlich, da Kaniko versucht, Caches zu erstellen. Nach einigen Änderungen an Modulen und Dateien sind die Ergebnisse jedoch beeindruckend:

Kaniko verwenden

Vier Dinge werden benötigt:

• Eine Dockerfile und Quellcode (Build-Kontext) sowie kleine Anpassungen am Dockerfile
• Eine Registry, in die gepusht werden soll
• Kaniko selbst
• Kaniko-Dokumentation

Meine Methode

Hier ist der vollständige Befehl, den ich verwende:

        /kaniko/executor
        --context "projectDirectory"
        --dockerfile "$projectDirectory/Dockerfile"
        --destination "imageTag:version"
        --cache-copy-layers=true
        --snapshotMode=time
        --use-new-run
        --cache=true
        --cache-repo="imageTag:cache"

Fazit

Hinweise

Hinweise zur Produktion

Dies wurde auf Staging-, Entwicklungs- und anderen Nicht-Produktionsumgebungen angewandt. Es kann bis zu sechs Monate dauern, bis diese Methode und die Tools vollständig übernommen wurden. Wer dies implementieren möchte, sollte sicherstellen, dass alles gründlich getestet wurde und keine komplexen Probleme – insbesondere Sicherheitsprobleme – auftreten, die die Produktion gefährden. Es handelt sich um ein stabiles und ausgereiftes Tool. Nutzung auf eigene Gefahr.

Weitere Anmerkungen

Das Ziel dieses Beitrags ist es, die Leistung und Sicherheit von Docker-Build-Pipelines zu verbessern. Kommentare sind jederzeit willkommen. Bei Unstimmigkeiten oder Problemen bitte melden :)