Przewodnik po Dockerze · 1 min czytania

Docker za proxy: demon, budowanie i kompozycja

Docker potrzebuje proxy w trzech oddzielnych miejscach — demon, który pobiera obrazy, budowa, która wykonuje polecenia, oraz kontenery, które uruchamiasz. Ustawienie niewłaściwego spowoduje, że pobieranie nadal będzie nieudane. Oto każde z nich, poprawnie określone.

Zacznij

Trzy warstwy, trzy konfiguracje

Powód, dla którego "ustawiłem http_proxy, ale pobieranie z dockera nadal nie działa" jest tak powszechny, to fakt, że Docker ma trzy niezależne konteksty sieciowe, a zmienne środowiskowe twojej powłoki dotyczą tylko jednego z nich. Po pierwsze, demon (dockerd) to ten, który faktycznie pobiera obrazy z rejestru — działa jako usługa systemowa i odczytuje swój proxy z własnej konfiguracji, a nie z twojej powłoki. Po drugie, budowa wykonuje każdy RUN krok wewnątrz tymczasowego kontenera, który potrzebuje własnego proxy, aby uzyskać dostęp do sieci. Po trzecie, działający kontener potrzebuje proxy, jeśli aplikacja w nim wykonuje połączenia wychodzące.

Wszystkie trzy używają s4m punktu końcowego HTTP na porcie 3128 z autoryzacją USER:PASS. Nowoczesny sposób konfigurowania demona i budowy to plik konfiguracyjny klienta Dockera ~/.docker/config.json, który automatycznie wstrzykuje ustawienia proxy do budów i docker run; sam demon jest konfigurowany za pomocą drop-in systemd lub ustawień Docker Desktop. Zobacz stronę proxy; to naturalnie łączy się z przewodnikami npm/yarn i pip/conda dotyczącymi tego, co działa wewnątrz twoich obrazów.

Skonfiguruj wszystkie trzy warstwy

Demon przez systemd drop-in, buduje i uruchamia przez docker config.json oraz fallback compose. Zastąp USER:PASS.

bash

# --- 1) DAEMON (image pulls): systemd drop-in on Linux ---
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf >/dev/null <<'CONF'
[Service]
Environment="HTTP_PROXY=http://USER:PASS@proxy.s4m.online:3128"
Environment="HTTPS_PROXY=http://USER:PASS@proxy.s4m.online:3128"
Environment="NO_PROXY=localhost,127.0.0.1,.internal"
CONF
sudo systemctl daemon-reload && sudo systemctl restart docker

# --- 2) BUILDS + RUNS: ~/.docker/config.json (injected automatically) ---
cat > ~/.docker/config.json <<'JSON'
{
  "proxies": {
    "default": {
      "httpProxy":  "http://USER:PASS@proxy.s4m.online:3128",
      "httpsProxy": "http://USER:PASS@proxy.s4m.online:3128",
      "noProxy":    "localhost,127.0.0.1,.internal"
    }
  }
}
JSON

# --- 3) docker-compose fallback (per-service build args) ---
# services:
#   app:
#     build:
#       context: .
#       args:
#         HTTP_PROXY:  http://USER:PASS@proxy.s4m.online:3128
#         HTTPS_PROXY: http://USER:PASS@proxy.s4m.online:3128

Uzyskaj działający docker pull i build

Napraw warstwy w kolejności, w jakiej zazwyczaj występują błędy.

Najpierw napraw demona

Jeśli pobieranie docker pull nie powiedzie się, demon nie może dotrzeć do rejestru. Dodaj drop-in systemd z HTTP_PROXY/HTTPS_PROXY, a następnie daemon-reload i uruchom ponownie dockera. W Docker Desktop ustaw proxy w Ustawieniach.

Skonfiguruj klienta dla wersji

Dodaj blok proxy do ~/.docker/config.json, aby docker build i docker run automatycznie wstrzykiwały proxy w każdym kroku i kontenerze — nie są wymagane żadne edycje Dockerfile.

Dodaj NO_PROXY wszędzie

Uwzględnij localhost, 127.0.0.1 oraz wszelkie wewnętrzne rejestry lub hosty usług w NO_PROXY na każdym poziomie, aby ruch wewnętrzny nie był niepotrzebnie kierowany przez proxy.

