განვითარებისა და ტესტირების პროცესი Docker და Gitlab CI-ით

მე ვთავაზობ ალექსანდრე სიგაჩოვის მოხსენების ტრანსკრიპტის წაკითხვას Inventos-დან "განვითარება და ტესტირების პროცესი Docker + Gitlab CI-ით"

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

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

ვისაც აინტერესებს, გთხოვთ, კატის ქვეშ.

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

პრეზენტაციის თემა: განვითარების პროცესი Docker-ისა და Gitlab CI-ის გამოყენებით.

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

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

ჩვენი დევიზია: დაამაგრეთ ყველაფერი, რაც ხელთ გვაქვს.

რა პრობლემებს ვაგვარებთ?

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

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

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

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

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

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

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

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

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

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

Frondend-დეველოპერს, რომელიც ვითარდება JS-ზე, თითქმის არ აქვს გავლენა Backend-ზე. ბექენდის დეველოპერი, თავის მხრივ, ავითარებს, ჩვენს შემთხვევაში, Ruby on Rails და არ ერევა Frondend-ში. ურთიერთქმედება ხორციელდება API-ს გამოყენებით.

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

ხელსაწყოები. რას ვიყენებთ?

• თავად დოკერი. Dockerfile აღწერს ერთი აპლიკაციის დამოკიდებულებებს.
• Docker-compose არის ნაკრები, რომელიც აერთიანებს ჩვენს რამდენიმე Docker აპლიკაციას.
• ჩვენ ვიყენებთ GitLab-ს წყაროს კოდის შესანახად.
• ჩვენ ვიყენებთ GitLab-CI სისტემის ინტეგრაციისთვის.

მოხსენება ორი ნაწილისგან შედგება.

პირველ ნაწილში საუბარი იქნება იმაზე, თუ როგორ მუშაობდა Docker დეველოპერების მანქანებზე.

მეორე ნაწილი ვისაუბრებთ იმაზე, თუ როგორ უნდა ვიმოქმედოთ GitLab-თან, როგორ ვაწარმოებთ ტესტებს და როგორ გადავალთ Staging-ზე.

Docker არის ტექნოლოგია, რომელიც საშუალებას იძლევა (დეკლარაციული მიდგომის გამოყენებით) აღწეროს საჭირო კომპონენტები. ეს არის Dockerfile-ის მაგალითი. აქ ჩვენ ვაცხადებთ, რომ ჩვენ ვიღებთ მემკვიდრეობას ოფიციალური Ruby:2.3.0 Docker სურათიდან. ის შეიცავს დაინსტალირებულ Ruby ვერსიას 2.3. ჩვენ ვაყენებთ საჭირო build ბიბლიოთეკებს და NodeJS-ს. ჩვენ აღვწერთ, რომ ჩვენ ვქმნით დირექტორიას /app. დააყენეთ აპლიკაციის დირექტორია, როგორც სამუშაო დირექტორია. ამ დირექტორიაში ვათავსებთ საჭირო მინიმალურ Gemfile და Gemfile.lock. შემდეგ ჩვენ ვაშენებთ პროექტებს, რომლებიც დააინსტალირებენ ამ დამოკიდებულების სურათს. ჩვენ აღვნიშნავთ, რომ კონტეინერი მზად იქნება მოსასმენად გარე პორტზე 3000. ბოლო ბრძანება არის ბრძანება, რომელიც პირდაპირ უშვებს ჩვენს აპლიკაციას. თუ ჩვენ შევასრულებთ პროექტის დაწყების ბრძანებას, აპლიკაცია შეეცდება გაუშვას და გაუშვას მითითებული ბრძანება.

ეს არის docker-compose ფაილის მინიმალური მაგალითი. ამ შემთხვევაში ჩვენ ვაჩვენებთ, რომ არსებობს კავშირი ორ კონტეინერს შორის. ეს პირდაპირ არის მონაცემთა ბაზის სერვისში და ვებ სერვისში. ჩვენი ვებ აპლიკაციები უმეტეს შემთხვევაში საჭიროებს რაიმე სახის მონაცემთა ბაზას მონაცემთა შესანახად. ვინაიდან ჩვენ ვიყენებთ MySQL, მაგალითი არის MySQL - მაგრამ არაფერი გვიშლის ხელს სხვა მონაცემთა ბაზის გამოყენებაში (PostgreSQL, Redis).

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

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

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

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

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

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

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

