დოკერი სათამაშოა თუ არა? ან კიდევ არის?

გაუმარჯოს ყველას!

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

Entry

მე ვარ პროგრამისტი, რომელსაც აქვს გამოცდილება წინა გვერდის აპლიკაციების, scala/java და nodejs სერვერზე შემუშავებაში.

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

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

გამოყენების მიზეზები

რატომ გამოვიყენე დოკერი? ალბათ შემდეგი მიზეზების გამო:

• მონაცემთა ბაზის გაშვება, აპლიკაციების 99% იყენებს მათ
• nginx-ის გაშვება ფრონტენდის დისტრიბუციისთვის და პროქსირება backend-ისთვის
• შეგიძლიათ აპლიკაცია შეფუთოთ დოკერის სურათში, ამ გზით ჩემი აპლიკაცია იმუშავებს სადაც კი დოკერი არსებობს, განაწილების პრობლემა დაუყოვნებლივ მოგვარდება
• სერვისის აღმოჩენა ყუთიდან, შეგიძლიათ შექმნათ მიკროსერვისები, თითოეული კონტეინერი (დაკავშირებული საერთო ქსელთან) ადვილად მიაღწევს მეორეს მეტსახელის საშუალებით, ძალიან მოსახერხებელია
• სახალისოა კონტეინერის შექმნა და მასში "თამაში".

რაც ყოველთვის არ მომწონს დოკერში:

