Menukar pool lalai Docker tidak menomborkan semula rangkaian

Menukar default-address-pools tidak menomborkan semula rangkaian yang sudah anda miliki, dan menjangkakan ia berbuat demikian ialah cara pelan yang teliti bertukar menjadi gangguan tidak dijangka. Tetapan ini mengawal peruntukan automatik untuk rangkaian yang dicipta selepas daemon dimulakan semula dengan konfigurasi baharu. Semua yang sudah berjalan mengekalkan subrangkaian yang diberikan, kerana subrangkaian itu ialah sebahagian daripada takrifan tersimpan rangkaian. Mitos itu memudahkan kerana ia mencadangkan satu suntingan membaiki setiap pertindihan, dan realitinya ialah kerja dua bahagian: pilih julat yang benar-benar bebas, kemudian migrasikan rangkaian yang tidak bebas.

Mitos: satu perubahan pool membaiki pertindihan

Mitos itu mempunyai bentuk tertentu. Seseorang membaca bahawa pool lalai Docker boleh ditukar, menukarnya, memulakan semula daemon dan menyimpulkan bahawa rangkaian kontena tidak lagi berlanggar dengan VPN pejabat. Rangkaian lama masih ada, masih bersambung dan masih memegang alamat yang berlanggar.

Yang berubah ialah tingkah laku masa depan peruntuk, yang benar-benar berguna dan benar-benar terbatas. Rangkaian baharu yang dicipta tanpa --subnet eksplisit dipotong daripada pool baharu; yang sedia ada tidak pernah berada dalam pool itu. Permulaan semula tidak membina semula rangkaian dan tidak memindahkan kontena antaranya. Jika gejala berterusan selepas perubahan, perubahan itu nyata dan diagnosis tidak lengkap.

Julat asas dan awalan yang diperuntukkan

Konfigurasi ini mempunyai dua medan yang mudah dikelirukan. base ialah julat yang peruntuk potong, dan size ialah panjang awalan setiap rangkaian yang diperuntukkan, jadi asas 10.10.0.0/16 dengan saiz 24 mengagihkan /24 di dalam /16 itu. Membalikkan peranan menghasilkan corak peruntukan yang tidak anda maksudkan, biasanya satu rangkaian besar atau pool yang habis.

Pool ialah tempahan, bukan bukti. Docker mengelak pertembungan yang dilihatnya dalam jadual penghalaan hos, dan ia tidak dapat melihat VPN yang belum anda sambungkan.

Batasan itulah seluruh sebab untuk memilih dengan sedar. Julat yang perlu dibandingkan ialah yang mesti dicapai oleh hos: LAN pejabat, subrangkaian dalaman VPN korporat, awalan makmal atau staging dan mana-mana hos kontena lain pada overlay yang sama. Tuliskannya sebagai CIDR sebelum menyentuh daemon, kerana senarai dalam kepala akan terlepas yang paling penting. Kemudian pilih asas yang tidak bertindih dengan mana-mana daripadanya, dan simpan senarai bersama penggunaan supaya orang seterusnya tidak mengulangi latihan itu dari ingatan.

Inventori sebelum memilih

Mula-mula inventori apa yang ada. docker network ls menyenaraikan rangkaian, dan docker network inspect bridge -f '{{.IPAM.Config}}' mencetak subrangkaian yang digunakan oleh rangkaian tertentu. Ulangi untuk setiap rangkaian yang ditakrifkan pengguna, kerana projek Compose mencipta rangkaian sendiri dan --subnet eksplisit dalam fail compose memintas pool sepenuhnya.

Perkara terakhir itulah yang bertahan selepas migrasi. Perubahan pool tidak menghalang rakan sekerja daripada memakukan 172.18.0.0/16 dalam fail compose, dan pertembungan kembali dengan pengarang lain.

Memigrasi apa yang sudah ada

Memigrasi rangkaian sedia ada ialah operasi berasingan yang disokong. Setiap rangkaian terjejas mesti dicipta semula dengan subrangkaian baharu, yang bermaksud melepaskan dan menyambung semula kontena yang menggunakannya, dan mencipta semula rangkaian membuang lampiran kontena dan bukannya memindahkannya. Kekalkan volum dan konfigurasi dan anggap penciptaan semula sebagai penggunaan, bukan penetapan semula data. Lakukan kerja dalam tetingkap penyelenggaraan, kerana kontena pada rangkaian yang dicipta semula akan dimulakan semula sama ada anda merancangnya atau tidak.

Ikut konfigurasi daemon dan prosedur permulaan semula yang didokumenkan, dan selaraskan gangguan itu. Pada hos dengan satu daemon, systemctl restart docker memulakan semula kontena mengikut dasar permulaan semula mereka, dan itu tingkah laku yang wajar diketahui sebelum, bukan selepas.

Kemudian sahkan dua perkara yang sepatutnya dibaiki oleh perubahan itu. Periksa subrangkaian baharu dengan docker network inspect dan pastikan ia berada dalam asas yang dipilih, kemudian periksa laluan ke destinasi VPN yang mewakili dengan ip route get 10.20.30.40 dan pastikan ia pergi ke tempat yang anda jangkakan dan bukan ke jambatan. Uji juga penemuan perkhidmatan dan komunikasi antara kontena, kerana rangkaian yang dicipta semula dengan pengalamatan berbeza boleh memecahkan penyelesaian nama dengan cara yang kelihatan seperti pepijat aplikasi.

Apa yang masih rosak selepas itu

Bahagian yang tahan lama ialah rekod. Simpan senarai peruntukan, asas dan saiz yang dipilih, serta rangkaian yang dicipta semula di tempat yang sama dengan penggunaan.

Julat yang persendirian tidak menjadikannya selamat untuk digunakan semula. 10.0.0.0/8 adalah persendirian dan juga perkara yang paling mungkin sudah digunakan di suatu tempat pada laluan, sebab itu jawapannya ialah tempahan tertentu dan bukan keutamaan kepada satu blok. Dokumentasi rangkaian Docker menerangkan peruntukan subrangkaian automatik dan medan pool. Pilih julat berdasarkan apa yang mesti anda capai, bukan berdasarkan apa yang kelihatan kemas.