დამწყებთათვის სახელმძღვანელო: DevOps მილსადენის შექმნა

თუ თქვენ ახალი ხართ DevOps-ში, გადახედეთ ამ ხუთსაფეხურიან სახელმძღვანელოს თქვენი პირველი მილსადენის შესაქმნელად.

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

ჩემი DevOps მოგზაურობა

ადრე ვმუშაობდი Citi ჯგუფის ღრუბლოვან გუნდზე, რომელიც ავითარებდა Infrastructure-as-a-Service (IaaS) ვებ აპლიკაციას Citi-ს ღრუბლოვანი ინფრასტრუქტურის სამართავად, მაგრამ ყოველთვის მაინტერესებდა როგორ გავხადო განვითარების პროცესი უფრო ეფექტური და შემომეტანა პოზიტიური კულტურული ცვლილებები განვითარების გუნდი. პასუხი ვიპოვე წიგნში, რომელიც რეკომენდირებულია გრეგ ლავენდერის, CTO Cloud Architecture-ისა და ინფრასტრუქტურის Citi-ში. წიგნს ერქვა The Phoenix Project (ფენიქსის პროექტი), და ის განმარტავს DevOps-ის პრინციპებს, მაგრამ იკითხება რომანივით.

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

Amazon: 23 დღეში
Google: 5 დღეში
Netflix: 500 დღეში
Facebook: დღეში ერთხელ
Twitter: კვირაში 3-ჯერ
ტიპიური კომპანია: 9 თვეში ერთხელ

როგორ არის შესაძლებელი Amazon, Google და Netflix სიხშირეები? ეს იმიტომ ხდება, რომ ამ კომპანიებმა გაარკვიეს, თუ როგორ უნდა შექმნან თითქმის სრულყოფილი DevOps მილსადენი.

ჩვენ შორს ვიყავით ამისგან, სანამ არ განვახორციელეთ DevOps Citi-ში. მაშინ ჩემს გუნდს განსხვავებული გარემო ჰქონდა, მაგრამ განვითარების სერვერზე განლაგება სრულიად ხელით იყო. ყველა დეველოპერს ჰქონდა წვდომა მხოლოდ ერთ განვითარების სერვერზე, რომელიც დაფუძნებულია IBM WebSphere Application Server Community Edition-ზე. პრობლემა ის იყო, რომ სერვერი ითიშებოდა, როდესაც რამდენიმე მომხმარებელი ცდილობდა ერთდროულად განლაგებას, ამიტომ დეველოპერებს უწევდათ თავიანთი განზრახვების ერთმანეთთან კომუნიკაცია, რაც საკმაოდ მტკივნეული იყო. გარდა ამისა, იყო პრობლემები დაბალი დონის სატესტო კოდის დაფარვასთან, შრომატევადი ხელით განლაგების პროცესებთან და კონკრეტულ დავალებასთან ან მომხმარებლის ისტორიასთან დაკავშირებული კოდის განლაგების თვალყურის დევნების შეუძლებლობასთან.

მივხვდი, რომ რაღაცის გაკეთება იყო საჭირო და თანამოაზრე კოლეგა ვიპოვე. ჩვენ გადავწყვიტეთ ვითანამშრომლოთ DevOps-ის საწყისი მილსადენის მშენებლობაზე - მან შექმნა Tomcat ვირტუალური მანქანა და აპლიკაციის სერვერი, სანამ მე ვმუშაობდი Jenkins-ზე, გავაერთიანე Atlassian Jira და BitBucket და ვმუშაობდი სატესტო კოდის გაშუქებაზე. ეს გვერდითი პროექტი იყო ძალიან წარმატებული: ჩვენ თითქმის მთლიანად მოვახდინეთ მრავალი პროცესის ავტომატიზაცია, მივაღწიეთ თითქმის 100% ფუნქციონირებას ჩვენს დეველოპერულ სერვერზე, უზრუნველყოფილი იყო თვალყურის დევნება და კოდის გაუმჯობესებული ტესტის გაშუქება და დავამატეთ Git ფილიალების Jira-ს საკითხებთან ან განლაგებასთან დაკავშირების შესაძლებლობა. ინსტრუმენტების უმეტესობა, რომლებიც ჩვენ ვიყენებდით ჩვენი DevOps მილსადენის ასაშენებლად, იყო ღია წყარო.

ახლა მე მესმის, რამდენად მარტივი იყო ჩვენი DevOps მილსადენი: ჩვენ არ ვიყენებდით გაფართოებებს, როგორიცაა Jenkins ფაილები ან Ansible. თუმცა, ეს მარტივი მილსადენი კარგად მუშაობდა, ალბათ პარეტოს პრინციპის გამო (ასევე ცნობილი როგორც 80/20 წესი).

მოკლე შესავალი DevOps-სა და CI/CD მილსადენზე

