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

პირველი, პატარა თეორია. Რა მოხდა თორმეტი ფაქტორის აპლიკაცია?

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

დოკუმენტი შექმნეს Heroku პლატფორმის დეველოპერებმა.

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

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

1. Codebase – ერთი კოდის ბაზა, რომელიც თვალყურს ადევნებს ვერსიის კონტროლს – მრავალჯერადი განლაგება
2. დამოკიდებულებები - მკაფიოდ გამოაცხადეთ და იზოლირებული დამოკიდებულებები
3. კონფიგურაცია - შეინახეთ კონფიგურაცია გაშვების დროს
4. სარეზერვო სერვისები – განიხილეთ დამხმარე სერვისები, როგორც დანამატის რესურსები
5. აშენება, გათავისუფლება, გაშვება – მკაცრად გამოყავით შეკრების და შესრულების ეტაპები
6. Процессы – გაუშვით აპლიკაცია, როგორც ერთი ან მეტი მოქალაქეობის არმქონე პროცესი
7. პორტის შეკვრა – სერვისების ექსპორტი პორტის სავალდებულო საშუალებით
8. პარალელიზმი - გააფართოვეთ თქვენი განაცხადი პროცესების გამოყენებით
9. ერთჯერადობა - მაქსიმალურად გაზარდეთ საიმედოობა სწრაფი გაშვებით და სუფთა გამორთვით
10. აპლიკაციის შემუშავება/ოპერაციული პარიტეტი - შეინახეთ თქვენი განვითარების, დადგმის და წარმოების გარემო რაც შეიძლება მსგავსი
11. ხე-ტყე - იხილეთ ჟურნალი, როგორც მოვლენების ნაკადი
12. ადმინისტრაციის ამოცანები – ადმინისტრაციული/მართვის ამოცანების შესრულება ad hoc პროცესების გამოყენებით

შეგიძლიათ მიიღოთ მეტი ინფორმაცია 12 ფაქტორის შესახებ შემდეგი რესურსებიდან:

• ოფიციალური წყარო - აუცილებლად წასაკითხი
• სტატია ჰაბრ. თორმეტი ფაქტორის აპლიკაცია - ოფიციალური თარგმანი
• სტატია ჰაბრ. 7 დაკარგული ფაქტორი 12 ფაქტორის აპლიკაციაში - ახალი დათვალიერება 12 ფაქტორზე მათი გაუმჯობესების მიზნით.

რა არის ლურჯი-მწვანე განლაგება?

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

კლასიკური BG Deploy სქემა ჰგავს ქვემოთ მოცემულ სურათზე ნაჩვენები.

• დასაწყისში არის 2 ფიზიკური სერვერი აბსოლუტურად იგივე კოდით, აპლიკაციით, პროექტით და არის როუტერი (ბალანსერი).
• როუტერი თავდაპირველად მიმართავს ყველა მოთხოვნას ერთ-ერთ სერვერზე (მწვანე).
• იმ მომენტში, როდესაც თქვენ გჭირდებათ ხელახლა გამოშვება, მთელი პროექტი განახლდება სხვა სერვერზე (Синий), რომელიც ამჟამად არცერთ მოთხოვნას არ ამუშავებს.
• კოდის ჩართვის შემდეგ ლურჯი სერვერი მთლიანად განახლებულია, როუტერს ეძლევა გადართვის ბრძანება მწვანე on Синий სერვერი.
• ახლა ყველა კლიენტი ხედავს კოდის გაშვების შედეგს ლურჯი სერვერი.
• გარკვეული პერიოდის განმავლობაში, მწვანე სერვერი ემსახურება როგორც სარეზერვო ასლს წარუმატებელი განლაგების შემთხვევაში Синий სერვერზე და მარცხისა და შეცდომების შემთხვევაში, როუტერი აბრუნებს მომხმარებლის ნაკადს მწვანე სერვერი ძველი სტაბილური ვერსიით და ახალი კოდი იგზავნება გადასინჯვისა და ტესტირებისთვის.
• და პროცესის ბოლოს, იგი განახლდება იმავე გზით მწვანე სერვერი. და განახლების შემდეგ, როუტერი ცვლის მოთხოვნის ნაკადს უკან მწვანე სერვერი.

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

ცუდი და კარგი რჩევა

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

