Bir yanaşma IaC (Kod kimi infrastruktur) təkcə depoda saxlanılan koddan deyil, həm də bu kodu əhatə edən insanlardan və proseslərdən ibarətdir. Proqram təminatının hazırlanmasından infrastrukturun idarə edilməsinə və təsvirinə qədər yanaşmalardan təkrar istifadə etmək mümkündürmü? Məqaləni oxuyarkən bu fikri yadda saxlamaq yaxşı olardı.

English version

Bu mənim transkriptdir Göstəriləcək tamaşalar haqqında DevopsConf 2019.

Slaydlar və videolar

• English version
• Rus versiyası
• Quru qaçış 2019-04-24 SpbLUG
• Video(RU) DevopsConf-dan 2019-05-28
• 2019-06-20 DINS DevOps EVENING-dən video(RU).
• Slaydlar

İnfrastruktur bash tarixi kimi

Tutaq ki, yeni bir layihəyə gəldiniz və onlar sizə deyirlər: “Bizdə var Kod kimi infrastruktur". Reallıqda belə çıxır İnfrastruktur bash tarixi kimi və ya məsələn Sənədlər bash tarixi kimi. Bu, çox real vəziyyətdir, məsələn, oxşar hadisəni Denis Lısenko çıxışında təsvir edib Bütün infrastrukturu necə əvəz etmək və dinc yatmağa başlamaq olar, o, bash tarixindən layihə üçün əlaqəli infrastrukturu necə əldə etdiklərini söylədi.

Bir az istəklə bunu deyə bilərik İnfrastruktur bash tarixi kimi bu kod kimidir:

1. reproduktivlik: Siz bash tarixçəsini götürə, oradan əmrləri işlədə bilərsiniz və yeri gəlmişkən, çıxış kimi işləyən konfiqurasiya əldə edə bilərsiniz.
2. versiyalaşdırma: kimin gəldiyini və nə etdiklərini bilirsiniz, yenə də bunun sizi çıxışda işləyən konfiqurasiyaya aparacağı fakt deyil.
3. история: kimin nə etdiyini hekayəsi. yalnız serveri itirsəniz ondan istifadə edə bilməyəcəksiniz.

Nə etmək?

Kod kimi infrastruktur

Hətta belə qəribə bir hal İnfrastruktur bash tarixi kimi qulaqlarından çəkə bilərsiniz Kod kimi infrastruktur, lakin biz köhnə yaxşı LAMP serverindən daha mürəkkəb bir şey etmək istədikdə, bu kodun bir şəkildə dəyişdirilməsi, dəyişdirilməsi, təkmilləşdirilməsi lazım olduğu qənaətinə gələcəyik. Daha sonra aralarındakı paralelləri nəzərdən keçirmək istərdik Kod kimi infrastruktur və proqram təminatının inkişafı.

QURU

Saxlama sisteminin inkişafı layihəsində bir alt tapşırıq var idi vaxtaşırı SDS-i konfiqurasiya edin: biz yeni buraxılışı buraxırıq - onu əlavə sınaq üçün yaymaq lazımdır. Tapşırıq çox sadədir:

• ssh vasitəsilə buraya daxil olun və əmri yerinə yetirin.
• faylı oraya köçürün.
• burada konfiqurasiyanı düzəldin.
• orada xidmətə başlayın
• ...
• PROFIT!

Təsvir edilən məntiq üçün bash kifayətdir, xüsusən layihənin ilkin mərhələlərində, yeni başlayanda. Bu bash istifadə etməyiniz pis deyil, lakin zaman keçdikcə oxşar, lakin bir qədər fərqli bir şey yerləşdirmək üçün sorğular var. Ağla gələn ilk şey kopyala-yapışdırmaqdır. İndi isə demək olar ki, eyni işi görən iki çox oxşar skriptimiz var. Zaman keçdikcə skriptlərin sayı artdı və biz fərqli skriptlər arasında sinxronizasiya edilməli olan bir quraşdırma yerləşdirmək üçün müəyyən bir iş məntiqinin olması ilə qarşılaşdıq, bu olduqca mürəkkəbdir.