Zweryfikuj każdą warstwę

Testuj za pomocą docker pull hello-world (demon), budowy, która uruchamia apt-get lub pip (budowa) oraz kontenera, który wywołuje punkt końcowy IP-echo (czas działania).

Zakres, sekrety i uczciwość

Dwie uwagi. Po pierwsze, trzymaj dane uwierzytelniające proxy z dala od warstw obrazu. Ustawianie zmiennych środowiskowych proxy wewnątrz Dockerfile za pomocą ENV wprowadza je do obrazu; zamiast tego użyj argumentów budowy lub wstrzykiwania klienta config.json, aby dane uwierzytelniające pozostały na hoście budowy. Po drugie, bądź precyzyjny z NO_PROXY — brak wpisu dla wewnętrznego rejestru oznacza, że Docker próbuje się do niego dostać przez zewnętrzny proxy i kończy się to mylącą porażką.

Proxy HTTP s4m to uwierzytelniony punkt końcowy w centrum danych, płatny na zasadzie pay-as-you-go — doskonale nadaje się do budowniczych CI i hostów DevOps, które muszą pobierać obrazy i pakiety z za kontrolowanego wyjścia. Nie jest to proxy mieszkalne, a jest to proxy pośredniczące, a nie lustro rejestru ani pamięć podręczna; do pamięci podręcznej pull-through uruchom lustro rejestru obok niego. Gdy twoja flota budowlana potrzebuje jednego dozwolonego adresu IP wyjścia, dodaj dedykowany osobisty adres IP. Wszędzie, gdzie pojawia się 407, oznacza to złe dane uwierzytelniające proxy — zobacz przewodnik 407. Zweryfikuj punkt końcowy za pomocą narzędzi.

FAQ

Pytania, odpowiedzi

Dlaczego docker pull nie działa, mimo że ustawiłem http_proxy w moim shellu?

Ponieważ pobieranie obrazów odbywa się przez demona, a nie przez Twoją powłokę. Skonfiguruj proxy dockerd za pomocą drop-in systemd (lub ustawień Docker Desktop) z HTTP_PROXY/HTTPS_PROXY, a następnie zrób daemon-reload i uruchom ponownie dockera.

Jak mogę używać proxy do budowy docker i uruchamiania docker bez edytowania Dockerfile?

Dodaj blok proxy do ~/.docker/config.json. Klient Docker automatycznie wstrzykuje httpProxy/httpsProxy w każdym kroku budowy i kontenerze, więc nie są potrzebne żadne zmiany w Dockerfile.

Jak mogę ukryć dane logowania do proxy w moim obrazie?

Nie ustawiaj ich za pomocą ENV w pliku Dockerfile — to wbudowuje je w warstwy. Użyj argumentów budowy lub wstrzykiwania w pliku config.json klienta, aby dane uwierzytelniające pozostały na hoście budującym, a nie w dostarczonym obrazie.

Czy s4m zapewnia lustrzane odbicie rejestru lub pamięć podręczną?

Nie. s4m to proxy z centrum danych do ruchu wychodzącego, a nie pamięć podręczna rejestru. Aby buforować obrazy, uruchom lustro rejestru i skieruj je przez proxy, jeśli to konieczne.

Czytaj dalej

Może ci się również spodobać

Pobierz i zbuduj za pomocą proxy

Przekieruj demona Docker, budowy i kontenery przez uwierzytelniony punkt końcowy HTTP na proxy.s4m.online:3128. Płatność za użycie, dedykowany adres IP dla list dozwolonych CI.

Zobacz ceny proxy Zobacz ceny

Ludzie znaleźli tę stronę, szukając

Docker za proxy
jak używać proxy z Scrapy
Docker za proxy samouczek
Ustawienia Docker za proxy
jak sprawdzić, czy proxy jest ważne (z gotowym skryptem)
jak proxy socks5 działa
jak wireguard działa
czy uwierzytelnianie proxy jest bezpieczne
adres IP
jak długo żyją darmowe proxy
uwierzytelnianie proxy

Rzeczywiste frazy wyszukiwania, na które ta strona odpowiada — powiązane otwierają stronę, która je szczegółowo omawia.