თუ რამდენიმე ადამიანს ჰკითხავთ: „რა არის DevOps?“, ალბათ მიიღებთ რამდენიმე განსხვავებულ პასუხს. DevOps, ისევე როგორც Agile, განვითარდა და მოიცავს მრავალ სხვადასხვა დისციპლინას, მაგრამ ადამიანების უმეტესობა თანხმდება რამდენიმე საკითხზე: DevOps არის პროგრამული უზრუნველყოფის განვითარების პრაქტიკა ან პროგრამული უზრუნველყოფის განვითარების სასიცოცხლო ციკლი (SDLC), რომლის ცენტრალური პრინციპი ცვლის კულტურას, რომელშიც დეველოპერები და არა დეველოპერები არსებობენ ისეთ გარემოში, რომელშიც:

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

მართალია, სწორი პროგრამული ხელსაწყოების არსებობა არ არის ერთადერთი, რაც გჭირდებათ DevOps გარემოს შესაქმნელად, ზოგიერთი ინსტრუმენტი აუცილებელია. ძირითადი ინსტრუმენტი არის უწყვეტი ინტეგრაცია და უწყვეტი განლაგება (CI/CD). ამ მილსადენში, გარემოს აქვს სხვადასხვა ეტაპები (მაგ. DEV, INT, TST, QA, UAT, STG, PROD), ბევრი ოპერაცია ავტომატიზირებულია და დეველოპერებს შეუძლიათ დაწერონ მაღალი ხარისხის კოდი, მიაღწიონ განვითარების სისწრაფეს და განლაგების მაღალ სიჩქარეს.

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

ნაბიჯი 1: CI/CD მეთოდები

პირველი რაც გჭირდებათ არის CI/CD ინსტრუმენტი. Jenkins, Java-ზე დაფუძნებული ღია კოდის ინსტრუმენტი და ლიცენზირებული MIT ლიცენზიით, არის ინსტრუმენტი, რომელმაც პოპულარიზაცია გაუწია DevOps-ს და გახდა დე ფაქტო სტანდარტი.

მაშ რა არის ჯენკინსი? წარმოიდგინეთ, რომ ეს არის ერთგვარი ჯადოსნური უნივერსალური დისტანციური მართვა, რომელსაც შეუძლია ისაუბროს და მოაწყოს სხვადასხვა სერვისები და ინსტრუმენტები. თავისთავად, ჯენკინსის მსგავსი CI/CD ინსტრუმენტი გამოუსადეგარია, მაგრამ ის უფრო მძლავრი ხდება სხვადასხვა ინსტრუმენტებთან და სერვისებთან დაკავშირებისას.

Jenkins არის მხოლოდ ერთი ღია კოდის CI/CD ხელსაწყოებიდან, რომელიც შეგიძლიათ გამოიყენოთ თქვენი DevOps მილსადენის შესაქმნელად.

ჯენკინსი: Creative Commons და MIT
ტრევის CI: MIT
კრუიზკონტროლი: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
კაბინა: GNU

აი, როგორ გამოიყურება DevOps პროცესები CI/CD ხელსაწყოთი:

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

ნაბიჯი 2: მართეთ წყაროს კონტროლის სისტემები

საუკეთესო (და ალბათ უმარტივესი) გზა იმის დასადასტურებლად, რომ თქვენს CI/CD ხელსაწყოს შეუძლია თავისი ჯადოსნური მოქმედება, არის ინტეგრირება წყაროს კოდის კონტროლის (SCM) ინსტრუმენტთან. რატომ გჭირდებათ წყაროს კონტროლი? ვთქვათ, თქვენ ავითარებთ აპლიკაციას. როდესაც თქვენ ქმნით აპლიკაციას, თქვენ პროგრამირებთ და არ აქვს მნიშვნელობა იყენებთ Java, Python, C++, Go, Ruby, JavaScript, თუ მილიონობით პროგრამირების ენას. თქვენს მიერ დაწერილი კოდი ეწოდება წყაროს კოდს. დასაწყისში, განსაკუთრებით მაშინ, როცა მარტო მუშაობთ, ალბათ კარგია ყველაფრის ადგილობრივ დირექტორიაში ჩასმა. მაგრამ რამდენადაც პროექტი ფართოვდება და თქვენ იწვევთ სხვა ადამიანებს თანამშრომლობისთვის, თქვენ გჭირდებათ გზა, რათა თავიდან აიცილოთ კონფლიქტები და ეფექტურად გააზიაროთ ცვლილებები. თქვენ ასევე გჭირდებათ წინა ვერსიების აღდგენის გზა, რადგან სარეზერვო ასლების შექმნა და მათში კოპირება/ჩასმა მოძველებულია. თქვენ (და თქვენს თანაგუნდელებს) გჭირდებათ რაღაც უკეთესი.

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

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

Git: GPLv2 და LGPL v2.1
დივერსია: Apache 2.0
კონკურენტული ვერსიების სისტემა (CVS): GNU
ვესტა: LGPL
Mercurial: GNU GPL v2+

