Пристап IaC (Инфраструктура како код) не се состои само од кодот што е зачуван во складиштето, туку и од луѓето и процесите што го опкружуваат овој код. Дали е можно повторно да се користат пристапи од развој на софтвер до управување со инфраструктура и опис? Би било добра идеја да ја имате на ум оваа идеја додека ја читате статијата.

Ова е мој транскрипт настапи на DevopsConf 2019.

Слајдови и видеа

англиска верзија
Руска верзија
Суво трчање 2019-04-24 SpbLUG
Видео (RU) од DevopsConf 2019-05-28
Видео(RU) од DINS DevOps VENING 2019-06-20
Слајдови

Инфраструктурата како баш историја

Да претпоставиме дека доаѓате на нов проект, а тие ви велат: „имаме Инфраструктурата како код“. Во реалноста излегува Инфраструктурата како баш историја или на пример Документација како баш историја. Ова е многу реална ситуација, на пример, сличен случај опиша Денис Лисенко во говор Како да ја замените целата инфраструктура и да почнете здраво да спиете, раскажа како добиле кохерентна инфраструктура за проектот од баш историјата.

Со одредена желба, можеме да го кажеме тоа Инфраструктурата како баш историја ова е како код:

репродуктивност: Можете да земете баш историја, да ги извршите командите оттаму и можеби, патем, ќе добиете работна конфигурација како излез.
верзии: знаете кој влезе и што направи, повторно, не е факт дека тоа ќе ве доведе до работна конфигурација на излезот.
историја: приказната за тоа кој што направил. само што нема да можете да го користите ако го изгубите серверот.

Што да сторите?

Инфраструктурата како код

Дури и таков чуден случај како Инфраструктурата како баш историја можете да го повлечете за уши Инфраструктурата како код, но кога сакаме да направиме нешто покомплицирано од стариот добар LAMP сервер, ќе дојдеме до заклучок дека овој код треба некако да се измени, промени, подобри. Следно би сакале да ги разгледаме паралелите помеѓу Инфраструктурата како код и развој на софтвер.

СУВО

На проект за развој на систем за складирање, имаше подзадача периодично конфигурирајте SDS: издаваме ново издание - треба да се појави за понатамошно тестирање. Задачата е исклучително едноставна:

најавете се овде преку ssh и извршете ја командата.
копирајте ја датотеката таму.
поправете ја конфигурацијата овде.
започнете ја услугата таму
...
ПРОИЗВОД!

За опишаната логика, башот е повеќе од доволен, особено во раните фази на проектот, кога тој штотуку започнува. Ова не е лошо што користиш баш, но со текот на времето има барања да се распореди нешто слично, но малку поинакво. Првото нешто што ми паѓа на ум е copy-paste. И сега веќе имаме две многу слични скрипти кои го прават речиси истото. Со текот на времето, бројот на скрипти растеше и се соочивме со фактот дека постои одредена деловна логика за распоредување на инсталација која треба да се синхронизира помеѓу различни скрипти, ова е доста комплицирано.

Излегува дека постои таква практика како СУВО (Не се повторувај). Идејата е повторно да се искористи постоечкиот код. Звучи едноставно, но не дојдовме до ова веднаш. Во нашиот случај, тоа беше банална идеја: да се одделат конфигурациите од скриптите. Оние. деловна логика за тоа како инсталацијата се распоредува одделно, конфигурира одделно.

СОЛИД за CFM

Со текот на времето проектот растеше и природно продолжение беше појавата на Ансибл. Главната причина за нејзиниот изглед е тоа што има стручност во тимот и дека баш не е дизајниран за сложена логика. Ансибл исто така почна да содржи сложена логика. За да се спречи сложената логика да се претвори во хаос, постојат принципи на организација на кодот во развојот на софтверот ЦВРСТ Исто така, на пример, Григориј Петров во извештајот „Зошто на ИТ специјалист му треба личен бренд“ го постави прашањето дека лицето е дизајнирано на таков начин што му е полесно да работи со некои општествени субјекти, при развој на софтвер овие се предмети. Ако ги споиме овие две идеи и продолжиме да ги развиваме, ќе забележиме дека можеме и да користиме ЦВРСТ за да може полесно да се одржува и модифицира оваа логика во иднина.

Принципот на единствена одговорност

Секоја класа извршува само една задача.

Нема потреба да мешате код и да правите монолитни божествени чудовишта од шпагети. Инфраструктурата треба да се состои од едноставни тули. Излегува дека ако ја поделите Playbook на Ansible на мали парчиња, ги читате улогите на Ansible, тогаш тие се полесни за одржување.

