Docker: bir konteyneri VPN üzerinden yönlendirin, diğerini doğrudan bırakın

Tek bir ana makine, iki iş yükü ve onları ayıran bir gereksinim: ticari bir VPN üzerinden çıkması gereken bir indirme istemcisi ve ana makinenin bağlantısını kullanmaya devam etmesi gereken bir yönetim arayüzü. VPN istemcisini ana makineye kurmak gereksinimi hemen bozar, çünkü o zaman iki iş yükü tek bir çıkışı paylaşır. Gerçekten işleyen desen, tüneli kendi konteynerine taşımak ve yalnızca ona ihtiyaç duyan iş yüklerinin o konteynerin ağ ad alanına katılmasına izin vermektir. Geri kalan her şey olağan Docker yolunu korur ve ardından gelen ayrıntılar ad alanının kime ait olduğunun sonuçlarıdır.

Paylaşılan bir ad alanı kuralları neden değiştirir

Başka birinin ad alanına katılan konteyner kendi ağ yığınını almaz. Katıldığı konteynerle aynı arayüzleri, aynı yönlendirme tablosunu ve aynı loopback'i görür; desenin yararlı olmasının nedeni tam da budur: iş yükü normal biçimde çözer ve bağlanır, alttaki tünel ise trafiği uygulama bilmeden yakalar. Bedeli, her ağ ayarının artık tek bir sahibi olmasıdır ve katılan konteyner o sahip değildir.

Bu sahiplik kuralı, yapılandırma sorularının çoğuna sorulmadan önce yanıt verir. Ayar ağ yığınında yaşıyorsa yan konteynere aittir. Süreci tanımlıyorsa iş yükünde kalır.

loopback insanları şaşırtan kısımdır. Katılan konteynerin içinde localhost yan konteynerin loopback'ine çözümlenir, kendine ait özel bir adrese değil, bu yüzden yalıtım bekleyerek 127.0.0.1'e bağlanan bir hizmet artık bu adresi tünel konteyneriyle paylaşır.

Portları ad alanına sahip olan konteynerde yayımlayın

Port eşlemesi, dinleyen süreç diğer konteynerde çalışsa bile ad alanının sahibine aittir. Eşlemeyi yan konteynerde bildirin ve iş yükü kendi süreç yapılandırmasını dokunulmadan korusun. Katılan hizmetteki bir eşleme yürürlüğe giremez; motor onu reddetse de konteynerin nasıl başlatıldığına bağlı olarak sessizce yok saysa da, bu yüzden bir an önce erişilebilir olan arayüz desen uygulanır uygulanmaz kaybolur.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add: [NET_ADMIN]
    ports: ["8080:8080"]
  client-vpn:
    image: example/client
    network_mode: "service:gluetun"
  client-direct:
    image: example/client
    ports: ["8081:8080"]

Bu bloğu üç hizmet değil üç karar olarak okuyun. Yan konteyner tünele ve yayımlanan porta sahiptir; katılan istemci hiçbir ağ bildirmez; doğrudan istemci varsayılan ağda kendi eşlemesini korur. Yetenek NET_ADMIN yan konteynerin arayüz oluşturmasını ve yolları değiştirmesini sağlayan şeydir ve bu konteynerin hizmet verdiği iş yüklerinden daha fazla ayrıcalığa ihtiyaç duymasının nedeni budur.

Doğrudan kalan hizmet kendi ağını korur

Tünelden geçmemesi gereken iş yükü varsayılan köprüyü ya da kendi kullanıcı tanımlı ağını, kendi yayımlanmış portu ve kendi çıkışıyla korur. İki konteynerin adla konuşabilmesi için onu yan konteynerin ağına bağlamak cezbedicidir, ancak o tek adım trafiğini sessizce tünele taşır. Birbirlerine ulaşmaları gerekiyorsa ayrı bir kullanıcı tanımlı ağ kurun, ikisini de ona bağlayın ve yan konteyneri dışarı çıkan tek yol olarak bırakın.

İki soruyu ayrı tutun: hangi konteynerler birbirine ulaşabilir ve hangisi nereden çıkar. Bunları birleştirmek, bu tasarımın yeniden tüm ana makineyi kapsayan bir VPN'e dönüşmesinin en yaygın yoludur.

İlk saat için bir arıza matrisi

İlk denemelerin çoğu dört yoldan biriyle başarısız olur ve her birinin farklı bir nedeni vardır. Bunları bu sırayla kontrol edin, çünkü ilk ikisi neredeyse her raporu açıklar.

Dördüncü satır, insanların yanlışlıkla uygulama hatası olarak teşhis ettiği satırdır. İş yükünün kendi loopback'ine karşı yazılmış bir sonda artık tünel konteynerini sınar, bu yüzden ya başarısız olur ya da tamamen yanlış bir hizmet bildirir.

Tek bir ana makine adı tünele ihtiyaç duyduğunda

Bazen tam tünel fazla gelir: bir iç adın kurumsal VPN'den geçmesi gerekirken yerel bir soket veya görüntü bağlantısı çalışmaya devam eder. Konteyner içindeki tam tünel bu yolu ve ana makineye adreslenen her şeyi bozar, bu yüzden yalnızca ihtiyaç duyan öneki yönlendirin. İstemcinin çevresindeki bölünmüş yönlendirme sarmalayıcısı bunu yapar, adlandırılmış ana makineyi tünelden geçirir ve önceki yolu diğer her şey için dokunulmadan bırakır.

Bunu yalnızca tek bir hizmete ulaşmanız gerektiğinde ve konteynerin tüm trafiğini taşımaya çalışmadığınızda seçin. Yan konteynerden farklı bir araçtır ve farklı bir soruya yanıt verir.

Doğrulayın ve ardından yeniden başlatmaya dayanıklı hale getirin

Her konteynere hangi adresten geliyor göründüğünü sorun. Tüneldeki sağlayıcının adresini, doğrudan olan ise ana makinenin çıkışını yazdırmalıdır. Aynı yanıtlar, doğrudan hizmetin yanlış ad alanını devraldığını ya da ana makine düzeyindeki bir VPN'in hâlâ her şeyi yakaladığını gösterir ve bu iki düzeltme farklıdır. Her compose düzenlemesinden sonra kontrolü yeniden çalıştırın, çünkü kopyalanmış tek bir hizmet bloğu sorunu geri getirmeye yeter.

Üç şey sonradan bozulma eğilimindedir. DNS ad alanının sahibini izler, bu yüzden çözümleyici ve arama etki alanı ayarları ana makineye değil yan konteynere aittir. Port yönlendirmeli bir VPN yeniden bağlanırken dinleme portunu değiştirir, bu yüzden sağlayıcının yönlendirdiği port ve konteyner tarafındaki dinleme portu istemci yapılandırmasına veya port eşlemesine geri yazılmalıdır; genellikle sağlayıcının API'sini okuyan küçük bir güncelleyici bunu yapar. Ve localhost karşı yazılmış her sonda artık iş yüküne değil tünel konteynerine sorar.

Deseni yazın; hangi konteynerin ad alanına sahip olduğu ve hangi portların ona ait olduğu da dahil. Sıradaki kişi bir hizmet ekleyecek, yanlış bloğu kopyalayacak ve bu makaledeki ilk arızayı yeniden üretecek.