default-address-pools ni o'zgartirish sizda allaqachon mavjud tarmoqlarni qayta raqamlamaydi va shuni kutish ehtiyotkor rejaning kutilmagan uzilishga aylanish yo'lidir. Bu sozlama demon yangi konfiguratsiya bilan qayta ishga tushganidan keyin yaratiladigan tarmoqlar uchun avtomatik taqsimotni boshqaradi. Allaqachon ishlab turgan hamma narsa o'ziga berilgan quyi tarmoqni saqlab qoladi, chunki bu quyi tarmoq tarmoqning saqlangan ta'rifining bir qismidir. Afsona qulay, chunki u bitta o'zgartirish har qanday ustma-ust tushishni tuzatadi deb ko'rsatadi, aslida esa bu ikki qismli ish: haqiqatan bo'sh diapazonni tanlang, so'ng bo'sh bo'lmagan tarmoqlarni ko'chiring.

Afsona: hovuzning bitta o'zgarishi ustma-ust tushishni tuzatadi

Afsonaning aniq shakli bor. Kimdir Docker standart hovuzini o'zgartirish mumkinligini o'qib, uni o'zgartiradi, demonni qayta ishga tushiradi va konteyner tarmog'i endi ofis VPN bilan to'qnashmaydi degan xulosaga keladi. Eski tarmoq hali ham joyida, hali ham ulangan va to'qnashadigan manzilni hali ham ushlab turadi.

O'zgargan narsa taqsimlovchining kelajakdagi xatti-harakati bo'lib, u haqiqatan foydali va haqiqatan cheklangan. Aniq --subnet siz yaratilgan yangi tarmoqlar yangi hovuzdan kesiladi; mavjudlari hech qachon bu hovuzda bo'lmagan. Qayta ishga tushirish tarmoqlarni qayta qurmaydi va konteynerlarni ular orasida ko'chirmaydi. Agar o'zgarishdan keyin ham alomat saqlanib qolsa, o'zgarish haqiqiy edi, tashxis esa to'liq emas edi.

Asosiy diapazon va ajratilgan prefiks

Konfiguratsiyada chalkashtirish oson bo'lgan ikkita maydon bor. base — taqsimlovchi kesadigan diapazon, size esa har bir ajratilgan tarmoqning prefiks uzunligi, shuning uchun 10.10.0.0/16 asosi 24 o'lchami bilan o'sha /16 ichida /24 tarqatadi. Rollarni teskari qilish siz niyat qilmagan taqsimot naqshini keltiradi, odatda bitta ulkan tarmoq yoki tugagan hovuz.

Hovuz — band qilish, dalil emas. Docker xostning marshrutlash jadvalida ko'radigan to'qnashuvlardan qochadi va siz hali ulanmagan VPN ni ko'ra olmaydi.

Bu cheklov ongli tanlovning butun sababidir. Taqqoslanadigan diapazonlar xost yetib borishi kerak bo'lganlar: ofis LAN, korporativ VPN ning ichki quyi tarmoqlari, laboratoriya yoki staging prefikslari va o'sha overlay dagi har qanday boshqa konteyner xosti. Demonni tegishdan oldin ularni CIDR sifatida yozing, chunki xayoldagi ro'yxat aynan muhim bo'lganini o'tkazib yuboradi. So'ng ularning hech biri bilan ustma-ust tushmaydigan asos tanlang va ro'yxatni joylashtirish bilan birga saqlang, keyingi odam bu mashqni xotiradan takrorlamasin.

Tanlashdan oldin ro'yxatga oling

Avval mavjud narsani ro'yxatga oling. docker network ls tarmoqlarni sanaydi, docker network inspect bridge -f '{{.IPAM.Config}}' esa ma'lum tarmoq ishlatadigan quyi tarmoqni chiqaradi. Foydalanuvchi belgilagan har bir tarmoq uchun buni takrorlang, chunki Compose loyihalari o'zlarinikini yaratadi va compose faylidagi aniq --subnet hovuzni butunlay chetlab o'tadi.

Aynan oxirgi band ko'chirishdan keyin ham yashaydi. Hovuz o'zgarishi hamkasbni compose faylida 172.18.0.0/16 qotirib qo'yishdan to'xtatmaydi va to'qnashuv boshqa muallif bilan qaytadi.

Allaqachon mavjudni ko'chirish

Mavjud tarmoqlarni ko'chirish alohida, qo'llab-quvvatlanadigan amaliyotdir. Har bir ta'sirlangan tarmoq yangi quyi tarmoq bilan qayta yaratilishi kerak, bu esa undan foydalanadigan konteynerlarni ajratib, qayta ulashni anglatadi, tarmoqni qayta yaratish esa uning konteyner ulanishlarini ko'chirish o'rniga olib tashlaydi. Jildlar va konfiguratsiyani saqlang va qayta yaratishni ma'lumotlarni tiklash emas, joylashtirish deb biling. Ishni texnik xizmat oynasida bajaring, chunki qayta yaratilgan tarmoqdagi konteynerlar rejalashtirganingizdan qat'i nazar qayta ishga tushadi.

Hujjatlashtirilgan demon konfiguratsiyasi va qayta ishga tushirish tartibiga amal qiling va uzilishni muvofiqlashtiring. Bitta demonli xostda systemctl restart docker konteynerlarni ularning qayta ishga tushirish siyosatlariga ko'ra qayta ishga tushiradi va bu keyin emas, oldin bilishga arziydigan xatti-harakat.

So'ng o'zgarish tuzatishi kerak bo'lgan ikki narsani tekshiring. Yangi quyi tarmoqni docker network inspect bilan ko'zdan kechiring va u tanlangan asos ichida ekaniga ishonch hosil qiling, so'ng vakillik VPN manziliga yo'lni ip route get 10.20.30.40 bilan tekshiring va u siz kutgan joyga borishini, ko'prikka emasligini tasdiqlang. Xizmatlarni topish va konteynerdan konteynerga aloqani ham sinab ko'ring, chunki boshqa manzillash bilan qayta yaratilgan tarmoq nomlarni hal qilishni ilova xatosiga o'xshash tarzda buzishi mumkin.

Keyin ham nima buziladi

Barqaror qism — yozuv. Taqsimot ro'yxatini, tanlangan asos va o'lchamni hamda qayta yaratilgan tarmoqlarni joylashtirish bilan bir joyda saqlang.

Diapazonning xususiy bo'lishi uni qayta ishlatish uchun xavfsiz qilmaydi. 10.0.0.0/8 xususiy va shu bilan birga yo'lda biror joyda allaqachon ishlatilayotgan bo'lish ehtimoli eng yuqori, shuning uchun javob bitta blokka ustunlik emas, aniq band qilishdir. Docker tarmoq hujjatlari avtomatik quyi tarmoq taqsimoti va hovuz maydonlarini tavsiflaydi. Diapazonni tartibli ko'rinishiga qarab emas, yetib borishingiz kerak bo'lgan narsaga qarab tanlang.

O'xshash maqolalar