hombre
v1.23.2
Deben cumplirse las siguientes condiciones:
Depende de usted encontrar la herramienta de automatización que mejor se adapte a sus necesidades. Recomendamos utilizar un sistema CI/CD moderno, como flujos de trabajo de GitHub o GitLab CI. Como nosotros (los autores) usamos GitLab CI, los siguientes ejemplos están diseñados para esta plataforma específica, pero los principios subyacentes deben aplicarse en cualquier otro lugar y los ejemplos se mantienen lo suficientemente simples, para que pueda seguirlos, incluso sin ningún experiencias previas con esta plataforma específica. En caso de duda, visite la página de referencia gitlab-ci.yml para obtener una descripción general completa de las palabras clave de 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} En aras de la simplicidad, nos abstuvimos deliberadamente de usar imágenes etiquetadas con versiones (todas las compilaciones se etiquetarán como "más recientes") en los ejemplos anteriores, ya que creemos que esto agrega mucho código específico de plataforma y flujo de trabajo.
Sin embargo, para cualquiera interesado en cómo manejamos el control de versiones (dinámico) en GitLab, aquí hay un breve resumen:
CI_COMMIT_TAG predefinida de GitLab al ejecutar una canalización de etiquetas.needs de los trabajos de compilación y fusión en consecuencia), lo que establecerá la etiqueta en la latest cuando se ejecute en la rama predeterminada. al hash de confirmación cuando se ejecuta en otras ramas y a la etiqueta de lanzamiento cuando se ejecuta en una canalización de etiquetas.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 Herramientas similares incluyen:
Todas estas herramientas crean imágenes de contenedores con diferentes enfoques.
BuildKit (e img ) puede funcionar como un usuario no root desde un contenedor, pero requiere que seccomp y AppArmor estén deshabilitados para crear contenedores anidados. kaniko en realidad no crea contenedores anidados, por lo que no requiere que seccomp y AppArmor estén deshabilitados. BuildKit admite contenedores de múltiples arcos "entre edificios" aprovechando QEMU.
orca-build depende de runc para crear imágenes a partir de Dockerfiles, que no se pueden ejecutar dentro de un contenedor (por razones similares a las de img arriba). kaniko no usa runc por lo que no requiere el uso de técnicas de espacio de nombres del kernel. Sin embargo, orca-build no requiere Docker ni ningún demonio privilegiado (por lo que las compilaciones se pueden realizar completamente sin privilegios).
umoci funciona sin ningún privilegio y tampoco tiene restricciones en cuanto al sistema de archivos raíz que se extrae (aunque requiere manejo adicional si su sistema de archivos es lo suficientemente complicado). Sin embargo, no tiene herramientas de compilación similares Dockerfile (es una herramienta de nivel ligeramente inferior que se puede utilizar para crear dichos constructores, como orca-build ).
Buildah se especializa en la creación de imágenes OCI. Los comandos de Buildah replican todos los comandos que se encuentran en un Dockerfile. Esto permite crear imágenes con y sin Dockerfiles sin requerir ningún privilegio de root. El objetivo final de Buildah es proporcionar una interfaz coreutils de nivel inferior para crear imágenes. La flexibilidad de crear imágenes sin Dockerfiles permite la integración de otros lenguajes de programación en el proceso de construcción. Buildah sigue un modelo simple de ejecución de bifurcación y no se ejecuta como un demonio, pero se basa en una API integral en golang, que se puede distribuir en otras herramientas.
FTL y Bazel tienen como objetivo lograr la creación más rápida posible de imágenes Docker para un subconjunto de imágenes. Estos pueden considerarse como una "ruta rápida" de caso especial que se puede utilizar junto con el soporte para Dockerfiles generales que proporciona kaniko.
grupo de Google de usuarios de kaniko
Para contribuir a kaniko, consulte DEVELOPMENT.md y CONTRIBUTING.md.
Al tomar una instantánea, los algoritmos hash de kaniko incluyen (o en el caso de --snapshot-mode=time , solo usan) el mtime de un archivo para determinar si el archivo ha cambiado. Desafortunadamente, hay un retraso entre el momento en que se realizan los cambios en un archivo y el momento en que se actualiza mtime . Esto significa:
--snapshot-mode=time ), kaniko puede omitir por completo los cambios introducidos por los comandos RUN .--snapshot-mode=full ), si kaniko agregará o no una capa en el caso de que un comando RUN modifique un archivo pero el contenido no cambie es teóricamente no determinista. Esto no afecta el contenido que seguirá siendo correcto, pero sí afecta el número de capas.Tenga en cuenta que estas cuestiones son actualmente sólo teóricas. Si ve que se produce este problema, abra un problema.
--chown Kaniko actualmente admite los comandos COPY --chown y ADD --chown Dockerfile. No es compatible con RUN --chown .