ასე გამოიყურება DevOps მილსადენი წყაროს კოდის კონტროლის დამატებით.

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

ნაბიჯი 3: შექმენით Build Automation Tool

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

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

სახელი
ლიცენზია
Პროგრამირების ენა

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

სამრეკლო
Apache 2.0
Java

ბაზელი
Apache 2.0
Java

გააკეთოს
GNU
N / A

გრანტი
MIT
JavaScript

გულფრთიანი
MIT
JavaScript

აღმაშენებელი
Apache
Ruby

რაკი
MIT
Ruby

AAP
GNU
Python

სკონები
MIT
Python

BitBake
GPLv2
Python

ნამცხვარი
MIT
C#

ASDF
ექსპატრი (MIT)
ტუჩის

ზუსტი
BSD
ჰასკეელი

დიდი! თქვენ შეგიძლიათ განათავსოთ Build ავტომატიზაციის ხელსაწყოს კონფიგურაციის ფაილები თქვენს წყაროს მართვის სისტემაში და მიეცით საშუალება თქვენს CI/CD ხელსაწყოს შეაერთოს ყველაფერი.

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

ნაბიჯი 4: ვებ აპლიკაციის სერვერი

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

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

არსებობს რამდენიმე ღია კოდის ვებ აპლიკაციის სერვერი.

სახელი
ლიცენზია
Პროგრამირების ენა

Tomcat
Apache 2.0
Java

გზიდან
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

მინის თევზი
CDDL & GNU ნაკლებად საჯარო
Java

Django
3-პუნქტი BSD
Python

Tornado
Apache 2.0
Python

გუნიკორნი
MIT
Python

Python
MIT
Python

რელსები
MIT
Ruby

Node.js
MIT
Javascript

თქვენი DevOps მილსადენი თითქმის მზად არის გამოსაყენებლად. Ყოჩაღ!

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

ნაბიჯი 5: კოდის ტესტირების გაშუქება

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

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

კოდების ტესტირების სისტემები

სახელი
ლიცენზია
Პროგრამირების ენა

JUnit
Eclipse საზოგადოებრივი ლიცენზია
Java

EasyMock
Apache
Java

მოკიტო
MIT
Java

PowerMock
Apache 2.0
Java

პითესტი
MIT
Python

ჰიპოთეზა
Mozilla
Python

ტოქს
MIT
Python

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

სახელი
ლიცენზია
Პროგრამირების ენა

დაფარვის
GNU
Java

CodeCover
Eclipse Public (EPL)
Java

გაშუქება.py
Apache 2.0
Python

Emma
საერთო საჯარო ლიცენზია
Java

JaCoCo
Eclipse საზოგადოებრივი ლიცენზია
Java

ჰიპოთეზა
Mozilla
Python

ტოქს
MIT
Python

Jasmine
MIT
JavaScript

კარმა
MIT
JavaScript

Mocha
MIT
JavaScript

არ არის
MIT
JavaScript

გაითვალისწინეთ, რომ ზემოთ ნახსენები ხელსაწყოებისა და ჩარჩოების უმეტესობა დაწერილია Java, Python და JavaScript-ისთვის, რადგან C++ და C# არის საკუთრების პროგრამირების ენები (თუმცა GCC არის ღია წყარო).

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

დამატებითი ნაბიჯები

კონტეინერები

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

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

მიუხედავად იმისა, რომ არსებობს სხვა კონტეინერის ვარიანტები, ყველაზე პოპულარულია Docker და Kubernetes.

დოკერი: Apache 2.0
Kubernetes: Apache 2.0

შუალედური ავტომატიზაციის ხელსაწყოები

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

აქ არის რამოდენიმე ღია წყაროს შუალედური ავტომატიზაციის ინსტრუმენტი:

პასუხი: GNU Public
SaltStack: Apache 2.0
შეფ: Apache 2.0
თოჯინა: Apache ან GPL

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

• DevOps კურსი (12 თვე)

მეტი კურსები

• მანქანათმცოდნეობის კურსი (12 კვირა)
• მონაცემთა მეცნიერების პროფესიის სწავლება ნულიდან (12 თვე)
• ანალიტიკოსის პროფესია ნებისმიერი საწყისი დონის (9 თვე)
• Python ვებ განვითარების კურსი (9 თვე)

სასარგებლო

• 450 უფასო აივი ლიგის კურსი
• ტენდენციები მონაცემთა მეცნიერებაში 2020
• მონაცემთა მეცნიერება მკვდარია. გაუმარჯოს ბიზნეს მეცნიერებას
• მონაცემთა მეცნიერება სტეროიდებზე: შესავალი გადაწყვეტილების დაზვერვაში
• ყველაზე წარმატებული და ყველაზე სკანდალური მონაცემთა მეცნიერების პროექტი: Cambridge Analytica

წყარო: www.habr.com