Mann
v1.23.2
Folgende Bedingungen müssen erfüllt sein:
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.
gitlab-ci.yml:
# define a job for building the containers
build-container :
stage : container-build
# run parallel builds for the desired architectures
parallel :
matrix :
- ARCH : amd64
- ARCH : arm64
tags :
# run each build on a suitable, preconfigured runner (must match the target architecture)
- runner-${ARCH}
image :
name : gcr.io/kaniko-project/executor:debug
entrypoint : [""]
script :
# build the container image for the current arch using kaniko
- >-
/kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile
"${CI_PROJECT_DIR}/Dockerfile" # push the image to the GitLab container
registry, add the current arch as tag. --destination
"${CI_REGISTRY_IMAGE}:${ARCH}" gitlab-ci.yml:
# define a job for creating and pushing a merged manifest
merge-manifests :
stage : container-build
# all containers must be build before merging them
# alternatively the job may be configured to run in a later stage
needs :
- job : container-build
artifacts : false
tags :
# may run on any architecture supported by manifest-tool image
- runner-xyz
image :
name : mplatform/manifest-tool:alpine
entrypoint : [""]
script :
- >-
manifest-tool # authorize against your container registry
--username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push
from-args # define the architectures you want to merge --platforms
linux/amd64,linux/arm64 # "ARCH" will be automatically replaced by
manifest-tool # with the appropriate arch from the platform definitions
--template ${CI_REGISTRY_IMAGE}:ARCH # The name of the final, combined
image which will be pushed to your registry --target ${CI_REGISTRY_IMAGE} 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:
CI_COMMIT_TAG verwenden.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 :
stage : pre-container-build-stage
tags :
- runner-xyz
image : busybox
script :
# All other branches are tagged with the currently built commit SHA hash
- |
# If pipeline runs on the default branch: Set tag to "latest"
if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; then
tag="latest"
# If pipeline is a tag pipeline, set tag to the 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 to the build and merge jobs.
# See: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
artifacts :
reports :
dotenv : build.env Zu den ähnlichen Tools gehören:
Alle diese Tools erstellen Container-Images mit unterschiedlichen Ansätzen.
BuildKit (und img ) können von einem Container aus als Nicht-Root-Benutzer 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.
Kaniko-Nutzer Google-Gruppe
Informationen zum Mitwirken bei kaniko finden Sie unter DEVELOPMENT.md und CONTRIBUTING.md.
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:
--snapshot-mode=time ) übersieht Kaniko möglicherweise Änderungen, die durch RUN Befehle eingeführt werden, vollständig.--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.
--chown Kaniko unterstützt derzeit die Dockerfile-Befehle COPY --chown und ADD --chown . RUN --chown wird nicht unterstützt.