მაგალითების უმეტესობა ამა თუ იმ გზით გადაიკვეთება ვებ-განვითარებასთან (ეს სიურპრიზია), PHP-თან და Docker-თან.

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

1. Codebase

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

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

2. დამოკიდებულებები

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

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

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

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

3. კონფიგურაცია

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

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

ანუ, მაშინაც კი, თუ თქვენ ინახავთ რამდენიმე კონფიგურაციის ფაილს .config.prod .config.local და გადაარქმევთ მათ განლაგების დროს .config-ზე (მთავარი კონფიგურაცია, საიდანაც აპლიკაცია კითხულობს მონაცემებს) - ეს არ იქნება სწორი მიდგომა, რადგან ამ შემთხვევაში კონფიგურაციებიდან ინფორმაცია საჯაროდ იქნება ხელმისაწვდომი აპლიკაციის ყველა დეველოპერისთვის და საწარმოო სერვერის მონაცემები გატეხილი იქნება. ყველა კონფიგურაცია უნდა იყოს შენახული უშუალოდ განლაგების სისტემაში (CI/CD) და გენერირებული იყოს სხვადასხვა გარემოსთვის, განსხვავებული მნიშვნელობებით, რომლებიც აუცილებელია კონკრეტული გარემოსთვის განლაგების დროს.

4. მესამე მხარის მომსახურება

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

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

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

5. აშენება, გათავისუფლება, შესრულება

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

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

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

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

6. პროცესები

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

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

7. პორტის შეკვრა

მხოლოდ ვებ სერვერმა უნდა იცოდეს მესამე მხარის სერვისებთან მუშაობა. ან კიდევ უკეთესი, დააინსტალირეთ მესამე მხარის სერვისები პირდაპირ ვებ სერვერის შიგნით. მაგალითად, როგორც PHP მოდული Apache-ში.
ყველა თქვენი სერვისი უნდა იყოს ერთმანეთთან წვდომა რომელიმე მისამართსა და პორტზე წვდომის გზით (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), ანუ nginx-დან შემიძლია წვდომა როგორც php-fpm, ასევე postgres და php-fpm-დან postgres-მდე და nginx-მდე და რეალურად თითოეული სერვისიდან შემიძლია სხვა სერვისზე წვდომა. ამ გზით, მომსახურების სიცოცხლისუნარიანობა არ არის მიბმული სხვა სერვისის სიცოცხლისუნარიანობასთან.

8. პარალელიზმი

იმუშავეთ ერთ პროცესთან, თორემ რამდენიმე პროცესი ერთმანეთს ვერ შეეგუება!

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

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

9. ერთჯერადი გამოყენება

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

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

10. აპლიკაციის შემუშავება/ოპერაციული პარიტეტი

განაცხადის წარმოება, დადგმა და ლოკალური ვერსია განსხვავებული უნდა იყოს. წარმოებაში ჩვენ ვიყენებთ Yii Lite ჩარჩოს და ადგილობრივად Yii-ს, რათა ის უფრო სწრაფად მუშაობდეს წარმოებაში!

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

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

11. მორები

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

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

12. ადმინისტრაციის ამოცანები

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

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

განხორციელების მაგალითი PHP, Laravel, Laradock, Docker-Compose-ში

P.S ყველა მაგალითი გაკეთდა MacOS-ზე. მათი უმეტესობა ასევე შესაფერისია Linux-ისთვის. ვინდოუსის მომხმარებლებო, მაპატიეთ, მაგრამ ვინდოუსზე დიდი ხანია არ ვმუშაობ.

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

docker -v && 
docker-compose -v

1. განათავსეთ ლარადოკი

git clone https://github.com/Laradock/laradock.git && 
ls

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

2. დააკონფიგურირეთ Laradock ჩვენი აპლიკაციის გასაშვებად.

cd laradock && 
cp env-example .env

2.1. გახსენით habr დირექტორია (მშობელი საქაღალდე, რომელშიც კლონირებულია laradock) ზოგიერთ რედაქტორში. (ჩემს PHPStorm შემთხვევაში)

ამ ეტაპზე ჩვენ მხოლოდ პროექტს ვაძლევთ სახელს.

2.2. გაუშვით სამუშაო სივრცის სურათი. (თქვენს შემთხვევაში, სურათების შექმნას გარკვეული დრო დასჭირდება)
Workspace არის სპეციალურად მომზადებული სურათი დეველოპერის სახელით ფრეიმორთან მუშაობისთვის.

