Docker-bou bereik nie ’n private afhanklikheid nie: kyk hierna

’n Private pakket wat op jou eie masjien sonder probleme opgelos word, kan in die bou misluk met ’n 404 of ’n time-out, en die Dockerfile is selde die oorsaak. Die boustap loop in ’n ander netwerknaamruimte, met ’n ander DNS-beeld en ’n ander stoor van geloofsbriewe as die dop waarin jy getoets het. Gaan hierdie kontroles in volgorde na en stop by die eerste een wat misluk, want elke volgende kontrole neem aan dat die vorige geslaag het. Elke stap noem die opdrag wat die saak besleg.

Begin by die bouer, nie die Dockerfile nie

BuildKit kan plaaslik, in ’n houer of op ’n ander masjien loop, en elkeen het sy eie versteknetwerk. Voer docker buildx ls uit en lees die nodus wat met ’n asterisk gemerk is voordat jy iets verander. ’n docker-container drywer of ’n wolkbouer deel nie die private roete op jou skootrekenaar net omdat jy die opdrag daar getik het nie. As die aktiewe bouer op ’n afstand is, moet elke oorblywende kontrole teen daardie gasheer loop, nie teen jou werkstasie nie.

Die bouer dra ook sy eie oplosser-konfigurasie en proxy-veranderlikes. Albei word tydens die bou gelees en word nie van die terminal oorgeneem wat die bou begin het nie.

Bewys die netwerkpad van binne ’n boustap

Skryf ’n weggooi-stadium wat die afhanklikheidsgasheer oplos en ’n verbinding daarmee oopmaak. Dit is die enigste toets wat die vraag vir die bouer beantwoord eerder as vir jou dop.

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/

Bou daardie lêer met dieselfde bouer, netwerkmodus en geheimbindings as wat jou regte bou gebruik: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. As getent niks druk nie, is die fout naamoplossing en geen geloofsbrief gaan dit regmaak nie. As die naam oplos maar curl rapporteer ’n time-out, is die hindernis die roete of die uitgangsbeleid voor die registreerder.

Skrap die sondeerder sodra dit antwoord. Dit is ’n diagnostiese stadium, nie iets wat ooit gemerk of gestoot moet word nie.

Monteer die geloofsbrief eerder as om dit te kopieer

Sodra die pad werk, is verifikasie die volgende fout in die ry. ’n BuildKit-geheimbinding stel ’n lêer aan een RUN stap bloot sonder om dit in ’n laag te skryf; dit is wat die afhanklikheidsinstrument nodig het en wat die beeld nie mag behou nie.

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

Die geheim moet van buite die Dockerfile verskaf word: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Die lêer bly op die kliënt en beland nooit in die beeldgeskiedenis nie. ’n ARG of ENV wat dieselfde token hou, doen nie hierdie werk nie, want albei word in die beeldkonfigurasie aangeteken.

’n Nie-wortel-beeld het sy eie teikenpad nodig, soos /home/app/.npmrc of die ekwivalente lêer vir pip, Maven of Cargo. Die monteerteiken moet ooreenstem met die gebruiker wat die opdrag loop, anders sal die instrument ’n ontbrekende konfigurasielêer rapporteer wat eintlik daar is.

Kontroleer wat die afhanklikheidsinstrument in die beeld agterlaat

’n Tydelike binding hou die geloofsbrief uit ’n laag, maar dit keer nie die instrument om iets anders te skryf nie. Pakketbestuurders laat sluitlêers, kasgidse en soms die opgeloste registreerder-URL agter.

Lees die voltooide lêerstelsel eerder as om die Dockerfile te vertrou. docker history --no-trunc image:tag lys elke laagopdrag, en docker run --rm image:tag sh -c "ls -a /root" wys wat in die lopende houer oorleef het. Selfs wanneer die lêer net gebind is, bly ’n token wat tydens npm ci in ’n logreël beland, ’n lek.

Lees ook die boulog, want --progress=plain druk opdrag-uitset woordeliks. As die token daar verskyn, roteer dit voor enigiets anders en stuur dit deur ’n lêer wat die instrument stil lees.

Verifieer dat die looptyd-beeld nie meer die private pad nodig het nie

Die bou en die lopende toepassing is twee verskillende verbruikers van dieselfde afhanklikheid, en net die eerste een het die private roete nodig. ’n Voltooide beeld moet begin, sy looptyd-afhanklikhede oplos en verkeer bedien sonder die geloofsbrief van die bou.

Toets dit waar die private registreerder onbereikbaar is, of begin die houer eenvoudig met --network none en bevestig dat dit opstart sonder die gebinde geheim. ’n Houer wat net begin wanneer die bougeheim teenwoordig is, is steeds aan die bou-omgewing gekoppel.

As die houer die registreerder werklik tydens looptyd nodig het, is dit ’n aparte toegangsbesluit, en dit hoort in die orkestreerder se geheimewinkel eerder as in die bou. Dokumenteer die twee paaie apart sodat niemand ’n looptyd-trek met ’n bou-vlag probeer regmaak nie. Wanneer al vyf kontroles slaag, het die oorspronklike simptoom op elke laag ’n genoemde oorsaak eerder as ’n raaiskoot oor Docker-netwerking.