O que é o BuildKit do Docker e por que isso é importante?

O Docker BuildKit é um mecanismo opcional de construção de imagens que oferece melhorias substanciais em relação ao processo tradicional. O BuildKit cria camadas de imagens em paralelo, acelerando o processo geral de construção.

O que é BuildKit?

O BuildKit foi desenvolvido como parte do projeto Moby, um esforço do Docker para “ montar sistemas de contêiner especializados sem reinventar a roda. ” Foi anunciado em 2017 e começou a ser distribuído com o Docker Engine na versão 18.09 de 2018.

O BuildKit se concentra em melhorar o desempenho de construção, gerenciamento de armazenamento e extensibilidade. Suas afirmações de título são processamento paralelo, armazenamento em cache mais avançado, uma arquitetura conectável e coleta de lixo automática. Eles se combinam em um sistema de construção que é mais eficiente e mais extensível do que o mecanismo original.

Camadas que não afetam umas às outras podem ser construídas simultaneamente, reduzindo o tempo de espera para que as etapas sejam concluídas. O BuildKit também otimiza o acesso aos arquivos locais aos quais você faz referência com as instruções COPY. Ele rastreia as mudanças que você faz e apenas copia os arquivos que foram modificados desde a última compilação, em vez de transferir todo o contexto de compilação.

O BuildKit também simplifica as compilações em várias plataformas. Você pode fornecer o sinalizador --platform para especificar os destinos para os quais construir. O BuildKit montará automaticamente um manifesto de imagem apropriado para cobrir todas as arquiteturas especificadas.

 docker buildx --create --platform linux / amd64, linux / arm64. 

Como funciona o BuildKit?

As melhorias de desempenho do BuildKit são facilitadas pelo uso de um formato de definição de construção de baixo nível, denominado LLB. É um formato binário baseado em gráfico que reúne definições de compilação complexas.

Publicidade

Como as camadas estão diretamente vinculadas, o BuildKit facilita a comparação mais rápida dos gráficos de construção e do conteúdo que eles incluem. O construtor Dockerfile padrão precisa confiar em heurísticas imprecisas para determinar se duas imagens são comparáveis.

O LLB é completamente separado do BuildKit “ front-end. ” O front-end pega uma representação legível de uma imagem, como um Dockerfile, e a converte em um gráfico LLB. Depois que um LLB é gerado, ele pode ser exportado e movido entre ambientes. A exportação para um registro permite que os clientes de front-end adquiram um LLB existente para melhorar ainda mais o desempenho da construção inicial.

Os detalhes técnicos do LLB são bastante complexos. A tecnologia subjacente é baseada na teoria dos gráficos e na comparação de checksum. Você não precisa entendê-lo para se beneficiar de seu poder: como um usuário final, as compilações funcionam da mesma maneira que nunca, com o comando docker build.

O BuildKit ainda cria imagens compatíveis com OCI que são portáveis ​​em diferentes ambientes de contêiner. Você pode usar BuildKit para criar qualquer imagem Docker com uma base Linux. As imagens do Windows não são compatíveis no momento.

Ativando o suporte BuildKit

Existem duas maneiras de ativar o BuildKit. Se você deseja construir uma única imagem com o recurso, defina a variável de ambiente DOCKER_BUILDKIT em seu shell:

 DOCKER_BUILDKIT = 1 compilação docker. 

Publicidade

Para uso de longo prazo, configure o daemon Docker para usar BuildKit por padrão. Crie ou edite o arquivo /etc/docker/daemon. json e adicione o seguinte conteúdo ao objeto de configuração de nível superior:

{" features & quot ;: {" buildkit & quot ;: true}}

Recarregue a configuração do daemon para aplicar a mudança:

 systemctl reload docker 

O BuildKit agora será usado em vez do mecanismo de compilação padrão quando você executar o comando docker build.

Você pode dizer quando o BuildKit está ativo porque ele produz uma saída CLI diferente para o mecanismo regular. A exibição de progresso do BuildKit oferece legibilidade aprimorada e visualização clara de quando cada estágio começa e termina. As informações incluem uma análise do tempo gasto para construir cada camada.

