Docker varsayılan havuzunu değiştirmek ağları yeniden numaralandırmaz

default-address-pools ayarını değiştirmek, zaten sahip olduğunuz ağları yeniden numaralandırmaz ve bunu beklemek, dikkatli bir planın beklenmedik bir kesintiye dönüşme biçimidir. Ayar, daemon yeni yapılandırmayla yeniden başladıktan sonra oluşturulan ağlar için otomatik tahsisi yönetir. Zaten çalışan her şey kendisine verilen alt ağı korur, çünkü o alt ağ ağın saklanan tanımının bir parçasıdır. Efsane elverişlidir çünkü tek bir düzenlemenin her çakışmayı düzelttiğini ima eder; gerçek ise iki parçalı bir iştir: gerçekten boş olan bir aralık seçin, sonra boş olmayan ağları taşıyın.

Efsane: tek bir havuz değişikliği çakışmayı düzeltir

Efsanenin belirli bir biçimi vardır. Birisi Docker'ın varsayılan havuzunun değiştirilebileceğini okur, değiştirir, daemon'u yeniden başlatır ve konteyner ağının artık ofis VPN'iyle çakışmadığı sonucuna varır. Eski ağ hâlâ oradadır, hâlâ bağlıdır ve çakışan adresi hâlâ tutmaktadır.

Değişen, tahsis edicinin gelecekteki davranışıdır; bu gerçekten yararlı ve gerçekten sınırlıdır. Açık bir --subnet olmadan oluşturulan yeni ağlar yeni havuzdan kesilir; mevcut olanlar o havuzda hiç bulunmamıştır. Yeniden başlatma ağları yeniden kurmaz ve konteynerleri aralarında taşımaz. Değişiklikten sonra belirti sürerse, değişiklik gerçekti ve tanı eksikti.

Temel aralık ve tahsis edilen önek

Yapılandırmada karıştırılması kolay iki alan vardır. base tahsis edicinin kestiği aralıktır, size ise tahsis edilen her ağın önek uzunluğudur; yani 10.10.0.0/16 tabanı 24 boyutuyla o /16 içinde /24 dağıtır. Rolleri ters çevirmek, amaçlamadığınız bir tahsis deseni üretir; genellikle tek bir dev ağ ya da tükenmiş bir havuz.

Havuz bir rezervasyondur, kanıt değil. Docker ana makinenin yönlendirme tablosunda gördüğü çakışmalardan kaçınır ve henüz bağlanmadığınız bir VPN'i göremez.

Bu sınırlama, bilinçli seçmenin tüm nedenidir. Karşılaştırılacak aralıklar ana makinenin ulaşması gerekenlerdir: ofis LAN'ı, kurumsal VPN'in iç alt ağları, laboratuvar ya da staging önekleri ve aynı overlay üzerindeki diğer konteyner ana makineleri. Daemon'a dokunmadan önce bunları CIDR olarak yazın, çünkü kafanızdaki liste tam da önemli olanı atlayacaktır. Sonra hiçbiriyle çakışmayan bir taban seçin ve listeyi dağıtımla birlikte saklayın ki bir sonraki kişi bu alıştırmayı bellekten tekrarlamasın.

Seçmeden önce envanterleyin

Önce ne olduğunu envanterleyin. docker network ls ağları listeler, docker network inspect bridge -f '{{.IPAM.Config}}' belirli bir ağın kullandığı alt ağı yazdırır. Kullanıcı tanımlı her ağ için bunu yineleyin, çünkü Compose projeleri kendilerininkini oluşturur ve bir compose dosyasındaki açık --subnet havuzu tamamen atlar.

Son nokta taşınmadan sonra da yaşayan noktadır. Havuz değişikliği bir iş arkadaşını compose dosyasında 172.18.0.0/16 sabitlemekten alıkoymaz ve çakışma başka bir yazarla geri döner.

Zaten var olanı taşımak

Mevcut ağları taşımak ayrı ve desteklenen bir işlemdir. Etkilenen her ağ yeni alt ağla yeniden oluşturulmalıdır; bu, onu kullanan konteynerlerin ayrılıp yeniden bağlanması demektir ve bir ağı yeniden oluşturmak konteyner bağlantılarını taşımak yerine kaldırır. Birimleri ve yapılandırmayı koruyun ve yeniden oluşturmayı veri sıfırlama değil dağıtım olarak ele alın. İşi bir bakım penceresinde yapın, çünkü yeniden oluşturulan bir ağdaki konteynerler planlamış olsanız da olmasanız da yeniden başlar.

Belgelenmiş daemon yapılandırmasını ve yeniden başlatma prosedürünü izleyin ve kesintiyi koordine edin. Tek daemon'lu bir ana makinede systemctl restart docker konteynerleri yeniden başlatma politikalarına göre yeniden başlatır ve bu, sonradan değil önceden bilinmesi gereken bir davranıştır.

Sonra değişikliğin düzeltmesi gereken iki şeyi doğrulayın. Yeni alt ağı docker network inspect ile inceleyin ve seçilen tabanın içinde olduğunu onaylayın, ardından temsili bir VPN hedefine giden yolu ip route get 10.20.30.40 ile kontrol edin ve beklediğiniz yere gittiğini, bir köprüye gitmediğini onaylayın. Hizmet keşfini ve konteynerden konteynere iletişimi de test edin, çünkü farklı adreslemeyle yeniden oluşturulan bir ağ ad çözümlemesini uygulama hatası gibi görünen biçimlerde bozabilir.

Sonrasında hâlâ ne bozulur

Kalıcı kısım kayıttır. Tahsis listesini, seçilen tabanı ve boyutu ve yeniden oluşturulan ağları dağıtımla aynı yerde saklayın.

Bir aralığın özel olması onu yeniden kullanım için güvenli kılmaz. 10.0.0.0/8 özeldir ve aynı zamanda yolda bir yerde zaten kullanımda olma olasılığı en yüksek olan şeydir; bu yüzden yanıt tek bir bloğa tercih değil, belirli bir rezervasyondur. Docker ağ belgeleri otomatik alt ağ tahsisini ve havuz alanlarını açıklar. Aralığı düzenli görünene göre değil, ulaşmanız gereken şeye göre seçin.