დოკერის შენახვის მიგრაციის პრობლემის ისტორია (docker root)

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

გაგრძელება:

1. გააჩერეთ და მოკალი ჩვენი აპლიკაციის ყველა კონტეინერი:

docker-compose down

თუ ბევრი კონტეინერია და ისინი სხვადასხვა კომპოზიციაშია, შეგიძლიათ ამის გაკეთება:

docker rm -f $(docker ps -q)

2. შეაჩერე დოკერ დემონი:

systemctl stop docker

3. გადაიტანეთ დირექტორია სასურველ ადგილას:

cp -r /var/lib/docker /docker/data/storage

4. ჩვენ ვეუბნებით დოკერ დემონს მოძებნოს ახალ დირექტორიაში. არსებობს რამდენიმე ვარიანტი: ან გამოიყენეთ -g დროშა დემონის ახალ გზაზე მითითებისთვის, ან systemd კონფიგურაციები, რომლებიც ჩვენ გამოვიყენეთ. ან სიმბოლიკი. მე არ ჩავწვდები ძალიან დეტალებს ამის შესახებ, ეს არის ინტერნეტში. სავსე სახელმძღვანელოები docker root-ის ახალ ადგილას გადატანის შესახებ.

5. გაუშვით დოკერ დემონი და დარწმუნდით, რომ ის სწორ ადგილას გამოიყურება:

systemctl status docker

ერთ-ერთ გამომავალ ხაზში უნდა ვნახოთ:

├─19493 /usr/bin/dockerd --data-root=/docker/data/storage

ჩვენ დავრწმუნდით, რომ ეს ვარიანტი გადაეცა დემონს, ახლა მოდით შევამოწმოთ, გამოიყენა თუ არა იგი (მადლობა inkvizitor68sl)!

docker info | awk '/Root Dir/ {print $NF}' 

6. დავიწყოთ ჩვენი აპლიკაცია:

docker-compose up -d

7. შეამოწმეთ

და აქ იწყება გართობა, DBMS, MQ, ყველაფერი კარგადაა! მონაცემთა ბაზა ხელუხლებელია, ყველაფერი მუშაობს... nginx-ის გარდა. ჩვენ გვაქვს საკუთარი nginx build კერბეროსებით და კურტიზანებით. და კონტეინერის ჟურნალების ნახვამ მიუთითა, რომ მას არ შეუძლია ჩაწეროს /var/tmp - ნებართვა უარყოფილია. თითებით ვზივარ ტაძრებს და ვცდილობ გავაანალიზო სიტუაცია... როგორ არის ეს შესაძლებელი? დოკერის სურათი არ შეცვლილა. ჩვენ უბრალოდ გადავიტანეთ დირექტორია. ის ყოველთვის მუშაობდა და აი შენთვის... ექსპერიმენტის გულისთვის ხელებით შევედი კონტეინერში და შევცვალე უფლებები ამ დირექტორიაზე, იყო root, root 755, მისცა root, root 777. და ყველაფერი დაიწყო... თავში აზრმა გაისმა - რაღაც სისულელე... ვიფიქრე, იქნებ რამე არ გავითვალისწინე...

გადავწყვიტე, რომ გადაცემის დროს შეგვიყვარდა ფაილებზე წვდომის უფლებები. ჩვენ შევაჩერეთ აპლიკაცია, docker daemon, წავშალეთ ახალი დირექტორია და დავაკოპირეთ /var/lib/docker დირექტორია გამოყენებით rsync -a.

ვფიქრობ, ახლა ყველაფერი კარგადაა, მოდით ავწიოთ Docker აპლიკაცია.

ააან... პრობლემა დარჩა... თვალი ამიკანკალდა. სასწრაფოდ მივედი ჩემი ვირტუალური აპარატის კონსოლში, სადაც ვაწარმოებ სხვადასხვა ტესტებს, მქონდა ეს nginx სურათი და ავძვერი კონტეინერში და აქ /var/tmp დირექტორიაზე უფლებები არის root, root 777. ანუ ისევე როგორც მე ხელით უნდა დავაყენო. მაგრამ სურათები იდენტურია!

xfs ფაილური სისტემა ყველგან იყო გამოყენებული.

შევადარე ბრძანების გამოყენებით

docker inspect my-nginx:12345

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

აღარ მახსოვს, რა ფიქრები მიტრიალებდა თავში, გარდა "აააააააააა" და სხვა ყვირილისა. დილის 4 საათი იყო და Docker-ის წყაროს კოდი გამოიყენებოდა გამოსახულების ფენების ჰეშირების პრინციპის გასაგებად. გაიხსნა ენერგეტიკული სასმელის მესამე ქილა. და ბოლოს მივხვდი, რომ ჰეშინგში მხედველობაში მიიღება მხოლოდ ფაილი, მისი შინაარსი, მაგრამ არ არის წვდომის უფლებები! ანუ რაღაც იდუმალი გზით ჩვენი უფლებები დაიკარგა, selinux გამორთულია, acl არ გამოიყენება და არ არის წებოვანი ბიტი.

მე წავშალე ლოკალური სურათი, ასევე წავშალე სურათი დოკერის რეესტრიდან და ისევ დავძარი. და ყველაფერი მუშაობდა. გამოდის, რომ გადაცემის დროს დაიკარგა უფლებები, როგორც ლოკალური იმიჯის შიგნით, ასევე რეესტრში დევს გამოსახულების შიგნით. როგორც უკვე ვთქვი, მრავალი მიზეზის გამო ის იმავე მანქანაზე იყო განთავსებული. და შედეგად, ერთ დირექტორიაში /var/lib/docker.

და იმის გათვალისწინება, რომ ცდილობდნენ თუ არა დოკერის მზერის დაბრუნება ძველ დირექტორიაში - არა, ისინი არ ცდილობდნენ, სამწუხაროდ, გარემოებებმა ამის საშუალება არ მისცა. დიახ, და მე ნამდვილად მინდოდა ამის გარკვევა.

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

შედეგი: პრობლემა მოვაგვარე, მიზეზი მაინც ვერ გავიგე =(

თუ ვინმემ იცის, გამოიცნობს, ჰქონდა ხედვა ამ პრობლემის შესაძლო მიზეზების შესახებ, ძალიან მოხარული ვიქნები მოვისმინოთ თქვენგან კომენტარებში!

წყარო: www.habr.com