Baixar imagens base do Docker: proxy do builder versus argumentos de build
Os argumentos de proxy fornecidos às etapas de build não configuram todas as requisições ao registro feitas pelo builder. Localize o builder que resolve a imagem base.
Um build pode falhar ao resolver FROM antes de qualquer etapa de download de pacotes do Dockerfile ser executada. O cliente de registro do builder precisa de sua própria rota para obter essa imagem base.
| Operação | Componente que precisa da rota |
|---|---|
| Resolver e obter a imagem base | O cliente de registro do builder |
| Download durante RUN | O processo que executa a etapa de build |
| Chamar uma API em tempo de execução | A aplicação em execução |
Localize o builder
O driver padrão do Docker gira em torno do daemon. Outros drivers Buildx podem usar um contêiner BuildKit dedicado, Kubernetes ou um serviço remoto. Configure o mecanismo de proxy compatível com o driver escolhido onde esse worker é executado.
Um proxy de loopback no laptop não é acessível automaticamente a partir de um worker remoto, e editar o daemon local não reconfigura esse builder remoto.
Um ARG antes de FROM pode ajudar a escolher a referência da imagem. No entanto, isso não configura a rota de rede do cliente de registro. Comandos RUN posteriores que gravam configurações de pacotes ou instalam certificados não conseguem reparar essa requisição anterior.
Confiança, contas e dados em cache
O material de CA aprovado deve estar disponível para o componente que valida a conexão inicial com o registro. Credenciais de registro e credenciais de proxy autorizam partes diferentes; um login no registro não pode responder a um 407 do proxy.
Um worker que reutiliza dados de imagem em cache pode não repetir a mesma requisição de rede de um worker novo. Compare a operação realmente registrada. Depois que o acesso à imagem base funcionar pela rota pretendida, diagnostique qualquer download posterior da etapa de build nessa próxima fronteira.