Belə çıxır ki, DRY (Özünüzü Təkrar Etməyin) kimi bir təcrübə var. İdeya mövcud kodu yenidən istifadə etməkdir. Bu sadə səslənir, amma biz buna dərhal gəlmədik. Bizim vəziyyətimizdə bu banal bir fikir idi: konfiqurasiyaları skriptlərdən ayırmaq. Bunlar. quraşdırmanın ayrıca, konfiqurasiyaların ayrıca yerləşdirilməsinin biznes məntiqi.

CFM üçün SOLID

Zamanla layihə böyüdü və təbii davamı Ansible'in meydana çıxması idi. Görünüşünün əsas səbəbi komandada təcrübənin olması və bashın mürəkkəb məntiq üçün nəzərdə tutulmamasıdır. Ansible də mürəkkəb məntiqi ehtiva etməyə başladı. Mürəkkəb məntiqin xaosa çevrilməsinin qarşısını almaq üçün proqram təminatının hazırlanmasında kodun təşkili prinsipləri mövcuddur MƏKTƏK Həmçinin, məsələn, Qriqori Petrov “İT mütəxəssisinə nə üçün şəxsi brend lazımdır” adlı hesabatında insan elə qurulub ki, onun bəzi sosial qurumlarla işləməsi daha asan olsun. obyektlərdir. Bu iki fikri birləşdirsək və onları inkişaf etdirməyə davam etsək, biz də istifadə edə biləcəyimizi görəcəyik MƏKTƏK gələcəkdə bu məntiqin saxlanmasını və dəyişdirilməsini asanlaşdırmaq üçün.

Vahid Məsuliyyət Prinsipi

Hər sinif yalnız bir tapşırığı yerinə yetirir.

Kodu qarışdırmağa və monolit ilahi spagetti canavarları etməyə ehtiyac yoxdur. İnfrastruktur sadə kərpicdən ibarət olmalıdır. Belə çıxır ki, Ansible oyun kitabını kiçik parçalara ayırsanız, Ansible rollarını oxusanız, onlara qulluq etmək daha asandır.

Açıq Qapalı Prinsip

Açıq/qapalı prinsip.

• Genişləndirməyə açıq: müəssisənin davranışının yeni qurum növləri yaratmaqla genişləndirilə biləcəyini bildirir.
• Dəyişikliyə qapalı: Müəssisənin davranışının genişləndirilməsi nəticəsində həmin obyektlərdən istifadə edən kodda heç bir dəyişiklik edilməməlidir.

Əvvəlcə biz sınaq infrastrukturunu virtual maşınlarda yerləşdirdik, lakin yerləşdirmənin biznes məntiqi icradan ayrı olduğuna görə heç bir problem olmadan baremetall-a yayma əlavə etdik.

Liskov əvəzetmə prinsipi

Barbara Liskovun əvəzetmə prinsipi. proqramdakı obyektlər proqramın düzgün icrasını dəyişdirmədən onların alt tiplərinin nümunələri ilə əvəz edilməlidir.

Daha geniş baxsanız, bu, hansısa konkret layihənin xüsusiyyəti deyil ki, orada tətbiq olunsun MƏKTƏK, ümumiyyətlə CFM haqqındadır, məsələn, başqa bir layihədə müxtəlif Java, proqram serverləri, verilənlər bazaları, ƏS və s. Bu nümunədən istifadə edərək əlavə prinsipləri nəzərdən keçirəcəyəm MƏKTƏK

Bizim vəziyyətimizdə, infrastruktur komandası daxilində razılıq var ki, əgər biz imbjava və ya oraclejava rolunu quraşdırmışıqsa, o zaman bizdə Java binar icra edilə bilən var. Bu lazımdır, çünki Upstream rolları bu davranışdan asılıdır; onlar java gözləyirlər. Eyni zamanda, bu, tətbiqin yerləşdirilməsi məntiqini dəyişmədən bir java tətbiqini/versiyasını digəri ilə əvəz etməyə imkan verir.

Burada problem ondadır ki, bunu Ansible-da həyata keçirmək mümkün deyil, nəticədə komanda daxilində bəzi razılaşmalar yaranır.

