kaniko
v1.23.2
Les conditions suivantes doivent être remplies :
Vous devez accéder aux machines de build exécutant les architectures souhaitées (exécuter Kaniko dans un émulateur, par exemple QEMU devrait également être possible mais dépasse le cadre de cette documentation). C'est quelque chose à garder à l'esprit lorsque vous utilisez des outils de construction SaaS tels que github.com ou gitlab.com, qui, au moment de la rédaction, ne prennent pas en charge les exécuteurs SaaS non x86_64 (GitHub, GitLab), alors soyez prêt à apporter le vôtre machines (GitHub,GitLab.
Kaniko doit pouvoir fonctionner sur les architectures souhaitées. Au moment de la rédaction de cet article, le conteneur Kaniko officiel prend en charge Linux/amd64, linux/arm64, linux/s390x et linux/ppc64le (pas sur les images *-debug).
Le registre de conteneurs de votre choix doit être compatible OCIv1 ou Docker v2.2.
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 :
# définir un travail pour construire le containersbuild-container: stage: containers-build
# exécuter des builds parallèles pour les architectures souhaitées
parallèle:matrice:
- ARCH : amd64 - ARCH : arm64
tags :# exécutez chaque build sur un runner approprié et préconfiguré (doit correspondre à l'architecture cible)- runner-${ARCH}
image: nom : gcr.io/kaniko-project/executor:debugentrypoint : [""]
script:# crée l'image du conteneur pour l'arche actuelle en utilisant kaniko- >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" # envoie l'image vers le registre des conteneurs GitLab, ajoutez l'arche actuelle comme balise. --destination "${CI_REGISTRY_IMAGE} :${ARCH}"gitlab-ci.yml :
# définir un travail pour créer et transmettre un manifeste fusionnémerge-manifests : stage : conteneur-build
# tous les conteneurs doivent être construits avant de les fusionner
# Alternativement, le travail peut être configuré pour être exécuté ultérieurement
besoins:
- travail : artefacts de construction de conteneur : false
tags :# peut s'exécuter sur n'importe quelle architecture prise en charge par manifest-tool image-runner-xyz
image: nom : mplatform/manifest-tool:alpineentrypoint : [""]
scénario:
->- manifest-tool # autoriser votre registre de conteneurs --username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push from-args # définir les architectures que vous souhaitez fusionner --platforms linux/amd64,linux/arm64 # "ARCH" sera automatiquement remplacé par manifest-tool # par l'arch approprié des définitions de la plateforme --template ${CI_REGISTRY_IMAGE}:ARCH # Le nom de l'image finale combinée qui sera poussée vers votre registre --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 :
Si vous souhaitez uniquement créer des versions balisées, vous pouvez simplement utiliser la variable CI_COMMIT_TAG prédéfinie par GitLab lors de l'exécution d'un pipeline de balises.
Lorsque vous (comme nous) souhaitez créer en plus des images de conteneurs en dehors des versions, les choses deviennent un peu plus compliquées. Dans notre cas, nous avons ajouté un travail supplémentaire qui s'exécute avant les travaux de construction et de fusion (n'oubliez pas d'étendre la section 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 :
conteneur-get-tag : étape : pré-conteneur-build-stage
balises :
- coureur-xyz
image : boîte occupée
script:# Toutes les autres branches sont étiquetées avec le hachage SHA de validation actuellement construit- | # Si le pipeline s'exécute sur la branche par défaut : définissez la balise sur "latest" if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ; then tag="latest" # Si le pipeline est un pipeline de balises, définissez la balise sur le git commit tag elif test -n "$CI_COMMIT_TAG" ; then tag="$CI_COMMIT_TAG" # Sinon, définissez la balise sur git commit sha else tag="$CI_COMMIT_SHA" fi - echo "tag=$tag" > build.env
# analyser la balise pour les tâches de construction et de fusion.
# Voir : https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
artefacts : rapports : dotenv : build.envLes outils similaires incluent :
Kit de construction
img
construction d'orques
umoci
buildah
FTL
Règles Bazel_docker
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 dans 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:
Avec le mode instantané uniquement temporel ( --snapshot-mode=time ), kaniko peut manquer complètement les modifications introduites par les commandes RUN .
Avec le mode instantané par défaut ( --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 .
Kaniko - Création d'images de conteneurs dans Kubernetes sans Docker.
