VPN bağlandıktan sonra Docker birim bağlaması başarısız oluyor: daemon'u denetleyin

Bu sorunla ilgili neredeyse her yazı birimi suçlar ve düzeltmenin bu kadar uzun sürmesinin nedeni tam olarak budur. Çalışan bir bind mount'unuz vardı, kurumsal VPN bağlandı ve docker compose up şimdi eksik bir kaynak yolu, boş bir dizin veya motorun oluşturmayı reddettiği bir bağlama ile başarısız oluyor. Temizlediğim ortamlarda Compose dosyası değişmemişti ve yol doğruydu. Değişen şey isteği hangi daemon'un aldığıydı ve bağlama hatası bu farkın ilk görünür olduğu yerdi.

Birim hiç hareket etmedi; istek hareket etti

Bir -v /srv/app:/app bayrak, kabuğunuzun yaptığı bir dizin kopyası değildir. İstemci onu bir API isteğine dönüştürür ve yanıt veren daemon /srv/app yolunu kendi dosya sistemine göre çözer. İki taraf da aynı çekirdek üzerinde çalıştığında bu yol, dosya yöneticinizde gördüğünüz yoldur. Endpoint değiştiğinde aynı dize, proje dizininizi hiç duymamış bir makinede aranır ve daemon ya kaynağı eksik olarak bildirir ya da yerine sessizce boş bir dizin oluşturur.

Adlandırılmış bir birimin çalışmaya devam ederken bind mount'un etmemesinin nedeni de budur. -v appdata:/app daemon'un sahip olduğu depolamayı adlandırır, bu yüzden hiçbir ana makine yolunun belirli bir yerde var olması gerekmez. Bir hizmeti bind mount'tan adlandırılmış bir birime taşımak hatayı ortadan kaldırıyorsa sorunu çözmemişsinizdir. İstemcinin ve daemon'un yolun hangi dosya sistemine ait olduğu konusunda anlaşmadığını doğruladınız ve bu anlaşmazlık yeniden gerçek bir ana makine dizinine ihtiyaç duyduğunuz anda geri döner.

Bağlamaya dokunmadan önce endpoint'i yazdırın

Birkaç ayar istemciyi bir endpoint'e yönlendirebilir ve bunlar her zaman aynı fikirde değildir: --context bayrağı, DOCKER_CONTEXT, DOCKER_HOST geçerli kabukta ve istemci yapılandırmasında kayıtlı context. Öncelik hakkında akıl yürütmek yerine hepsini yazdırın ve yanıtları karşılaştırın.

docker context show
docker context ls
docker version
docker info --format "{{.Name}} {{.OperatingSystem}} {{.ServerVersion}}"

İstemci yapılandırması şurada bulunur: ~/.docker/config.json Linux ve macOS'ta, şurada da: %USERPROFILE%\.docker\config.json Windows'ta ve geçerli terminalde dışa aktarılan bir değer, kayıtlı olanı yalnızca o oturum için geçersiz kılar. Endpoint yerel bir socket yerine bir ana makine adıysa, ad çözümlemesi ve rotalar nereye ineceğine karar verir ve bir VPN istemcisinin yeniden yazdığı tam olarak bunlardır. Bir rota ekleyen veya çözümleyiciyi değiştiren bir tünel, eskiden bu dizüstü bilgisayarı ifade eden bir adı kurumsal ağ içindeki bir adrese gönderebilir.

Yapılandırmayı değil durumu karşılaştırın. Tünel kapalıyken docker ps -a ve docker images komutlarını çalıştırın, sonra tünel açıkken tekrar. Farklı bir konteyner listesi herhangi bir yapılandırma dosyasından daha güçlü kanıttır, çünkü isteğinize başka bir daemon'un yanıt verdiğini gösterir.

Yolun orada olup olmadığını daemon'a sorun