İnterfeys Seqreqasiya Prinsipi

İnterfeys ayırma prinsipi: “Bir çox müştəriyə xas interfeyslər bir ümumi təyinatlı interfeysdən daha yaxşıdır.

Əvvəlcə biz proqramların yerləşdirilməsinin bütün dəyişkənliyini bir Ansible oyun kitabına yerləşdirməyə çalışdıq, lakin bunu dəstəkləmək çətin idi və xarici interfeys göstərildikdə (müştəri 443 portunu gözləyir), o zaman infrastruktur fərdi olaraq yığıla bilər. müəyyən bir icra üçün kərpic.

Asılılığın inversiya prinsipi

Asılılığın inversiya prinsipi. Daha yüksək səviyyələrdə olan modullar aşağı səviyyələrdəki modullardan asılı olmamalıdır. Hər iki modul növü abstraksiyalardan asılı olmalıdır. Abstraksiyalar detallardan asılı olmamalıdır. Detallar abstraksiyalardan asılı olmalıdır.

Burada nümunə bir antipattern əsasında qurulacaq.

1. Müştərilərdən birinin şəxsi buludu var idi.
2. Bulud daxilində virtual maşınlar sifariş etdik.
3. Lakin buludun təbiətinə görə, tətbiqin yerləşdirilməsi VM-nin aktiv olduğu hipervizora bağlı idi.

Bunlar. Yüksək səviyyəli tətbiq yerləşdirmə məntiqi asılılıqlarla hipervizorun aşağı səviyyələrinə axır və bu, bu məntiqdən təkrar istifadə zamanı problemlər demək idi. Bunu bu şəkildə etməyin.

Qarşılıqlı əlaqə

Kod kimi infrastruktur təkcə kod deyil, həm də kod və insanlar arasındakı əlaqə, infrastruktur tərtibatçıları arasında qarşılıqlı əlaqədir.

Avtobus amili

Tutaq ki, layihənizdə Vasya var. Vasya sizin infrastrukturunuz haqqında hər şeyi bilir, Vasya birdən yoxa çıxsa nə olacaq? Bu, çox real vəziyyətdir, çünki onu avtobus vura bilər. Bəzən olur. Əgər bu baş verərsə və kod, onun strukturu, necə işlədiyi, görünüşlər və parollar haqqında biliklər komanda arasında bölüşdürülməzsə, o zaman bir sıra xoşagəlməz hallarla qarşılaşa bilərsiniz. Bu riskləri minimuma endirmək və bilikləri komanda daxilində yaymaq üçün müxtəlif yanaşmalardan istifadə edə bilərsiniz

Cütləşmə

kimi deyil zarafat kimi, adminlərin pivə içdiyini, parolları dəyişdirdiyini və cüt proqramlaşdırmanın analoqu olduğunu. Bunlar. iki mühəndis bir kompüterdə, bir klaviaturada oturur və birlikdə infrastrukturunuzu qurmağa başlayır: server qurmaq, Ansible rolu yazmaq və s. Gözəl səslənir, amma bizim üçün işləmədi. Ancaq bu təcrübənin xüsusi halları işə yaradı. Yeni işçi gəldi, mentoru onunla birlikdə real bir vəzifə götürür, işləyir və bilik ötürür.

Başqa bir xüsusi hal insident çağırışıdır. Problem zamanı növbətçi və aidiyyəti şəxslərdən ibarət bir qrup toplanır, ekranını paylaşan və düşüncə qatarını səsləndirən bir rəhbər təyin olunur. Digər iştirakçılar liderin fikirlərini izləyir, konsoldan fəndlərə casusluq edir, jurnalda bir sətri qaçırmadıqlarını yoxlayır və sistem haqqında yeni şeylər öyrənirlər. Bu yanaşma çox vaxt işləmirdi.

Kod icmalı

Subyektiv olaraq, kodun nəzərdən keçirilməsindən istifadə edərək infrastruktur və onun necə işləməsi haqqında bilikləri yaymaq daha effektiv idi:

