Docker-build ei tavoita yksityistä riippuvuutta: tarkista tämä

Yksityinen paketti, joka ratkeaa koneellasi ongelmitta, voi epäonnistua buildin sisällä 404-virheeseen tai aikakatkaisuun, ja Dockerfile on harvoin syy. Build-vaihe ajetaan toisessa verkon nimiavaruudessa, toisenlaisella DNS-näkymällä ja toisenlaisella tunnistetietovarastolla kuin se komentotulkki, jossa testasit. Käy nämä tarkistukset järjestyksessä ja pysähdy ensimmäiseen, joka epäonnistuu, koska jokainen myöhempi tarkistus olettaa edellisen menneen läpi. Jokainen vaihe nimeää komennon, joka ratkaisee asian.

Aloita nimeämällä buildaaja, ei Dockerfile

BuildKit voi olla paikallinen, kontissa tai toisella koneella, ja jokaisella on oma oletusverkkonsa. Suorita docker buildx ls ja lue tähdellä merkitty solmu ennen kuin muutat mitään. Yksi docker-container ajuri tai pilvibuildaaja ei jaa kannettavasi yksityistä reittiä vain siksi, että kirjoitit komennon sinne. Jos aktiivinen buildaaja on etäinen, jokainen jäljellä oleva tarkistus on ajettava sitä isäntää vasten eikä työasemaasi vasten.

Buildaaja kantaa myös oman resolver-asetuksensa ja proxy-muuttujansa. Molemmat luetaan build-aikana, eikä niitä periytetä päätteestä, joka buildin käynnisti.

Todista verkkopolku build-vaiheen sisältä

Kirjoita kertakäyttöinen vaihe, joka ratkaisee riippuvuuden isännän ja avaa siihen yhteyden. Se on ainoa testi, joka vastaa kysymykseen buildaajan eikä komentotulkkisi puolesta.

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/

Buildaa tiedosto samalla buildaajalla, verkkotilalla ja samoilla secret-liitoksilla, joita oikea buildisi käyttää: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. Jos getent ei tulosta mitään, vika on nimien ratkaisussa eikä mikään tunnistetieto korjaa sitä. Jos nimi ratkeaa mutta curl ilmoittaa aikakatkaisusta, este on reitti tai rekisterin edessä oleva lähtevän liikenteen käytäntö.

Poista anturi, kun se on vastannut. Se on diagnostinen vaihe, eikä sitä pitäisi koskaan tagata tai pushata.

Liitä tunnistetieto sen sijaan että kopioisit sen

Kun reitti toimii, todennus on seuraava epäonnistuminen jonossa. BuildKitin secret-liitos tarjoaa tiedoston yhdelle RUN vaiheelle kirjoittamatta sitä kerrokseen, ja juuri sitä riippuvuustyökalu tarvitsee ja mitä imagen ei pidä säilyttää.

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

Salaisuus on toimitettava Dockerfilen ulkopuolelta: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. Tiedosto jää asiakkaalle eikä koskaan päädy imagen historiaan. Yksi ARG tai ENV samalla tokenilla ei tee tätä työtä, koska molemmat tallennetaan imagen kokoonpanoon.

Rootiton image tarvitsee oman kohdepolkunsa, esimerkiksi /home/app/.npmrc tai vastaavan tiedoston pipille, Mavenille tai Cargolle. Liitoksen kohteen on vastattava käyttäjää, joka komennon suorittaa, tai työkalu ilmoittaa puuttuvasta kokoonpanotiedostosta, joka todella on olemassa.

Tarkista, mitä riippuvuustyökalu jättää imageen

Väliaikainen liitos pitää tunnistetiedon kerroksen ulkopuolella, mutta ei estä työkalua kirjoittamasta jotain muuta. Paketinhallintaohjelmat jättävät lock-tiedostoja, välimuistihakemistoja ja joskus ratkaistun rekisterin URL-osoitteen.

Lue valmis tiedostojärjestelmä sen sijaan että luottaisit Dockerfileen. docker history --no-trunc image:tag luettelee jokaisen kerroskomennon, ja docker run --rm image:tag sh -c "ls -a /root" näyttää, mikä selvisi käynnissä olevaan konttiin. Vaikka tiedosto olisi vain liitetty, lokiriville kirjoitettu token on silti vuoto, myös npm ci vaiheessa.

Lue myös build-loki, koska --progress=plain tulostaa komentojen tulosteen sanatarkasti. Jos token ilmestyy sinne, kierrätä se ennen kaikkea muuta ja välitä se tiedoston kautta, jota työkalu lukee hiljaa.

Varmista, ettei ajonaikainen image tarvitse enää yksityistä reittiä

Build ja käynnissä oleva sovellus ovat saman riippuvuuden kaksi eri käyttäjää, ja vain ensimmäinen tarvitsee yksityisen reitin. Valmiin imagen pitäisi käynnistyä, ratkaista ajonaikaiset riippuvuutensa ja palvella liikennettä ilman buildin tunnistetietoa.

Testaa sitä siellä, missä yksityinen rekisteri ei ole tavoitettavissa, tai käynnistä kontti yksinkertaisesti --network none ja varmista, että se käynnistyy ilman liitettyä salaisuutta. Kontti, joka käynnistyy vain kun build-salaisuus on läsnä, on edelleen kytketty build-ympäristöön.

Jos kontti todella tarvitsee rekisteriä ajon aikana, se on erillinen käyttöpäätös, ja se kuuluu orkestroijan salaisuusvarastoon eikä buildiin. Dokumentoi molemmat polut erikseen, ettei kukaan yritä korjata ajonaikaista pullia build-lipulla. Kun kaikki viisi tarkistusta menevät läpi, alkuperäisellä oireella on jokaisella kerroksella nimetty syy arvailun sijaan Dockerin verkosta.