Perché docker pull ignora il proxy del contenitore
Configura il componente Docker che scarica davvero le immagini invece di aspettarti che le variabili del contenitore controllino il daemon.
Se docker pull fallisce, configura il daemon Docker o Docker Desktop. L’immagine viene scaricata prima che il contenitore applicativo possa leggere le proprie variabili proxy.
Docker Engine nativo
Unisci questa sezione alla configurazione proxy esistente del daemon, sostituendo l’endpoint di documentazione e conservando le impostazioni estranee. Per prove con immagini pubbliche in cui siano ammessi proxy pubblici, la lista di proxy HTTP offre candidati:
{
"proxies": {
"http-proxy": "http://203.0.113.10:8080",
"https-proxy": "http://203.0.113.10:8080",
"no-proxy": "localhost,127.0.0.1,registry.example.internal"
}
}Le chiavi del daemon con trattino sono diverse da quelle camelCase in ~/.docker/config.json del client Docker. La sezione proxy del client fornisce variabili d’ambiente ai nuovi contenitori e alle build; non configura né i download del daemon né gli ambienti dei contenitori già esistenti.
Esegui il riavvio del daemon documentato per l’installazione, pianificandone l’effetto sui carichi attuali. Il daemon può anche ricevere variabili proxy nell’ambiente di avvio; un export successivo in un terminale non aggiorna un servizio in esecuzione.
Docker Desktop
Usa le impostazioni proxy di Desktop. Docker documenta che Desktop ignora le voci proxy in daemon.json, quindi modificare continuamente l’esempio di Engine nativo non configura il percorso di questo prodotto.
Riprova a scaricare l’immagine dopo aver aggiornato il componente corretto. Distingui un errore di accesso al registro, autenticazione, reindirizzamento o download dei layer. Una richiesta HTTP riuscita dentro un contenitore esistente verifica soltanto il percorso di quell’applicazione. Non inserire credenziali proxy in screenshot condivisi o file sottoposti a commit; configurazione del daemon e ambiente del contenitore non sono archivi di segreti.