Əgər siz DevOps-da yenisinizsə, ilk boru kəmərinizi yaratmaq üçün bu beş addımlı bələdçiyə nəzər salın.
DevOps yavaş, bir-birindən ayrılmış və ya pozulmuş proqram təminatı inkişaf proseslərinin düzəltmək üçün standart həll yolu olmuşdur. Problem ondadır ki, əgər siz DevOps-da yenisinizsə və haradan başlayacağınızı bilmirsinizsə, bu üsulları başa düşə bilməzsiniz. Bu məqalə DevOps boru kəmərinin tərifini müzakirə edəcək və onu yaratmaq üçün beş addımlı təlimatlar verəcəkdir. Bu dərslik tam olmasa da, gələcəkdə səyahətinizə başlamaq və biliklərinizi genişləndirmək üçün sizə əsas verməlidir. Ancaq tarixdən başlayaq.
Mənim DevOps səyahətim
Mən əvvəllər Citi-nin bulud infrastrukturunu idarə etmək üçün İnfrastructure- as-a-Service (IaaS) veb tətbiqini inkişaf etdirən Citi Group bulud komandasında işləmişəm, lakin məni həmişə inkişaf prosesini necə daha səmərəli etmək və sosial şəbəkəyə müsbət mədəni dəyişiklik gətirmək maraqlandırırdı. inkişaf komandası. Cavabı Citi-nin Bulud Memarlığı və İnfrastrukturunun CTO-su Greg Lavender tərəfindən tövsiyə olunan kitabda tapdım. Kitab The Phoenix Project adlanırdı () və DevOps-un prinsiplərini izah edir, lakin roman kimi oxunur.
Kitabın arxasındakı cədvəl müxtəlif şirkətlərin sistemlərini buraxılış mühitində nə qədər tez-tez yerləşdirdiklərini göstərir:
Amazon: gündə 23
Google: gündə 5
Netflix: gündə 500
Facebook: Gündə bir dəfə
Twitter: həftədə 3 dəfə
Tipik şirkət: 9 ayda bir
Amazon, Google və Netflix tezlikləri necə mümkündür? Bunun səbəbi, bu şirkətlərin demək olar ki, mükəmməl DevOps boru kəmərini necə yaratmağı tapmasıdır.
Citi-də DevOps tətbiq edənə qədər bundan çox uzaq idik. O vaxtlar komandam fərqli mühitlərə malik idi, lakin inkişaf serverində yerləşdirmə tamamilə əl ilə idi. Bütün tərtibatçıların IBM WebSphere Application Server Community Edition əsasında yalnız bir inkişaf serverinə çıxışı var idi. Problem onda idi ki, birdən çox istifadəçi eyni anda yerləşdirməyə cəhd etdikdə server bağlanırdı, ona görə də tərtibatçılar öz niyyətlərini bir-birinə bildirməli oldular, bu, olduqca ağrılı idi. Bundan əlavə, aşağı səviyyəli test kodu əhatə dairəsi, əl ilə yerləşdirmənin çətin prosesləri və xüsusi tapşırıq və ya istifadəçi hekayəsi ilə əlaqəli kodun yerləşdirilməsini izləmək mümkünsüzlüyü ilə bağlı problemlər var idi.
Nəsə etmək lazım olduğunu başa düşdüm və həmfikir həmkar tapdım. Biz ilkin DevOps boru kəmərinin qurulmasında əməkdaşlıq etmək qərarına gəldik - mən Jenkins üzərində işləyərkən, Atlassian Jira və BitBucket-i birləşdirərkən və test kodu əhatə dairəsində işləyərkən o, Tomcat virtual maşını və proqram serveri qurdu. Bu yan layihə çox uğurlu oldu: biz bir çox prosesləri demək olar ki, tamamilə avtomatlaşdırdıq, inkişaf serverimizdə demək olar ki, 100% işləmə müddətinə nail olduq, kodun izlənilməsini və təkmilləşdirilmiş test əhatəsini təmin etdik və Git filiallarını Jira problemləri və ya yerləşdirmələri ilə əlaqələndirmək imkanı əlavə etdik. DevOps boru kəmərimizi qurmaq üçün istifadə etdiyimiz alətlərin əksəriyyəti açıq mənbə idi.
İndi başa düşürəm ki, bizim DevOps boru kəmərimiz nə qədər sadə idi: biz Jenkins faylları və ya Ansible kimi uzantılardan istifadə etməmişik. Bununla belə, bu sadə boru kəməri bəlkə də Pareto prinsipi (80/20 qaydası kimi də tanınır) sayəsində yaxşı işləyirdi.
DevOps və CI/CD Boru Kəmərinə Qısa Giriş
Bir neçə nəfərdən “DevOps nədir?” deyə soruşsanız, yəqin ki, bir neçə fərqli cavab alacaqsınız. Agile kimi DevOps da bir çox fərqli fənləri əhatə etmək üçün təkamül etdi, lakin insanların çoxu bir neçə şeydə razılaşacaqlar: DevOps proqram təminatının inkişaf etdirilməsi təcrübəsi və ya proqram təminatının inkişaf etdirilməsinin həyat dövrüdür (SDLC) və onun mərkəzi prinsipi tərtibatçıların və olmayanların mədəniyyətini dəyişdirir. Tərtibatçılar aşağıdakı mühitdə mövcuddur:
Əvvəllər əl ilə yerinə yetirilən əməliyyatlar avtomatlaşdırılıb;
Hər kəs ən yaxşısını edir;
Müəyyən bir müddət ərzində tətbiqlərin sayı artır; Məhsuldarlıq artır;
İnkişaf çevikliyinin artması.
Düzgün proqram vasitələrinə sahib olmaq DevOps mühiti yaratmaq üçün lazım olan tək şey olmasa da, bəzi alətlər vacibdir. Əsas alət davamlı inteqrasiya və davamlı yerləşdirmədir (CI/CD). Bu boru kəmərində mühitlərin müxtəlif mərhələləri var (məsələn, DEV, INT, TST, QA, UAT, STG, PROD), bir çox əməliyyatlar avtomatlaşdırılıb və tərtibatçılar yüksək keyfiyyətli kod yaza, inkişaf çevikliyinə və yüksək yerləşdirmə dərəcələrinə nail ola bilərlər.
Bu məqalə açıq mənbə alətlərindən istifadə edərək aşağıdakı diaqramda göstərilən kimi DevOps boru kəməri yaratmaq üçün beş addımlı yanaşmanı təsvir edir.
Addım 1: CI/CD Metodları
Sizə lazım olan ilk şey CI/CD alətidir. Java-ya əsaslanan və MIT lisenziyası ilə lisenziyalı açıq mənbə aləti olan Jenkins DevOps-u populyarlaşdıran və faktiki standarta çevrilən vasitədir.
Beləliklə, Jenkins nədir? Bunu müxtəlif xidmətlər və alətlərlə danışa və təşkil edə bilən bir növ sehrli universal pult kimi düşünün. Özlüyündə Jenkins kimi CI/CD aləti faydasızdır, lakin müxtəlif alətlərə və xidmətlərə qoşulduqca daha güclü olur.
Jenkins, DevOps boru kəmərinizi qurmaq üçün istifadə edə biləcəyiniz bir çox açıq mənbəli CI/CD alətlərindən yalnız biridir.
Jenkins: Creative Commons və MIT
Travis CI: MIT
Cruise Control: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
DevOps prosesləri CI/CD aləti ilə belə görünür:
Localhost-da işləyən CI/CD alətiniz var, lakin hazırda edə biləcəyiniz çox şey yoxdur. Gəlin DevOps səyahətinin növbəti mərhələsinə keçək.
Addım 2: Mənbəyə Nəzarət Sistemlərini idarə edin
CI/CD alətinizin öz sehrini edə biləcəyini yoxlamağın ən yaxşı (və bəlkə də ən asan) yolu mənbə koduna nəzarət (SCM) aləti ilə inteqrasiya etməkdir. Niyə mənbə nəzarətinə ehtiyacınız var? Tutaq ki, siz proqram hazırlayırsız. Hər dəfə bir proqram yaratdığınız zaman proqramlaşdırırsınız və Java, Python, C++, Go, Ruby, JavaScript və ya milyonlarla proqramlaşdırma dillərindən hər hansı birini istifadə etməyiniz fərq etmir. Yazdığınız kod mənbə kodu adlanır. Başlanğıcda, xüsusən tək işlədiyiniz zaman hər şeyi yerli kataloqa yerləşdirmək çox güman ki, yaxşıdır. Lakin layihə böyüdükcə və siz digər insanları əməkdaşlığa dəvət etdikcə, dəyişiklikləri effektiv şəkildə paylaşarkən münaqişələrin qarşısını almaq üçün bir yola ehtiyacınız var. Siz həmçinin əvvəlki versiyaları bərpa etmək üçün bir yola ehtiyacınız var, çünki ehtiyat nüsxələrin yaradılması və onlara kopyalama/yapışdırmaq köhnəlməkdədir. Sizə (və komanda yoldaşlarınıza) daha yaxşı bir şey lazımdır.
Burada mənbə koduna nəzarət demək olar ki, zərurətə çevrilir. Bu alət kodunuzu depolarda saxlayır, versiyaları izləyir və layihə iştirakçılarının işini əlaqələndirir.
Orada bir çox mənbəyə nəzarət alətləri olsa da, Git standartdır və haqlı olaraq belədir. İstəyirsinizsə, başqa açıq mənbə seçimləri olsa da, Git-dən istifadə etməyi tövsiyə edirəm.
Git: GPLv2 və LGPL v2.1
Təxribat: Apache 2.0
Concurrent Versions System (CVS): GNU
Vəsta: LGPL
Mercurial: GNU GPL v2+
Mənbə kodu nəzarətlərinin əlavə edilməsi ilə DevOps boru kəməri belə görünür.
CI/CD aləti nəzərdən keçirmə, mənbə kodu əldə etmə və üzvlər arasında əməkdaşlıq proseslərini avtomatlaşdıra bilər. Pis deyil? Bəs onu necə işlək tətbiqə çevirmək olar ki, milyardlarla insan ondan istifadə edə və qiymətləndirə bilsin?
Addım 3: Quraşdırma Avtomatlaşdırma Aləti yaradın
Əla! Siz kodu nəzərdən keçirə və mənbə nəzarətində dəyişiklik edə və dostlarınızı inkişaf üzərində əməkdaşlığa dəvət edə bilərsiniz. Amma siz hələ proqram yaratmamısınız. Veb tətbiqi yaratmaq üçün o, yerləşdirilə bilən toplu formatda tərtib edilməli və qablaşdırılmalı və ya icra edilə bilən fayl kimi işlədilməlidir. (Qeyd edək ki, JavaScript və ya PHP kimi tərcümə edilmiş proqramlaşdırma dilinin tərtib edilməsinə ehtiyac yoxdur).
Quraşdırma avtomatlaşdırma alətindən istifadə edin. Hansı qurma avtomatlaşdırma alətindən istifadə etməyi qərara almağınızdan asılı olmayaraq, onların hamısının məqsədi eynidir: mənbə kodunu istənilən formatda qurmaq və təmizləmə, tərtib etmək, sınaqdan keçirmək və xüsusi mühitə yerləşdirmək vəzifəsini avtomatlaşdırın. Quraşdırma alətləri proqramlaşdırma dilinizdən asılı olaraq dəyişəcək, lakin burada bəzi ümumi açıq mənbə seçimləri var.
Ad
Lisenziya
Proqramlaşdırma dili
Maven
Apache 2.0
Java
Qarışqa
Apache 2.0
Java
Gradle
Apache 2.0
Java
Bazel
Apache 2.0
Java
etmək
GNU
N / A
Qışqırıq
MİT
JavaScript
Qucaqlamaq
MİT
JavaScript
İnşaatçı
Apache
yaqut
Rake
MİT
yaqut
AAP
GNU
Python
Qaşlar
MİT
Python
BitBake
GPLv2
Python
tort
MİT
C#
ASDF
Expat (MIT)
LISP
siyasi çağırış
BSD
Haskell
Əla! Quraşdırma avtomatlaşdırma alətinin konfiqurasiya fayllarını mənbə idarəetmə sisteminizə yerləşdirə və CI/CD alətinizin hər şeyi bir araya gətirməsinə icazə verə bilərsiniz.
Hər şey yaxşıdır, elə deyilmi? Bəs tətbiqinizi harada yerləşdirmək olar?
Addım 4: Veb Tətbiq Serveri
Hal-hazırda, icra edilə bilən və ya quraşdırıla bilən paketlənmiş faylınız var. Hər hansı bir tətbiqin həqiqətən faydalı olması üçün o, bir növ xidmət və ya interfeys təqdim etməlidir, lakin tətbiqinizi yerləşdirmək üçün konteynerə ehtiyacınız var.
Veb proqram serveri məhz belə bir konteynerdir. Server yerləşdirilən paketin məntiqinin müəyyən edilə biləcəyi bir mühit təmin edir. Server həmçinin interfeys təqdim edir və rozetkaları xarici dünyaya təqdim etməklə veb xidmətləri təklif edir. Onu quraşdırmaq üçün sizə HTTP serveri, həmçinin bəzi mühit (virtual maşın kimi) lazımdır. Hələlik, fərz edək ki, siz bu barədə daha çox məlumat əldə edəcəksiniz (baxmayaraq ki, aşağıda konteynerləri əhatə edəcəyəm).
Bir neçə açıq mənbəli veb proqram serverləri var.
Ad
Lisenziya
Proqramlaşdırma dili
Tomcat
Apache 2.0
Java
Jetty
Apache 2.0
Java
WildFly
GNU Lesser Public
Java
ŞüşəFish
CDDL və GNU Az İctimai
Java
Django
3-bənd BSD
Python
Qasırğa
Apache 2.0
Python
Gunikorn
MİT
Python
Python
MİT
Python
Rels
MİT
yaqut
Node.js
MİT
Javascript
DevOps boru kəməriniz demək olar ki, istifadəyə hazırdır. Yaxşı iş!
Orada dayanıb inteqrasiyanı özünüz idarə edə bilsəniz də, kodun keyfiyyəti proqram tərtibatçısının narahat olması üçün vacib bir şeydir.
Addım 5: Kod Testi Əhatəsi
Testlərin həyata keçirilməsi başqa bir çətin tələb ola bilər, lakin tərtibatçılar proqramdakı hər hansı səhvləri erkən tutmalı və son istifadəçilərin razı qalmasını təmin etmək üçün kodun keyfiyyətini artırmalıdırlar. Xoşbəxtlikdən, kodunuzu sınamaq və keyfiyyətini yaxşılaşdırmaq üçün tövsiyələr vermək üçün bir çox açıq mənbə alətləri var. Ən yaxşısı odur ki, əksər CI/CD alətləri bu alətlərə qoşula və prosesi avtomatlaşdıra bilər.
Kod testi iki hissədən ibarətdir: testləri yazmağa və icra etməyə kömək edən kod testi çərçivələri və kodun keyfiyyətini yaxşılaşdırmağa kömək edən təklif alətləri.
Kod test sistemləri
Ad
Lisenziya
Proqramlaşdırma dili
JUnit
Eclipse İctimai Lisenziya
Java
EasyMock
Apache
Java
Mokito
MİT
Java
PowerMock
Apache 2.0
Java
Pytest
MİT
Python
Fərziyyə
Mozilla
Python
Tox
MİT
Python
Kodun təkmilləşdirilməsi üçün tövsiyə sistemləri
Ad
Lisenziya
Proqramlaşdırma dili
Əhatə
GNU
Java
CodeCover
Eclipse Public (EPL)
Java
Əhatə dairəsi.py
Apache 2.0
Python
Emma
Ümumi İctimai Lisenziya
Java
JaCoCo
Eclipse İctimai Lisenziya
Java
Fərziyyə
Mozilla
Python
Tox
MİT
Python
jasmin
MİT
JavaScript
Karma
MİT
JavaScript
Mocha
MİT
JavaScript
var
MİT
JavaScript
Qeyd edək ki, yuxarıda qeyd olunan alətlər və çərçivələrin əksəriyyəti Java, Python və JavaScript üçün yazılmışdır, çünki C++ və C# özəl proqramlaşdırma dilləridir (baxmayaraq ki, GCC açıq mənbədir).
İndi sınaq əhatə dairəsi alətlərini tətbiq etdiyinizə görə, DevOps boru kəməriniz bu təlimatın əvvəlində göstərilən diaqrama bənzər görünməlidir.
Əlavə addımlar
Konteynerlər
Dediyim kimi, serverinizi virtual maşında və ya serverdə yerləşdirə bilərsiniz, lakin konteynerlər məşhur bir həlldir.
Konteynerlər nədir? Qısa izahat ondan ibarətdir ki, virtual maşına proqramın ölçüsündən çox böyük həcmdə əməliyyat sistemi yaddaşı lazımdır, konteynerə isə tətbiqi işə salmaq üçün yalnız bir neçə kitabxana və konfiqurasiya lazımdır. Aydındır ki, virtual maşın üçün hələ də vacib istifadələr var, lakin konteyner proqram serveri də daxil olmaqla bir proqramın yerləşdirilməsi üçün yüngül həll yoludur.
Digər konteyner variantları olsa da, ən populyarları Docker və Kubernetesdir.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Aralıq avtomatlaşdırma vasitələri
Bizim DevOps boru kəmərimiz ilk növbədə birgə proqramların yaradılması və yerləşdirilməsinə yönəlib, lakin DevOps alətləri ilə edilə bilən bir çox başqa şeylər var. Onlardan biri də orta proqram avtomatlaşdırma alətləri kimi tanınan İnfrastruktur kimi Kod (IaC) alətlərinin istifadəsidir. Bu alətlər ara proqram üçün quraşdırma, idarəetmə və digər tapşırıqları avtomatlaşdırmağa kömək edir. Beləliklə, məsələn, avtomatlaşdırma aləti düzgün konfiqurasiyaları olan veb proqram serveri, verilənlər bazası və monitorinq aləti kimi proqramları çıxara və onları proqram serverinə yerləşdirə bilər.
Burada bəzi açıq mənbəli orta proqram avtomatlaşdırma vasitələri var:
Ansible: GNU Public
SaltStack: Apache 2.0
Şef: Apache 2.0
Kukla: Apache və ya GPL
SkillFactory ödənişli onlayn kurslarını tamamlayaraq, sıfırdan və ya bacarıq və əmək haqqı baxımından axtarılan peşəni necə əldə etməyin təfərrüatlarını öyrənin:
- (12 ay)
daha çox kurslar
- (12 həftə)
- (12 ay)
- (9 ay)
- (9 ay)
Полезное
Mənbə: www.habr.com