Docker-ის ნაგულისხმევი პულის შეცვლა ქსელებს ხელახლა არ დანომრავს

default-address-pools-ის შეცვლა ხელახლა არ დანომრავს იმ ქსელებს, რომლებიც უკვე გაქვთ, და სწორედ ამის მოლოდინი აქცევს ყურადღებიან გეგმას მოულოდნელ შეფერხებად. პარამეტრი მართავს ავტომატურ გამოყოფას იმ ქსელებისთვის, რომლებიც იქმნება მას შემდეგ, რაც დემონი ახალი კონფიგურაციით გადაიტვირთება. ყველაფერი, რაც უკვე მუშაობს, ინარჩუნებს მიცემულ ქვექსელს, რადგან ეს ქვექსელი ქსელის შენახული განსაზღვრების ნაწილია. მითი მოსახერხებელია, რადგან გვთავაზობს, რომ ერთი ცვლილება ასწორებს ყველა გადაფარვას, სინამდვილეში კი ეს ორნაწილიანი სამუშაოა: აირჩიეთ ნამდვილად თავისუფალი დიაპაზონი, შემდეგ მიგრაცია გაუკეთეთ იმ ქსელებს, რომლებიც თავისუფალი არ არის.

მითი: პულის ერთი ცვლილება ასწორებს გადაფარვას

მითს კონკრეტული ფორმა აქვს. ვიღაც კითხულობს, რომ Docker-ის ნაგულისხმევი პული შეიძლება შეიცვალოს, ცვლის მას, გადატვირთავს დემონს და ასკვნის, რომ კონტეინერის ქსელი უკვე აღარ ეჯახება ოფისის VPN-ს. ძველი ქსელი კვლავ იქ არის, კვლავ დაკავშირებულია და კვლავ ინახავს იმ მისამართს, რომელიც ეჯახება.

რაც შეიცვალა, გამომყოფის მომავალი ქცევაა, რომელიც ნამდვილად სასარგებლო და ნამდვილად შეზღუდულია. ახალი ქსელები, რომლებიც იქმნება გამოკვეთილი --subnet-ის გარეშე, ახალი პულიდან იჭრება; არსებულები არასდროს ყოფილან ამ პულში. გადატვირთვა ქსელებს ხელახლა არ აშენებს და კონტეინერებს მათ შორის არ გადაადგილებს. თუ სიმპტომი ცვლილების შემდეგაც გრძელდება, ცვლილება რეალური იყო, ხოლო დიაგნოზი — არასრული.

საბაზისო დიაპაზონი და გამოყოფილი პრეფიქსი

კონფიგურაციას ორი ველი აქვს, რომელთა არევაც ადვილია. base არის დიაპაზონი, საიდანაც გამომყოფი ჭრის, ხოლო size არის თითოეული გამოყოფილი ქსელის პრეფიქსის სიგრძე, ამიტომ 10.10.0.0/16 საფუძველი 24 ზომით ანაწილებს /24-ებს ამ /16-ის შიგნით. როლების შებრუნება იძლევა განაწილების ისეთ სქემას, რომელიც არ გინდოდათ, ჩვეულებრივ ერთ უზარმაზარ ქსელს ან ამოწურულ პულს.

პული ჯავშანია, არა მტკიცებულება. Docker თავს არიდებს იმ კონფლიქტებს, რომლებსაც ხედავს ჰოსტის მარშრუტიზაციის ცხრილში, და ვერ ხედავს იმ VPN-ს, რომელსაც ჯერ არ დაკავშირებიხართ.

ეს შეზღუდვა გონივრული არჩევანის მთელი მიზეზია. შესადარებელი დიაპაზონებია ისინი, რომლებსაც ჰოსტი უნდა მიაღწიოს: ოფისის LAN, კორპორატიული VPN-ის შიდა ქვექსელები, ლაბორატორიის ან staging-ის პრეფიქსები და ნებისმიერი სხვა კონტეინერის ჰოსტი იმავე overlay-ზე. ჩაწერეთ ისინი CIDR-ად, სანამ დემონს შეეხებით, რადგან თავში შენახული სია სწორედ იმას გამოტოვებს, რაც მნიშვნელოვანია. შემდეგ აირჩიეთ საფუძველი, რომელიც არც ერთ მათგანს არ ემთხვევა, და სია შენახეთ განლაგებასთან ერთად, რათა შემდეგმა ადამიანმა ეს ვარჯიში მეხსიერებიდან არ გაიმეოროს.

