A compilación de Docker non chega a unha dependencia privada: revise isto

Un paquete privado que na súa máquina se resolve sen problemas pode fallar dentro da compilación cun 404 ou cun tempo de espera esgotado, e o Dockerfile case nunca é a causa. O paso de compilación execútase noutro espazo de nomes de rede, con outra visión do DNS e outro almacén de credenciais que a shell na que probou. Percorra estas comprobacións en orde e detéñase na primeira que falle, porque cada comprobación posterior dá por feito que a anterior pasou. Cada paso nomea o comando que resolve o asunto.

Empece por nomear o builder, non o Dockerfile

BuildKit pode ser local, estar nun contedor ou correr noutra máquina, e cada un ten a súa propia rede por defecto. Execute docker buildx ls e lea o nodo marcado cun asterisco antes de cambiar nada. Un docker-container controlador ou un builder na nube non comparte a ruta privada do seu portátil só porque escribiu alí o comando. Se o builder activo é remoto, cada comprobación restante debe executarse contra ese host e non contra a súa estación de traballo.

O builder tamén leva a súa propia configuración do resolutor e as súas variables de proxy. Ambas se len no momento da compilación e non se herdan da terminal que a iniciou.

Demostre a ruta de rede desde dentro dun paso de compilación

Escriba unha etapa dun só uso que resolva o host da dependencia e abra unha conexión con el. É a única proba que responde á pregunta polo builder e non pola súa shell.

FROM alpine:3.20
RUN apk add --no-cache curl bind-tools  && getent hosts registry.example.internal  && curl -sS -o /dev/null -w "%{http_code}
" https://registry.example.internal/simple/

Compile ese ficheiro co mesmo builder, modo de rede e montaxes de segredos que usa a súa compilación real: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Se getent non imprime nada, o fallo é de resolución de nomes e ningunha credencial o arranxará. Se o nome se resolve pero curl informa dun tempo de espera esgotado, o obstáculo é a ruta ou a política de saída diante do rexistro.

Borre a sonda en canto responda. É unha etapa de diagnóstico e nunca debería etiquetarse nin publicarse.

Monte a credencial en lugar de copiala

Cando a ruta funcione, a autenticación é o seguinte fallo da lista. Unha montaxe de segredo de BuildKit expón un ficheiro a un só paso RUN sen escribilo nunha capa, que é o que necesita a ferramenta de dependencias e o que a imaxe non debe conservar.

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc     npm ci --omit=dev

O segredo debe fornecerse desde fóra do Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. O ficheiro queda no cliente e nunca entra no historial da imaxe. Un ARG ou un ENV co mesmo token non fan este traballo, porque ambos quedan rexistrados na configuración da imaxe.

Unha imaxe sen root necesita a súa propia ruta de destino, como /home/app/.npmrc ou o ficheiro equivalente para pip, Maven ou Cargo. O destino da montaxe debe coincidir co usuario que executa o comando, ou a ferramenta informará dun ficheiro de configuración ausente que en realidade está aí.

Audite que deixa a ferramenta de dependencias na imaxe

Unha montaxe temporal mantén a credencial fóra dunha capa, pero non impide que a ferramenta escriba outra cousa. Os xestores de paquetes deixan ficheiros de bloqueo, directorios de caché e ás veces a URL do rexistro xa resolta.

Lea o sistema de ficheiros terminado en lugar de confiar no Dockerfile. docker history --no-trunc image:tag lista cada comando de capa, e docker run --rm image:tag sh -c "ls -a /root" mostra que sobreviviu ao contedor en execución. Mesmo cando o ficheiro só se montou, un token escrito nunha liña de rexistro durante npm ci segue sendo unha fuga.

Lea tamén o rexistro de compilación, porque --progress=plain imprime a saída dos comandos tal cal. Se o token aparece alí, róteo antes que nada e páseo por un ficheiro que a ferramenta lea en silencio.

Verifique que a imaxe de execución xa non precisa a ruta privada

A compilación e a aplicación en marcha son dous consumidores distintos da mesma dependencia, e só o primeiro precisa a ruta privada. Unha imaxe terminada debería arrincar, resolver as súas dependencias de execución e servir tráfico sen a credencial de compilación.

Próbeo onde o rexistro privado non sexa accesible, ou simplemente inicie o contedor con --network none e confirme que arrinca sen o segredo montado. Un contedor que só arrinca cando o segredo de compilación está presente segue acoplado á contorna de compilación.

Se o contedor realmente necesita o rexistro en tempo de execución, é unha decisión de acceso aparte, e corresponde ao almacén de segredos do orquestrador e non á compilación. Documente as dúas rutas por separado para que ninguén intente reparar unha descarga en execución cunha bandeira de compilación. Cando as cinco comprobacións pasan, o síntoma orixinal ten unha causa nomeada en cada capa en lugar dunha conxectura sobre a rede de Docker.