Docker BuildKit es un motor de creación de imágenes opcional que ofrece mejoras sustanciales sobre el proceso tradicional. BuildKit crea capas de imágenes en paralelo, acelerando el proceso de construcción general.
¿Qué es BuildKit?
BuildKit se desarrolló como parte del proyecto Moby, un esfuerzo de Docker para “ensamblar sistemas de contenedores especializados sin reinventar la rueda”. Se anunció en 2017 y comenzó a distribuirse con Docker Engine en la versión 18.09 de 2018.
BuildKit se centra en mejorar el rendimiento de la compilación, la gestión del almacenamiento y la extensibilidad. Sus afirmaciones principales son el procesamiento paralelo, el almacenamiento en caché más avanzado, una arquitectura conectable y la recolección automática de basura. Estos se combinan en un sistema de construcción que es más eficiente y más extensible que el motor original.
Las capas que no se impactan entre sí se pueden construir simultáneamente, lo que reduce los tiempos de espera para que se completen las etapas. BuildKit también optimiza el acceso a los archivos locales a los que hace referencia COPY instrucciones. Realiza un seguimiento de los cambios que realiza y solo copia los archivos que se han modificado desde la última compilación, en lugar de transferir todo el contexto de compilación.
BuildKit también simplifica las compilaciones multiplataforma. Puede suministrar el --platform marca para especificar los objetivos para los que construir. BuildKit ensamblará automáticamente un manifiesto de imagen apropiado para cubrir todas las arquitecturas especificadas.
docker buildx --create --platform linux/amd64,linux/arm64 .
¿Cómo funciona BuildKit?
Las mejoras de rendimiento de BuildKit se facilitan mediante el uso de un formato de definición de compilación de bajo nivel, denominado LLB. Es un formato binario basado en gráficos que une definiciones de compilación complejas.
Como las capas están directamente vinculadas, BuildKit facilita una comparación más rápida de los gráficos de construcción y el contenido que incluyen. El constructor de Dockerfile predeterminado debe depender de heurísticas imprecisas para determinar si dos imágenes son comparables.
El LLB está completamente separado de la “interfaz” de BuildKit. La interfaz toma una representación legible por humanos de una imagen, como un Dockerfiley lo convierte en un gráfico LLB. Una vez que se ha generado un LLB, se puede exportar y mover entre entornos. Exportar a un registro permite a los clientes frontend adquirir un LLB existente para mejorar aún más el rendimiento de la construcción por primera vez.
Los detalles técnicos de LLB son bastante complejos. La tecnología subyacente se basa en la teoría de grafos y la comparación de sumas de comprobación. No es necesario que lo comprenda para beneficiarse de su poder: como usuario final, las compilaciones funcionan de la misma manera que siempre, con la docker build mando.
BuildKit aún crea imágenes compatibles con OCI que son portátiles en diferentes entornos de contenedores. Puede usar BuildKit para crear cualquier imagen de Docker con una base de Linux. Actualmente, las imágenes de Windows no son compatibles.
Activando el soporte de BuildKit
Hay dos formas de habilitar BuildKit. Si desea crear una sola imagen con la función, configure el DOCKER_BUILDKIT variable de entorno en su shell:
DOCKER_BUILDKIT=1 docker build .
Para un uso a largo plazo, configure el demonio Docker para usar BuildKit de forma predeterminada. Cree o edite el /etc/docker/daemon.json archivo y agregue el siguiente contenido al objeto de configuración de nivel superior:
{
"features": {
"buildkit": true
}
}
Vuelva a cargar la configuración del demonio para aplicar el cambio:
systemctl reload docker
BuildKit ahora se usará en lugar del motor de compilación predeterminado cuando ejecute el docker build mando.
Puede saber cuándo BuildKit está activo porque produce una salida CLI diferente a la del motor normal. La pantalla de progreso de BuildKit ofrece una legibilidad mejorada y una visualización clara de cuándo comienza y finaliza cada etapa. La información incluye un desglose del tiempo necesario para construir cada capa.
“Docker buildx”
También puede interactuar con BuildKit a través de docker buildx comandos. Estos siempre usarán BuildKit. La dockerx El grupo de comandos expone la funcionalidad avanzada de BuildKit, incluida la capacidad de construir en un host remoto.
Un solo cliente de BuildKit puede interactuar con varias instancias distintas del generador de imágenes. Esto facilita las compilaciones multiplataforma al permitirle agregar un constructor para cada arquitectura a la que se dirige.
A continuación, se muestra un ejemplo de cómo agregar un host remoto como destino de BuildKit. Esto supone que la máquina de destino tiene un socket Docker expuesto en el puerto TCP 2375. Puede hacer referencia al host mediante cualquier identificador de punto final de Docker o el nombre de un contexto de Docker (obtenido de docker context ls). Este último le permite construir en entornos de nube compatibles agregándolos como contexto.
docker buildx create --name remote-builder tcp://my-docker-host:2375
Puede seleccionar el constructor para usar con el docker buildx use mando:
docker buildx use remote-builder
Entonces puedes usar el build comando para construir su imagen en la instancia de constructor seleccionada:
docker buildx build .
Puede eliminar instancias de constructor usando docker buildx rm, pasando el nombre del constructor. Los constructores se enumeran usando docker buildx ls; puedes usar docker buildx inspect para obtener información más detallada sobre un constructor específico.
Si desea verificar el uso del disco de BuildKit, ejecute el docker buildx du mando. Puede borrar la caché de compilación para liberar almacenamiento con docker buildx prune. Esto puede reducir el rendimiento la próxima vez que reconstruya su imagen, ya que se reconstruirán las capas almacenadas en caché anteriormente.
Características de construcción
BuildKit agrega un par de funciones adicionales de tiempo de compilación para simplificar su Dockerfile pasos.
Puede pasar datos secretos utilizando el --secret bandera. Esto le permite a su Dockerfile acceder a valores sensibles sin almacenarlos dentro de la imagen. Los valores solo disponible en el momento de la construcción.
docker build --secret id=demo-secret,src=demo-secret.txt .
FROM my-image:latest RUN --mount=type=secret,id=demo-secret cat /run/secrets/demo-secrets
Esto Dockerfile hace referencia a un secreto llamado demo-secret. Su valor se lee de la demo-secret.txt archivo cuando se ejecuta docker build. La RUN instrucción con el --mount bandera proporciona acceso al secreto. El archivo se monta temporalmente en el /run/secrets directorio.
BuildKit también le permite reenviar el agente SSH de su host para que sus instrucciones de compilación puedan interactuar con las conexiones remotas existentes. Pasa el --ssh bandera a docker build y añadir --mount=type=ssh a RUN instrucciones en tu Dockerfile:
docker build --ssh .
RUN --mount=type=ssh git clone [email protected]:/project.git
Estas características hacen que la creación de imágenes sea más conveniente sin afectar la seguridad general. El reenvío de agentes SSH y los montajes secretos solo están disponibles en BuildKit; no hay contraparte en el motor de compilación predeterminado.
Conclusión
BuildKit es el generador de imágenes de Docker de próxima generación que utiliza un formato binario graficado para acelerar drásticamente las compilaciones. Aunque el rendimiento variará considerablemente para cada Dockerfile, puede esperar ver aceleraciones sustanciales en los casos en que sea posible el procesamiento paralelo de capas de imágenes.
La arquitectura de BuildKit optimiza algunos de los más nuevos Dockerfile características. Las compilaciones de varias etapas se benefician al omitir las etapas no utilizadas, lo que hace que el proceso sea más eficiente que el constructor estándar.
Aunque BuildKit ahora es estable, Docker todavía no se envía con él de forma predeterminada. Asegúrese de habilitarlo en su cliente Docker si desea utilizar sus funciones. Hay una propuesta activa para hacer de BuildKit el motor de compilación estándar, pero todavía hay problemas sin resolver que impiden el cambio.