• იმისათვის, რომ ჩემმა აპლიკაციამ იმუშაოს, მე მჭირდება თავად Docker სერვერზე. რატომ მჭირდება ეს, თუ ჩემი აპლიკაციები მუშაობს jre ან nodejs-ზე და მათთვის გარემო უკვე სერვერზეა?
• თუ მსურს ჩემი (პირადი) ლოკალურად აშენებული სურათის გაშვება დისტანციურ სერვერზე, მაშინ მჭირდება ჩემი საკუთარი დოკერის საცავი, მჭირდება რეესტრი, რომ სადმე იმუშაოს და ასევე მჭირდება https-ის კონფიგურაცია, რადგან docker cli მუშაობს მხოლოდ https-ზე. ოჰ ჯანდაბა... არის ვარიანტები, რა თქმა უნდა, გამოსახულების ლოკალურად შენახვა docker save და უბრალოდ გაგზავნეთ სურათი scp-ის საშუალებით... მაგრამ ეს არის სხეულის ბევრი მოძრაობა. გარდა ამისა, ის გამოიყურება როგორც "ყავარჯენი" გამოსავალი, სანამ არ გამოჩნდება თქვენი საკუთარი საცავი
• docker-compose. საჭიროა მხოლოდ კონტეინერების გასაშვებად. Სულ ეს არის. სხვა ვერაფერს აკეთებს. Docker-compose აქვს თავისი ფაილების მრავალი ვერსია, საკუთარი სინტაქსი. რაც არ უნდა დეკლარაციული იყოს, არ მინდა მათი დოკუმენტაციის წაკითხვა. სხვაგან არ დამჭირდება.
• გუნდში მუშაობისას, ადამიანების უმეტესობა წერს Dockerfile-ს ძალიან უხერხულად, არ ესმის, როგორ არის ქეშირებული, ამატებენ ყველაფერს, რაც მათ სჭირდებათ და არ სჭირდებათ სურათს, იღებენ მემკვიდრეობას იმ სურათებიდან, რომლებიც არ არის Dockerhub-ში ან კერძო საცავში, ქმნიან რამდენიმე docker-compose ფაილები მონაცემთა ბაზებით და არაფერი გრძელდება. ამავდროულად, დეველოპერები ამაყად აცხადებენ, რომ Docker მაგარია, მათთვის ყველაფერი ლოკალურად მუშაობს და HR მნიშვნელოვანია ვაკანსიაზე წერს: „ჩვენ ვიყენებთ Docker-ს და გვჭირდება კანდიდატი ასეთი სამუშაო გამოცდილებით“.
• გამუდმებით მაწუხებს ფიქრები Docker-ში ყველაფრის ამაღლებაზე: postgresql, kafka, redis. სამწუხაროა, რომ ყველაფერი კონტეინერებში არ მუშაობს, ყველაფრის კონფიგურაცია და გაშვება ადვილი არ არის. ამას მხარს უჭერენ მესამე მხარის დეველოპერები და არა თავად მომწოდებლები. სხვათა შორის, მაშინვე ჩნდება კითხვა: გამყიდველები არ ზრუნავენ Docker-ში პროდუქციის შენარჩუნებაზე, რატომ არის ეს, იქნებ მათ იციან რამე?
• ყოველთვის ჩნდება კითხვა კონტეინერის მონაცემების მდგრადობის შესახებ. და შემდეგ თქვენ ფიქრობთ, უბრალოდ უნდა დავამონტაჟო ჰოსტის დირექტორია, შევქმნა დოკერის ტომი ან გავაკეთო მონაცემთა კონტეინერი, რომელიც ახლა არის deprecated? თუ დირექტორიას ვამონტაჟებ, მაშინ უნდა დავრწმუნდე, რომ კონტეინერში მომხმარებლის uid და gid ემთხვევა იმ მომხმარებლის id-ს, რომელმაც კონტეინერი გაუშვა, წინააღმდეგ შემთხვევაში კონტეინერის მიერ შექმნილი ფაილები შეიქმნება root უფლებებით. თუ გამოვიყენებ volume მაშინ მონაცემები უბრალოდ შეიქმნება ზოგიერთში /usr/* და იქნება იგივე ამბავი უიდთან და გიდთან, როგორც პირველ შემთხვევაში. თუ თქვენ იწყებთ მესამე მხარის კომპონენტს, თქვენ უნდა წაიკითხოთ დოკუმენტაცია და მოძებნოთ პასუხი კითხვაზე: "რომელ კონტეინერების დირექტორიაში წერს კომპონენტი ფაილებს?"

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

წარმოგიდგენთ Ansible

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

• docker არეგულირებს iptables-ს (თუმცა შეგიძლიათ გამორთოთ ის daemon.json-ში)
• დოკერი არის ბაგი და ჩვენ არ გამოვამუშავებთ მას წარმოებაში
• თუ დოკერ დემონი დაეჯახა, მაშინ ინფრასტრუქტურის მქონე ყველა კონტეინერი ავარიულად იშლება
• არ არის საჭირო დოკერი
• რატომ დოკერი თუ არსებობს Ansible და ვირტუალური მანქანები

ამავე სამსახურში გავიცანი კიდევ ერთი ინსტრუმენტი - Ansible. ერთხელ გავიგე ამის შესახებ, მაგრამ არ მიცდია ჩემი სათამაშო წიგნების დაწერა. ახლა კი დავიწყე ჩემი ამოცანების წერა და შემდეგ ჩემი ხედვა მთლიანად შეიცვალა! იმიტომ, რომ მივხვდი: Ansible-ს აქვს მოდულები ერთი და იგივე დოკერის კონტეინერების, სურათების აწყობის, ქსელების და ა.შ. გასაშვებად და კონტეინერების გაშვება შესაძლებელია არა მხოლოდ ლოკალურად, არამედ დისტანციურ სერვერებზეც! ჩემს სიამოვნებას საზღვარი არ ჰქონდა - ვიპოვე ნორმალური ინსტრუმენტი და გადავყარე ჩემი Makefile და docker-compose ფაილები, ისინი შეიცვალა yaml ამოცანებით. კოდი შემცირდა ისეთი კონსტრუქციების გამოყენებით, როგორიცაა loop, whenდა ა.შ.

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

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

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

ssh -L 9000:localhost:5432 [ელ.ფოსტით დაცულია]

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

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

საბედნიეროდ, AWS, GoogleCloud და სხვები გაძლევთ ერთი წლის უფასო გამოყენებას, ამიტომ გამოიყენეთ ისინი! ისინი იაფია, თუ გამორთავთ მათ, როდესაც არ იყენებთ. ყოველთვის მაინტერესებდა, რატომ მჭირდებოდა დისტანციური სერვერი, როგორიცაა gcloud, როგორც ჩანს, ვიპოვე ისინი.

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

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

ცოტა რამ დოკერის სურათებისა და განაწილების შესახებ

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

გინახავთ სადმე, სადაც პროგრამული უზრუნველყოფის დეველოპერები პორტირებენ თავიანთ პროდუქტებს მხოლოდ დოკერის სურათში?
პროდუქტების უმეტესობის შედეგი არის ორობითი ფაილები კონკრეტული პლატფორმისთვის; ისინი უბრალოდ ემატება დოკერის სურათს, რომელიც მემკვიდრეობით მიიღება სასურველი პლატფორმიდან. ოდესმე დაფიქრებულხართ, რატომ არის ამდენი მსგავსი სურათი dockerhub-ზე? შედით მაგალითად nginx, ნახავთ 100500 სურათს სხვადასხვა ადამიანისგან. ამ ადამიანებმა არ შექმნეს თავად nginx, მათ უბრალოდ დაამატეს ოფიციალური nginx თავიანთ დოკერის სურათს და დააგემოვნეს ის საკუთარი კონფიგურაციებით, კონტეინერების გაშვების მოხერხებულობისთვის.

ზოგადად, შეგიძლიათ უბრალოდ შეინახოთ tgz-ში, თუ ვინმეს სჭირდება მისი გაშვება docker-ში, ნება მიეცით დაამატოთ tgz Dockerfile-ში, მიიღოს მემკვიდრეობა სასურველი გარემოდან და შექმნას დამატებითი buns, რომლებიც არ ცვლის თავად აპლიკაციას tgz-ში. ვინც შექმნის დოკერის იმიჯს, იცის რა არის tgz და რა სჭირდება მას სამუშაოდ. ასე ვიყენებ დოკერს აქ

დედააზრი: მე არ მჭირდება დოკერის რეესტრი, გამოვიყენებ რაიმე სახის S3 ან უბრალოდ ფაილების შენახვას, როგორიცაა google drive/dropbox

დოკერი CI-ში

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

ეს კომპანიები იყენებენ დოკერს თავიანთ სერვერებზე, სადაც გადის CI პროცესი. კითხვა: რატომ გჭირდებათ პროექტების აშენება დოკერ კონტეინერში თქვენს სერვერებზე? რატომ არ მოამზადოთ გარემო build-ისთვის, მაგალითად, დაწეროთ Ansible playbook, რომელიც დააინსტალირებს nodejs, php, jdk, ssh კლავიშების კოპირებას და ა.შ. საჭირო ვერსიებს სერვერზე, რომელშიც ჩატარდება მშენებლობა?

ახლა მესმის, რომ ეს არის ფეხში სროლა, რადგან დოკერი თავისი იზოლაციით არანაირ მოგებას არ მოაქვს. პრობლემები, რომლებიც დამხვდა CI-სთან დოკერში:

• ისევ დაგჭირდებათ დოკერის გამოსახულება ასაგებად. თქვენ უნდა მოძებნოთ სურათი ან დაწეროთ თქვენი საკუთარი dockerfile.
• 90% რომ თქვენ უნდა გადააგზავნოთ რამდენიმე ssh გასაღები, საიდუმლო მონაცემები, რომელთა ჩაწერა არ გსურთ დოკერის სურათზე.
• კონტეინერი იქმნება და კვდება, მასთან ერთად იკარგება ყველა ქეში. შემდეგი build ხელახლა ჩამოტვირთავს ყველა პროექტის დამოკიდებულებას, რაც შრომატევადი და არაეფექტურია და დრო არის ფული.

დეველოპერები არ აშენებენ პროექტებს დოკერის კონტეინერებში (მე ვიყავი ოდესღაც ასეთი გულშემატკივარი, მართლაც, ვწუხვარ ჩემს თავს წარსულში xD). ჯავაში შესაძლებელია გქონდეთ რამდენიმე ვერსია და ერთი ბრძანებით შეცვალოთ ის, რაც ახლა გჭირდებათ. იგივეა nodejs-ში, არის nvm.

გამოყვანის

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

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

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

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

• იყავით უკიდურესად ფრთხილად
• ნუ აიძულებთ დეველოპერებს გამოიყენონ დოკერი
• მოახდინეთ მისი გამოყენების ლოკალიზება ერთ ადგილას, არ გაავრცელოთ იგი ყველა Dockfile და docker-compose საცავში

PS:

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

გმადლობთ წაკითხვისთვის, გისურვებთ გამჭვირვალე გადაწყვეტილებებს თქვენს საქმეებში და ნაყოფიერ სამუშაო დღეებს!

წყარო: www.habr.com