kit de construção
0.17.0
BuildKit é um kit de ferramentas para converter código-fonte para construir artefatos de maneira eficiente, expressiva e repetível.
Principais recursos:
Coleta automática de lixo
Formatos de front-end extensíveis
Resolução de dependência simultânea
Cache de instruções eficiente
Construir importação/exportação de cache
Invocações de trabalho de construção aninhadas
Trabalhadores distribuíveis
Vários formatos de saída
Arquitetura conectável
Execução sem privilégios de root
Leia a proposta de moby/moby#32925
Postagem introdutória no blog https://blog.mobyproject.org/introduzindo-buildkit-17e056cc5317
Junte-se ao canal #buildkit no Docker Community Slack
Observação
Se você estiver visitando este repositório para usar recursos do Dockerfile somente do BuildKit, como RUN --mount=type=(bind|cache|tmpfs|secret|ssh) , consulte a referência do Dockerfile.
Observação
docker build usa Buildx e BuildKit por padrão desde Docker Engine 23.0. Você não precisa ler este documento, a menos que queira usar a versão autônoma completa do BuildKit.
Usado por
Início rápido
Imagem/Registro
Diretório local
Tarball do Docker
Tarball OCI
armazenamento de imagens em contêiner
Construindo um Dockerfile com buildctl
Construindo um Dockerfile usando frontend externo
Configuração do Linux
Configuração do Windows
Configuração do macOS
Construir a partir da fonte
Explorando LLB
Explorando Dockerfiles
Saída
Cache
Inline (enviar imagem e cache juntos)
Registro (enviar imagem e cache separadamente)
Diretório local
Cache de ações do GitHub (experimental)
Cache S3 (experimental)
Cache do Armazenamento de Blobs do Azure (experimental)
Coleta de lixo
Exportar cache
Hash consistente
Metadados
Ativação do soquete Systemd
Expor o BuildKit como um serviço TCP
Balanceamento de carga
Contentorizando BuildKit
Podman
Nerdctl
Kubernetes
Sem daemon
Suporte OpenTelemetry
Executando o BuildKit sem privilégios de root
Construindo imagens multiplataforma
Controles de saída de cores
Número de linhas de log (para etapas ativas no modo tty)
Configurando buildctl
Contribuindo
BuildKit é usado pelos seguintes projetos:
Moby e Docker ( DOCKER_BUILDKIT=1 docker build )
imagem
Nuvem OpenFaaS
interface de construção de contêiner
Tekton Pipelines (anteriormente Knative Build Templates)
a ferramenta de construção Sanic
vab
rio
Kim
BolsaContainer
Docker build x
Nuvem Okteto
Arquivos terrestres terrestres
Gitpod
Punhal
ambiente
Depósito
Espaço para nome
Unikraft
DevZero
dac
Para implantações do Kubernetes, consulte examples/kubernetes .
BuildKit é composto pelo daemon buildkitd e pelo cliente buildctl . Embora o cliente buildctl esteja disponível para Linux, macOS e Windows, o daemon buildkitd está disponível apenas para Linux e *Windows atualmente.
Os binários mais recentes do BuildKit estão disponíveis aqui para Linux, macOS e Windows.
O daemon buildkitd requer a instalação dos seguintes componentes:
runc ou crun
containerd (se você quiser usar o trabalhador containerd)
Iniciando o daemon buildkitd : Você precisa executar buildkitd como usuário root no host.
$ sudo buildkitd
Para executar buildkitd como um usuário não root, consulte docs/rootless.md .
O daemon buildkitd oferece suporte a dois back-ends de trabalho: OCI (runc) e containerd.
Por padrão, o trabalhador OCI (runc) é usado. Você pode definir --oci-worker=false --containerd-worker=true para usar o trabalhador containerd.
Estamos abertos para adicionar mais back-ends.
Para iniciar o daemon buildkitd usando a ativação do soquete systemd, você pode instalar os arquivos de unidade systemd do buildkit. Consulte ativação do soquete Systemd
O daemon buildkitd escuta a API gRPC em /run/buildkit/buildkitd.sock por padrão, mas você também pode usar soquetes TCP. Consulte Expor o BuildKit como um serviço TCP.
Consulte instruções e notas em docs/windows.md .
A fórmula Homebrew (não oficial) está disponível para macOS.
$ brew install buildkit
A fórmula Homebrew não contém o daemon ( buildkitd ).
Por exemplo, Lima pode ser usado para iniciar o daemon dentro de uma VM Linux.
brew install limalimactl start template://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"
Para construir o BuildKit a partir do código-fonte, consulte .github/CONTRIBUTING.md .
Para obter uma referência buildctl , consulte este documento.
As compilações do BuildKit são baseadas em um formato intermediário binário chamado LLB que é usado para definir o gráfico de dependência para processos que executam parte de sua compilação. dr: LLB está para o Dockerfile o que LLVM IR está para C.
Marshaled como mensagens Protobuf
Executável simultaneamente
Armazenável em cache com eficiência
Fornecedor neutro (ou seja, linguagens não Dockerfile podem ser facilmente implementadas)
Consulte solver/pb/ops.proto para obter a definição do formato e consulte ./examples/README.md para obter exemplos de aplicativos LLB.
Atualmente, as seguintes linguagens de alto nível foram implementadas para LLB:
Dockerfile (consulte Explorando Dockerfiles)
Pacotes de construção
Arquivo simulado
Arquivo Gocker
bldr (arquivo Pkg)
HLB
Arquivo Terrestre (Terreno)
Cais de carga (ferrugem)
Nix
mopy (Python)
envd (estrela)
Gordura
Baixo
kraft.yaml (Unikraft)
r2d4/llb (gateway JSON)
(abra um PR para adicionar seu próprio idioma)
Frontends são componentes executados dentro do BuildKit e convertem qualquer definição de compilação em LLB. Existe um frontend especial chamado gateway ( gateway.v0 ) que permite usar qualquer imagem como frontend.
Durante o desenvolvimento, o frontend do Dockerfile ( dockerfile.v0 ) também faz parte do repositório BuildKit. No futuro, isso será removido e os Dockerfiles poderão ser construídos usando uma imagem externa.
buildctl compilação buildctl
--frontend=dockerfile.v0
--contexto local=.
--local dockerfile=.# compilação orbuildctl
--frontend=dockerfile.v0
--contexto local=.
--local dockerfile=.
--opt alvo=foo
--opt build-arg:foo=bar --local expõe arquivos de origem locais do cliente para o construtor. context e dockerfile são os nomes que o frontend do Dockerfile procura para o contexto de construção e a localização do Dockerfile.
Se o Dockerfile tiver um nome de arquivo diferente, ele poderá ser especificado com --opt filename=./Dockerfile-alternative .
Versões externas do frontend do Dockerfile são enviadas para https://hub.docker.com/r/docker/dockerfile-upstream e https://hub.docker.com/r/docker/dockerfile e podem ser usadas com o frontend do gateway . A fonte do frontend externo está atualmente localizada em ./frontend/dockerfile/cmd/dockerfile-frontend , mas sairá deste repositório no futuro (#163). Para construção automática a partir do branch master deste repositório, a imagem docker/dockerfile-upstream:master ou docker/dockerfile-upstream:master-labs pode ser usada.
compilação buildctl
--frontend gateway.v0
--opt fonte=docker/dockerfile
--contexto local=.
--local dockerfile=.
compilação buildctl
--frontend gateway.v0
--opt fonte=docker/dockerfile
--opt context=https://github.com/moby/moby.git
--opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.orgPor padrão, o resultado da compilação e o cache intermediário permanecerão apenas internamente no BuildKit. Uma saída precisa ser especificada para recuperar o resultado.
buildctl build ... --output type=image,name=docker.io/username/image,push=true
Para exportar a imagem para vários registros:
buildctl build ... --output type=image,"name=docker.io/username/image,docker.io/username2/image2",push=true
Para exportar o cache incorporado com a imagem e enviá-los para o registro juntos, o tipo registry é necessário para importar o cache, você deve especificar --export-cache type=inline e --import-cache type=registry,ref=... . Para exportar o cache diretamente para um local, você deve especificar --export-cache type=local . Detalhes no cache de exportação.
buildctl construir... --output type=image,name=docker.io/username/image,push=true --export-cache type = embutido --import-cache type=registry,ref=docker.io/username/image
Chaves suportadas pela saída de imagem:
name= : especifique o(s) nome(s) da(s) imagem(s)
push=true : push após criar a imagem
push-by-digest=true : envia imagem sem nome
registry.insecure=true : envia para registro HTTP inseguro
oci-mediatypes=true : use tipos de mídia OCI na configuração JSON em vez do Docker
unpack=true : descompacta a imagem após a criação (para uso com containerd)
dangling-name-prefix= : nomeia a imagem com prefix@ , usado para imagens anônimas
name-canonical=true : adicione nome canônico adicional name@
compression= : escolha o tipo de compactação para camadas recém-criadas e armazenadas em cache, gzip é o valor padrão. estargz deve ser usado com oci-mediatypes=true .
compression-level= : nível de compactação para gzip, estargz (0-9) e zstd (0-22)
rewrite-timestamp=true : reescreva os carimbos de data e hora do arquivo para o valor SOURCE_DATE_EPOCH . Consulte docs/build-repro.md para saber como especificar o valor SOURCE_DATE_EPOCH .
force-compression=true : aplica a opção compression à força a todas as camadas (incluindo camadas já existentes)
store=true : armazena as imagens resultantes no armazenamento de imagens do trabalhador (por exemplo, containerd), bem como garante que a imagem tenha todos os blobs no armazenamento de conteúdo (padrão true ). Ignorado se o trabalhador não tiver armazenamento de imagens (por exemplo, trabalhador OCI).
annotation. : anexe uma anotação com a respectiva key e value à imagem construída
Usando as sintaxes estendidas, annotation- , annotation[ e ambos combinados com annotation- , permite configurar exatamente onde anexar a anotação.
manifest (o padrão), manifest-descriptor , index e index-descriptor
platform , consulte docs/multi-platform.md .
Consulte docs/annotations.md para obter mais detalhes.
Se forem necessárias credenciais, buildctl tentará ler o arquivo de configuração do Docker $DOCKER_CONFIG/config.json . O padrão $DOCKER_CONFIG é ~/.docker .
O cliente local copiará os arquivos diretamente para o cliente. Isso é útil se o BuildKit estiver sendo usado para construir algo diferente de imagens de contêiner.
buildctl build ... --output type=local,dest=caminho/para/output-dir
Para exportar arquivos específicos, use compilações de vários estágios com um estágio inicial e copie os arquivos necessários para esse estágio com COPY --from .
... DO zero como testresultCOPY --from=builder /usr/src/app/testresult.xml . ...
buildctl build ... --opt target=testresult --output type=local,dest=caminho/para/output-dir
Com uma construção multiplataforma, uma subpasta correspondente a cada plataforma de destino será criada no diretório de destino:
FROM busybox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROM scratchCOPY --from=build /out /
$ buildctl compilação
--frontend dockerfile.v0
--opt plataforma=linux/amd64,linux/arm64
--output type=local,dest=./bin/release
$ árvore ./bin
./bin/
└── liberar
├── linux_amd64
│ └── olá-linux-amd64
└──linux_arm64
└── olá-linux-arm64 Você pode definir platform-split=false para mesclar arquivos de todas as plataformas no mesmo diretório:
$ buildctl compilação
--frontend dockerfile.v0
--opt plataforma=linux/amd64,linux/arm64
--output type=local,dest=./bin/release,platform-split=false
$ árvore ./bin
./bin/
└── liberar
├── olá-linux-amd64
└── olá-linux-arm64O exportador Tar é semelhante ao exportador local, mas transfere os arquivos por meio de um tarball.
buildctl build ... --output type=tar,dest=out.tar buildctl build ... --output type=tar > out.tar
# tarball exportado também é compatível com OCI specbuildctl build ... --output type=docker,name=myimage | carga da janela de encaixe
buildctl build ... --output type=oci,dest=caminho/para/output.tar buildctl build ... --output type=oci > output.tar
O trabalhador containerd precisa ser usado
buildctl build ... --output type=image,name=docker.io/username/image ctr --namespace=buildkit imagens ls
Para alterar o namespace containerd, você precisa alterar worker.containerd.namespace em /etc/buildkit/buildkitd.toml .
Para mostrar o cache de compilação local ( /var/lib/buildkit ):
buildctl du -v
Para limpar o cache de compilação local:
ameixa buildctl
Consulte ./docs/buildkitd.toml.md .
BuildKit oferece suporte aos seguintes exportadores de cache:
inline : incorpore o cache na imagem e envie-os para o registro juntos
registry : envie a imagem e o cache separadamente
local : exporta para um diretório local
gha : exportar para cache de ações do GitHub
Na maioria dos casos, você deseja usar o exportador de cache inline . No entanto, observe que o exportador de cache inline suporta apenas o modo de cache min . Para ativar o modo de cache max , envie a imagem e o cache separadamente usando o exportador de cache registry .
os exportadores inline e registry armazenam o cache no registro. Para importar o cache, type=registry é suficiente para ambos, pois não é necessário especificar o formato do cache.
buildctl construir... --output type=image,name=docker.io/username/image,push=true --export-cache type = embutido --import-cache type=registry,ref=docker.io/username/image
Observe que o cache embutido não é importado, a menos que --import-cache type=registry,ref=... seja fornecido.
O cache embutido incorpora metadados de cache na configuração da imagem. As camadas da imagem permanecerão intactas em comparação com a imagem sem informações de cache.
BuildKit integrado ao Docker ( DOCKER_BUILDKIT=1 docker build ) e docker buildx requer que --build-arg BUILDKIT_INLINE_CACHE=1 seja especificado para ativar o exportador de cache inline . No entanto, o buildctl independente NÃO requer --opt build-arg:BUILDKIT_INLINE_CACHE=1 e o build-arg é simplesmente ignorado.
buildctl construir... --output type=image,name=localhost:5000/myrepo:image,push=true --export-cache type=registry,ref=localhost:5000/myrepo:buildcache --import-cache type=registry,ref=localhost:5000/myrepo:buildcache
--export-cache :
type=registry
mode= : especifica camadas de cache para exportar (padrão: min )
min : exporta apenas camadas para a imagem resultante
max : exporta todas as camadas de todas as etapas intermediárias
ref= : especifique a referência do repositório para armazenar o cache, por exemplo, docker.io/user/image:tag
image-manifest= : se deve exportar o manifesto de cache como um manifesto de imagem compatível com OCI em vez de uma lista/índice de manifesto (padrão: false , deve ser usado com oci-mediatypes=true )
oci-mediatypes= : se deve usar tipos de mídia OCI em manifestos exportados (padrão: true , desde BuildKit v0.8 )
compression= : escolha o tipo de compactação para camadas recém-criadas e armazenadas em cache, gzip é o valor padrão. estargz e zstd devem ser usados com oci-mediatypes=true
compression-level= : escolha o nível de compactação para gzip, estargz (0-9) e zstd (0-22)
force-compression=true : aplica à força a opção compression a todas as camadas
ignore-error= : especifique se o erro será ignorado caso a exportação do cache falhe (padrão: false )
--import-cache opções:
type=registry
ref= : especifique a referência do repositório para recuperar o cache, por exemplo, docker.io/user/image:tag
buildctl build ... --export-cache type=local,dest=caminho/para/output-dir buildctl build ... --import-cache type=local,src=caminho/para/diretório de entrada
O layout do diretório está em conformidade com o OCI Image Spec v1.0.
--export-cache :
type=local
mode= : especifica camadas de cache para exportar (padrão: min )
min : exporta apenas camadas para a imagem resultante
max : exporta todas as camadas de todas as etapas intermediárias
dest= : diretório de destino para exportador de cache
tag= : especifica a tag personalizada da imagem para gravar no índice local (padrão: latest )
image-manifest= : se deve exportar o manifesto de cache como um manifesto de imagem compatível com OCI em vez de uma lista/índice de manifesto (padrão: false , deve ser usado com oci-mediatypes=true )
oci-mediatypes= : se deve usar tipos de mídia OCI em manifestos exportados (padrão true , desde BuildKit v0.8 )
compression= : escolha o tipo de compactação para camadas recém-criadas e armazenadas em cache, gzip é o valor padrão. estargz e zstd devem ser usados com oci-mediatypes=true .
compression-level= : nível de compactação para gzip, estargz (0-9) e zstd (0-22)
force-compression=true : aplica à força a opção compression a todas as camadas
ignore-error= : especifique se o erro será ignorado caso a exportação do cache falhe (padrão: false )
--import-cache opções:
type=local
src= : diretório de origem para importador de cache
tag= : especifica a tag personalizada da imagem para ler do índice local (padrão: latest )
digest=sha256: : especifique o resumo explícito da lista de manifestos a ser importada
buildctl construir... --output type=image,name=docker.io/username/image,push=true --export-cache type=gha --import-cache type=gha
O cache do GitHub Actions salva metadados e camadas do cache no serviço Cache do GitHub. Atualmente, esse cache tem um limite de tamanho de 10 GB que é compartilhado entre diferentes caches no repositório. Se você exceder esse limite, o GitHub salvará seu cache, mas começará a expulsá-los até que o tamanho total seja inferior a 10 GB. A reciclagem de caches com muita frequência pode resultar em tempos de execução mais lentos em geral.
Da mesma forma que o uso de ações/cache, os caches têm escopo definido por ramificação, com as ramificações padrão e de destino disponíveis para cada ramificação.
Os seguintes atributos são necessários para autenticação na API do serviço GitHub Actions Cache:
url : URL do servidor de cache (padrão $ACTIONS_CACHE_URL )
token : token de acesso (padrão $ACTIONS_RUNTIME_TOKEN )
Este tipo de cache pode ser usado com Docker Build Push Action onde url e token serão definidos automaticamente. Para usar esse back-end em uma etapa run inline, você deve incluir crazy-max/ghaction-github-runtime em seu fluxo de trabalho para expor o tempo de execução.
--export-cache :
type=gha
mode= : especifica camadas de cache para exportar (padrão: min )
min : exporta apenas camadas para a imagem resultante
max : exporta todas as camadas de todas as etapas intermediárias
scope= : a qual objeto de cache de escopo pertence ( buildkit padrão)
ignore-error= : especifique se o erro será ignorado caso a exportação do cache falhe (padrão: false )
timeout= : define a duração do tempo limite para exportação de cache (padrão: 10m )
--import-cache opções:
type=gha
scope= : a qual objeto de cache de escopo pertence ( buildkit padrão)
timeout= : define a duração do tempo limite para importação de cache (padrão: 10m )
buildctl construir... --output type=image,name=docker.io/username/image,push=true --export-cache type=s3,region=eu-west-1,bucket=my_bucket,name=my_image --import-cache type=s3,region=eu-west-1,bucket=my_bucket,name=my_image
Os seguintes atributos são obrigatórios:
bucket : bucket AWS S3 (padrão: $AWS_BUCKET )
region : região AWS (padrão: $AWS_REGION )
Locais de armazenamento:
blobs: s3:// , padrão: s3://
manifestos: s3:// , padrão: s3://
Configuração S3:
blobs_prefix : prefixo global para armazenar/ler blobs no s3 (padrão: blobs/ )
manifests_prefix : prefixo global para armazenar/ler manifestos no s3 (padrão: manifests/ )
endpoint_url : especifique um endpoint S3 específico (padrão: vazio)
use_path_style : se definido como true , coloque o nome do bucket na URL em vez de no nome do host (padrão: false )
Autenticação AWS:
A maneira mais simples é usar um perfil de instância IAM. Outras opções são:
Qualquer sistema que use variáveis de ambiente/arquivos de configuração compatíveis com o AWS Go SDK. A configuração deve estar disponível para o daemon do buildkit, não para o cliente.
Usando os seguintes atributos:
access_key_id : ID da chave de acesso
secret_access_key : Chave de acesso secreta
session_token : token de sessão
--export-cache :
type=s3
mode= : especifica camadas de cache para exportar (padrão: min )
min : exporta apenas camadas para a imagem resultante
max : exporta todas as camadas de todas as etapas intermediárias
prefix= : define o prefixo global para armazenar/ler arquivos no s3 (padrão: vazio)
name= : especifique o nome do manifesto a ser usado ( buildkit padrão)
Vários nomes de manifesto podem ser especificados ao mesmo tempo, separados por ; . O caso de uso padrão é usar git sha1 como nome e o nome da ramificação como duplicado e carregar ambos com 2 comandos import-cache .
ignore-error= : especifique se o erro será ignorado caso a exportação do cache falhe (padrão: false )
touch_refresh=24h : Em vez de serem carregados novamente quando não forem alterados, os arquivos blobs serão "tocados" no s3 a cada touch_refresh , o padrão é 24h. Devido a isso, uma política de expiração pode ser definida no bucket S3 para limpar arquivos inúteis automaticamente. Os arquivos de manifestos são reescritos sistematicamente, não há necessidade de tocá-los.
upload_parallelism=4 : Este parâmetro altera o número de camadas carregadas para s3 em paralelo. Cada camada individual é carregada com 5 threads, usando o gerenciador de upload fornecido pelo AWS SDK.
--import-cache opções:
type=s3
prefix= : define o prefixo global para armazenar/ler arquivos no s3 (padrão: vazio)
blobs_prefix= : define o prefixo global para armazenar/ler blobs no s3 (padrão: blobs/ )
manifests_prefix= : define o prefixo global para armazenar/ler manifestos em s3 (padrão: manifests/ )
name= : nome do manifesto a ser usado ( buildkit padrão)
buildctl construir... --output type=image,name=docker.io/username/image,push=true --export-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image --import-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image
Os seguintes atributos são obrigatórios:
account_url : a URL da conta do Armazenamento de Blobs do Azure (padrão: $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL )
Locais de armazenamento:
blobs:
manifestos:
Configuração do Armazenamento de Blobs do Azure:
container : o nome do contêiner do Armazenamento de Blobs do Azure (padrão: buildkit-cache ou $BUILDKIT_AZURE_STORAGE_CONTAINER se definido)
blobs_prefix : prefixo global para armazenar/ler blobs no contêiner do Azure Blob Storage ( blobs/ )
manifests_prefix : prefixo global para armazenar/ler blobs no contêiner do Azure Blob Storage ( manifests/ )
Autenticação do Armazenamento de Blobs do Azure:
Existem 2 opções suportadas para autenticação do Azure Blob Storage:
Qualquer sistema que utilize variáveis ambientais suportadas pelo SDK do Azure para Go. A configuração deve estar disponível para o daemon do buildkit, não para o cliente.
Chave de acesso secreta, usando o atributo secret_access_key para especificar a chave de conta primária ou secundária para sua conta do Armazenamento de Blobs do Azure. Chaves da conta do Armazenamento de Blobs do Azure
Observação
O nome da conta também pode ser especificado com o atributo account_name (ou $BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ) se não fizer parte do host do URL da conta.
--export-cache :
type=azblob
mode= : especifica camadas de cache para exportar (padrão: min )
min : exporta apenas camadas para a imagem resultante
max : exporta todas as camadas de todas as etapas intermediárias
prefix= : defina o prefixo global para armazenar/ler arquivos no contêiner do Azure Blob Storage (
name= : especifique o nome do manifesto a ser usado (padrão: buildkit )
Vários nomes de manifesto podem ser especificados ao mesmo tempo, separados por ; . O caso de uso padrão é usar git sha1 como nome e o nome da ramificação como duplicado e carregar ambos com 2 comandos import-cache .
ignore-error= : especifique se o erro será ignorado caso a exportação do cache falhe (padrão: false )
--import-cache opções:
type=azblob
prefix= : defina o prefixo global para armazenar/ler arquivos no contêiner do Azure Blob Storage (
blobs_prefix= : defina o prefixo global para armazenar/ler blobs no contêiner do Azure Blob Storage ( blobs/ )
manifests_prefix= : defina o prefixo global para armazenar/ler manifestos no contêiner do Azure Blob Storage ( manifests/ )
name= : nome do manifesto a ser usado (padrão: buildkit )
Se você tiver várias instâncias do daemon do BuildKit, mas não quiser usar o registro para compartilhar o cache no cluster, considere o balanceamento de carga do lado do cliente usando hashing consistente.
Consulte ./examples/kubernetes/consistenthash .
Para gerar metadados de compilação, como o resumo da imagem, passe o sinalizador --metadata-file . Os metadados serão gravados como um objeto JSON no arquivo especificado. O diretório do arquivo especificado já deve existir e ser gravável.
buildctl build ... --metadata-file metadata.json
jq '.' metadados.json
{ "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "containerimage.descriptor": {"anotações": { "config.digest": 9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": " 2022-02-08T21:28:03Z"},"digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3","mediaType": "application/vnd.oci.image.manifest.v1+json","tamanho 50": 6
}, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"} Em sistemas baseados em Systemd, você pode se comunicar com o daemon por meio da ativação do soquete Systemd, use buildkitd --addr fd:// . Você pode encontrar exemplos de uso da ativação de soquete Systemd com BuildKit e Systemd em ./examples/systemd .
O daemon buildkitd pode escutar a API gRPC em um soquete TCP.
É altamente recomendável criar certificados TLS tanto para o daemon quanto para o cliente (mTLS). Habilitar TCP sem mTLS é perigoso porque os contêineres executores (também conhecidos como contêineres Dockerfile RUN ) também podem chamar a API BuildKit.
kit de construção --addr tcp://0.0.0.0:1234 --tlscacert /caminho/para/ca.pem --tlscert /caminho/para/cert.pem --tlskey /caminho/para/key.pem
construirctl --addr tcp://example.com:1234 --tlscacert /caminho/para/ca.pem --tlscert /caminho/para/clientcert.pem --tlskey /caminho/para/clientkey.pem construir ...
buildctl build pode ser chamado contra daemons buildkitd com balanceamento de carga aleatório.
Consulte também Hashing consistente para balanceamento de carga do lado do cliente.
O BuildKit também pode ser usado executando o daemon buildkitd dentro de um contêiner Docker e acessando-o remotamente.
Fornecemos as imagens do contêiner como moby/buildkit :
moby/buildkit:latest : construído a partir da versão regular mais recente
moby/buildkit:rootless : igual ao latest , mas funciona como um usuário sem privilégios, consulte docs/rootless.md
moby/buildkit:master : construído a partir do branch master
moby/buildkit:master-rootless : igual ao master, mas é executado como um usuário sem privilégios, consulte docs/rootless.md
Para executar o daemon em um contêiner:
docker run -d --name buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd buildctl construir --ajuda
Para se conectar a um daemon BuildKit em execução em um contêiner Podman, use podman-container:// em vez de docker-container:// .
podman run -d --name buildkitd --privileged moby/buildkit:mais recente buildctl --addr=podman-container://buildkitd build --frontend dockerfile.v0 --local context=. --local dockerfile=. --tipo de saída=oci | podman carregar foo
sudo não é necessário.
Para se conectar a um daemon BuildKit em execução em um contêiner Nerdctl, use nerdctl-container:// em vez de docker-container:// .
nerdctl run -d --name buildkitd --privileged moby/buildkit:mais recente buildctl --addr=nerdctl-container://buildkitd build --frontend dockerfile.v0 --local context=. --local dockerfile=. --tipo de saída=oci | carga nerdctl
sudo não é necessário.
Para implantações do Kubernetes, consulte examples/kubernetes .
Para executar o cliente e um daemon efêmero em um único contêiner ("modo sem daemon"):
execução do docker
-isto
--rm
--privilegiado
-v /caminho/para/dir:/tmp/work
--entrypoint buildctl-daemonless.sh
moby/buildkit:mestre
construir
--frontend dockerfile.v0
--local contexto=/tmp/trabalho
--local dockerfile=/tmp/trabalhoou
execução do docker
-isto
--rm
--security-opt seccomp = não confinado
--security-opt apparmor = não confinado
-e BUILDKITD_FLAGS=--oci-worker-no-process-sandbox
-v /caminho/para/dir:/tmp/work
--entrypoint buildctl-daemonless.sh
moby/buildkit:master-rootless
construir
--front-end
arquivo docker.v0
--local contexto=/tmp/trabalho
--local dockerfile=/tmp/trabalho BuildKit oferece suporte a OpenTelemetry para API buildkitd gRPC e comandos buildctl. Para capturar o rastreio para Jaeger, configure a variável de ambiente JAEGER_TRACE para o endereço de coleta.
docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# reinicie buildkitd e buildctl para que eles saibam JAEGER_TRACE# qualquer comando buildctl deve ser rastreado para http:/ /127.0.0.1:16686/
No Windows, se você estiver executando o Jaeger fora de um contêiner,
jaeger-all-in-one.exe, defina a variável de ambientesetx -m JAEGER_TRACE "0.0.0.0:6831", reiniciebuildkitdem um novo terminal e os rastreamentos serão coletados automaticamente.
Consulte docs/rootless.md .
Consulte docs/multi-platform.md .
buildctl buildctl tem suporte para modificar as cores usadas para enviar informações para o terminal. Você pode definir a variável de ambiente BUILDKIT_COLORS para algo como run=green:warning=yellow:error=red:cancel=255,165,0 para definir as cores que você gostaria de usar. Definir NO_COLOR como qualquer coisa desabilitará qualquer saída colorida conforme recomendado por no-color.org.
Erros de análise serão relatados, mas ignorados. Isso resultará no uso de valores de cores padrão quando necessário.
A lista de cores predefinidas.
Você pode alterar quantas linhas de log ficam visíveis para etapas ativas no modo tty definindo BUILDKIT_TTY_LOG_LINES como um número (padrão: 6).
Quer contribuir com o BuildKit? Incrível! Você pode encontrar informações sobre como contribuir para este projeto em CONTRIBUTING.md