Принципот на отворено затворено

Принцип на отворено/затворено.

Отворено за проширување: значи дека однесувањето на еден ентитет може да се прошири со создавање нови типови на ентитети.
Затворено за промени: Како резултат на проширување на однесувањето на ентитетот, не треба да се прават промени во кодот што ги користи тие ентитети.

Првично, ја распоредивме тест-инфраструктурата на виртуелни машини, но поради фактот што деловната логика на распоредување беше одвоена од имплементацијата, без никакви проблеми додадовме превртување во baremetall.

Принципот на замена на Лисков

Принципот на замена на Барбара Лисков. објектите во програмата мора да бидат заменливи со примероци од нивните подтипови без да се менува правилното извршување на програмата

Ако го погледнете пошироко, тоа не е карактеристика на некој конкретен проект што може да се примени таму ЦВРСТ, генерално се работи за CFM, на пример, на друг проект потребно е да се распореди кутирана Java апликација врз различни Java, сервери за апликации, бази на податоци, оперативен систем итн. Користејќи го овој пример, ќе разгледам понатамошни принципи ЦВРСТ

Во нашиот случај, постои договор во рамките на инфраструктурниот тим дека ако сме ја инсталирале улогата imbjava или oraclejava, тогаш имаме java бинарен извршна датотека. Ова е неопходно затоа што Улогите нагоре зависат од ова однесување, тие очекуваат java. Во исто време, ова ни овозможува да замениме една Java имплементација/верзија со друга без да ја менуваме логиката за распоредување на апликацијата.

Проблемот тука лежи во фактот што е невозможно да се спроведе ова во Ansible, како резултат на што се појавуваат некои договори во тимот.

Принципот на сегрегација на интерфејс

Принцип на раздвојување на интерфејс: „Многу интерфејси специфични за клиентот се подобри од еден интерфејс за општа намена.

Првично, се обидовме да ја ставиме целата варијабилност на распоредувањето на апликацијата во една Ansible Playbook, но беше тешко да се поддржи, а пристапот кога имаме надворешен интерфејс беше наведен (клиентот очекува порта 443), тогаш инфраструктурата може да се состави од индивидуални тули за специфична имплементација.

Принцип на инверзија на зависност

Принципот на инверзија на зависност. Модулите на повисоките нивоа не треба да зависат од модулите на пониските нивоа. Двата типа на модули мора да зависат од апстракции. Апстракциите не треба да зависат од детали. Деталите мора да зависат од апстракции.

Овде примерот ќе се заснова на антишаблон.

Еден од клиентите имаше приватен облак.
Нарачавме виртуелни машини во облакот.
Но, поради природата на облакот, распоредувањето на апликацијата беше поврзано со кој хипервизор беше вклучен VM.

Оние. Логиката за распоредување на апликации на високо ниво течеше со зависности до пониските нивоа на хипервизорот, а тоа значеше проблеми при повторното користење на оваа логика. Не правете го тоа на овој начин.

Интеракција

Инфраструктурата како код не е само за код, туку и за односот помеѓу кодот и луѓето, за интеракциите помеѓу развивачите на инфраструктура.

Фактор на автобус

Да претпоставиме дека ја имате Васија на вашиот проект. Васија знае сè за вашата инфраструктура, што ќе се случи ако Васија одеднаш исчезне? Ова е многу реална ситуација, бидејќи може да го удри автобус. Понекогаш тоа се случува. Ако тоа се случи и ако знаењето за кодот, неговата структура, како функционира, изгледот и лозинките не се дистрибуира меѓу тимот, тогаш може да наидете на голем број непријатни ситуации. За да ги минимизирате овие ризици и да го дистрибуирате знаењето во тимот, можете да користите различни пристапи

Спари Devopsing

Не е како како на шега, дека администраторите пиеле пиво, смениле лозинки и аналог на програмирање парови. Оние. двајца инженери седнуваат на еден компјутер, една тастатура и заедно започнуваат да ја поставуваат вашата инфраструктура: поставување сервер, пишување улога на Ansible итн. Звучи убаво, но не ни успеа. Но, посебни случаи на оваа практика функционираа. Дојде нов вработен, неговиот ментор заедно со него презема вистинска задача, работи и пренесува знаење.

Друг посебен случај е повик за инцидент. За време на некој проблем, се собира група од дежурните и вклучените, се назначува еден водач, кој го споделува својот екран и го искажува возот на мислите. Другите учесници ги следат мислите на лидерот, шпионираат трикови од конзолата, проверуваат дали не пропуштиле линија во дневникот и учат нови работи за системот. Овој пристап функционираше почесто отколку не.