• İnfrastruktur depoda kodla təsvir olunur.
• Dəyişikliklər ayrı bir filialda baş verir.
• Birləşmə sorğusu zamanı siz infrastrukturdakı dəyişikliklərin deltasını görə bilərsiniz.

Burada diqqət çəkən məqam ondan ibarət idi ki, rəyçilər bir-bir, qrafikə uyğun seçilirdilər, yəni. müəyyən dərəcədə ehtimalla siz yeni bir infrastruktur parçasına dırmaşacaqsınız.

kod üslubu

Vaxt keçdikcə rəylər zamanı mübahisələr görünməyə başladı, çünki... rəyçilərin öz üslubu var idi və rəyçilərin fırlanması onları müxtəlif üslublarla birləşdirirdi: 2 boşluq və ya 4, camelCase və ya snake_case. Bunu dərhal həyata keçirmək mümkün deyildi.

• İlk fikir linterdən istifadə etməyi tövsiyə etmək idi, axı, hamı mühəndisdir, hamı ağıllıdır. Amma müxtəlif redaktorlar, OS, rahat deyil
• Bu, hər bir problemli öhdəçilik üçün boşluq yazan və linter çıxışını əlavə edən bir bota çevrildi. Lakin əksər hallarda görüləsi daha vacib işlər var idi və kod düzəldilməmiş qalırdı.

Yaşıl Quraşdırma Ustası

Vaxt keçir və biz belə qənaətə gəldik ki, müəyyən sınaqlardan keçməyən öhdəliklər ustaya buraxıla bilməz. Voila! Biz uzun müddət proqram təminatının hazırlanmasında tətbiq olunan Green Build Master-ı icad etdik:

• Ayrı bir filialda inkişaf gedir.
• Bu mövzuda testlər aparılır.
• Testlər uğursuz olarsa, kod master-a daxil olmayacaq.

Bu qərarı vermək çox ağrılı idi, çünki... çox mübahisələrə səbəb oldu, amma buna dəyərdi, çünki... Rəylər üslub fərqləri olmadan birləşmələr üçün müraciətlər almağa başladı və zaman keçdikcə problemli sahələrin sayı azalmağa başladı.

IaC Testi

Üslub yoxlanışına əlavə olaraq, başqa şeylərdən də istifadə edə bilərsiniz, məsələn, infrastrukturunuzun həqiqətən yerləşdirilə biləcəyini yoxlamaq üçün. Və ya yoxlayın ki, infrastrukturda dəyişikliklər pul itkisinə səbəb olmayacaq. Bu niyə lazım ola bilər? Sual mürəkkəb və fəlsəfidir, bir hekayə ilə cavab vermək daha yaxşıdır ki, Powershell-də sərhəd şərtlərini yoxlamayan avtomatik miqyaslayıcı var => lazım olduğundan daha çox VM yaradıldı => müştəri planlaşdırdığından daha çox pul xərclədi. Bu çox xoşagələn deyil, lakin bu səhvi əvvəlki mərhələlərdə tutmaq olduqca mümkün olardı.

Sual oluna bilər ki, niyə mürəkkəb infrastrukturu daha da mürəkkəbləşdirirsiniz? İnfrastruktur üçün testlər, kod üçün olduğu kimi, sadələşdirmə ilə bağlı deyil, infrastrukturunuzun necə işləməli olduğunu bilmək üçündür.

IaC Test Piramidası

IaC Testi: Statik Analiz

Bütün infrastrukturu bir anda yerləşdirsəniz və onun işlədiyini yoxlasanız, bunun çox vaxt apardığını və çox vaxt tələb etdiyini görə bilərsiniz. Ona görə də əsas elə bir şey olmalıdır ki, tez işləyir, çox var və bir çox primitiv yerləri əhatə edir.

Bash çətin

Önəmsiz bir misala baxaq. cari qovluqdakı bütün faylları seçin və başqa yerə köçürün. Ağla gələn ilk şey:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Fayl adında boşluq varsa nə etməli? Yaxşı, biz ağıllıyıq, sitatlardan necə istifadə edəcəyimizi bilirik:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Yaxşı etdiniz? Yox! Kataloqda heç bir şey yoxdursa, yəni. globbing işləməyəcək.

