Docker build nenokļūst līdz privātai atkarībai: pārbaudiet šo

Privāta pakotne, kas jūsu mašīnā tiek atrisināta bez problēmām, build laikā var neizdoties ar 404 vai taimautu, un Dockerfile reti ir iemesls. Build solis darbojas citā tīkla nosaukumu telpā, ar citu DNS skatījumu un citu akreditācijas datu krātuvi nekā tā čaula, kurā jūs testējāt. Izpildiet šīs pārbaudes secīgi un apstājieties pie pirmās, kas neizdodas, jo katra nākamā pārbaude pieņem, ka iepriekšējā ir izturēta. Katrs solis nosauc komandu, kas izšķir jautājumu.

Sāciet ar builder nosaukšanu, nevis ar Dockerfile

BuildKit var būt lokāls, konteinerā vai citā mašīnā, un katram ir savs noklusējuma tīkls. Palaidiet docker buildx ls un izlasiet ar zvaigznīti atzīmēto mezglu, pirms kaut ko maināt. Viens docker-container draiveris vai mākoņa builder nedala privāto maršrutu jūsu klēpjdatorā tikai tāpēc, ka tur ierakstījāt komandu. Ja aktīvais builder ir attāls, katra atlikušā pārbaude jāveic tajā resursdatorā, nevis jūsu darbstacijā.

Builder nēsā arī savu resolver konfigurāciju un proxy mainīgos. Abi tiek nolasīti build laikā, un tos nepārmanto no termināļa, kas sāka build.

Pierādiet tīkla ceļu no build soļa iekšpuses

Uzrakstiet vienreizēju posmu, kas atrisina atkarības resursdatoru un atver ar to savienojumu. Tas ir vienīgais tests, kas atbild uz jautājumu builder labā, nevis jūsu čaulas labā.

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/

Kompilējiet šo failu ar to pašu builder, tīkla režīmu un tiem pašiem noslēpumu pievienojumiem, ko izmanto jūsu īstais build: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Ja getent neko neizdrukā, vaina ir nosaukumu atrisināšanā, un nekādi akreditācijas dati to nelabos. Ja nosaukums tiek atrisināts, bet curl ziņo par taimautu, šķērslis ir maršruts vai izejas politika reģistra priekšā.

Dzēsiet zondi, tiklīdz tā atbild. Tas ir diagnostikas posms, un to nekad nevajadzētu iezīmēt vai nosūtīt.

Pievienojiet akreditācijas datus, nevis kopējiet tos

Kad ceļš darbojas, autentifikācija ir nākamā neveiksme rindā. BuildKit noslēpuma pievienojums atklāj failu vienam RUN solim, to neierakstot slānī; tas ir tas, kas vajadzīgs atkarību rīkam un kas image nav jāsaglabā.

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

Noslēpums jāpiegādā ārpus Dockerfile: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Fails paliek klientā un nekad neiekļūst image vēsturē. Viens ARG vai ENV ar to pašu token neveic šo darbu, jo abi tiek ierakstīti image konfigurācijā.

Image bez root ir vajadzīgs savs mērķa ceļš, piemēram /home/app/.npmrc vai atbilstošais fails pip, Maven vai Cargo. Pievienojuma mērķim jāatbilst lietotājam, kas izpilda komandu, citādi rīks ziņos par trūkstošu konfigurācijas failu, kas patiesībā ir.

Pārbaudiet, ko atkarību rīks atstāj image

Pagaidu pievienojums tur akreditācijas datus ārpus slāņa, bet netraucē rīkam ierakstīt ko citu. Pakešu pārvaldnieki atstāj lock failus, kešatmiņas mapes un dažreiz atrisināto reģistra URL.

Lasiet gatavo failu sistēmu, nevis uzticieties Dockerfile. docker history --no-trunc image:tag uzskaita katru slāņa komandu, un docker run --rm image:tag sh -c "ls -a /root" parāda, kas izdzīvoja darbojošajā konteinerā. Pat ja fails tika tikai pievienots, žurnāla rindā ierakstīts token npm ci laikā joprojām ir noplūde.

Lasiet arī build žurnālu, jo --progress=plain izdrukā komandu izvadi burtiski. Ja token tur parādās, nomainiet to pirms visa cita un nododiet to caur failu, ko rīks lasa klusi.

Pārliecinieties, ka izpildes image vairs nav vajadzīgs privātais ceļš

Build un darbojošā lietotne ir divi dažādi vienas atkarības patērētāji, un privātais ceļš vajadzīgs tikai pirmajam. Gatavam image jāsākas, jāatrisina savas izpildes atkarības un jāapkalpo satiksme bez build akreditācijas datiem.

Pārbaudiet to vietā, kur privātais reģistrs nav sasniedzams, vai vienkārši palaidiet konteineru ar --network none un apstipriniet, ka tas startē bez pievienotā noslēpuma. Konteiners, kas startē tikai tad, kad ir build noslēpums, joprojām ir saistīts ar build vidi.

Ja konteineram tiešām vajadzīgs reģistrs izpildes laikā, tas ir atsevišķs piekļuves lēmums, un tā vieta ir orķestrētāja noslēpumu krātuvē, nevis build. Dokumentējiet abus ceļus atsevišķi, lai neviens nemēģinātu labot izpildes laika pull ar build karodziņu. Kad visi pieci pārbaudījumi iztur, sākotnējam simptomam katrā slānī ir nosaukts cēlonis, nevis minējums par Docker tīklu.