Docker-proxyændringer anvendt på den forkerte daemon

Du føjede en proxy til docker.service, genstartede den, og det næste pull opførte sig præcis som før. På en maskine med både apt- og snap-installationer skal du kontrollere, om det er den daemon, din CLI bruger.

Der er tre separate identiteter at afstemme: CLI-kørselen, det valgte endpoint og serverprocessen bag det endpoint. At finde én docker-kommando i PATH afklarer kun den første.

docker context show
docker context inspect

Docker-kontekster beskriver endpoints. DOCKER_HOST, DOCKER_CONTEXT og valg af endpoint på kommandolinjen kan tilsidesætte den tilsyneladende standard, så undersøg også miljøet og kaldet.

Knyt derefter den valgte socket eller fjernadresse til den faktiske daemon og dens tjenestekonfiguration. To installationer kan have forskellige units, konfigurationsstier og lager. En fjernkontekst kan pege helt uden for maskinen.

Anvend proxyen via den grænseflade, der hører til den daemon. Dockers dokumenterede daemonindstillinger og dens opstartsmiljø er ikke en udsendelse til enhver Docker-installation på værten.

Foretag denne identifikation, før du afinstallerer en pakke for at "rydde op". En daemon, der ser ubrugt ud, kan eje containere eller images, som den anden instans ikke administrerer. Den umiddelbare proxyreparation er at konfigurere den valgte server bevidst; beslutningen om, hvilken installation der skal beholdes, er en separat vedligeholdelsesændring.