Docker საშუალებას გაძლევთ გამოიყენოთ სასურველი ვერსიის Python, Ruby, NodeJS, PHP თარჯიმანი. ჩვენ ვიხსნით რაიმე სახის ვერსიის მენეჯერის გამოყენების აუცილებლობას. ადრე რუბი იყენებდა rpm პაკეტს, რომელიც საშუალებას გაძლევთ შეცვალოთ ვერსია პროექტის მიხედვით. ის ასევე საშუალებას აძლევს, Docker კონტეინერის წყალობით, შეუფერხებლად გადაიტანოს კოდი და დამოკიდებულებებთან ერთად ვერსიები. ჩვენ არ გვაქვს პრობლემა როგორც თარჯიმნის, ასევე კოდის ვერსიის გაგებაში. ვერსიის განახლებისთვის, ჩამოწიეთ ძველი კონტეინერი და აწიეთ ახალი კონტეინერი. თუ რამე არასწორედ წარიმართა, ჩვენ შეგვიძლია ჩამოვწიოთ ახალი კონტეინერი, ავწიოთ ძველი კონტეინერი.

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

Frontend-ზე ვიყენებთ JavaScipt და NodeJS.

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

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

აქ მე მივეცი ჩვენი ბოლო პროექტის სქემა.

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

რა გავაკეთეთ ამისთვის?

ჩვენ დავყავით აპლიკაციაში ისეთ კომპონენტებად, როგორიცაა: ადმინისტრაციული ნაწილი JS-ზე, backend, რომელიც მუშაობს REST ინტერფეისით Ruby on Rails-ის ქვეშ. Backend ურთიერთქმედებს მონაცემთა ბაზასთან. შედეგი, რომელიც წარმოიქმნება, ეძლევა კლიენტს. ადმინისტრაციული პანელი ურთიერთქმედებს backend-თან და მონაცემთა ბაზასთან REST ინტერფეისის საშუალებით.

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

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

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

იქმნება რიგები და შემდეგ იგზავნება შეტყობინებები მათი მექანიზმის მიხედვით.

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

იგივე, მაგრამ რიცხვებში. ეს არის სადაც კოდის ხელახალი გამოყენება მნიშვნელოვანია.

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

იმ დროს ჩვენ ვიყენებდით NodeJS-ის მე-4 ვერსიას. ახლა (2017 წელს - რედ. შენიშვნა) ბოლო დროს განვითარებულ მოვლენებში ვიყენებთ NodeJS-ის მე-7 ვერსიას. არ არის პრობლემა ახალ კომპონენტებში ბიბლიოთეკების ახალი ვერსიების ჩართვისთვის.

საჭიროების შემთხვევაში, შეგიძლიათ გადააკეთოთ და გაზარდოთ NodeJS ვერსია Push შეტყობინებების სერვისიდან.

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

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

ახალი პროექტის შექმნისას ვქმნით Dockerfile-ს, აღვწერთ სასურველ ეკოსისტემას (Python, Ruby, NodeJS). Docker-compose-ში აღწერს აუცილებელ დამოკიდებულებას - მონაცემთა ბაზას. ჩვენ აღვწერთ, რომ გვჭირდება მონაცემთა ბაზა ამა თუ იმ ვერსიის, მონაცემების შენახვა იქ და იქ.

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

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

შემდეგი, ჩვენ გვაქვს რამდენიმე კომპონენტი: ადმინისტრატორი, ინფორმირება-API, push შეტყობინებები.

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

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

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

თუ საჭიროა push-შეტყობინებებთან ინტეგრირება, მაშინ გაშვებულია docker-compose.yaml და docker-compose-push.yaml.

ვინაიდან docker-compose.yaml და docker-compose-push.yaml არის საქაღალდეში, ავტომატურად იქმნება ერთი ვირტუალური ქსელი.

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

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

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

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

გრაფიკულად, გამოდის, რომ კლიენტი არის ჩვენი ბრაუზერი ან რაიმე ინსტრუმენტი, რომლითაც ჩვენ ვთხოვთ ბალანსერს.

დომენის სახელის ბალანსერი განსაზღვრავს რომელ კონტეინერს დაუკავშირდეს.

ეს შეიძლება იყოს nginx, რომელიც აძლევს ადმინისტრატორს JS. ეს შეიძლება იყოს nginx, რომელიც იძლევა API-ს, ან სტატიკური ფაილები, რომლებიც გადაეცემა nginx-ს სურათების ატვირთვის სახით.