Hangi daemon'a ulaştığınızı öğrendikten sonra ona dizine bakmasını söyleyin. --mount biçim, kısa bayraktan daha açık bir mesajla başarısız olur, çünkü konteyneri başlatmadan önce kaynağı doğrular:

docker run --rm --mount type=bind,source=/srv/app,target=/app alpine ls -la /app

Kaynağı eksik olarak bildirirse, yanıt veren makinede oluşturun veya hizmeti adlandırılmış bir birime yönlendirip verileri oraya kopyalayın. Yapmamanız gereken şey, bu denetimden önce birimleri yeniden oluşturmak ve motoru yeniden kurmaktır. Bu eylemler ortamı uyumsuzluğu gizleyecek kadar değiştirir ama onu yerinde bırakır.

Bir yol daha tamamen başka bir yerde çalışır: image çekmek daemon işidir, istemci işi değildir. Başarılı bir çekme yalnızca daemon'un bir registry'ye ulaşabildiğini kanıtlar, çalışan bir bind mount ise yalnızca bir yolun çözüldüğünü. Her yolu gerçekten yürütüldüğü yerde test edin, yoksa bir öğleden sonrayı yanlış olanla geçirirsiniz.

İntranet adları başka bir nedenle başarısız olur

Aynı raporun ikinci yarısı genellikle konteynerin intranet.corp.exampleadresine ulaşamamasıdır. Bu ayrı bir mekanizmadır, ikinci bir birim sorunu değildir. Konteyner /etc/resolv.conf dosyasını başlarken alır, bu daemon'un çözümleyici ayarlarından üretilir, bu nedenle konteyner oluşturulduktan sonra VPN'in eklediği bir DNS sunucusu, konteyner yeniden oluşturulana kadar orada görünmez.

Kullanıcı tanımlı bir ağda Docker'ın gömülü çözümleyicisi dış sorguları ana makinenin yapılandırılmış sunucularına iletir; bu, VPN ana makine çözümleyicisini yeniden yazdığında yardımcı olur ve bölünmüş DNS iç bölgeyi daemon'un artık görmediği bir sunucuya gönderdiğinde zarar verir. Dar ve açık bir eşleme, hiç değişmeyen adlar için bu tartışmayı atlar:

services:
  web:
    extra_hosts:
      - "intranet.corp.example:10.20.30.40"

Bu, konteynerin hosts dosyasına bir girdi yazar, böylece konteyner tünel hakkında hiçbir şey öğrenmez ve adresi de dondurur. İç ana makine taşındığında, biri Compose dosyasını düzenleyene kadar girdi yanlış kalır. Sabit bir cihaz veya sabitlenmiş bir veritabanı için kullanın ve hareket eden adları DNS'e bırakın.

Yeniden kurulum gerçekte neyi değiştirir

Docker Desktop'ı yeniden kurmak VM'i, socket'i ve context listesini yeniden oluşturur ve bağlama yeniden çalışmaya başlar. Bu sonuç gerçektir ve hiçbir şey öğretmez, bu yüzden aynı arıza bir sonraki VPN güncellemesinden sonra geri döner. Yeniden kurulum istemcinin kullandığı endpoint'i değiştirdi; projenizin adlandırdığı yolu daemon'un gerçekte okuduğu dosya sistemiyle uzlaştırmadı.

Çalışma sıram kısa. İstemcinin hangi endpoint'i kullanacağını doğrulayın. Konteyner listelerini karşılaştırarak hangi daemon'un yanıt verdiğini doğrulayın. O daemon'dan kaynak yolunu listelemesini isteyin. Ancak ondan sonra bağlamayı düzenleyin, bir hosts girdisi ekleyin veya bir birim türünü değiştirin. Compose dosyasını VPN üzerinden çalışan bir ekip için sürdürüyorsanız, daemon'un sahip olması gereken veriler için adlandırılmış birimleri tercih edin, böylece bir ana makine yolu asla sözleşmenin parçası olmaz.