ჩამოთვალეთ სანამ აირჩევთ

ჯერ ჩამოთვალეთ რაც არსებობს. docker network ls ქსელებს ჩამოთვლის, ხოლო docker network inspect bridge -f '{{.IPAM.Config}}' ბეჭდავს ქვექსელს, რომელსაც კონკრეტული ქსელი იყენებს. გაიმეორეთ მომხმარებლის მიერ განსაზღვრულ თითოეულ ქსელზე, რადგან Compose პროექტები საკუთარს ქმნიან და compose ფაილში გამოკვეთილი --subnet პულს მთლიანად გვერდს უვლის.

ეს უკანასკნელი პუნქტია, რომელიც მიგრაციას გადაურჩება. პულის ცვლილება ხელს არ უშლის კოლეგას, compose ფაილში ჩაამაგროს 172.18.0.0/16, და კონფლიქტი სხვა ავტორთან ბრუნდება.

უკვე არსებულის მიგრაცია

არსებული ქსელების მიგრაცია ცალკე, მხარდაჭერილი ოპერაციაა. ყოველი დაზარალებული ქსელი უნდა ხელახლა შეიქმნას ახალი ქვექსელით, რაც ნიშნავს მისი კონტეინერების მოწყვეტასა და ხელახლა მიერთებას, ხოლო ქსელის ხელახლა შექმნა მის კონტეინერ-მიმაგრებებს შლის და არ გადაადგილებს. შეინარჩუნეთ ტომები და კონფიგურაცია და ხელახლა შექმნას განლაგებად მოეპყარით და არა მონაცემების განულებად. სამუშაო შეასრულეთ ტექნიკური მომსახურების ფანჯარაში, რადგან ხელახლა შექმნილ ქსელზე კონტეინერები გადაიტვირთება, დაგეგმეთ ეს თუ არა.

მიჰყევით დოკუმენტირებულ დემონის კონფიგურაციას და გადატვირთვის პროცედურას და შეათანხმეთ შეფერხება. ერთი დემონის მქონე ჰოსტზე systemctl restart docker კონტეინერებს მათი გადატვირთვის პოლიტიკის მიხედვით გადატვირთავს, და ეს ის ქცევაა, რომლის ცოდნა ადრე ღირს და არა შემდეგ.

შემდეგ შეამოწმეთ ის ორი რამ, რაც ცვლილებას უნდა გამოესწორებინა. შეამოწმეთ ახალი ქვექსელი docker network inspect-ით და დაადასტურეთ, რომ ის არჩეული საფუძვლის შიგნითაა, შემდეგ შეამოწმეთ მარშრუტი წარმომადგენლობით VPN დანიშნულებამდე ip route get 10.20.30.40-ით და დაადასტურეთ, რომ ის მიდის იქ, სადაც ელით და არა ხიდში. შეამოწმეთ ასევე სერვისების აღმოჩენა და კონტეინერ-კონტეინერ კომუნიკაცია, რადგან სხვა მისამართებით ხელახლა შექმნილმა ქსელმა შეიძლება დააზიანოს სახელების გარჩევა ისე, რომ აპლიკაციის შეცდომას ჰგავდეს.

რა ტყდება მერეც

ხანგრძლივი ნაწილი ჩანაწერია. შეინახეთ განაწილების სია, არჩეული საფუძველი და ზომა და ხელახლა შექმნილი ქსელები განლაგების იმავე ადგილას.

ის, რომ დიაპაზონი კერძოა, მას ხელახალი გამოყენებისთვის უსაფრთხოს არ ხდის. 10.0.0.0/8 კერძოა და ამავდროულად ყველაზე სავარაუდო ის არის, რაც უკვე გამოიყენება სადღაც გზაზე, ამიტომ პასუხი კონკრეტული ჯავშანია და არა ერთი ბლოკის უპირატესობა. Docker-ის ქსელური დოკუმენტაცია აღწერს ქვექსელების ავტომატურ გამოყოფას და პულის ველებს. აირჩიეთ დიაპაზონი იმის მიხედვით, რასაც უნდა მიაღწიოთ, და არა იმის მიხედვით, რაც მოწესრიგებულად გამოიყურება.