homme
v1.23.2
Les conditions suivantes doivent être remplies :
A vous de trouver l’outil d’automatisation qui correspond le mieux à vos besoins. Nous vous recommandons d'utiliser un système CI/CD moderne tel que les workflows GitHub ou GitLab CI. Comme nous (les auteurs) utilisons GitLab CI, les exemples suivants sont adaptés à cette plate-forme spécifique, mais les principes sous-jacents doivent s'appliquer partout ailleurs et les exemples restent suffisamment simples, pour que vous puissiez suivre, même sans aucun expériences antérieures avec cette plateforme spécifique. En cas de doute, visitez la page de référence gitlab-ci.yml pour un aperçu complet des mots-clés GitLab CI.
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} Par souci de simplicité, nous nous sommes délibérément abstenus d'utiliser des images balisées versionnées (toutes les versions seront marquées comme « dernières ») dans les exemples précédents, car nous pensons que cela ajoute beaucoup de code spécifique à la plate-forme et au flux de travail.
Néanmoins, pour toute personne intéressée par la façon dont nous gérons le versioning (dynamique) dans GitLab, voici un bref aperçu :
CI_COMMIT_TAG prédéfinie par GitLab lors de l'exécution d'un pipeline de balises.needs des travaux de construction et de fusion en conséquence), qui définira la balise sur latest lors de l'exécution sur la branche par défaut, au hachage de validation lorsqu'il est exécuté sur d'autres branches et à la balise de publication lorsqu'il est exécuté sur un pipeline de balises.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 Les outils similaires incluent :
Tous ces outils créent des images de conteneurs avec des approches différentes.
BuildKit (et img ) peut fonctionner en tant qu'utilisateur non root à partir d'un conteneur, mais nécessite que seccomp et AppArmor soient désactivés pour créer des conteneurs imbriqués. kaniko ne crée pas réellement de conteneurs imbriqués, il ne nécessite donc pas la désactivation de seccomp et AppArmor. BuildKit prend en charge les conteneurs multi-arch « cross-building » en tirant parti de QEMU.
orca-build dépend de runc pour créer des images à partir de Dockerfiles, qui ne peuvent pas s'exécuter dans un conteneur (pour des raisons similaires à celles de img ci-dessus). kaniko n'utilise pas runc , il ne nécessite donc pas l'utilisation de techniques d'espacement de noms du noyau. Cependant, orca-build ne nécessite pas Docker ni aucun démon privilégié (les builds peuvent donc être effectués entièrement sans privilège).
umoci fonctionne sans aucun privilège et n'a également aucune restriction sur le système de fichiers racine en cours d'extraction (bien que cela nécessite une manipulation supplémentaire si votre système de fichiers est suffisamment compliqué). Cependant, il ne dispose pas d'outils de construction de type Dockerfile (il s'agit d'un outil de niveau légèrement inférieur qui peut être utilisé pour créer de tels générateurs, tels que orca-build ).
Buildah est spécialisé dans la création d'images OCI. Les commandes de Buildah répliquent toutes les commandes trouvées dans un Dockerfile. Cela permet de créer des images avec et sans Dockerfiles sans nécessiter de privilèges root. L'objectif ultime de Buildah est de fournir une interface coreutils de niveau inférieur pour créer des images. La flexibilité de créer des images sans Dockerfiles permet l'intégration d'autres langages de script dans le processus de construction. Buildah suit un modèle fork-exec simple et ne s'exécute pas comme un démon, mais il est basé sur une API complète en Golang, qui peut être vendue dans d'autres outils.
FTL et Bazel visent à réaliser la création la plus rapide possible d'images Docker pour un sous-ensemble d'images. Ceux-ci peuvent être considérés comme un « chemin rapide » dans un cas particulier qui peut être utilisé en conjonction avec la prise en charge des Dockerfiles généraux fournis par Kaniko.
Groupe Google d'utilisateurs kaniko
Pour contribuer à kaniko, voir DEVELOPMENT.md et CONTRIBUTING.md.
Lors de la prise d'un instantané, les algorithmes de hachage de kaniko incluent (ou dans le cas de --snapshot-mode=time , utilisent uniquement) mtime d'un fichier pour déterminer si le fichier a changé. Malheureusement, il existe un délai entre le moment où les modifications sont apportées à un fichier et le moment où le mtime est mis à jour. Cela signifie:
--snapshot-mode=time ), kaniko peut manquer complètement les modifications introduites par les commandes RUN .--snapshot-mode=full ), le fait que kaniko ajoute ou non une couche dans le cas où une commande RUN modifie un fichier mais que le contenu ne change pas est théoriquement non déterministe. Cela n'affecte pas le contenu qui sera toujours correct, mais cela affecte le nombre de couches.Notez que ces questions sont actuellement uniquement théoriques. Si vous constatez que ce problème se produit, veuillez ouvrir un problème.
--chown en charge chown Kaniko prend actuellement en charge les commandes COPY --chown et ADD --chown Dockerfile. Il ne prend pas en charge RUN --chown .
