Mapa proxies w Dockerze zależy od daemona, a nie od witryny
Wpis specyficzny dla hosta w konfiguracji proxy klienta Docker wybiera ustawienia połączenia z daemonem Docker. Nie jest to reguła PAC dla każdego celu.
Obiekt JSON wygląda obiecująco: mapa proxies z wpisem default i dodatkowymi kluczami adresów. Kuszące jest umieszczenie tam nazwy hosta rejestru i oczekiwanie, że żądania do tego rejestru użyją innego proxy.
Te klucze identyfikują daemony Docker, z którymi łączy się klient. Nie identyfikują witryn, których będzie żądać kontener.
Konfiguracja klienta Docker może przekazywać nowym kontenerom zmienne środowiskowe proxy, a nowym kompilacjom argumenty kompilacji proxy. Wpis specyficzny dla daemona zmienia tę przekazaną konfigurację dla odpowiedniego kontekstu daemona.
Nie konfiguruje własnego połączenia wychodzącego daemona przez proxy. Nie zamienia też klienta HTTP kontenera w ewaluator PAC.
Jeśli Twoim zadaniem jest utrzymanie wewnętrznego rejestru bezpośrednio, podczas gdy daemon uzyskuje dostęp do innych usług przez proxy, sprawdź obsługiwaną przez daemona konfigurację proxy i obejścia. Jeśli aplikacja potrzebuje różnych proxy nadrzędnych dla różnych celów, ta polityka należy do odpowiedniego układu klienta lub przekazywania.
Przed edycją mapy zapisz, który adres reprezentuje klucz i który proces wykonuje nieudane żądanie. Ta sama nazwa hosta może pojawić się w połączeniu z daemonem, w adresie URL rejestru i w adresie URL proxy, ale to trzy różne role.