უწყვეტი მიწოდების პრაქტიკა Docker-თან (მიმოხილვა და ვიდეო)

ჩვენ დავიწყებთ ჩვენს ბლოგს ჩვენი ტექნიკური დირექტორის უახლესი გამოსვლების საფუძველზე პუბლიკაციებით დისტოლი (დიმიტრი სტოლიაროვი). ყველა მათგანი 2016 წელს გაიმართა სხვადასხვა პროფესიულ ღონისძიებაზე და მიეძღვნა DevOps-ისა და Docker-ის თემას. ერთი ვიდეო Docker Moscow-ის შეხვედრიდან Badoo-ს ოფისში, უკვე გვაქვს გამოქვეყნდა ონლაინ. ახლებს დაერთვება მოხსენებების არსის გადმოცემის სტატიები. Ისე…

31 მაისს კონფერენციაზე RootConf 2016ფესტივალის „რუსული ინტერნეტ ტექნოლოგიები“ (RIT++ 2016) ფარგლებში გაიმართა, სექცია „უწყვეტი განლაგება და განლაგება“ გაიხსნა მოხსენებით „დოკერით უწყვეტი მიწოდების საუკეთესო პრაქტიკა“. მან შეაჯამა და სისტემატიზაცია მოახდინა საუკეთესო პრაქტიკა უწყვეტი მიწოდების (CD) პროცესის შესაქმნელად Docker-ისა და სხვა ღია კოდის პროდუქტების გამოყენებით. ჩვენ ვმუშაობთ ამ გადაწყვეტილებებით წარმოებაში, რაც საშუალებას გვაძლევს დავეყრდნოთ პრაქტიკულ გამოცდილებას.

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

უწყვეტი მიწოდება Docker-ით

ქვეშ უწყვეტი მიწოდების ჩვენ გვესმის მოვლენების ჯაჭვი, რის შედეგადაც Git-ის საცავიდან აპლიკაციის კოდი ჯერ წარმოებაში მოდის და შემდეგ მთავრდება არქივში. ეს ასე გამოიყურება: Git → Build → Test → Release → Operate.

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

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

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

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

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

კონტეინერიზაცია იძლევა ბევრ სხვა სარგებელს განლაგებისას. ნებისმიერი განაცხადი დამოკიდებულია კონკრეტული ვერსია (ან ვერსიის დიაპაზონი) თარჯიმანი, მოდულების/გაფართოებების ხელმისაწვდომობა და ა.შ., ასევე მათი ვერსიები. და ეს ეხება არა მხოლოდ უშუალო შესრულებადი გარემოს, არამედ მთელ გარემოს, მათ შორის სისტემის პროგრამული უზრუნველყოფა და მისი ვერსია (გამოყენებული Linux დისტრიბუციამდე). იმის გამო, რომ კონტეინერები შეიცავს არა მხოლოდ აპლიკაციის კოდს, არამედ წინასწარ დაინსტალირებულ სისტემას და საჭირო ვერსიების აპლიკაციის პროგრამულ უზრუნველყოფას, შეგიძლიათ დაივიწყოთ დამოკიდებულებებთან დაკავშირებული პრობლემები.

შევაჯამოთ ძირითადი გაშვების ნიმუში ახალი ვერსიები შემდეგი ფაქტორების გათვალისწინებით:

1. თავდაპირველად, აპლიკაციის ძველი ვერსია მუშაობს პირველ კონტეინერში.
2. შემდეგ ახალი ვერსია იშლება და „თბება“ მეორე კონტეინერში. აღსანიშნავია, რომ თავად ამ ახალ ვერსიას შეიძლება ჰქონდეს არა მხოლოდ განახლებული აპლიკაციის კოდი, არამედ მისი რომელიმე დამოკიდებულება, ასევე სისტემის კომპონენტები (მაგალითად, OpenSSL-ის ახალი ვერსია ან მთელი განაწილება).
3. როდესაც ახალი ვერსია სრულად მზად არის მოთხოვნებისთვის, ტრაფიკი გადადის პირველი კონტეინერიდან მეორეზე.
4. ძველი ვერსია ახლა შეიძლება შეჩერდეს.

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

ბოლო პირველი რეკომენდაცია ჟღერს რაღაცაში, რაშიც კაპიტანმაც კი ვერ იპოვა ბრალი: ”[დოკერთან უწყვეტი მიწოდების ორგანიზებისას] გამოიყენეთ Docker [და გაიგე რას იძლევა]" დაიმახსოვრე, ეს არ არის ვერცხლის ტყვია, რომელიც გადაჭრის ყველა პრობლემას, არამედ ინსტრუმენტი, რომელიც უზრუნველყოფს შესანიშნავ საძირკველს.

