kit de construcción
0.17.0
BuildKit es un conjunto de herramientas para convertir código fuente para crear artefactos de manera eficiente, expresiva y repetible.
Características clave:
Recolección automática de basura
Formatos de interfaz extensibles
Resolución de dependencia concurrente
Almacenamiento en caché de instrucciones eficiente
Importación/exportación de caché de compilación
Invocaciones de trabajos de construcción anidados
Trabajadores distribuibles
Múltiples formatos de salida
Arquitectura conectable
Ejecución sin privilegios de root
Lea la propuesta de moby/moby#32925
Publicación de blog introductoria https://blog.mobyproject.org/introtaining-buildkit-17e056cc5317
Únase al canal #buildkit en Docker Community Slack
Nota
Si visita este repositorio para utilizar funciones de Dockerfile exclusivas de BuildKit como RUN --mount=type=(bind|cache|tmpfs|secret|ssh) , consulte la referencia de Dockerfile.
Nota
docker build usa Buildx y BuildKit de forma predeterminada desde Docker Engine 23.0. No necesita leer este documento a menos que desee utilizar la versión independiente con todas las funciones de BuildKit.
Utilizado por
Inicio rápido
Imagen/Registro
directorio local
archivo tar de Docker
archivo comprimido OCI
tienda de imágenes en contenedores
Construyendo un Dockerfile con buildctl
Construyendo un Dockerfile usando una interfaz externa
Configuración de Linux
Configuración de Windows
Configuración de macOS
Construir desde la fuente
Explorando el LLB
Explorando archivos Docker
Producción
Cache
En línea (empuje la imagen y el caché juntos)
Registro (enviar imagen y caché por separado)
directorio local
Caché de acciones de GitHub (experimental)
Caché S3 (experimental)
Caché de Azure Blob Storage (experimental)
Recolección de basura
Exportar caché
hash consistente
Metadatos
Activación del socket systemd
Exponer BuildKit como un servicio TCP
Equilibrio de carga
BuildKit de contenedores
Podman
Nerdctl
Kubernetes
Sin demonio
Soporte OpenTelemetry
Ejecutando BuildKit sin privilegios de root
Creación de imágenes multiplataforma
Controles de salida de color
Número de líneas de registro (para pasos activos en modo tty)
Configurando buildctl
Contribuyendo
BuildKit es utilizado por los siguientes proyectos:
Moby y Docker ( DOCKER_BUILDKIT=1 docker build )
imagen
Nube abierta FaaS
interfaz de construcción de contenedores
Tekton Pipelines (anteriormente Knative Build Templates)
la herramienta de construcción Sanic
vab
Río
kim
BolsaContenedor
compilación de Docker
Nube Okteto
Archivos terrestres terrenales
Gitpod
Daga
envd
Depósito
Espacio de nombres
Unikraft
DevZero
dacc
Para implementaciones de Kubernetes, consulte examples/kubernetes .
BuildKit se compone del demonio buildkitd y el cliente buildctl . Si bien el cliente buildctl está disponible para Linux, macOS y Windows, el demonio buildkitd solo está disponible actualmente para Linux y *Windows.
Los binarios más recientes de BuildKit están disponibles aquí para Linux, macOS y Windows.
El demonio buildkitd requiere que se instalen los siguientes componentes:
runc o crun
contenedor (si desea utilizar un trabajador contenedor)
Iniciar el demonio buildkitd : debe ejecutar buildkitd como usuario root en el host.
$ sudo buildkitd
Para ejecutar buildkitd como usuario no root, consulte docs/rootless.md .
El demonio buildkitd admite dos backends de trabajo: OCI (runc) y containerd.
De forma predeterminada, se utiliza el trabajador OCI (runc). Puede configurar --oci-worker=false --containerd-worker=true para usar el trabajador contenedor.
Estamos abiertos a agregar más backends.
Para iniciar el demonio buildkitd mediante la activación del socket systemd, puede instalar los archivos de la unidad systemd del buildkit. Ver activación del socket Systemd
El demonio buildkitd escucha la API gRPC en /run/buildkit/buildkitd.sock de forma predeterminada, pero también puede usar sockets TCP. Consulte Exponer BuildKit como un servicio TCP.
Consulte las instrucciones y notas en docs/windows.md .
La fórmula casera (no oficial) está disponible para macOS.
$ brew instalar kit de compilación
La fórmula Homebrew no contiene el demonio ( buildkitd ).
Por ejemplo, Lima se puede utilizar para iniciar el demonio dentro de una máquina virtual Linux.
plantilla de inicio de limalimactl de instalación de cerveza://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"
Para compilar BuildKit desde el código fuente, consulte .github/CONTRIBUTING.md .
Para obtener una referencia buildctl , consulte este documento.
Las compilaciones de BuildKit se basan en un formato binario intermedio llamado LLB que se utiliza para definir el gráfico de dependencia para los procesos que ejecutan parte de su compilación. tl;dr: LLB es para Dockerfile lo que LLVM IR es para C.
Clasificados como mensajes de Protobuf
ejecutable al mismo tiempo
Almacenamiento en caché eficiente
Proveedor neutral (es decir, los lenguajes que no son Dockerfile se pueden implementar fácilmente)
Consulte solver/pb/ops.proto para ver la definición de formato y consulte ./examples/README.md para ver ejemplos de aplicaciones LLB.
Actualmente, se han implementado los siguientes lenguajes de alto nivel para LLB:
Dockerfile (consulte Exploración de Dockerfiles)
Paquetes de construcción
Archivo simulado
archivo gocker
bldr (archivo paquete)
HLB
Earthfile (terrenal)
Muelle de carga (óxido)
Nada
mopy (Python)
envd (alondra)
Grasa de ballena
Bajo
kraft.yaml (Unikraft)
r2d4/llb (puerta de enlace JSON)
(abra un PR para agregar su propio idioma)
Las interfaces son componentes que se ejecutan dentro de BuildKit y convierten cualquier definición de compilación a LLB. Hay una interfaz especial llamada gateway ( gateway.v0 ) que permite usar cualquier imagen como interfaz.
Durante el desarrollo, la interfaz de Dockerfile ( dockerfile.v0 ) también forma parte del repositorio de BuildKit. En el futuro, esto se eliminará y los Dockerfiles se podrán crear utilizando una imagen externa.
buildctl compilación buildctl
--frontend=dockerfile.v0
--contexto local=.
--local dockerfile=.# orbuildctl build
--frontend=dockerfile.v0
--contexto local=.
--archivo acoplable local=.
--opt objetivo=foo
--opt build-arg:foo=bar --local expone los archivos fuente locales del cliente al constructor. context y dockerfile son los nombres que la interfaz de Dockerfile busca para el contexto de compilación y la ubicación de Dockerfile.
Si el Dockerfile tiene un nombre de archivo diferente, se puede especificar con --opt filename=./Dockerfile-alternative .
Las versiones externas de la interfaz de Dockerfile se envían a https://hub.docker.com/r/docker/dockerfile-upstream y https://hub.docker.com/r/docker/dockerfile y se pueden usar con la interfaz de puerta de enlace. . La fuente de la interfaz externa se encuentra actualmente en ./frontend/dockerfile/cmd/dockerfile-frontend pero saldrá de este repositorio en el futuro (#163). Para la compilación automática desde la rama master de este repositorio, se puede utilizar la imagen docker/dockerfile-upstream:master o docker/dockerfile-upstream:master-labs .
compilación buildctl
--frontend gateway.v0
--opt fuente=docker/dockerfile
--contexto local=.
--archivo acoplable local=.
compilación buildctl
--frontend gateway.v0
--opt fuente=docker/dockerfile
--opt contexto=https://github.com/moby/moby.git
--opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.orgDe forma predeterminada, el resultado de la compilación y el caché intermedio solo permanecerán internamente en BuildKit. Es necesario especificar una salida para recuperar el resultado.
buildctl build... --tipo de salida=imagen,nombre=docker.io/nombre de usuario/imagen,push=true
Para exportar la imagen a múltiples registros:
buildctl build... --output type=image,"name=docker.io/username/image,docker.io/username2/image2",push=true
Para exportar el caché incrustado con la imagen y enviarlos al registro juntos, se requiere el tipo registry para importar el caché, debe especificar --export-cache type=inline y --import-cache type=registry,ref=... . Para exportar el caché a un local directamente, debe especificar --export-cache type=local . Detalles en Exportar caché.
buildctl construir... --tipo de salida=imagen,nombre=docker.io/nombre de usuario/imagen,push=true --export-cache tipo=en línea --import-cache tipo=registro,ref=docker.io/nombre de usuario/imagen
Claves admitidas por la salida de imagen:
name= : especifica los nombres de las imágenes
push=true : empujar después de crear la imagen
push-by-digest=true : enviar imagen sin nombre
registry.insecure=true : enviar al registro HTTP inseguro
oci-mediatypes=true : use tipos de medios OCI en la configuración JSON en lugar de Docker
unpack=true : descomprime la imagen después de su creación (para usar con contenedores)
dangling-name-prefix= : nombre de la imagen con prefix@ , usado para imágenes anónimas
name-canonical=true : agrega un nombre canónico adicional name@
compression= : elija el tipo de compresión para las capas recién creadas y almacenadas en caché, gzip es el valor predeterminado. estargz debe usarse con oci-mediatypes=true .
compression-level= : nivel de compresión para gzip, estargz (0-9) y zstd (0-22)
rewrite-timestamp=true : reescribe las marcas de tiempo del archivo al valor SOURCE_DATE_EPOCH . Consulte docs/build-repro.md para saber cómo especificar el valor SOURCE_DATE_EPOCH .
force-compression=true : aplica con fuerza la opción de compression a todas las capas (incluidas las capas ya existentes)
store=true : almacena las imágenes de resultados en el almacén de imágenes del trabajador (por ejemplo, en un contenedor) y garantiza que la imagen tenga todos los blobs en el almacén de contenido (valor predeterminado, true ). Se ignora si el trabajador no tiene un almacén de imágenes (por ejemplo, trabajador OCI).
annotation. : adjunte una anotación con la key y value respectivos a la imagen construida
Usando las sintaxis extendidas, annotation- , annotation[ y ambos combinados con annotation- , permite configurar exactamente dónde adjuntar la anotación.
manifest (el valor predeterminado), manifest-descriptor , index y index-descriptor
platform , consulte docs/multi-platform.md .
Consulte docs/annotations.md para obtener más detalles.
Si se requieren credenciales, buildctl intentará leer el archivo de configuración de Docker $DOCKER_CONFIG/config.json . $DOCKER_CONFIG por defecto es ~/.docker .
El cliente local copiará los archivos directamente al cliente. Esto es útil si BuildKit se utiliza para crear algo más que imágenes de contenedores.
buildctl build... --tipo de salida=local,dest=ruta/a/dir-salida
Para exportar archivos específicos, utilice compilaciones de varias etapas con una etapa inicial y copie los archivos necesarios en esa etapa con COPY --from .
...DESDE cero como testresultCOPY --from=builder /usr/src/app/testresult.xml . ...
buildctl build... --opt target=testresult --tipo de salida=local,dest=ruta/a/dir-salida
Con una compilación multiplataforma, se creará una subcarpeta que coincida con cada plataforma de destino en el directorio de destino:
FROM togetherbox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROM scratchCOPY --from=build /out /
$ buildctl construir
--frontend dockerfile.v0
--opt plataforma=linux/amd64,linux/arm64
--tipo de salida=local,dest=./bin/release
$ árbol ./bin
./papelera/
└── liberar
├── linux_amd64
│ └── hola-linux-amd64
└── linux_arm64
└── hola-linux-arm64 Puede configurar platform-split=false para fusionar archivos de todas las plataformas en el mismo directorio:
$ buildctl construir
--frontend dockerfile.v0
--opt plataforma=linux/amd64,linux/arm64
--tipo de salida=local,dest=./bin/release,platform-split=false
$ árbol ./bin
./papelera/
└── liberar
├── hola-linux-amd64
└── hola-linux-arm64El exportador de tar es similar al exportador local pero transfiere los archivos a través de un tarball.
buildctl build... --tipo de salida=tar,dest=out.tar buildctl build... --tipo de salida=tar > out.tar
# El tarball exportado también es compatible con la compilación OCI specbuildctl... --output type=docker,name=myimage | carga de la ventana acoplable
buildctl build... --tipo de salida=oci,dest=ruta/a/salida.tar buildctl build... --tipo de salida=oci > salida.tar
Es necesario utilizar el trabajador en contenedor.
buildctl build... --tipo de salida=imagen,nombre=docker.io/nombre de usuario/imagen ctr --namespace=imágenes del kit de compilación ls
Para cambiar el espacio de nombres del contenedor, debe cambiar worker.containerd.namespace en /etc/buildkit/buildkitd.toml .
Para mostrar el caché de compilación local ( /var/lib/buildkit ):
buildctl du -v
Para podar la caché de compilación local:
podar buildctl
Consulte ./docs/buildkitd.toml.md .
BuildKit admite los siguientes exportadores de caché:
inline : incrusta el caché en la imagen y los envía juntos al registro
registry : envíe la imagen y el caché por separado
local : exportar a un directorio local
gha : exportar a la caché de acciones de GitHub
En la mayoría de los casos, desea utilizar el exportador de caché inline . Sin embargo, tenga en cuenta que el exportador de caché inline solo admite el modo de caché min . Para habilitar el modo de caché max , envíe la imagen y el caché por separado utilizando el exportador de caché registry .
Los exportadores inline y registry almacenan el caché en el registro. Para importar el caché, type=registry es suficiente para ambos, ya que no es necesario especificar el formato del caché.
buildctl construir... --tipo de salida=imagen,nombre=docker.io/nombre de usuario/imagen,push=true --export-cache tipo=en línea --import-cache tipo=registro,ref=docker.io/nombre de usuario/imagen
Tenga en cuenta que el caché en línea no se importa a menos que se proporcione --import-cache type=registry,ref=...
La caché en línea incorpora metadatos de la caché en la configuración de la imagen. Las capas de la imagen quedarán intactas en comparación con la imagen sin información de caché.
BuildKit integrado en Docker ( DOCKER_BUILDKIT=1 docker build ) y docker buildx requieren que se especifique --build-arg BUILDKIT_INLINE_CACHE=1 para habilitar el exportador de caché inline . Sin embargo, el buildctl independiente NO requiere --opt build-arg:BUILDKIT_INLINE_CACHE=1 y el build-arg simplemente se ignora.
buildctl construir... --tipo de salida=imagen,nombre=localhost:5000/myrepo:imagen,push=true --export-cache tipo=registro,ref=localhost:5000/myrepo:buildcache --import-cache tipo=registro,ref=localhost:5000/myrepo:buildcache
--export-cache :
type=registry
mode= : especifica las capas de caché para exportar (predeterminado: min )
min : solo exporta capas para la imagen resultante
max : exporta todas las capas de todos los pasos intermedios
ref= : especifica la referencia del repositorio para almacenar la caché, por ejemplo, docker.io/user/image:tag
image-manifest= : si se exporta el manifiesto de caché como un manifiesto de imagen compatible con OCI en lugar de una lista/índice de manifiesto (predeterminado: false , debe usarse con oci-mediatypes=true )
oci-mediatypes= : si se deben usar tipos de medios OCI en manifiestos exportados (predeterminado: true , desde BuildKit v0.8 )
compression= : elija el tipo de compresión para las capas recién creadas y almacenadas en caché, gzip es el valor predeterminado. estargz y zstd deben usarse con oci-mediatypes=true
compression-level= : elige el nivel de compresión para gzip, estargz (0-9) y zstd (0-22)
force-compression=true : aplica por la fuerza la opción compression a todas las capas
ignore-error= : especifica si el error se ignora en caso de que falle la exportación de caché (predeterminado: false )
--import-cache :
type=registry
ref= : especifica la referencia del repositorio desde el que recuperar el caché, por ejemplo, docker.io/user/image:tag
buildctl build... --export-cache tipo=local,dest=ruta/al/dir-salida buildctl build... --import-cache tipo=local,src=ruta/a/dir-entrada
El diseño del directorio se ajusta a OCI Image Spec v1.0.
--export-cache :
type=local
mode= : especifica las capas de caché para exportar (predeterminado: min )
min : solo exporta capas para la imagen resultante
max : exporta todas las capas de todos los pasos intermedios
dest= : directorio de destino para el exportador de caché
tag= : especifica la etiqueta personalizada de la imagen para escribir en el índice local (predeterminado: latest )
image-manifest= : si se exporta el manifiesto de caché como un manifiesto de imagen compatible con OCI en lugar de una lista/índice de manifiesto (predeterminado: false , debe usarse con oci-mediatypes=true )
oci-mediatypes= : si se deben utilizar tipos de medios OCI en manifiestos exportados (valor predeterminado true , desde BuildKit v0.8 )
compression= : elija el tipo de compresión para las capas recién creadas y almacenadas en caché, gzip es el valor predeterminado. estargz y zstd deben usarse con oci-mediatypes=true .
compression-level= : nivel de compresión para gzip, estargz (0-9) y zstd (0-22)
force-compression=true : aplica por la fuerza la opción compression a todas las capas
ignore-error= : especifica si el error se ignora en caso de que falle la exportación de caché (predeterminado: false )
--import-cache :
type=local
src= : directorio de origen para el importador de caché
tag= : especifica la etiqueta personalizada de la imagen para leer desde el índice local (predeterminado: latest )
digest=sha256: : especifica un resumen explícito de la lista de manifiestos para importar
buildctl construir... --tipo de salida=imagen,nombre=docker.io/nombre de usuario/imagen,push=true --tipo de caché de exportación = gha --tipo de caché de importación = gha
La caché de GitHub Actions guarda tanto los metadatos como las capas de la caché en el servicio de caché de GitHub. Actualmente, esta caché tiene un límite de tamaño de 10 GB que se comparte entre diferentes cachés del repositorio. Si excede este límite, GitHub guardará su caché pero comenzará a desalojar cachés hasta que el tamaño total sea inferior a 10 GB. Reciclar cachés con demasiada frecuencia puede generar tiempos de ejecución más lentos en general.
De manera similar al uso de acciones/caché, los cachés tienen un alcance por rama, y las ramas predeterminadas y de destino están disponibles para cada rama.
Se requieren los siguientes atributos para autenticarse en la API del servicio GitHub Actions Cache:
url : URL del servidor de caché (predeterminado $ACTIONS_CACHE_URL )
token : token de acceso (predeterminado $ACTIONS_RUNTIME_TOKEN )
Este tipo de caché se puede utilizar con Docker Build Push Action, donde url y token se configurarán automáticamente. Para usar este backend en un paso run en línea, debe incluir Crazy-max/ghaction-github-runtime en su flujo de trabajo para exponer el tiempo de ejecución.
--export-cache :
type=gha
mode= : especifica las capas de caché para exportar (predeterminado: min )
min : solo exporta capas para la imagen resultante
max : exporta todas las capas de todos los pasos intermedios
scope= : a qué objeto de caché de alcance pertenece ( buildkit predeterminado)
ignore-error= : especifica si el error se ignora en caso de que falle la exportación de caché (predeterminado: false )
timeout= : establece la duración del tiempo de espera para la exportación de caché (predeterminado: 10m ).
--import-cache :
type=gha
scope= : a qué objeto de caché de alcance pertenece ( buildkit predeterminado)
timeout= : establece la duración del tiempo de espera para la importación de caché (predeterminado: 10m ).
buildctl construir... --tipo de salida=imagen,nombre=docker.io/nombre de usuario/imagen,push=true --export-cache tipo=s3,región=eu-west-1,bucket=my_bucket,name=my_image --import-cache type=s3,region=eu-west-1,bucket=my_bucket,name=my_image
Se requieren los siguientes atributos:
bucket : depósito de AWS S3 (predeterminado: $AWS_BUCKET )
region : región de AWS (predeterminada: $AWS_REGION )
Lugares de almacenamiento:
blobs: s3:// , valor predeterminado: s3://
manifiestos: s3:// , predeterminado: s3://
Configuración S3:
blobs_prefix : prefijo global para almacenar/leer blobs en s3 (predeterminado: blobs/ )
manifests_prefix : prefijo global para almacenar/leer manifiestos en s3 (predeterminado: manifests/ )
endpoint_url : especifica un punto final S3 específico (predeterminado: vacío)
use_path_style : si se establece en true , coloque el nombre del depósito en la URL en lugar de en el nombre de host (predeterminado: false )
Autenticación de AWS:
La forma más sencilla es utilizar un perfil de instancia de IAM. Otras opciones son:
Cualquier sistema que utilice variables de entorno/archivos de configuración compatibles con AWS Go SDK. La configuración debe estar disponible para el demonio del kit de compilación, no para el cliente.
Usando los siguientes atributos:
access_key_id : ID de clave de acceso
secret_access_key : clave de acceso secreta
session_token : token de sesión
--export-cache :
type=s3
mode= : especifica las capas de caché para exportar (predeterminado: min )
min : solo exporta capas para la imagen resultante
max : exporta todas las capas de todos los pasos intermedios
prefix= : establece el prefijo global para almacenar/leer archivos en s3 (predeterminado: vacío)
name= : especifica el nombre del manifiesto a usar ( buildkit predeterminado)
Se pueden especificar varios nombres de manifiesto al mismo tiempo, separados por ; . El caso de uso estándar es usar git sha1 como nombre y el nombre de la rama como duplicado, y cargar ambos con 2 comandos import-cache .
ignore-error= : especifica si el error se ignora en caso de que falle la exportación de caché (predeterminado: false )
touch_refresh=24h : en lugar de cargarse nuevamente cuando no se modifican, los archivos blobs se "tocarán" en s3 cada touch_refresh , el valor predeterminado es 24h. Debido a esto, se puede establecer una política de caducidad en el depósito de S3 para limpiar archivos inútiles automáticamente. Los archivos de manifiestos se reescriben sistemáticamente, no es necesario tocarlos.
upload_parallelism=4 : este parámetro cambia la cantidad de capas cargadas en s3 en paralelo. Cada capa individual se carga con 5 subprocesos, utilizando el administrador de carga proporcionado por el SDK de AWS.
--import-cache :
type=s3
prefix= : establece el prefijo global para almacenar/leer archivos en s3 (predeterminado: vacío)
blobs_prefix= : establece el prefijo global para almacenar/leer blobs en s3 (predeterminado: blobs/ )
manifests_prefix= : establece el prefijo global para almacenar/leer manifiestos en s3 (predeterminado: manifests/ )
name= : nombre del manifiesto a utilizar ( buildkit predeterminado)
buildctl construir... --tipo de salida=imagen,nombre=docker.io/nombre de usuario/imagen,push=true --export-cache tipo=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image --import-cache tipo=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image
Se requieren los siguientes atributos:
account_url : URL de la cuenta de Azure Blob Storage (predeterminada: $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL ).
Lugares de almacenamiento:
blobs:
manifiestos:
Configuración de Azure Blob Storage:
container : el nombre del contenedor de Azure Blob Storage (predeterminado: buildkit-cache o $BUILDKIT_AZURE_STORAGE_CONTAINER si está configurado)
blobs_prefix : prefijo global para almacenar/leer blobs en el contenedor de Azure Blob Storage ( blobs/ ).
manifests_prefix : prefijo global para almacenar/leer blobs en el contenedor de Azure Blob Storage ( manifests/ ).
Autenticación de Azure Blob Storage:
Hay dos opciones admitidas para la autenticación de Azure Blob Storage:
Cualquier sistema que utilice variables de entorno compatibles con Azure SDK for Go. La configuración debe estar disponible para el demonio del kit de compilación, no para el cliente.
Clave de acceso secreta, mediante el atributo secret_access_key para especificar la clave de cuenta principal o secundaria para su cuenta de Azure Blob Storage. Claves de cuenta de Azure Blob Storage
Nota
El nombre de la cuenta también se puede especificar con el atributo account_name (o $BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ) si no forma parte del host de URL de la cuenta.
--export-cache :
type=azblob
mode= : especifica las capas de caché para exportar (predeterminado: min )
min : solo exporta capas para la imagen resultante
max : exporta todas las capas de todos los pasos intermedios
prefix= : establece el prefijo global para almacenar/leer archivos en el contenedor de Azure Blob Storage (
name= : especifica el nombre del manifiesto a usar (predeterminado: buildkit )
Se pueden especificar varios nombres de manifiesto al mismo tiempo, separados por ; . El caso de uso estándar es usar git sha1 como nombre y el nombre de la rama como duplicado, y cargar ambos con 2 comandos import-cache .
ignore-error= : especifica si el error se ignora en caso de que falle la exportación de caché (predeterminado: false )
--import-cache :
type=azblob
prefix= : establece el prefijo global para almacenar/leer archivos en el contenedor de Azure Blob Storage (
blobs_prefix= : establece el prefijo global para almacenar/leer blobs en el contenedor de Azure Blob Storage ( blobs/ ).
manifests_prefix= : establece el prefijo global para almacenar/leer manifiestos en el contenedor de Azure Blob Storage ( manifests/ )
name= : nombre del manifiesto a utilizar (predeterminado: buildkit )
Si tiene varias instancias del demonio BuildKit, pero no desea utilizar el registro para compartir el caché en todo el clúster, considere equilibrar la carga del lado del cliente mediante hash consistente.
Consulte ./examples/kubernetes/consistenthash .
Para generar metadatos de compilación, como el resumen de la imagen, pase la marca --metadata-file . Los metadatos se escribirán como un objeto JSON en el archivo especificado. El directorio del archivo especificado ya debe existir y poder escribirse.
buildctl build... --metadata-file metadata.json
jq'.' metadatos.json
{ "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "containerimage.descriptor": {"annotations": { "config.digest": 7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": " 2022-02-08T21:28:03Z"},"digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3","mediaType": "application/vnd.oci.image.manifest.v1+json","size": 506
}, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"} En sistemas basados en Systemd, puede comunicarse con el demonio mediante la activación del socket Systemd, use buildkitd --addr fd:// . Puede encontrar ejemplos del uso de la activación de socket Systemd con BuildKit y Systemd en ./examples/systemd .
El demonio buildkitd puede escuchar la API gRPC en un socket TCP.
Se recomienda encarecidamente crear certificados TLS tanto para el demonio como para el cliente (mTLS). Habilitar TCP sin mTLS es peligroso porque los contenedores ejecutores (también conocidos como contenedores Dockerfile RUN ) también pueden llamar a la API BuildKit.
kit de construcción --dirección tcp://0.0.0.0:1234 --tlscacert /ruta/a/ca.pem --tlscert /ruta/a/cert.pem --tlskey /ruta/a/key.pem
buildctl --addr tcp://ejemplo.com:1234 --tlscacert /ruta/a/ca.pem --tlscert /ruta/a/clientcert.pem --tlskey /ruta/a/clientkey.pem construir ...
buildctl build se puede invocar contra demonios buildkitd con equilibrio de carga aleatoria.
Consulte también Hash consistente para equilibrio de carga del lado del cliente.
BuildKit también se puede utilizar ejecutando el demonio buildkitd dentro de un contenedor Docker y accediendo a él de forma remota.
Proporcionamos las imágenes del contenedor como moby/buildkit :
moby/buildkit:latest : creado a partir de la última versión regular
moby/buildkit:rootless : igual que latest pero se ejecuta como un usuario sin privilegios, consulte docs/rootless.md
moby/buildkit:master : construido desde la rama master
moby/buildkit:master-rootless : igual que master pero se ejecuta como un usuario sin privilegios, consulte docs/rootless.md
Para ejecutar un demonio en un contenedor:
docker run -d --name buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd buildctl construir --ayuda
Para conectarse a un demonio BuildKit que se ejecuta en un contenedor Podman, use podman-container:// en lugar de docker-container:// .
podman run -d --name buildkitd --privileged moby/buildkit:latest buildctl --addr=podman-container://buildkitd build --frontend dockerfile.v0 --local context=. --archivo acoplable local=. --tipo de salida=oci | podman carga foo
sudo no es necesario.
Para conectarse a un demonio BuildKit que se ejecuta en un contenedor Nerdctl, use nerdctl-container:// en lugar de docker-container:// .
nerdctl run -d --name buildkitd --privileged moby/buildkit:latest buildctl --addr=nerdctl-container://buildkitd build --frontend dockerfile.v0 --local context=. --archivo acoplable local=. --tipo de salida=oci | carga nerdctl
sudo no es necesario.
Para implementaciones de Kubernetes, consulte examples/kubernetes .
Para ejecutar el cliente y un demonio efímero en un solo contenedor ("modo sin demonio"):
ejecución de la ventana acoplable
-él
--rm
--privilegiado
-v /ruta/al/dir:/tmp/trabajo
--punto de entrada buildctl-daemonless.sh
moby/buildkit: maestro
construir
--frontend dockerfile.v0
--contexto local=/tmp/trabajo
--local dockerfile=/tmp/trabajoo
ejecución de la ventana acoplable
-él
--rm
--security-opt seccomp=inlimitado
--security-opt apparmor=ilimitado
-e BUILDKITD_FLAGS=--oci-worker-sin-proceso-sandbox
-v /ruta/al/dir:/tmp/trabajo
--punto de entrada buildctl-daemonless.sh
moby/buildkit:master-rootless
construir
--Interfaz
archivo acoplable.v0
--contexto local=/tmp/trabajo
--local dockerfile=/tmp/trabajo BuildKit admite OpenTelemetry para la API gRPC de buildkitd y los comandos buildctl. Para capturar el seguimiento de Jaeger, establezca la variable de entorno JAEGER_TRACE en la dirección de colección.
docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# reinicie buildkitd y buildctl para que sepan JAEGER_TRACE# cualquier comando buildctl debe rastrearse hasta http:/ /127.0.0.1:16686/
En Windows, si está ejecutando Jaeger fuera de un contenedor,
jaeger-all-in-one.exe, configure la variable de entornosetx -m JAEGER_TRACE "0.0.0.0:6831", reiniciebuildkitden una nueva terminal y los rastros serán recogidos automáticamente.
Consulte docs/rootless.md .
Consulte docs/multi-platform.md .
buildctl buildctl admite la modificación de los colores que se utilizan para enviar información al terminal. Puede configurar la variable de entorno BUILDKIT_COLORS en algo como run=green:warning=yellow:error=red:cancel=255,165,0 para configurar los colores que le gustaría usar. Establecer NO_COLOR en cualquier valor deshabilitará cualquier salida coloreada según lo recomendado por no-color.org.
Los errores de análisis se informarán pero se ignorarán. Esto dará como resultado que se utilicen valores de color predeterminados cuando sea necesario.
La lista de colores predefinidos.
Puede cambiar cuántas líneas de registro son visibles para los pasos activos en el modo tty configurando BUILDKIT_TTY_LOG_LINES en un número (predeterminado: 6).
¿Quieres contribuir a BuildKit? ¡Impresionante! Puede encontrar información sobre cómo contribuir a este proyecto en CONTRIBUTING.md