დიაგრამა აჩვენებს, რომ კონტეინერები დაკავშირებულია ვირტუალური ქსელით და იმალება პროქსის მიღმა.

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

რომელ მაგალითს მივხედოთ თქვენი განაცხადის დოკერიზაციისთვის? ჩემი აზრით, კარგი მაგალითია ოფიციალური დოკერის სურათი MySQL-ისთვის.

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

Hub.docker.com ჩვეულებრივ შეიცავს ბმულებს github.com-ზე, რომელიც შეიცავს ნედლეულ მონაცემებს პირდაპირ, საიდანაც შეგიძლიათ თავად შექმნათ სურათი.

შემდგომ ამ საცავში არის docker-endpoint.sh სკრიპტი, რომელიც პასუხისმგებელია საწყის ინიციალიზაციაზე და აპლიკაციის გაშვების შემდგომ დამუშავებაზე.

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

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

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

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

docker-endpoint.sh არის სკრიპტი, რომელიც პასუხისმგებელია შესვლის წერტილზე. საწყისი ინიციალიზაციის დროს საჭიროა გარკვეული მოსამზადებელი ნაბიჯები და ყველა ეს ქმედება კეთდება მხოლოდ ინიციალიზაციის სკრიპტში.

გადავიდეთ მეორე ნაწილზე.

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

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

Gitlab CI 2 საუბარი https://goo.gl/uohKjI - რეპორტაჟი Ruby Russia კლუბიდან - საკმაოდ დეტალური და ალბათ დაგაინტერესებთ.

ახლა ჩვენ გადავხედავთ რა არის საჭირო Gitlab CI-ის გასააქტიურებლად. იმისათვის, რომ დავიწყოთ Gitlab CI, ჩვენ უბრალოდ უნდა დავაყენოთ .gitlab-ci.yml ფაილი პროექტის root-ში.

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

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

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

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

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

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

ჩვენ ვიყენებთ მიმდინარე გარემოს ცვლადი მონაცემთა ბაზის მიგრაციას, რომელიც დაწერილია დეველოპერების მიერ.

არსებობს შენიშვნა, რომ ეს ეხება მხოლოდ მთავარ ფილიალს.

სხვა ფილიალების შეცვლისას არ სრულდება.

შესაძლებელია განლაგების ორგანიზება ფილიალების მიხედვით.

ამის შემდგომი ორგანიზებისთვის, ჩვენ უნდა დავაყენოთ Gitlab Runner.

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

გაშვებისას ჩვენ ვარეგისტრირებთ Gitlab Runner-ს.

ჩვენ ვიღებთ გასაღებს Gitlab ვებ ინტერფეისში.

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

დააყენეთ Gitlab Runner ინტერაქტიულად (Shell, Docker, VirtualBox, SSH)

Gitlab Runner-ის კოდი შესრულდება ყველა დავალებაში, .gitlab-ci.yml პარამეტრის მიხედვით.

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

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

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

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

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

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

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

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

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

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

შემდეგი საკითხი არის დადგმის გაყოფა მრავალ პროექტზე.

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

როგორ მოვაგვარეთ? ჩვენ დავანიშნეთ ერთი Gitlab Runner ყველა ძირითად პროექტზე.

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

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

ჩვენ გადავიყვანეთ nginx-proxy ცალკე გაშვების სკრიპტში და დავამატეთ ბადეები მასში შემავალი ყველა პროექტისთვის.

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

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

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

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

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

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

რა პრობლემები წარმოიქმნა, როდესაც ჩვენ დავამატეთ მომხმარებელი?

მომხმარებლის შექმნისას ხშირად არ გვაქვს იგივე ჯგუფის ID (UID) და მომხმარებლის ID (GID).

კონტეინერში ამ პრობლემის მოსაგვარებლად, ჩვენ ვიყენებთ მომხმარებლებს ID 1000.

ჩვენს შემთხვევაში, ეს დაემთხვა იმ ფაქტს, რომ თითქმის ყველა დეველოპერი იყენებს Ubuntu OS-ს. Ubuntu-ზე კი პირველ მომხმარებელს აქვს ID 1000.

გვაქვს გეგმები?

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

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

ამიტომ მინდა უფრო შორს წავიდე უკვე პირდაპირ ორკესტრირებაზე.

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

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

წყარო: www.habr.com