find . -type f -exec mv -v {} dst/{}.bak ;

Yaxşı oldu indi? Xeyr... Fayl adında nə ola biləcəyini unutmuşam n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Statik analiz alətləri

Əvvəlki addımdakı problem sitatları unutduqda tutula bilər, bunun üçün təbiətdə bir çox vasitə var. Shellcheck, ümumiyyətlə, onların çoxu var və çox güman ki, IDE-nin altında yığınınız üçün linter tapa bilərsiniz.

Dil
Alət

bash
Shellcheck

yaqut
RuboCop

python
Pilot

ansible
Ansible Lint

IaC Testi: Vahid Testləri

Əvvəlki nümunədən gördüyümüz kimi, linters hər şeyə qadir deyil və bütün problem sahələrini göstərə bilməz. Bundan əlavə, proqram təminatının işlənib hazırlanmasında sınaq ilə bənzətməklə, vahid testləri xatırlaya bilərik. Dərhal ağlına gələn budur şunut, yunit, rspec, pestest. Bəs ansible, chef, saltstack və digərləri ilə nə etmək lazımdır?

Əvvəlcədən danışdıq MƏKTƏK və infrastrukturumuz kiçik kərpiclərdən ibarət olmalıdır. Onların vaxtı gəldi.

1. İnfrastruktur kiçik kərpiclərə bölünür, məsələn, Ansible rolları.
2. Docker və ya VM olsun, bir növ mühit yerləşdirilir.
3. Ansible rolumuzu bu sınaq mühitinə tətbiq edirik.
4. Hər şeyin gözlədiyimiz kimi işlədiyini yoxlayırıq (testlər keçiririk).
5. Yaxşı ya yox qərar veririk.

IaC Testi: Vahid Test Alətləri

Sual, CFM üçün testlər nədir? Siz sadəcə skripti işlədə bilərsiniz və ya bunun üçün hazır həllərdən istifadə edə bilərsiniz:

CFM
Alət

Yoxdur
Testinfra

Chef
Qeyri-müəyyən

Chef
Serverspec

duz yığını
Goss

Testinfra üçün nümunə, istifadəçilərin yoxlanılması test1, test2 mövcuddur və qrup halındadırlar sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Nə seçmək lazımdır? Sual mürəkkəb və qeyri-müəyyəndir, 2018-2019-cu illər üçün github-da layihələrdəki dəyişikliklərə bir nümunə:

IaC Test çərçivələri

Sual yaranır: hamısını necə bir yerə yığmaq və işə salmaq olar? Bacarmaq götür və özünüz edin kifayət qədər sayda mühəndis varsa. Və ya hazır həllər qəbul edə bilərsiniz, baxmayaraq ki, onlardan çoxu yoxdur:

CFM
Alət

Yoxdur
Molekulyar

Chef
Test Mətbəxi

Terraform
Terratest

2018-2019-cu illər üçün github-da layihələrdəki dəyişikliklərə nümunə:

Molekul vs. Test mətbəxi

Əvvəlcə biz testkitchen istifadə etməyə çalışdı:

1. Paralel olaraq VM yaradın.
2. Ansible rollarını tətbiq edin.
3. Yoxlama aparın.

25-35 rol üçün 40-70 dəqiqə işləyirdi, bu da uzun idi.

Növbəti addım jenkins/docker/ansible/molekula keçid idi. İdioloji olaraq hər şey eynidir

1. Lint oyun kitabları.
2. Rolları sıralayın.
3. Konteyneri işə salın
4. Ansible rollarını tətbiq edin.
5. Testinfranı işə salın.
6. Qüsursuzluğu yoxlayın.

40 rol üçün linting və onlarla testlər təxminən 15 dəqiqə çəkməyə başladı.

Nə seçmək bir çox amillərdən asılıdır, məsələn, istifadə olunan yığın, komandadakı təcrübə və s. burada hər kəs Vahid test sualını necə bağlayacağına özü qərar verir

IaC Testi: İnteqrasiya Testləri

