VPN-ის კონფიგურაცია კონტეინერის ხელახლა შექმნას გადაურჩება მხოლოდ მაშინ, თუ მას დაამონტაჟებ
გაშვებული კონტეინერის შიგნით რედაქტირებული ფაილი ცხოვრობს ფენაში, რომელიც ქრება. შეადარეთ bind mount-ები, volume-ები და secret-ები, შემდეგ ხელახლა შექმენით და შეამოწმეთ ოთხი რამ.
თქვენ არედაქტირებთ WireGuard-ის კონფიგურაციას გაშვებული კონტეინერის შიგნით, ის მუშაობს, და შემდეგი image-ის განახლება შლის მას. არაფერი იყო არასწორად კონფიგურირებული. ფაილი ცხოვრობდა კონტეინერის ჩაწერად ფენაში, რომელიც არსებობს მხოლოდ ამ კონტეინერის ეგზემპლარისთვის. მნიშვნელოვანი შედარება არ არის რომელი ინსტრუმენტი გამოიყენოთ, არამედ რომელი შენატანები აცხადებს თქვენი განლაგება. ყველაფერი, რაც ხელით შეასწორეთ, არის შენატანი, რომლის შესახებაც განლაგებამ არ იცის.
ორი სახის მდგომარეობა, ერთი ერთჯერადია
კონტეინერს აქვს ჩაწერადი ფენა მუშაობის დროს გაკეთებული ცვლილებებისთვის, და ეს ფენა იშლება, როცა კონტეინერი ჩანაცვლდება. ის არ არის კონფიგურაციის საცავი და არ არის სარეზერვო ასლი. image და დეკლარირებული შენატანები არის სრული განმარტება იმისა, რაც მუშაობს.
იკითხეთ, რომელი თქვენი VPN ფაილია დეკლარირებული შენატანი და რომელი შემთხვევითობა:
docker diff wg-vpn
docker inspect --format '{{json .Mounts}}' wg-vpndiff ჩამოთვლის, რა შეიცვალა ჩაწერად ფენაში, და ეს ზუსტად იმ ნივთების ნაკრებია, რომლებიც გაქრება. mount-ების სია აჩვენებს, რა რჩება. ორივეს შედარება პასუხობს კითხვას სანამ რამეს დაკარგავთ.
bind mount, დასახელებული volume თუ secret: რას იცავს თითოეული
სამივე შეუძლია VPN პროფილის შენახვა, და ისინი განსხვავდებიან იმით, ვის შეუძლია მისი წაკითხვა და რა ხდება ჩანაცვლებისას.
| Mechanism | Survives recreation | Who can read it |
|---|---|---|
| Writable layer | No | Anyone with container access, until it is gone |
| Bind mount | Yes, while the host path exists | Whatever the host permissions allow |
| Named volume | Yes, until the volume is removed | Managed by the runtime |
| Secret | Yes, as a declared input | The container process, by design |
bind mount ასახავს host-ის ბილიკს, ამიტომ ფაილი დაცულია იმდენად, რამდენადაც ეს ბილიკი, და ხილულია იმდენად, რამდენადაც host-ის ნებართვები იძლევა. დასახელებულ volume-ს მართავს runtime და ის გადაურჩება კონტეინერის წაშლას, რაც მას უფრო უსაფრთხო ნაგულისხმევ ვარიანტად აქცევს იმ მდგომარეობისთვის, რომელსაც განლაგება ფლობს. secret-ის მექანიზმი განკუთვნილია მასალისთვის, რომლის განთავსებაც არ გსურთ image-ში ან გარემოს ცვლადში.
არ მოექეცით ყოველ გარემოს ცვლადს და ყოველ host ფაილს როგორც თანაბარ დაცვას, რადგან ასე არ არის.
კონტეინერის შიგნით რედაქტირება ხაფანგია
ხაფანგი არ არის ინსტრუმენტი, არამედ რედაქტირების მიმართულება. გაშვებული კონტეინერის შიგნით გაკეთებული ცვლილება განლაგებისთვის უხილავია, ამიტომ შემდეგი ხელახლა შექმნა ჩუმად აბრუნებს მას და სიმპტომი image-ში რეგრესიას ჰგავს. თუ დიაგნოსტიკისთვის იქ ცვლილება გჭირდებათ, დაუყოვნებლივ გადააკოპირეთ გარეთ და ჩადეთ დეკლარირებულ შენატანში. შემდეგ ხელახლა შექმენით, რომ დაამტკიცოთ: განლაგება მას ამრავლებს.
პროფილი შეიძლება ატარებდეს პირად გასაღებებს და ანგარიშის მასალას, რაც ამ ფაილის სარეზერვო ასლს აქცევს საიდუმლოებთან მუშაობის ამოცანად და არა ფაილის კოპირებად. შეინახეთ მფლობელობა და წაკითხვის წვდომა შეზღუდული კონტეინერის რეალურ პროცესზე, ნაცვლად იმისა, რომ host-ის საქაღალდე გააფართოოთ ნებართვის შეცდომის გასაქრობად.
სწორედ ეს გაფართოება აქცევს კონტეინერში კომფორტს host-ის გამოვლენად.
განზრახ ხელახლა შექმენით, შემდეგ შეამოწმეთ ოთხი რამ
ჩაწერეთ image-ის ვერსია, საჭირო მოწყობილობა და შესაძლებლობები, ქსელური მიერთება და მუდმივი შენატანები. მოწყობილობისა და შესაძლებლობების სია განსაკუთრებით მნიშვნელოვანია VPN კონტეინერისთვის, რადგან გვირაბს სჭირდება ქსელური მოწყობილობა და მისი კონფიგურირების უფლება.
დაადასტურეთ, რომელი გენერირებული მუშაობის მდგომარეობა უნდა აღდგეს და არა შენახულ იქნას. გასაღებები, რომლებიც გვირაბმა პირველ გაშვებაზე შექმნა, მდგომარეობაა, და მათი შენახვა თუ ხელახლა გენერირება გადაწყვეტილებაა, რომელსაც შედეგები აქვს ყოველი peer-ისთვის, ვინც ძველი საჯარო გასაღები იცის.
კონტროლირებული ხელახლა შექმნის შემდეგ შეამოწმეთ იდენტობა, მარშრუტიზაცია, DNS და საჭირო წარუმატებლობის ბლოკი. პროცესი, რომელიც უშეცდომოდ იწყება, ამ ოთხიდან არც ერთს არ ამტკიცებს. შეამოწმეთ ის, სანამ გვირაბი მუშაობს, და ისევ მისი გაჩერების შემდეგ, რადგან წარუმატებლობის ბლოკი თავს ავლენს მხოლოდ მაშინ, როცა გვირაბი ქრება.
შეინახეთ აღდგენის ასლი კონტეინერის გარეთ
შეინახეთ აღდგენის ასლი, რომელიც კონტეინერისგან დამოუკიდებლად ცხოვრობს, და გამოსცადეთ მისი აღდგენა დოკუმენტირებული პროცესით. VPN პროფილის გამოუცდელი სარეზერვო ასლი იმედია, განსაკუთრებით მაშინ, როცა აღდგენის გზა მოიცავს ნებართვებს, რომლებიც კონტეინერის პროცესს სჭირდება.
თუ VPN-ის მფლობელი კონტეინერი ჩანაცვლდება, კოორდინირეთ აპლიკაციები, რომლებიც მის ქსელურ დასტას იზიარებენ, runtime-ის მხარდაჭერილ სასიცოცხლო ციკლში.
ეს კოორდინაცია განსხვავებაა გადატვირთვასა და შეწყვეტას შორის. განლაგებამ უნდა აღწეროს, საიდან მოდის კონფიგურაცია, და volume-ების დოკუმენტაცია ის ადგილია, სადაც ამოწმებთ, რას ინახავს runtime სინამდვილეში.