ჩვენ შევდივართ კონტეინერში გამოყენებით

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. ლარაველის ინსტალაცია

composer create-project --prefer-dist laravel/laravel application

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

ls
exit
docker-compose down

2.5. მოდით დავუბრუნდეთ PHPStorm-ს და დავაყენოთ სწორი გზა ჩვენი laravel განაცხადისკენ .env ფაილში.

3. დაამატეთ ყველა კოდი Git-ში.

ამისათვის ჩვენ შევქმნით საცავს Github-ზე (ან სხვაგან). მოდით გადავიდეთ ტერმინალში habr დირექტორიაში და შევასრულოთ შემდეგი კოდი.

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

მოდით შევამოწმოთ ყველაფერი რიგზეა თუ არა.

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

4. დავიწყოთ!

დაწყებამდე დარწმუნდით, რომ არაფერი არ არის ჩამოკიდებული 80 და 443 პორტებზე.

docker-compose up -d nginx php-fpm

ამრიგად, ჩვენი პროექტი შედგება 3 ცალკეული სერვისისგან:

• nginx - ვებ სერვერი
• php-fpm - php ვებ სერვერიდან მოთხოვნის მისაღებად
• სამუშაო ადგილი - php დეველოპერებისთვის

ამ დროისთვის ჩვენ მივაღწიეთ იმას, რომ შევქმენით აპლიკაცია, რომელიც აკმაყოფილებს 4 ქულას 12-დან, კერძოდ:

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

2. დამოკიდებულებები - ყველა ჩვენი დამოკიდებულება ცალსახად არის დაწერილი application/composer.json-ში და თითოეული კონტეინერის თითოეულ Dockerfile-ში.

3. სარეზერვო სერვისები — თითოეული სერვისი (php-fom, nigx, სამუშაო სივრცე) თავისი ცხოვრებით ცხოვრობს და დაკავშირებულია გარედან და ერთ სერვისთან მუშაობისას მეორეზე არ იმოქმედებს.

4. Процессы — თითოეული სერვისი ერთი პროცესია. თითოეული სერვისი არ ინარჩუნებს შიდა მდგომარეობას.

5. პორტის შეკვრა

docker ps

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

6. პარალელიზმი

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

გავაჩეროთ კონტეინერები და გავატაროთ დროშაზე -- მასშტაბი

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

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

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

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

9. ხე-ტყე — ამ კონტეინერებში ყველა ჟურნალი გადადის ნაკადში და ჩანს Docker კონსოლში. (ამ შემთხვევაში, ფაქტობრივად, სხვა ხელნაკეთი კონტეინერების შემთხვევაში, ეს შეიძლება არ იყოს, თუ არ იზრუნებთ მასზე)

 docker-compose logs -f

მაგრამ არის ის, რომ ნაგულისხმევი მნიშვნელობები PHP-სა და Nginx-ში ასევე წერს ჟურნალებს ფაილში. 12 ფაქტორის დასაკმაყოფილებლად აუცილებელია გამორთვა ჟურნალის ჩაწერა ფაილში თითოეული კონტეინერის კონფიგურაციებში ცალკე.

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

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

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

 
docker-compose exec workspace bash
php artisan list

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

11. კონფიგურაციები და 12 აშენება, გათავისუფლება, გაშვება

მინდოდა ეს ნაწილი მიმეძღვნა Blue-Green Deployment-ისთვის, მაგრამ აღმოჩნდა ძალიან ვრცელი ამ სტატიისთვის. ამის შესახებ ცალკე სტატიას დავწერ.

მოკლედ, კონცეფცია ეფუძნება CI/CD სისტემებს, როგორიცაა Jenkins и Gitlab CI. ორივეში შეგიძლიათ დააყენოთ გარემოს ცვლადები, რომლებიც დაკავშირებულია კონკრეტულ გარემოსთან. შესაბამისად, ამ სიტუაციაში შესრულდება გ პუნქტი კონფიგურაციები.

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

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

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

P.S.: ყველა ეს მიდგომა შეიძლება გამოყენებულ იქნას ნებისმიერი სხვა კომუნალური და პროგრამირების ენით. მთავარი ის არის, რომ არსი არ განსხვავდება.

წყარო: www.habr.com