რა არის დოკერი: მოკლე ექსკურსია ისტორიაში და ძირითად აბსტრაქციებში

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

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

რა არის დოკერი

მოდით გადავხედოთ დოკერის განმარტებას ვიკიპედიიდან.

Docker არის პროგრამა კონტეინერულ გარემოში აპლიკაციების განლაგებისა და მართვის ავტომატიზაციისთვის.

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

მონოლითური ეპოქა

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

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

Hypervisor-ზე დაფუძნებული ვირტუალიზაციის სისტემები

ალბათ ყველას სმენია ვირტუალიზაციის სისტემების შესახებ: VMware, VirtualBox, Hyper-V, Qemu KVM და ა.შ. ისინი უზრუნველყოფენ აპლიკაციების იზოლაციას და რესურსების მართვას, მაგრამ აქვთ უარყოფითი მხარეებიც. ვირტუალიზაციის გასაკეთებლად საჭიროა ჰიპერვიზორი. და ჰიპერვიზორი არის რესურსი ზედმეტად. და თავად ვირტუალური მანქანა, როგორც წესი, არის მთელი კოლოსი - მძიმე სურათი, რომელიც შეიცავს ოპერაციულ სისტემას, Nginx, Apache და შესაძლოა MySQL. სურათი დიდია და ვირტუალური მანქანა არასასიამოვნოა მუშაობისთვის. შედეგად, ვირტუალურ მანქანებთან მუშაობა შეიძლება ნელი იყოს. ამ პრობლემის გადასაჭრელად შეიქმნა ვირტუალიზაციის სისტემები ბირთვის დონეზე.

ბირთვის დონის ვირტუალიზაციის სისტემები

ბირთვის დონის ვირტუალიზაცია მხარდაჭერილია OpenVZ, Systemd-nspawn, LXC სისტემებით. ასეთი ვირტუალიზაციის ნათელი მაგალითია LXC (Linux Containers).

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

არსებითად LXC ქმნის კონტეინერებს. რა განსხვავებაა ვირტუალურ მანქანებსა და კონტეინერებს შორის?

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

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

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

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

რა გამოიყენება კონტეინერიზაციისთვის ბირთვის დონეზე

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

სახელების სივრცეები: PID, ქსელი, დამონტაჟება და მომხმარებელი. უფრო მეტია, მაგრამ გასაგებად ჩვენ ყურადღებას გავამახვილებთ მათზე.

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

Networking Namespace გაძლევთ საშუალებას შეზღუდოთ/იზოლიროთ ქსელი და განათავსოთ თქვენი საკუთარი ინტერფეისები შიგნით. Mount არის ფაილური სისტემის შეზღუდვა. მომხმარებელი - მომხმარებლის შეზღუდვა.

საკონტროლო ჯგუფები: მეხსიერება, CPU, IOPS, ქსელი - სულ დაახლოებით 12 პარამეტრი. სხვაგვარად მათ ასევე უწოდებენ Cgroups ("C-ჯგუფები").

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

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

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

Copy-on-Write სისტემა საშუალებას გვაძლევს ვიმუშაოთ Docker სურათებთან და გამოვიყენოთ ისინი უფრო ეფექტურად.

Docker-ს ამჟამად აქვს თავსებადობის პრობლემები Cgroups v2-თან, ამიტომ ეს სტატია კონკრეტულად Cgroups v1-ზეა ფოკუსირებული.

მაგრამ დავუბრუნდეთ ისტორიას.

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

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

ყველა ამ პრობლემის გადასაჭრელად დადგა შემდეგი ერა.

კონტეინერის ეპოქა

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

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

გახსოვს რა ვთქვი შინაური ცხოველების წინააღმდეგ პირუტყვის შესახებ? ადრე ინსტანციები შინაურ ცხოველებს ჰგავდა, ახლა კი პირუტყვს დაემსგავსა. ადრე იყო მონოლითი - ერთი აპლიკაცია. ახლა ეს არის 100 მიკროსერვისი, 100 კონტეინერი. ზოგიერთ კონტეინერს შეიძლება ჰქონდეს 2-3 ასლი. ჩვენთვის ნაკლებად მნიშვნელოვანი ხდება ყველა კონტეინერის კონტროლი. ჩვენთვის უფრო მნიშვნელოვანი არის თავად სერვისის ხელმისაწვდომობა: რას აკეთებს კონტეინერების ეს ნაკრები. ეს ცვლის მონიტორინგის მიდგომებს.

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

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

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

დიგრესია ზედნადების შესახებ

ყოველთვის არის კამათი ზედნადებთან დაკავშირებით. ზოგიერთი ადამიანი თვლის, რომ Docker არ ატარებს დამატებით დატვირთვას, რადგან ის იყენებს Linux-ის ბირთვს და მის ყველა პროცესს, რომელიც აუცილებელია კონტეინერიზაციისთვის. მაგალითად, "თუ თქვენ ამბობთ, რომ Docker არის ზედმეტად, მაშინ Linux kernel არის ზემოთ."

მეორეს მხრივ, თუ უფრო ღრმად ჩავალთ, Docker-ში მართლაც არის რამდენიმე რამ, რაც, დაჭიმულობით, შეიძლება ითქვას, რომ ზევით არის.

პირველი არის PID სახელთა სივრცე. როდესაც ჩვენ ვათავსებთ პროცესს სახელთა სივრცეში, მას ენიჭება PID 1. ამავდროულად, ამ პროცესს აქვს სხვა PID, რომელიც მდებარეობს ჰოსტის სახელთა სივრცეში, კონტეინერის გარეთ. მაგალითად, ჩვენ გავუშვით Nginx კონტეინერში, ის გახდა PID 1 (მასტერ პროცესი). ჰოსტზე კი მას აქვს PID 12623. და ძნელი სათქმელია, რამდენად დიდია ეს.

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

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