İnfrastruktur sınaq piramidasında növbəti addım inteqrasiya testləri olacaq. Onlar vahid testlərinə bənzəyir:

1. İnfrastruktur kiçik kərpiclərə bölünür, məsələn, Ansible rolları.
2. Docker və ya VM olsun, bir növ mühit yerləşdirilir.
3. Bu sınaq mühiti üçün müraciət edin çox Həssas rollar.
4. Hər şeyin gözlədiyimiz kimi işlədiyini yoxlayırıq (testlər keçiririk).
5. Yaxşı ya yox qərar veririk.

Kobud desək, biz vahid testlərdə olduğu kimi sistemin fərdi elementinin işini yoxlamırıq, serverin bütövlükdə necə konfiqurasiya olunduğunu yoxlayırıq.

IaC Testi: Başdan sona testlər

Piramidanın yuxarı hissəsində bizi Sondan Sona testlər qarşılayır. Bunlar. Ayrı bir serverin, ayrıca skriptin və ya infrastrukturumuzun ayrıca bir kərpicinin performansını yoxlamırıq. Bir çox serverin bir-birinə qoşulduğunu yoxlayırıq, infrastrukturumuz gözlədiyimiz kimi işləyir. Təəssüf ki, mən heç vaxt hazır qutulu həllər görməmişəm, yəqin ki... İnfrastruktur tez-tez unikaldır və şablonlaşdırmaq və sınaq üçün çərçivə yaratmaq çətindir. Nəticədə hər kəs öz həll yollarını yaradır. Tələb var, amma cavab yoxdur. Buna görə də, başqalarını sağlam düşüncələrə sövq etmək və ya burnumu sürtmək üçün hər şeyin bizdən çox əvvəl icad edildiyini söyləmək üçün sizə nə olduğunu söyləyəcəyəm.

Zəngin tarixə malik layihə. Böyük təşkilatlarda istifadə olunur və yəqin ki, hər birinizin onunla dolayı yolları kəsişib. Tətbiq bir çox verilənlər bazası, inteqrasiya və s. dəstəkləyir. İnfrastrukturun necə görünə biləcəyini bilmək çoxlu docker-kompozisiya faylları və hansı testlərin hansı mühitdə işlədiləcəyini bilməkdir.

Bu sxem, çərçivə daxilində olana qədər kifayət qədər uzun müddət işlədi araşdırma biz bunu Openshift-ə köçürməyə çalışmadıq. Konteynerlər eyni qalır, lakin işə salınma mühiti dəyişdi (yenidən salam DRY).

Tədqiqat ideyası daha da irəli getdi və openshift-də onlar infrastrukturu konteynerə necə yerləşdirmək barədə bilikləri toplamağa imkan verən APB (Ansible Playbook Bundle) kimi bir şey tapdılar. Bunlar. infrastrukturun necə yerləşdirilməsinə dair təkrarlana bilən, sınaqdan keçirilə bilən bilik nöqtəsi var.

Bütün bunlar heterojen bir infrastrukturla qarşılaşana qədər yaxşı səsləndi: testlər üçün bizə Windows lazım idi. Nəticə olaraq, nəyin, harada, necə yerləşdirilməsi və sınaqdan keçirilməsi haqqında biliklər jenkins-də olur.

Nəticə

Kod olduğu kimi infrastruktur

• Anbarda kod.
• İnsan qarşılıqlı əlaqəsi.
• İnfrastruktur sınaqları.

links

• English Version
• Şəxsi bloqdan çapraz yazı
• Quru qaçış 2019-04-24 SpbLUG
• Video(RU) DevopsConf-dan 2019-05-28
• 2019-06-20 DINS DevOps EVENING-dən video(RU).
• 300,000-dən çox İnfrastruktur Kodunun Yazılmasından Alınan Dərslər & mətn versiyası
• İnfrastrukturun Kod kimi Davamlı Çatdırılma Boru Kəmərinə inteqrasiyası
• İnfrastrukturun kod kimi sınaqdan keçirilməsi
• Ansible rollarının effektiv inkişafı və saxlanması
• Ansible bash deyil!

Mənbə: www.habr.com