Docker-basisimages ophalen: builderproxy versus build-argumenten
Proxyargumenten die aan buildstappen worden gegeven, configureren niet elke registeraanvraag van de builder. Zoek de builder die de basisimage resolveert.
Een build kan mislukken bij het resolven van FROM voordat een Dockerfile-pakketdownloadstap draait. De registerclient van de builder heeft zijn eigen route nodig om die basisimage op te halen.
| Bewerking | Component dat de route nodig heeft |
|---|---|
| Basisimage resolven en ophalen | De registerclient van de builder |
| Download tijdens RUN | Het proces dat de buildstap uitvoert |
| Een API aanroepen tijdens runtime | De draaiende applicatie |
Zoek de builder
Het standaard Docker-stuurprogramma draait om de daemon. Andere Buildx-stuurprogramma's kunnen een toegewijde BuildKit-container, Kubernetes of een externe dienst gebruiken. Configureer het ondersteunde proxymechanisme van het gekozen stuurprogramma waar die worker draait.
Een loopbackproxy op een laptop is niet automatisch bereikbaar vanaf een externe worker, en het bewerken van de lokale daemon herconfigureert die externe builder niet.
Een ARG vóór FROM kan helpen bij het kiezen van de imagereferentie. Daarmee wordt echter niet de netwerkroute van de registerclient geconfigureerd. Latere RUN-opdrachten die pakketinstellingen schrijven of certificaten installeren, kunnen deze eerdere aanvraag niet repareren.
Vertrouwen, accounts en gecachte gegevens
Goedgekeurd CA-materiaal moet beschikbaar zijn voor het component dat de eerste registerverbinding valideert. Registerreferenties en proxyreferenties autoriseren verschillende partijen; een registeraanmelding kan geen proxy 407 beantwoorden.
Een worker die gecachte imagegegevens hergebruikt, herhaalt mogelijk niet dezelfde netwerkaanvraag als een nieuwe worker. Vergelijk de werkelijk gelogde bewerking. Zodra de toegang tot de basisimage via de bedoelde route werkt, diagnosticeert u elke latere download in de buildstap bij die volgende grens.