Docker-Build erreecht keng privat Ofhängegkeet: iwwerpréift dat

E privat Pak, dat sech op Ärem Rechner ouni Problemer opléist, kann am Build mat engem 404 oder engem Timeout feelen, an den Dockerfile ass selten d’Ursaach. De Buildschrëtt leeft an engem aneren Netzwierk-Namensraum, mat enger anerer DNS-Siicht an engem aneren Depot vu Umeldungsdaten wéi d’Shell, an där Dir getest hutt. Gitt dës Kontrollen an der Rei duerch a stoppt bei der éischter, déi feelt, well all spéider Kontroll unhëlt, datt déi virech bestanen huet. All Schrëtt nennt de Befehl, deen d’Saach entscheet.

Fänkt mat dem Builder un, net mam Dockerfile

BuildKit kann lokal, am Container oder op enger anerer Maschinn lafen, an all huet säin eegene Standardnetzwierk. Féiert docker buildx ls aus a liest den Node, dee mat engem Stärchen markéiert ass, ier Dir eppes ännert. Ee docker-container Driver oder e Cloud-Builder deelt d’privat Route op Ärem Laptop net just well Dir de Befehl do getippt hutt. Wann den aktive Builder wäit ewech ass, muss all déi aner Kontroll géint deen Host lafen, net géint Är Aarbechtsstatioun.

De Builder dréit och seng eegen Resolver-Konfiguratioun a Proxy-Variabelenmat sech. Béides gëtt zur Buildzäit geliest a gëtt net vum Terminal ierf, deen de Build gestart huet.

Beweist den Netzwierkwee vun engem Buildschrëtt aus

Schreift eng Eenzjob-Phase, déi den Host vun der Ofhängegkeet opléist an eng Verbindung dohiermecht opmécht. Et ass den eenzegen Test, deen d’Fro fir de Builder beäntwert an net fir Är 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/

Baut dës Datei mat demselwechte Builder, Netzwierkmodus an deene selwechte Secret-Montagen, déi Äre richtege Build benotzt: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Wann getent näischt dréckt, läit de Feeler an der Nummopléisung a keng Umeldungsdaten hëlleft dobäi. Wann den Numm sech opléist, awer curl en Timeout mellt, ass de Blocage d’Route oder d’Egress-Politik virum Registre.

Läscht d’Sond, soubal se äntwert. Et ass eng diagnostesch Phase an soll ni getaggt oder gepusht ginn.

Montéiert d’Umeldungsdaten amplaz se ze kopéieren

Wann de Wee funktionéiert, ass d’Authentifizéierung den nächste Feeler an der Rei. Eng BuildKit-Secret-Montage weist eng Datei engem eenzegen RUN Schrëtt, ouni se an eng Schicht ze schreiwen; dat brauch dat Ofhängegkeets-Tool an dat däerf den Image net behalen.

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

D’Geheimnis muss vun ausserhalb vum Dockerfile komm: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. D’Datei bleift beim Client an et geet ni an d’Image-Historie. Een ARG oder ENV mat demselwechten Token leeschten dës Aarbecht net, well béides an der Image-Konfiguratioun festgehale gëtt.

En Image ouni root brauch säin eegene Zilwee, zum Beispill /home/app/.npmrc oder déi entspriechend Datei fir pip, Maven oder Cargo. D’Montage-Zil muss zu deem Benotzer passen, deen de Befehl ausféiert, soss mellt d’Tool eng feelend Konfiguratiounsdatei, déi tatsächlech do ass.

Préift, wat d’Ofhängegkeets-Tool am Image hannerlässt

Eng temporär Montage hält d’Umeldungsdaten aus enger Schicht eraus, awer et verhënnert net, datt d’Tool eppes anescht schreift. Pakmanager loossen Lock-Dateien, Cache-Verzeechnisser an heiansdo déi opgeléist Registre-URL hannerloossen.

Liest d’fäerdeg Dateisystem amplaz dem Dockerfile ze vertrauen. docker history --no-trunc image:tag zielt all Schichtbefehl op, an docker run --rm image:tag sh -c "ls -a /root" weist, wat an den lafenden Container iwwerlieft huet. Och wann d’Datei just montéiert war, en Token deen während npm ci an enger Logzeil geschriwwe gëtt, bleift eng Dell.

Liest och de Build-Log, well --progress=plain dréckt d’Ausgab vun de Befehler wuertwiertlech. Wann den Token do erschéngt, rotéiert en ier allem aneren a gitt en duerch eng Datei, déi d’Tool roueg liest.

Iwwerpréift, datt den Image fir d’Ausféierung de privaten Trëpp net méi brauch

De Build an d’Applikatioun déi leeft sinn zwee verschidde Benotzer vun der selwechter Ofhängegkeet, a just deen éischten brauch de privaten Trëpp. En fäerdegen Image soll starten, seng Ausféierungs-Ofhängegkeete léisen a Verkéier zerwéieren ouni d’Umeldungsdaten vum Build.

Test et do, wou de private Registre net erreechbar ass, oder start de Container einfach mat --network none a bestätegt, datt en ouni dat montéiert Geheimnis ugeet. En Container, deen nëmme start wann d’Build-Geheimnis do ass, ass nach un d’Build-Ëmgebung gekoppelt.

Wann de Container de Registre wierklech zur Ausféierungszäit brauch, ass dat eng eegen Zougängsentscheedung, an se gehéiert an de Secret-Store vum Orchestrator an net an de Build. Dokumentéiert déi zwee Weeër getrennt, sou datt keen probéiert en Ausféierungspull mat engem Build-Flag ze flécken. Wann all fënnef Kontrollen duerchginn, huet de urspréngleche Symptom op all Schicht eng genannte Ursaach amplaz vun enger Vermutung iwwer Docker-Netzwierker.