Zmiany proxy Dockera zastosowane w niewłaściwym demonie

Dodałeś proxy do docker.service, uruchomiłeś go ponownie, a następne pobieranie zachowało się dokładnie jak wcześniej. Na maszynie z instalacjami zarówno apt, jak i snap sprawdź, czy to ten demon, którego używa Twoje CLI.

Trzeba dopasować trzy odrębne tożsamości: plik wykonywalny CLI, wybrany punkt końcowy oraz proces serwera stojący za tym punktem końcowym. Znalezienie jednego polecenia docker w PATH rozstrzyga tylko pierwszą.

docker context show
docker context inspect

Konteksty Dockera opisują punkty końcowe. DOCKER_HOST, DOCKER_CONTEXT oraz wybór punktu końcowego w wierszu poleceń mogą nadpisać pozorną wartość domyślną, więc sprawdź także środowisko i wywołanie.

Następnie powiąż wybrany gniazdo lub adres zdalny z rzeczywistym demonem i konfiguracją jego usługi. Dwie instalacje mogą mieć różne jednostki, ścieżki konfiguracji i magazyn. Kontekst zdalny może wskazywać całkowicie poza maszynę.

Zastosuj proxy przez interfejs należący do tego demona. Udokumentowane ustawienia demona Dockera i jego środowisko startowe nie są rozgłaszaniem do każdej instalacji Dockera na hoście.

Wykonaj tę identyfikację, zanim odinstalujesz pakiet, aby "posprzątać". Demon wyglądający na nieużywany może być właścicielem kontenerów lub obrazów, którymi druga instalacja nie zarządza. Natychmiastowa naprawa proxy to świadome skonfigurowanie wybranego serwera; decyzja, którą instalację zachować, jest osobną zmianą konserwacyjną.