Accesarea unui proxy de pe gazdă dintr-un container Docker bridge

Alege o adresă proxy accesibilă containerului și distinge un punct public de un proxy care rulează pe gazda Docker.

Într-un container obișnuit în rețea bridge, 127.0.0.1 este loopback-ul containerului însuși. Un proxy care ascultă pe localhost-ul laptopului nu ascultă automat în fiecare container.

Asta explică o diferență comună: același URL proxy funcționează în terminalul gazdei, dar conexiunea e refuzată în container. Adresa indică un punct de rețea diferit în fiecare loc.

Un proxy public poate fi folosit direct

Dacă punctul dintr-un serviciu sau din lista de proxy-uri HTTP este într-adevăr un IP public accesibil, transmite acea adresă aplicației, nu o schimba în localhost:

docker run --rm \
  -e HTTP_PROXY=http://203.0.113.10:8080 \
  -e HTTPS_PROXY=http://203.0.113.10:8080 \
  your-image

Înlocuiește adresa de documentație și imaginea. Programul din imagine trebuie totuși să accepte variabilele de mediu; Docker nu transformă fiecare socket în cerere proxy doar fiindcă există variabilele.

Dacă proxy-ul rulează pe gazda Docker

Docker Desktop oferă host.docker.internal pentru a ajunge la adresa internă a gazdei. Într-o configurație Engine nativă acceptată, o mapare de gazdă poate furniza acest nume convențional:

docker run --rm \
  --add-host host.docker.internal=host-gateway \
  -e HTTP_PROXY=http://host.docker.internal:8080 \
  -e HTTPS_PROXY=http://host.docker.internal:8080 \
  your-image

Aceasta schimbă rezolvarea numelor, nu este comandă de redirecționare a portului. Pe Linux nativ, un serviciu legat doar de loopback-ul gazdei poate rămâne inaccesibil prin adresa bridge a gazdei. Ascultătorul, firewall-ul și ruta containerului trebuie să permită conexiunea. Limitează ascultătorul modificat la clienții necesari în loc să creezi un proxy deschis fără autentificare.

Testează din același loc ca aplicația

Un rezultat curl pe gazdă testează doar ruta gazdei. Fă cererea din mediul containerului și verifică atingerea punctului dorit.

„Gazdă” înseamnă și mașina care rulează Docker Engine. Cu un Engine distant nu este neapărat laptopul tău. De aceea, un IP loopback dintr-o aplicație locală de desktop are șanse deosebit de mici să funcționeze neschimbat pe un builder sau server distant.

Separă problemele de descărcare a imaginii: daemonul descarcă imaginea înainte ca aplicația să poată utiliza mediul de mai sus.

Articole similare