“ docker buildx ”

Você também pode interagir com o BuildKit por meio dos comandos docker buildx. Eles sempre usarão o BuildKit. O grupo de comando dockerx expõe a funcionalidade BuildKit avançada, incluindo a capacidade de construir em um host remoto.

Um único cliente BuildKit pode interagir com várias instâncias distintas do construtor de imagens. Isso facilita compilações em várias plataformas, permitindo que você adicione um construtor para cada arquitetura que você está almejando.

Aqui está um exemplo de adição de um host remoto como um alvo BuildKit. Isso pressupõe que a máquina de destino tem um soquete Docker exposto na porta TCP 2375. Você pode fazer referência ao host usando qualquer identificador de endpoint do Docker ou o nome de um contexto Docker (obtido do contexto docker ls). O último permite criar ambientes de nuvem compatíveis, adicionando-os como um contexto.

 docker buildx create --name remote-builder tcp: // my-docker-host: 2375 

Publicidade

Você pode selecionar o construtor a ser usado com o comando docker buildx use:

 docker buildx use remote-builder 

Então você pode usar o comando build para construir sua imagem na instância do builder selecionada:

 docker buildx build. 

Você pode remover instâncias do construtor usando docker buildx rm, passando o nome do construtor. Os construtores são listados usando docker buildx ls; você pode usar docker buildx inspect para obter informações mais detalhadas sobre um construtor específico.

Se você deseja verificar o uso do disco do BuildKit, execute o comando docker buildx du. Você pode limpar o cache de compilação para liberar armazenamento com o docker buildx prune. Isso pode reduzir o desempenho da próxima vez que você reconstruir sua imagem, pois as camadas armazenadas anteriormente em cache serão reconstruídas.

Recursos de construção

O BuildKit adiciona alguns recursos extras de tempo de construção para simplificar as etapas do Dockerfile.

Você pode passar dados secretos usando o sinalizador --secret. Isso permite que o Dockerfile acesse valores confidenciais sem armazená-los dentro da imagem. O valor está disponível apenas no momento da compilação.

 docker build --secret id = demo-secret, src = demo-secret. txt. 

DE minha-imagem: última RUN --mount = type = secret, id = demo-secret cat / run / secrets / demo-secrets

Publicidade

Este Dockerfile faz referência a um segredo chamado demo-secret. Seu valor é lido do arquivo demo-secret. txt ao executar o docker build. A instrução RUN com o sinalizador --mount fornece acesso ao segredo. O arquivo está temporariamente montado no diretório / run / secrets.

O BuildKit também permite que você encaminhe o agente SSH do seu host para que as instruções de construção possam interagir com as conexões remotas existentes. Passe a sinalização --ssh para docker build e adicione --mount = type = ssh às instruções RUN em seu Dockerfile:

 build docker --ssh. 

RUN --mount = type = ssh git clone git@example. com: /project. git

Esses recursos tornam a construção de imagens mais conveniente sem afetar a segurança geral. Encaminhamento de agente SSH e montagens secretas estão disponíveis apenas no BuildKit; não há contraparte no mecanismo de compilação padrão.

Conclusão

BuildKit é o criador de imagens Docker de próxima geração que usa um formato binário gráfico para acelerar drasticamente as compilações. Embora o desempenho varie consideravelmente para cada Dockerfile, você pode esperar acelerações substanciais nos casos em que o processamento paralelo de camadas de imagem é possível.

A arquitetura do BuildKit otimiza alguns dos mais novos recursos do Dockerfile. As compilações de vários estágios se beneficiam da omissão de etapas não utilizadas, o que torna o processo mais eficiente que o construtor padrão.

Embora o BuildKit agora seja estável, o Docker ainda não é fornecido com ele ativado por padrão. Certifique-se de habilitá-lo em seu cliente Docker se quiser usar seus recursos. Há uma proposta ativa para tornar o BuildKit o mecanismo de compilação padrão, mas ainda há problemas não resolvidos que impedem a mudança.