Docker-en buildak ez du menpekotasun pribatura iristen: aztertu hau

Zure makinan arazorik gabe ebazten den pakete pribatu batek build barruan huts egin dezake 404 batekin edo denbora-muga batekin, eta Dockerfile-a gutxitan da arrazoia. Build urratsa sare-namespace ezberdinean exekutatzen da, DNS ikuspegi ezberdin batekin eta probatu zenuen shell-aren biltegiratze ezberdin batekin. Egiaztapen hauek ordenan egin eta lehen huts egiten duenean gelditu, ondorengo egiaztapen bakoitzak aurrekoa pasa zela suposatzen baitu. Urrats bakoitzak kontua erabakitzen duen komandoa izendatzen du.

Hasi builder-a izendatzen, ez Dockerfile-a

BuildKit lokala, edukiontzian edo beste makina batean egon daiteke, eta horietako bakoitzak bere sare lehenetsia du. Exekutatu docker buildx ls eta irakurri izartxoarekin markatutako nodoa ezer aldatu aurretik. docker-container driver edo hodeiko builder batek ez du zure ordenagailuko bide pribatua partekatzen komandoa han idatzi duzulako. Builder aktiboa urrunekoa bada, gainerako egiaztapen bakoitzak ostalari horren aurka egin behar du, ez zure lan-estazioaren aurka.

Builder-ak bere resolver konfigurazioa eta proxy aldagaiakere eramaten ditu. Biak build garaian irakurtzen dira eta build-a abiarazi zuen terminaletik ez dira heredatzen.

Egiaztatu sare-bidea build urrats baten barrutik

Idatzi behin-behineko etapa bat menpekotasunaren ostalaria ebazten duena eta harekin konexio bat irekitzen duena. Hau da builder-rako, eta ez zure shell-erako, galderari erantzuten dion proba bakarra.

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/

Eraiki fitxategi hori zure build errealak erabiltzen dituen builder, sare-modu eta secret muntatze berberekin: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Baldin getent ez badu ezer inprimatzen, hutsegitea izen-ebazpenean dago eta kredentzial batek ere ez du konponduko. Izena ebazten bada baina curl-ek denbora-muga bat jakinarazten badu, oztopoa erregistroaren aurreko bidea edo irteera-politika da.

Ezabatu zunda erantzun ondoren. Etapa diagnostikoa da eta ez litzateke inoiz etiketatu edo push egin behar.

Muntatu kredentziala, ez kopiatu

Bidea funtzionatzen duenean, autentifikazioa da hurrengo hutsegitea. BuildKit secret muntatze batek fitxategi bat RUN urrats bakar bati erakusten dio, geruza batean idatzi gabe; hori da menpekotasun-tresnak behar duena eta image-ak gorde behar ez duena.

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

Secret-a Dockerfile-etik kanpotik eman behar da: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Fitxategia bezeroan geratzen da eta ez da inoiz image-aren historiarako sartzen. ARG edo ENV batek token bera edukita ez du lan hau egiten, biak image konfigurazioan erregistratzen baitira.

Root ez den image batek bere helburuko bidea behar du, adibidez /home/app/.npmrc edo pip, Maven edo Cargo-rako baliokidea den fitxategia. Muntatzearen helburuak komandoa exekutatzen duen erabiltzailearekin bat etorri behar du, bestela tresnak falta den konfigurazio-fitxategi bat jakinaraziko du, benetan han dagoena.

Egiaztatu menpekotasun-tresnak image-an uzten duena

Muntatze behin-behineko batek kredentziala geruzatik kanpo uzten du, baina ez dio tresnari beste zerbait idaztea eragozten. Pakete-kudeatzaileek lock fitxategiak, cache direktorioak eta batzuetan erregistroaren URL ebatzitakoa uzten dituzte.

Irakurri amaitutako fitxategi-sistema, Dockerfile-ari sinetsi ordez. docker history --no-trunc image:tag geruza-komando bakoitza zerrendatzen du, eta docker run --rm image:tag sh -c "ls -a /root" exekutatzen ari den edukiontzira zer iraun duen erakusten du. Fitxategia muntatu bakarrik egon bada ere, log lerro batean idatzitako token npm ci bitartean oraindik ihes bat da.

Irakurri build loga ere, zeren --progress=plain komandoen irteera hitzez hitz inprimatzen baitu. Token-a han agertzen bada, biratu ezazu beste edozer baino lehen eta tresnak isilka irakurtzen duen fitxategi baten bidez pasatu.

Egiaztatu runtime image-ak ez duela jada bide pribaturik behar

Build-a eta exekutatzen ari den aplikazioa menpekotasun beraren bi kontsumitzaile ezberdin dira, eta lehenengoak soilik behar du bide pribatua. Amaitutako image batek abiarazi, bere runtime menpekotasunak ebatzi eta trafikoa zerbitzatu beharko luke build-eko kredentzialik gabe.

Probatu erregistro pribatura iristen ez den tokian, edo abiarazi edukiontzia besterik gabe --network none eta egiaztatu muntatutako secret-ik gabe abiarazten dela. Build secret-a dagoenean soilik abiarazten den edukiontzi bat oraindik build inguruneari lotuta dago.

Edukiontziak runtime-an erregistroa benetan behar badu, sarbide-erabaki bereizia da, eta orkestratzailearen secret biltegian du tokia, ez build-ean. Dokumentatu bi bideak bereizita, inork ez dezan runtime pull bat build flag batekin konpondu nahi izan. Bost egiaztapenak pasatzen direnean, jatorrizko sintomak geruza bakoitzean izendatutako arrazoi bat du, Docker sareari buruzko susmo bat izan ordez.