kaniko

kaniko – Images in Kubernetes erstellen

HINWEIS: Kaniko ist kein offiziell unterstütztes Google-Produkt

Einschränkungen und Fallstricke

Folgende Bedingungen müssen erfüllt sein:

1. Sie benötigen Zugriff auf Build-Maschinen, auf denen die gewünschten Architekturen ausgeführt werden (die Ausführung von Kaniko in einem Emulator, z. B. QEMU, sollte ebenfalls möglich sein, geht jedoch über den Rahmen dieser Dokumentation hinaus). Dies ist zu beachten, wenn Sie SaaS-Build-Tools wie github.com oder gitlab.com verwenden, von denen zum Zeitpunkt des Verfassens dieses Artikels keine Nicht-x86_64-SaaS-Läufer (GitHub, GitLab) unterstützt werden. Seien Sie also bereit, Ihre eigenen mitzubringen Maschinen (GitHub,GitLab.

2. Kaniko muss auf den gewünschten Architekturen laufen können. Zum Zeitpunkt des Schreibens unterstützt der offizielle Kaniko-Container Linux/AMD64, Linux/Arm64, Linux/S390x und Linux/PPC64le (nicht auf *-Debug-Images).

3. Die Containerregistrierung Ihrer Wahl muss OCIv1- oder Docker v2.2-kompatibel sein.

Beispiel für eine CI-Pipeline (GitLab)

Es liegt an Ihnen, ein Automatisierungstool zu finden, das Ihren Anforderungen am besten entspricht. Wir empfehlen den Einsatz eines modernen CI/CD-Systems wie GitHub Workflows oder GitLab CI. Da wir (die Autoren) zufällig GitLab CI verwenden, sind die folgenden Beispiele auf diese spezielle Plattform zugeschnitten, aber die zugrunde liegenden Prinzipien sollten überall gelten und die Beispiele sind einfach genug gehalten, sodass Sie sie auch ohne nachvollziehen können Bisherige Erfahrungen mit dieser speziellen Plattform. Besuchen Sie im Zweifelsfall die Referenzseite gitlab-ci.yml, um einen umfassenden Überblick über die GitLab CI-Schlüsselwörter zu erhalten.

Erstellen der separaten Container-Images

gitlab-ci.yml:

 # Definieren Sie einen Job zum Erstellen des Containersbuild-Containers: Stage: Container-Build
  # Parallele Builds für die gewünschten Architekturen ausführen
  parallel:matrix:
      - ARCH: amd64 - ARCH: arm64
  Tags:# Führen Sie jeden Build auf einem geeigneten, vorkonfigurierten Runner aus (muss mit der Zielarchitektur übereinstimmen)- runner-${ARCH}
  image:name: gcr.io/kaniko-project/executor:debugentrypoint: [""]
  script:# Erstellen Sie das Container-Image für den aktuellen Arch mit kaniko- >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" # Schieben Sie das Image in die GitLab-Container-Registrierung. Fügen Sie den aktuellen Bogen als Tag hinzu. --destination "${CI_REGISTRY_IMAGE}:${ARCH}"

Zusammenführen der Containermanifeste

gitlab-ci.yml:

 # Definieren Sie einen Job zum Erstellen und Pushen eines zusammengeführten Manifestmerge-manifests: stage: container-build
  # Alle Container müssen erstellt werden, bevor sie zusammengeführt werden
  # Alternativ kann der Job so konfiguriert werden, dass er zu einem späteren Zeitpunkt ausgeführt wird
  braucht:
    – Job: Container-Build-Artefakte: falsch
  tags:# kann auf jeder Architektur ausgeführt werden, die von manifest-tool image-runner-xyz unterstützt wird
  image:name: mplatform/manifest-tool:alpineentrypoint: [""]
  Skript:
    - >- manifest-tool # Autorisierung für Ihre Container-Registrierung --username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push from-args # Definieren Sie die Architekturen, die Sie zusammenführen möchten --platforms linux/amd64,linux/arm64 # „ARCH“ wird automatisch von manifest-tool # durch den entsprechenden Arch aus den Plattformdefinitionen ersetzt –-template ${CI_REGISTRY_IMAGE}:ARCH # Der Name des endgültigen, kombinierten Bildes, das in Ihre Registrierung übertragen wird --target ${CI_REGISTRY_IMAGE}

Zum Hinweis zum Hinzufügen versionierter Tags

Der Einfachheit halber haben wir in den vorherigen Beispielen bewusst auf die Verwendung versionierter getaggter Bilder verzichtet (alle Builds werden als „neueste“ getaggt), da wir der Meinung sind, dass dadurch viel plattform- und Workflow-spezifischer Code hinzugefügt wird.

Dennoch, für alle, die sich dafür interessieren, wie wir mit der (dynamischen) Versionierung in GitLab umgehen, hier ein kurzer Überblick:

• Wenn Sie nur an der Erstellung getaggter Releases interessiert sind, können Sie beim Ausführen einer Tag-Pipeline einfach die vordefinierte GitLab-Variable CI_COMMIT_TAG verwenden.

• Wenn Sie (wie wir) zusätzlich Container-Images außerhalb von Releases erstellen möchten, wird die Sache etwas chaotischer. In unserem Fall haben wir einen zusätzlichen Job hinzugefügt, der vor den Build- und Merge-Jobs ausgeführt wird (vergessen Sie nicht, den Abschnitt needs der Build- und Merge-Jobs entsprechend zu erweitern), der das Tag auf latest setzt, wenn es im Standardzweig ausgeführt wird. zum Commit-Hash, wenn es in anderen Zweigen ausgeführt wird, und zum Release-Tag, wenn es in einer Tag-Pipeline ausgeführt wird.

gitlab-ci.yml:

 Container-Get-Tag: Stufe: Pre-Container-Build-Stufe
  Tags:
    - runner-xyz
  Bild: Busybox
  script:# Alle anderen Zweige werden mit dem aktuell erstellten Commit-SHA-Hash-| getaggt      # Wenn die Pipeline im Standardzweig ausgeführt wird: Setzen Sie das Tag auf „latest“, wenn test „$CI_COMMIT_BRANCH“ == „$CI_DEFAULT_BRANCH“; then tag="latest" # Wenn die Pipeline eine Tag-Pipeline ist, setzen Sie das Tag auf das Git-Commit-Tag elif test -n "$CI_COMMIT_TAG"; then tag="$CI_COMMIT_TAG" # Else set the tag to the git commit sha else tag="$CI_COMMIT_SHA" fi - echo "tag=$tag" > build.env
  # Parse-Tag für die Build- und Merge-Jobs.
  # Siehe: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
  Artefakte: Berichte: dotenv: build.env

Vergleich mit anderen Tools

Zu den ähnlichen Tools gehören:

• BuildKit

• Bild

• Orca-Build

• umoci

• buildah

• FTL

• Bazel Rules_Docker

Alle diese Tools erstellen Container-Images mit unterschiedlichen Ansätzen.

BuildKit (und img ) können als Nicht-Root-Benutzer in einem Container ausgeführt werden, erfordern jedoch die Deaktivierung von seccomp und AppArmor, um verschachtelte Container zu erstellen. kaniko erstellt eigentlich keine verschachtelten Container, daher ist es nicht erforderlich, seccomp und AppArmor zu deaktivieren. BuildKit unterstützt das „Cross-Building“ von Multi-Arch-Containern durch die Nutzung von QEMU.

orca-build ist auf runc angewiesen, um Images aus Docker-Dateien zu erstellen, die nicht in einem Container ausgeführt werden können (aus ähnlichen Gründen wie img oben). kaniko verwendet runc nicht und erfordert daher keine Verwendung von Kernel-Namespace-Techniken. orca-build ist jedoch kein Docker oder ein privilegierter Daemon erforderlich (Builds können also völlig ohne Privilegien durchgeführt werden).

umoci funktioniert ohne jegliche Privilegien und hat auch keine Einschränkungen hinsichtlich des zu extrahierenden Root-Dateisystems (obwohl es zusätzliche Handhabung erfordert, wenn Ihr Dateisystem ausreichend kompliziert ist). Allerdings verfügt es über kein Dockerfile -ähnliches Build-Tool (es ist ein etwas niedrigeres Tool, das zum Erstellen solcher Builder verwendet werden kann – wie z. B. orca-build ).

Buildah ist auf die Erstellung von OCI-Images spezialisiert. Die Befehle von Buildah replizieren alle Befehle, die in einer Docker-Datei enthalten sind. Dies ermöglicht das Erstellen von Images mit und ohne Dockerfiles, ohne dass dafür Root-Rechte erforderlich sind. Das ultimative Ziel von Buildah besteht darin, eine Coreutils-Schnittstelle auf niedrigerer Ebene zum Erstellen von Images bereitzustellen. Die Flexibilität beim Erstellen von Images ohne Dockerfiles ermöglicht die Integration anderer Skriptsprachen in den Build-Prozess. Buildah folgt einem einfachen Fork-Exec-Modell und läuft nicht als Daemon, sondern basiert auf einer umfassenden API in Golang, die in andere Tools integriert werden kann.

Ziel FTL und Bazel ist es, die schnellstmögliche Erstellung von Docker-Images für eine Teilmenge von Images zu erreichen. Diese können als „Schnellpfad“ für Sonderfälle betrachtet werden, der in Verbindung mit der von Kaniko bereitgestellten Unterstützung für allgemeine Dockerfiles verwendet werden kann.

Gemeinschaft

kaniko-users Google-Gruppe

Informationen zum Mitwirken bei kaniko finden Sie unter DEVELOPMENT.md und CONTRIBUTING.md.

Einschränkungen

Mtime und Snapshotting

Beim Erstellen eines Snapshots beziehen die Hashing-Algorithmen von Kaniko mtime einer Datei mit ein (oder verwenden sie im Fall von --snapshot-mode=time nur), um festzustellen, ob sich die Datei geändert hat. Leider gibt es eine Verzögerung zwischen Änderungen an einer Datei und der Aktualisierung der mtime . Das heisst:

• Mit dem Nur-Zeit-Snapshot-Modus ( --snapshot-mode=time ) übersieht Kaniko möglicherweise Änderungen, die durch RUN Befehle eingeführt werden, vollständig.

• Mit dem Standard-Snapshot-Modus ( --snapshot-mode=full ) ist es theoretisch nicht deterministisch, ob Kaniko eine Ebene hinzufügt, wenn ein RUN -Befehl eine Datei ändert, sich der Inhalt aber nicht ändert. Dies hat keinen Einfluss auf die weiterhin korrekten Inhalte , wohl aber auf die Anzahl der Ebenen.

Beachten Sie, dass diese Probleme derzeit nur theoretischer Natur sind. Wenn dieses Problem auftritt, öffnen Sie bitte ein Problem.

Unterstützung für Dockerfile-Befehle --chown

Kaniko unterstützt derzeit die Dockerfile-Befehle COPY --chown und ADD --chown . RUN --chown wird nicht unterstützt.

Referenzen

• Kaniko – Erstellen von Container-Images in Kubernetes ohne Docker.