Преглед на код

Субјективно, беше поефективно да се шири знаењето за инфраструктурата и како таа функционира користејќи преглед на кодот:

Инфраструктурата е опишана со код во складиштето.
Промените се случуваат во посебна гранка.
За време на барањето за спојување, можете да ја видите делтата на промени во инфраструктурата.

Врвот овде беше што рецензентите беа избрани еден по еден, според распоред, т.е. со одреден степен на веројатност ќе се качите во ново парче инфраструктура.

стил на код

Со текот на времето почнаа да се појавуваат препукувања при прегледите, бидејќи ... рецензентите имаа свој стил и ротацијата на рецензентите ги наредени со различни стилови: 2 празни места или 4, camelCase или snake_case. Не беше можно ова да се спроведе веднаш.

Првата идеја беше да се препорача употреба на линтер, на крајот на краиштата, сите се инженери, сите се паметни. Но, различни уредници, ОС, не се погодни
Ова еволуираше во бот кој пишуваше на олабавување за секое проблематично извршување и го прикачи излезот на линтер. Но, во повеќето случаи имаше поважни работи што требаше да се направат и кодот остана непоправен.

Зелена градба мајстор

Времето минува, а ние дојдовме до заклучок дека обврските што не поминуваат одредени тестови не можат да бидат дозволени во мајсторот. Voila! Го измисливме Green Build Master, кој долго време се практикува во развој на софтвер:

Развојот е во тек во посебна гранка.
Тестовите се извршуваат на оваа тема.
Ако тестовите не успеат, кодот нема да влезе во главниот.

Донесувањето на оваа одлука беше многу болно, бидејќи ... предизвика многу контроверзии, но вредеше, бидејќи. Прегледите почнаа да добиваат барања за спојувања без разлики во стилот, а со текот на времето бројот на проблематични области почна да се намалува.

IaC тестирање

Покрај проверката на стилот, можете да користите и други работи, на пример, за да проверите дали вашата инфраструктура навистина може да се распореди. Или проверете дали промените во инфраструктурата нема да доведат до губење на пари. Зошто може да биде потребно ова? Прашањето е сложено и филозофско, подобро е да се одговори со приказна дека некако имало автоматско мерење на Powershell што не ги проверувало граничните услови => создадени се повеќе VM отколку што е потребно => клиентот потрошил повеќе пари од планираното. Ова не е многу пријатно, но би било сосема можно да се фати оваа грешка во претходните фази.

Некој може да се запраша, зошто комплексната инфраструктура да биде уште посложена? Тестовите за инфраструктура, исто како и за кодот, не се за поедноставување, туку за знаење како треба да работи вашата инфраструктура.

Пирамида за тестирање IaC

IaC Тестирање: Статичка анализа

Ако ја распоредите целата инфраструктура одеднаш и проверите дали работи, може да откриете дека е потребно многу време и бара многу време. Затоа, основата мора да биде нешто што работи брзо, го има многу, а покрива многу примитивни места.

Баш е незгоден

Ајде да погледнеме тривијален пример. изберете ги сите датотеки во тековниот директориум и копирајте на друга локација. Првото нешто што ми паѓа на ум:

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

Што ако има празно место во името на датотеката? Па, добро, паметни сме, знаеме да користиме цитати:

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

Добро сторено? Не! Што ако нема ништо во директориумот, т.е. глобирањето нема да работи.

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

Добро направено сега? Не... Заборавив што може да има во името на датотеката n.

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

Алатки за статичка анализа

Проблемот од претходниот чекор можеше да се фати кога ги заборавивме цитатите, за ова има многу лекови во природата Шелпроверка, генерално, има многу од нив, и најверојатно можете да најдете ѓубре за вашиот оџак под вашиот IDE.

Јазик
Алатка

баш
Шелпроверка

Руби
RuboCop

python
Пилинт

одговорен
Ансибл Линт

IaC тестирање: Единица тестови

Како што видовме од претходниот пример, линтери не се семоќни и не можат да ги посочат сите проблематични области. Понатаму, по аналогија со тестирањето во развојот на софтвер, можеме да се потсетиме на единечни тестови. Она што веднаш ми паѓа на ум е шунит, џунит, рспец, pytest. Но, што да се прави со ansible, готвач, saltstack и други како нив?

На самиот почеток зборувавме за ЦВРСТ и дека нашата инфраструктура треба да се состои од мали тули. Нивното време дојде.

Инфраструктурата е поделена на мали тули, на пример, Ansible улоги.
Распоредена е некаква средина, било да е тоа докер или VM.
Ја применуваме нашата улога на Ansible во оваа средина за тестирање.
Проверуваме дали сè функционира како што очекувавме (вршиме тестови).
Одлучуваме добро или не е во ред.

