Mengubah pool default Docker tidak menomori ulang jaringan

Mengubah default-address-pools tidak menomori ulang jaringan yang sudah Anda miliki, dan mengharapkannya justru membuat rencana yang hati-hati berubah menjadi gangguan tak terduga. Pengaturan ini mengatur alokasi otomatis untuk jaringan yang dibuat setelah daemon dimulai ulang dengan konfigurasi baru. Semua yang sudah berjalan mempertahankan subnet yang diberikan, karena subnet itu adalah bagian dari definisi tersimpan jaringan tersebut. Mitosnya nyaman karena menyarankan satu perubahan memperbaiki setiap tumpang tindih, sedangkan kenyataannya adalah pekerjaan dua bagian: pilih rentang yang benar-benar kosong, lalu migrasikan jaringan yang tidak kosong.

Mitos: satu perubahan pool memperbaiki tumpang tindih

Mitos itu punya bentuk tertentu. Seseorang membaca bahwa pool default Docker bisa diubah, mengubahnya, memulai ulang daemon, dan menyimpulkan bahwa jaringan kontainer tidak lagi bertabrakan dengan VPN kantor. Jaringan lama masih ada, masih terpasang, dan masih memegang alamat yang bertabrakan.

Yang berubah adalah perilaku alokator di masa depan, yang benar-benar berguna dan benar-benar terbatas. Jaringan baru yang dibuat tanpa --subnet eksplisit dipotong dari pool baru; yang sudah ada tidak pernah berada di pool itu. Memulai ulang tidak membangun ulang jaringan dan tidak memindahkan kontainer di antaranya. Jika gejalanya tetap ada setelah perubahan, perubahan itu nyata dan diagnosisnya tidak lengkap.

Rentang dasar dan prefiks yang dialokasikan

Konfigurasi ini punya dua bidang yang mudah tertukar. base adalah rentang tempat alokator memotong, dan size adalah panjang prefiks setiap jaringan yang dialokasikan, jadi basis 10.10.0.0/16 dengan ukuran 24 membagikan /24 di dalam /16 itu. Membalik perannya menghasilkan pola alokasi yang tidak Anda maksud, biasanya satu jaringan raksasa atau pool yang habis.

Pool adalah reservasi, bukan bukti. Docker menghindari konflik yang terlihat di tabel perutean host, dan tidak bisa melihat VPN yang belum Anda sambungkan.

Batasan itulah seluruh alasan untuk memilih dengan sengaja. Rentang yang dibandingkan adalah yang harus dicapai host: LAN kantor, subnet internal VPN korporat, prefiks lab atau staging, dan host kontainer lain di overlay yang sama. Tuliskan sebagai CIDR sebelum menyentuh daemon, karena daftar di kepala akan melewatkan yang paling penting. Lalu pilih basis yang tidak tumpang tindih dengan satu pun, dan simpan daftarnya bersama penerapan agar orang berikutnya tidak mengulang latihan dari ingatan.

Inventarisasi sebelum memilih

Inventarisasi dulu apa yang ada. docker network ls mendaftar jaringannya, dan docker network inspect bridge -f '{{.IPAM.Config}}' mencetak subnet yang dipakai satu jaringan tertentu. Ulangi untuk setiap jaringan yang ditentukan pengguna, karena proyek Compose membuat jaringannya sendiri dan --subnet eksplisit dalam berkas compose melewati pool sepenuhnya.

Poin terakhir itulah yang bertahan setelah migrasi. Perubahan pool tidak mencegah rekan menambatkan 172.18.0.0/16 di berkas compose, dan konfliknya kembali dengan penulis berbeda.

Memigrasikan yang sudah ada

Memigrasikan jaringan yang ada adalah operasi terpisah yang didukung. Setiap jaringan yang terdampak harus dibuat ulang dengan subnet baru, yang berarti melepas dan memasang kembali kontainer yang memakainya, dan membuat ulang jaringan menghapus lampiran kontainernya alih-alih memindahkannya. Pertahankan volume dan konfigurasi, dan perlakukan pembuatan ulang sebagai penerapan, bukan pengaturan ulang data. Lakukan pekerjaan di jendela pemeliharaan, karena kontainer pada jaringan yang dibuat ulang akan mulai ulang entah Anda rencanakan atau tidak.

Ikuti konfigurasi daemon dan prosedur mulai ulang yang terdokumentasi, dan koordinasikan gangguannya. Pada host dengan satu daemon, systemctl restart docker memulai ulang kontainer sesuai kebijakan mulai ulangnya, dan itu perilaku yang layak diketahui sebelumnya, bukan sesudahnya.

Lalu verifikasi dua hal yang seharusnya diperbaiki oleh perubahan itu. Periksa subnet baru dengan docker network inspect dan pastikan berada di dalam basis yang dipilih, lalu periksa rute ke tujuan VPN yang mewakili dengan ip route get 10.20.30.40 dan pastikan rute itu menuju tempat yang Anda harapkan, bukan ke jembatan. Uji juga penemuan layanan dan komunikasi antar kontainer, karena jaringan yang dibuat ulang dengan pengalamatan berbeda bisa merusak resolusi nama dengan cara yang tampak seperti bug aplikasi.

Apa yang masih rusak sesudahnya

Bagian yang tahan lama adalah catatannya. Simpan daftar alokasi, basis dan ukuran yang dipilih, serta jaringan yang dibuat ulang di tempat yang sama dengan penerapan.

Rentang yang privat tidak membuatnya aman untuk dipakai ulang. 10.0.0.0/8 bersifat privat dan juga hal yang paling mungkin sudah dipakai di suatu tempat pada jalur, karena itulah jawabannya adalah reservasi tertentu, bukan preferensi pada satu blok. Dokumentasi jaringan Docker menjelaskan alokasi subnet otomatis dan bidang-bidang pool. Pilih rentang dari apa yang harus Anda capai, bukan dari apa yang tampak rapi.