რეპროდუცირებადობა

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

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

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

ინფრასტრუქტურა არის კოდი

თუ ინფრასტრუქტურის მოთხოვნები (სერვერის პროგრამული უზრუნველყოფის ხელმისაწვდომობა, მისი ვერსია და ა.შ.) არ არის ფორმალიზებული და „დაპროგრამებული“, მაშინ ნებისმიერი აპლიკაციის განახლების გავრცელებამ შეიძლება გამოიწვიოს დამღუპველი შედეგები. მაგალითად, ინსცენირებისას თქვენ უკვე გადაერთეთ PHP 7.0-ზე და შესაბამისად გადაწერეთ კოდი - მაშინ მისი გამოჩენა წარმოებაში ძველი PHP-ით (5.5) აუცილებლად გააკვირვებს ვინმეს. შეიძლება არ დაივიწყოთ თარჯიმანის ვერსიის მნიშვნელოვანი ცვლილება, მაგრამ „ეშმაკი დეტალებშია“: სიურპრიზი შეიძლება იყოს ნებისმიერი დამოკიდებულების უმნიშვნელო განახლებაში.

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

მრავალ ფენიანი აპლიკაციის არქიტექტურის შემთხვევაში - მაგალითად, არის nginx, რომელიც დგას აპლიკაციის წინ, რომელიც უკვე მუშაობს Docker კონტეინერში - Docker-ის სურათები უნდა შეიქმნას Git-ის კოდიდან თითოეული ფენისთვის. შემდეგ პირველი სურათი შეიცავს აპლიკაციას თარჯიმანით და სხვა „ახლო“ დამოკიდებულებებით, ხოლო მეორე სურათი შეიცავს ნგინქსს.

დოკერის სურათები, კომუნიკაცია Git-თან

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

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

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

დაპ

ყველაფერი აღწერილი (გაშვება, გამოსახულების შეკრება, შემდგომი მოვლა) შეიძლება განხორციელდეს დამოუკიდებლად Bash სკრიპტებისა და სხვა „იმპროვიზირებული“ ხელსაწყოების გამოყენებით. მაგრამ თუ ამას გააკეთებთ, მაშინ რაღაც მომენტში განხორციელება გამოიწვევს დიდ სირთულეს და ცუდი კონტროლირებას. ამის გაგებით, ჩვენ მოვედით, რომ შევქმნათ ჩვენი სპეციალიზებული Workflow პროგრამა CI/CD-ის შესაქმნელად - დაპ.

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

განახლებულია 13 წლის 2019 აგვისტოს: ამჟამად პროექტი დაპ გადაერქვა ვერფ, მისი კოდი მთლიანად გადაიწერა Go-ში და საგრძნობლად გაუმჯობესდა მისი დოკუმენტაცია.

კუბერნეტები

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

გავრცელებისთვის, Kubernetes გთავაზობთ:

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

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

საბოლოო რეკომენდაციები

1. გამოიყენეთ Docker.
2. შექმენით აპლიკაციების Docker სურათები თქვენი ყველა საჭიროებისთვის.
3. დაიცავით პრინციპი "ინფრასტრუქტურა არის კოდი".
4. დააკავშირეთ Git Docker-თან.
5. დაარეგულირეთ გაშვების თანმიმდევრობა.
6. გამოიყენეთ მზა პლატფორმა (Kubernetes ან სხვა).

ვიდეოები და სლაიდები

ვიდეო სპექტაკლიდან (დაახლოებით ერთი საათი) YouTube-ზე გამოქვეყნდა (თავად რეპორტაჟი მე-5 წუთიდან იწყება - ამ წუთიდან სათამაშოდ მიჰყევით ბმულს).

ანგარიშის პრეზენტაცია:

PS

სხვა მოხსენებები თემაზე ჩვენს ბლოგზე:

• «werf - ჩვენი ინსტრუმენტი CI / CD-სთვის Kubernetes-ში (მიმოხილვა და ვიდეო ანგარიში)» (დმიტრი სტოლიაროვი; 27 წლის 2019 მაისი DevOpsConf-ზე);
• «მონაცემთა ბაზები და კუბერნეტები» (დმიტრი სტოლიაროვი; 8 წლის 2018 ნოემბერი HighLoad++-ზე);
• «CI/CD საუკეთესო პრაქტიკა Kubernetes-თან და GitLab-თან» (დმიტრი სტოლიაროვი; 7 წლის 2017 ნოემბერი HighLoad++-ზე);
• «ჩვენი გამოცდილება Kubernetes-თან მცირე პროექტებში» (დმიტრი სტოლიაროვი; 6 წლის 2017 ივნისი RootConf-ზე).

წყარო: www.habr.com