დოკერის კონცეფციის შესახებ

დოკერი შედგება რამდენიმე კომპონენტისგან:

1. Docker Daemon არის იგივე Container Engine; უშვებს კონტეინერებს.
2. Docker CII არის Docker მართვის პროგრამა.
3. Dockerfile - ინსტრუქციები, თუ როგორ უნდა ავაშენოთ სურათი.
4. გამოსახულება - გამოსახულება, საიდანაც კონტეინერი ამოღებულია.
5. კონტეინერი.
6. დოკერის რეესტრი არის სურათების საცავი.

სქემატურად ასე გამოიყურება:

Docker daemon მუშაობს Docker_host-ზე და უშვებს კონტეინერებს. არის კლიენტი, რომელიც აგზავნის ბრძანებებს: შექმენით სურათი, გადმოწერეთ სურათი, გაუშვით კონტეინერი. Docker daemon მიდის რეესტრში და ახორციელებს მათ. Docker კლიენტს შეუძლია წვდომა როგორც ლოკალურად (Unix სოკეტზე) ასევე TCP-ის საშუალებით დისტანციური ჰოსტიდან.

მოდით გავიაროთ თითოეული კომპონენტი.

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

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

ძირითადი ბრძანებები:

docker ps - კონტეინერების ჩვენება, რომლებიც ამჟამად მუშაობს Docker ჰოსტზე.
დოკერის სურათები - ადგილობრივად გადმოწერილი სურათების ჩვენება.
დოკერის ძებნა <> - მოძებნეთ სურათი რეესტრში.
docker pull <> - ჩამოტვირთეთ სურათი რეესტრიდან მანქანაში.
დოკერის აშენება < > - შეაგროვეთ სურათი.
docker run <> - გაუშვით კონტეინერი.
docker rm <> - ამოიღეთ კონტეინერი.
დოკერის ჟურნალები <> - კონტეინერის ჟურნალები
docker start/stop/restart <> - კონტეინერთან მუშაობა

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

dockerfile - ინსტრუქციები გამოსახულების შესაქმნელად. თითქმის ყველა ინსტრუქციის ბრძანება არის ახალი ფენა. მოდით შევხედოთ მაგალითს.

ასე გამოიყურება Dockerfile: ბრძანებები მარცხნივ, არგუმენტები მარჯვნივ. თითოეული ბრძანება, რომელიც აქ არის (და ზოგადად Dockerfile-შია დაწერილი) ქმნის ახალ ფენას Image-ში.

მარცხენა მხარესაც კი უხეშად გაიგებთ რა ხდება. ჩვენ ვამბობთ: "შექმენით საქაღალდე ჩვენთვის" - ეს არის ერთი ფენა. "გააკეთე საქაღალდე სამუშაოდ" არის კიდევ ერთი ფენა და ა.შ. ფენოვანი ნამცხვარი ცხოვრებას აადვილებს. თუ მე შევქმნი სხვა Dockerfile-ს და შევცვლი რაღაცას ბოლო სტრიქონში - მე გავუშვი რაღაც სხვას, გარდა „python“ „main.py“, ან დავაყენებ დამოკიდებულებებს სხვა ფაილიდან - მაშინ წინა ფენები ხელახლა გამოიყენებს ქეშს.

Image - ეს არის კონტეინერის შეფუთვა; კონტეინერები გაშვებულია სურათიდან. თუ Docker-ს შევხედავთ პაკეტის მენეჯერის თვალსაზრისით (თითქოს ჩვენ ვმუშაობდით deb ან rpm პაკეტებით), მაშინ სურათი არსებითად არის rpm პაკეტი. yum install-ის საშუალებით ჩვენ შეგვიძლია დავაინსტალიროთ აპლიკაცია, წავშალოთ, ვიპოვოთ საცავში და გადმოვწეროთ. აქაც დაახლოებით იგივეა: კონტეინერები იხსნება სურათიდან, ისინი ინახება Docker-ის რეესტრში (yum-ის მსგავსი, საცავში) და თითოეულ სურათს აქვს SHA-256 ჰეში, სახელი და ტეგი.

სურათი აგებულია Dockerfile-ის ინსტრუქციის მიხედვით. Dockerfile-დან თითოეული ინსტრუქცია ქმნის ახალ ფენას. ფენების ხელახლა გამოყენება შესაძლებელია.

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

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

მოთხოვნა „ერთი კონტეინერი, ერთი პროცესი“ დაკავშირებულია PID სახელთა სივრცესთან. როდესაც პროცესი PID 1-ით იწყება სახელთა სივრცეში, თუ ის მოულოდნელად კვდება, მაშინ მთელი კონტეინერიც კვდება. თუ იქ ორი პროცესი მიმდინარეობს: ერთი ცოცხალია და მეორე მკვდარი, მაშინ კონტეინერი კვლავ გააგრძელებს სიცოცხლეს. მაგრამ ეს არის საუკეთესო პრაქტიკის საკითხი, მათზე ვისაუბრებთ სხვა მასალებში.

კურსის მახასიათებლებისა და სრული პროგრამის უფრო დეტალურად შესასწავლად მიჰყევით ბმულს: “დოკერის ვიდეო კურსი".

ავტორი: მარსელ იბრაევი, სერტიფიცირებული Kubernetes-ის ადმინისტრატორი, პრაქტიკოსი ინჟინერი Southbridge-ში, სპიკერი და Slurm კურსის შემქმნელი.

წყარო: www.habr.com