Pobieranie obrazów bazowych Dockera: proxy buildera a argumenty build
Argumenty proxy przekazywane krokom build nie konfigurują każdego żądania rejestru wykonywanego przez buildera. Zlokalizuj buildera, który rozwiązuje obraz bazowy.
Build może się nie powieść podczas rozwiązywania FROM, zanim uruchomi się jakikolwiek krok pobierania pakietów w Dockerfile. Klient rejestru buildera potrzebuje własnej trasy, aby uzyskać ten obraz bazowy.
| Operacja | Komponent wymagający trasy |
|---|---|
| Rozwiąż i pobierz obraz bazowy | Klient rejestru buildera |
| Pobieranie podczas RUN | Proces wykonujący krok build |
| Wywołanie API w czasie działania | Działająca aplikacja |
Zlokalizuj buildera
Domyślny sterownik Dockera koncentruje się na demonie. Inne sterowniki Buildx mogą używać dedykowanego kontenera BuildKit, Kubernetesa lub zdalnej usługi. Skonfiguruj obsługiwany przez wybrany sterownik mechanizm proxy tam, gdzie działa ten worker.
Proxy loopback na laptopie nie jest automatycznie osiągalne ze zdalnego workera, a edycja lokalnego demona nie rekonfiguruje tego zdalnego buildera.
ARG przed FROM może pomóc wybrać referencję obrazu. Nie konfiguruje jednak przez to trasy sieciowej klienta rejestru. Późniejsze polecenia RUN, które zapisują ustawienia pakietów lub instalują certyfikaty, nie mogą naprawić tego wcześniejszego żądania.
Zaufanie, konta i dane w pamięci podręcznej
Zatwierdzony materiał CA musi być dostępny dla komponentu sprawdzającego początkowe połączenie z rejestrem. Poświadczenia rejestru i poświadczenia proxy upoważniają różne strony; logowanie do rejestru nie może odpowiedzieć na 407 proxy.
Worker ponownie wykorzystujący dane obrazu z pamięci podręcznej może nie powtórzyć tego samego żądania sieciowego co nowy worker. Porównaj faktycznie zalogowaną operację. Gdy dostęp do obrazu bazowego działa zamierzoną trasą, zdiagnozuj każde późniejsze pobieranie w kroku build na tej następnej granicy.