IaC Тестирање: Алатки за тестирање на единици

Прашање, што се тестови за CFM? Можете едноставно да ја извршите скриптата или можете да користите готови решенија за ова:

CFM
Алатка

Ansible
Тестинфра

готвач
Инспекциски

готвач
Serverspec

солена маса
Goss

Пример за testinfra, проверка дека корисниците test1, test2 постојат и се во група 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

Што да се избере? Прашањето е сложено и двосмислено, еве пример за промени во проектите на github за 2018-2019 година:

Рамки за тестирање IaC

Се поставува прашањето: како да се собере сето тоа и да се лансира? Може земете го и направете го тоа сами доколку има доволен број инженери. Или можете да земете готови решенија, иако нема многу од нив:

CFM
Алатка

Ansible
молекула

готвач
Кујнски тест

Terraform
Тератест

Пример за промени во проекти на github за 2018-2019 година:

Молекула vs. Тест-кујна

Првично ние се обиде да користи тест-кујна:

Направете VM паралелно.
Примени ги улогите на Ansible.
Извршете инспекција.

За 25-35 улоги работеше 40-70 минути, што беше долго.

Следниот чекор беше транзицијата кон jenkins/docker/ansible/молекула. Идиолошки се е исто

Линт игротеки.
Подредете ги улогите.
Контејнер за лансирање
Примени ги улогите на Ansible.
Стартувај testinfra.
Проверете ја идемотенцијата.

Линтирањето за 40 улоги и тестовите за десетина почнаа да траат околу 15 минути.

Што да се избере зависи од многу фактори, како што се употребениот оџак, стручноста во тимот итн. овде секој сам одлучува како да го затвори прашањето за тестирање на единицата

IaC Тестирање: Тестови за интеграција

Следниот чекор во пирамидата за тестирање на инфраструктурата ќе бидат тестовите за интеграција. Тие се слични на единечните тестови:

Инфраструктурата е поделена на мали тули, на пример Ansible улоги.
Распоредена е некаква средина, било да е тоа докер или VM.
За оваа средина за тестирање се применува многу Обезбедени улоги.
Проверуваме дали сè функционира како што очекувавме (вршиме тестови).
Одлучуваме добро или не е во ред.

Грубо кажано, ние не ги проверуваме перформансите на поединечен елемент на системот како во тестовите на единицата, ние проверуваме како серверот е конфигуриран како целина.

IaC тестирање: Тестови од крај до крај

На врвот на пирамидата нè пречекуваат тестови од крај до крај. Оние. Ние не ги проверуваме перформансите на посебен сервер, посебна скрипта или посебна тула од нашата инфраструктура. Проверуваме дали многу сервери се поврзани заедно, нашата инфраструктура работи како што очекуваме. За жал, никогаш не сум видел готови решенија во кутии, веројатно затоа што ... Инфраструктурата е често единствена и тешко е да се образложи и да се создаде рамка за тестирање. Како резултат на тоа, секој создава свои решенија. Побарувачка има, но одговор нема. Затоа, ќе ви кажам што има за да ги поттикнам другите да звучат мисли или да ми го тријат носот во фактот дека сè е измислено многу одамна пред нас.

Проект со богата историја. Се користи во големи организации и веројатно секој од вас индиректно се вкрстил со него. Апликацијата поддржува многу бази на податоци, интеграции итн. Да се знае како може да изгледа инфраструктурата е многу датотеки со докер-компонирање и да се знае кои тестови да се извршат во која средина е Џенкинс.

Оваа шема работеше доста долго, се додека во рамките истражување не се обидовме да го пренесеме ова на Openshift. Контејнерите остануваат исти, но околината за лансирање е променета (здраво СУШИ повторно).

Идејата за истражување отиде подалеку, а во openshift најдоа нешто како APB (Ansible Playbook Bundle), што ви овозможува да спакувате знаење за тоа како да ја распоредите инфраструктурата во контејнер. Оние. постои повторлива, проверлива точка на знаење за тоа како да се распореди инфраструктурата.

Сето ова звучеше добро додека не налетавме на хетерогена инфраструктура: ни требаше Windows за тестови. Како резултат на тоа, знаењето за тоа што, каде, како да се распореди и тестира е во џенкинс.

Заклучок

Инфраструктурата каква што е Кодексот

Код во складиштето.
Човечка интеракција.
Инфраструктурно тестирање.

линкови

Извор: www.habr.com

Што научив од тестирањето на 200 линии на инфраструктурен код