Kurumsal proxy'niz neden bir Compose servis adını çözümlemeye çalışıyor

Uygulama internete kurumsal proxy'si üzerinden erişir, ancak http://catalog:8080/ başarısız olur ve proxy “catalog” adını çözemez. Bu istek Docker'ın dahili DNS'ini hiç kullanmamış olabilir.

Bir HTTP istemcisi doğrudan bağlantı kurmadan önce proxy'sini seçebilir. Dış proxy o zaman anlamı yalnızca Compose ağı içinde var olan bir ad alır.

1. İstekte ana makine adını kullanın. Compose servisleri uygun ağda servis adıyla bulunabilir. Değişebilecek bir konteyner IP'sini sabit kodlamak yerine catalog öğesini kullanan istemcinin desteklediği atlama yapılandırmasına ekleyin.
2. Mevcut istisnaları koruyun. Ortamın farkında olan bir istemci için ilgili girdileri kuruluş listesiyle birleştirin:

NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

İmgedeki gerçek kitaplığı veya çalıştırılabilir dosyayı büyük/küçük harf işleme, sürüm ve eşleştirme dilbilgisi açısından denetleyin. Evrensel bir NO_PROXY ayrıştırıcısı yoktur. Küçük bir imgedeki wget adlı programın GNU Wget gibi davranması gerekmez.

İstek doğrudan yönlendirmeyi seçtiğinde, çağıranın ve servisin ortak ağını, dinleyen servisi ve konteyner bağlantı noktasını denetleyin. Yayımlanan ana makine bağlantı noktası başka bir uç noktadır. Atlama, eksik bir ağ bağlantısını ekleyemez; tıpkı bir ağı yeniden oluşturmanın dış proxy'ye özel bir Compose adı öğretememesi gibi.

Amaçlanan ayrımı koruyun: dahili istekler kendi dahili yollarını kullanır; harici istekler onaylanmış proxy'yi korur. Proxy'yi genel olarak devre dışı bırakmak bu tek hatayı gizleyebilir ve aynı zamanda bir sonraki harici istek için gereken rotayı kaldırabilir.