kaniko

kaniko - Crear imágenes en Kubernetes

NOTA: kaniko no es un producto de Google compatible oficialmente

Limitaciones y trampas

Deben cumplirse las siguientes condiciones:

1. Necesita acceso a máquinas de compilación que ejecutan las arquitecturas deseadas (ejecutar Kaniko en un emulador, por ejemplo, QEMU, también debería ser posible, pero va más allá del alcance de esta documentación). Esto es algo a tener en cuenta al utilizar herramientas de compilación SaaS como github.com o gitlab.com, las cuales, al momento de escribir este artículo, no admiten ningún ejecutor SaaS que no sea x86_64 (GitHub, GitLab), así que prepárate para traer el tuyo propio. máquinas (GitHub, GitLab.

2. Kaniko debe poder ejecutarse en las arquitecturas deseadas. Al momento de escribir este artículo, el contenedor oficial Kaniko admite linux/amd64, linux/arm64, linux/s390x y linux/ppc64le (no en imágenes *-debug).

3. El registro de contenedor que elija debe ser compatible con OCIv1 o Docker v2.2.

Ejemplo de canalización de CI (GitLab)

Depende de usted encontrar la herramienta de automatización que mejor se adapte a sus necesidades. Recomendamos utilizar un sistema CI/CD moderno, como los 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.

Construyendo las imágenes de contenedores separados

gitlab-ci.yml:

 # definir un trabajo para construir los contenedoresbuild-container: etapa: container-build
  # ejecutar compilaciones paralelas para las arquitecturas deseadas
  paralelo:matriz:
      - ARCO: amd64 - ARCO: arm64
  etiquetas:# ejecutar cada compilación en un ejecutor preconfigurado adecuado (debe coincidir con la arquitectura de destino)- ejecutor-${ARCH}
  imagen:nombre: gcr.io/kaniko-project/executor:debugentrypoint: [""]
  script:# construir la imagen del contenedor para el arco actual usando kaniko- >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" # enviar la imagen al registro del contenedor de GitLab, agregue el arco actual como etiqueta. --destino "${CI_REGISTRY_IMAGE}:${ARCH}"

Fusionar los manifiestos de contenedores

gitlab-ci.yml:

 # definir un trabajo para crear y enviar un manifiesto fusionadomerge-manifests: stage: container-build
  # todos los contenedores deben construirse antes de fusionarlos
  # alternativamente, el trabajo puede configurarse para ejecutarse en una etapa posterior
  necesidades:
    - trabajo: artefactos de construcción de contenedores: falso
  etiquetas:# puede ejecutarse en cualquier arquitectura compatible con la herramienta de manifiesto image-runner-xyz
  imagen:nombre: mplatform/manifest-tool:alpineentrypoint: [""]
  guion:
    - >- manifest-tool # autoriza contra su registro de contenedor --username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push from-args # define las arquitecturas que desea fusionar --platforms linux/amd64,linux/arm64 # "ARCH" será reemplazado automáticamente por manifest-tool # con el arco apropiado de las definiciones de la plataforma --template ${CI_REGISTRY_IMAGE}:ARCH # El nombre de la imagen final combinada que se enviará a su registro --target ${CI_REGISTRY_IMAGE}

Sobre la nota de agregar etiquetas versionadas

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:

• Si solo está interesado en crear versiones etiquetadas, simplemente puede usar la variable CI_COMMIT_TAG predefinida de GitLab al ejecutar una canalización de etiquetas.

• Cuando usted (como nosotros) desea crear adicionalmente imágenes de contenedores fuera de los lanzamientos, las cosas se vuelven un poco más complicadas. En nuestro caso, agregamos un trabajo adicional que se ejecuta antes de los trabajos de compilación y fusión (no olvide extender la sección de 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:

 contenedor-get-tag: etapa: etapa-pre-construcción-del-contenedor
  etiquetas:
    - corredor-xyz
  imagen: caja ocupada
  script:# Todas las demás ramas están etiquetadas con el hash SHA de confirmación actualmente creado- |      # Si la canalización se ejecuta en la rama predeterminada: establezca la etiqueta en "latest" if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; luego tag="latest" # Si la canalización es una canalización de etiquetas, establezca la etiqueta en la etiqueta de confirmación de git elif test -n "$CI_COMMIT_TAG"; luego tag="$CI_COMMIT_TAG" # De lo contrario, establezca la etiqueta en git commit sha else tag="$CI_COMMIT_SHA" fi - echo "tag=$tag" > build.env
  # etiqueta de análisis para los trabajos de compilación y fusión.
  # Ver: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
  artefactos: informes: dotenv: build.env

Comparación con otras herramientas

Herramientas similares incluyen:

• Kit de construcción

• imagen

• construcción de orca

• umoci

• construir

• FTL

• Reglas de Bazel_docker

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.

Comunidad

grupo de Google de usuarios de kaniko

Para contribuir a kaniko, consulte DEVELOPMENT.md y CONTRIBUTING.md.

Limitaciones

mtime y instantáneas

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:

• Con el modo de instantánea de solo tiempo ( --snapshot-mode=time ), kaniko puede omitir por completo los cambios introducidos por los comandos RUN .

• Con el modo de instantánea predeterminado ( --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.

Comandos de Dockerfile: soporte --chown

Kaniko actualmente admite los comandos COPY --chown y ADD --chown Dockerfile. No es compatible con RUN --chown .

Referencias

• Kaniko: creación de imágenes de contenedores en Kubernetes sin Docker.