Көзқарас IaC (Инфрақұрылым код ретінде) репозиторийде сақталатын кодтан ғана емес, сонымен қатар осы кодты қоршап тұрған адамдар мен процестерден тұрады. Бағдарламалық жасақтаманы әзірлеуден бастап инфрақұрылымды басқаруға және сипаттауға дейінгі тәсілдерді қайта пайдалануға болады ма? Мақаланы оқығанда осы ойды есте ұстаған дұрыс болар еді.

ағылшын нұсқасы

Бұл менің стенограммам қойылымдар туралы DevopsConf 2019.

Слайдтар мен бейнелер

• ағылшын нұсқасы
• Орысша нұсқасы
• Құрғақ жүгіру 2019 ж SpbLUG
• DevopsConf ұсынған бейне(RU) 2019
• Бейне(RU) DINS DevOps кешінен 2019 ж
• слайдтар

Инфрақұрылым bash тарихы ретінде

Сіз жаңа жобаға келдіңіз делік, олар сізге: «бізде бар Код ретінде инфрақұрылым«. Шындығында бұл шығады Инфрақұрылым bash тарихы ретінде немесе мысалы Bash тарихы ретіндегі құжаттама. Бұл өте нақты жағдай, мысалы, осындай жағдайды Денис Лысенко өз баяндамасында сипаттады Бүкіл инфрақұрылымды қалай ауыстыруға және тыныш ұйықтауға болады, ол bash тарихынан жоба үшін үйлесімді инфрақұрылымды қалай алғанын айтты.

Бір тілекпен біз мұны айта аламыз Инфрақұрылым bash тарихы ретінде бұл код сияқты:

1. қайталану мүмкіндігі: Сіз bash тарихын алып, сол жерден пәрмендерді іске қоса аласыз және айтпақшы, шығыс ретінде жұмыс конфигурациясын аласыз.
2. нұсқалау: кімнің кіргенін және олардың не істегенін білесіз, бұл сізді шығудағы жұмыс конфигурациясына апаратыны шындық емес.
3. тарихы: кім не істегені туралы әңгіме. тек серверді жоғалтып алсаңыз, оны пайдалана алмайсыз.

Енді не істеу керек?

Код ретінде инфрақұрылым

Тіпті осындай оғаш жағдай Инфрақұрылым bash тарихы ретінде оны құлақтан тартып алуға болады Код ретінде инфрақұрылым, бірақ біз ескі жақсы LAMP серверіне қарағанда күрделірек нәрсе жасағымыз келгенде, біз бұл кодты қандай да бір түрде өзгерту, өзгерту, жақсарту керек деген қорытындыға келеміз. Әрі қарай біз арасындағы параллельдерді қарастырғымыз келеді Код ретінде инфрақұрылым және бағдарламалық қамтамасыз етуді әзірлеу.

ҚҰРҒАҚ

Сақтау жүйесін әзірлеу жобасында қосалқы тапсырма болды мезгіл-мезгіл SDS конфигурациялау: біз жаңа шығарылымды шығарамыз - оны әрі қарай тестілеу үшін шығару керек. Тапсырма өте қарапайым:

• ssh арқылы осы жерге кіріп, пәрменді орындаңыз.
• файлды сол жерге көшіріңіз.
• мұнда конфигурацияны түзетіңіз.
• сол жерде қызметті бастаңыз
• ...
• PROFIT!

Сипатталған логика үшін bash жеткілікті, әсіресе жобаның бастапқы кезеңдерінде, ол жаңадан басталған кезде. Бұл bash қолданатыныңыз жаман емес, бірақ уақыт өте ұқсас, бірақ сәл басқаша нәрсені орналастыруға сұраулар бар. Бірінші ойға келетін нәрсе - көшіріп қою. Ал қазір бізде бірдей нәрсені жасайтын екі өте ұқсас сценарий бар. Уақыт өте келе сценарийлер саны өсті және біз әртүрлі сценарийлер арасында синхрондауды қажет ететін орнатуды орналастырудың белгілі бір бизнес логикасы бар екеніне тап болдық, бұл өте күрделі.

ҚҰРАҚ (Өзіңді қайталама) деген тәжірибе бар екен. Идея бар кодты қайта пайдалану болып табылады. Бұл қарапайым көрінеді, бірақ біз бұған бірден келген жоқпыз. Біздің жағдайда бұл қарапайым идея болды: конфигурацияларды сценарийлерден бөлу. Анау. орнатудың бөлек орналастырылуының бизнес логикасы, конфигурациялары бөлек.

CFM үшін SOLID

Уақыт өте келе жоба өсті және табиғи жалғасы Ансиблдің пайда болуы болды. Оның пайда болуының басты себебі - командада тәжірибе бар және бұл bash күрделі логикаға арналмаған. Ansible де күрделі логиканы қамти бастады. Күрделі логиканың хаосқа айналуына жол бермеу үшін бағдарламалық жасақтаманы әзірлеуде кодты ұйымдастыру принциптері бар ҚАТТЫ Сондай-ақ, мысалы, Григорий Петров «IT маманына жеке бренд не үшін қажет» баяндамасында адам кейбір әлеуметтік құрылымдармен жұмыс істеу оңай болатындай етіп жасалған деген сұрақты көтерді, бағдарламалық жасақтаманы әзірлеуде бұл объектілер болып табылады. Осы екі идеяны біріктіріп, әрі қарай дамытатын болсақ, біз де қолдануға болатынын байқаймыз ҚАТТЫ болашақта осы логиканы сақтауды және өзгертуді жеңілдету үшін.

Бірыңғай жауапкершілік қағидасы

Әр сынып тек бір тапсырманы орындайды.

Кодты араластырып, монолитті құдай спагетти құбыжықтарын жасаудың қажеті жоқ. Инфрақұрылым қарапайым кірпіштен тұруы керек. Егер сіз Ansible ойын кітабын кішкене бөліктерге бөлсеңіз, Ansible рөлдерін оқысаңыз, оларды сақтау оңайырақ болады.

Ашық жабық принцип

Ашық/жабық принцип.

• Кеңейтімге ашық: нысанның әрекетін жаңа нысан түрлерін жасау арқылы кеңейтуге болатындығын білдіреді.
• Өзгертуге жабық: Нысан әрекетін кеңейту нәтижесінде сол нысандарды пайдаланатын кодқа ешқандай өзгертулер енгізілмеуі керек.

Бастапқыда біз сынақ инфрақұрылымын виртуалды машиналарда орналастырдық, бірақ орналастырудың бизнес логикасы іске асырудан бөлек болғандықтан, біз baremetall жүйесіне еш қиындықсыз шығаруды қостық.

Лисков алмастыру принципі

Барбара Лисковтың алмастыру принципі. Бағдарламадағы объектілер бағдарламаның дұрыс орындалуын өзгертпей, олардың ішкі типтерінің даналарымен ауыстырылуы керек.

Егер сіз оны кеңірек қарасаңыз, онда ол жерде қолдануға болатын нақты жобаның ерекшелігі емес ҚАТТЫ, бұл негізінен CFM туралы, мысалы, басқа жобада әртүрлі Java, қолданба серверлері, дерекқорлар, ОЖ және т.б. үстіне қорапты Java қосымшасын орналастыру қажет. Осы мысалды пайдалана отырып, мен келесі принциптерді қарастырамын ҚАТТЫ

Біздің жағдайда, егер біз imbjava немесе oraclejava рөлін орнатқан болсақ, онда бізде Java екілік орындалатын файлы бар деген инфрақұрылымдық топта келісім бар. Бұл қажет, өйткені Жоғары ағын рөлдері осы мінез-құлыққа байланысты; олар java күтеді. Сонымен қатар, бұл қосымшаны орналастыру логикасын өзгертпестен бір java енгізуін/нұсқасын басқасымен ауыстыруға мүмкіндік береді.

Бұл жерде мәселе Ansible-де мұны жүзеге асыру мүмкін еместігінде, нәтижесінде команда ішінде кейбір келісімдер пайда болады.

Интерфейсті бөлу принципі

Интерфейсті бөлу принципі: «Көптеген клиенттік интерфейстер бір жалпы мақсаттағы интерфейске қарағанда жақсырақ.

Бастапқыда біз қолданбаларды орналастырудың барлық өзгермелілігін бір Ansible ойын кітабына қоюға тырыстық, бірақ оны қолдау қиын болды және бізде сыртқы интерфейс көрсетілген кезде (клиент 443 портты күтеді), содан кейін инфрақұрылымды жекеден жинауға болады. нақты іске асыру үшін кірпіш.

Тәуелділіктің инверсия принципі

Тәуелділік инверсия принципі. Жоғары деңгейлердегі модульдер төменгі деңгейдегі модульдерге тәуелді болмауы керек. Модульдердің екі түрі де абстракцияларға тәуелді болуы керек. Абстракциялар бөлшектерге тәуелді болмауы керек. Мәліметтер абстракцияларға байланысты болуы керек.

Мұнда мысал антипаттернге негізделген.

1. Тұтынушылардың бірінде жеке бұлт болды.
2. Біз бұлт ішінде виртуалды машиналарға тапсырыс бердік.
3. Бірақ бұлттың сипатына байланысты қолданбаны орналастыру VM қосылған гипервизорға байланысты болды.

Анау. Жоғары деңгейлі қолданбаларды орналастыру логикасы тәуелділіктермен гипервизордың төменгі деңгейлеріне ағылды және бұл логиканы қайта пайдалану кезіндегі проблемаларды білдіреді. Бұлай істемеңіз.

Өзара әрекеттесу

Инфрақұрылым код ретінде тек код туралы ғана емес, сонымен қатар код пен адамдар арасындағы қарым-қатынас, инфрақұрылымды әзірлеушілер арасындағы өзара әрекеттесу туралы.

Автобус факторы

Сіздің жобаңызда Вася бар деп есептейік. Вася сіздің инфрақұрылымыңыз туралы бәрін біледі, егер Вася кенеттен жоғалып кетсе не болады? Бұл өте нақты жағдай, өйткені оны автобус қағып кетуі мүмкін. Кейде солай болады. Егер бұл орын алса және код, оның құрылымы, оның қалай жұмыс істейтіні, сыртқы түрі мен құпия сөздері туралы білім команда арасында таратылмаса, сіз бірқатар жағымсыз жағдайларға тап болуыңыз мүмкін. Осы тәуекелдерді азайту және топ ішінде білімді тарату үшін әртүрлі тәсілдерді қолдануға болады

Жұпты дамыту

Ол сияқты емес әзіл ретінде, әкімшілер сыра ішкен, құпия сөздерді өзгерткен және жұптық бағдарламалаудың аналогы. Анау. екі инженер бір компьютерде, бір пернетақтада отырады және сіздің инфрақұрылымыңызды бірге орнатуды бастайды: серверді орнату, Ansible рөлін жазу және т.б. Бұл жақсы естіледі, бірақ бұл біз үшін жұмыс істемеді. Бірақ бұл тәжірибенің ерекше жағдайлары жұмыс істеді. Жаңа қызметкер келеді, оның тәлімгері онымен бірге нақты тапсырма алады, жұмыс істейді және білім береді.

Тағы бір ерекше жағдай - инциденттік қоңырау. Мәселе кезінде кезекшілер мен тартылғандардың бір тобы жиналып, бір басшы тағайындалады, ол өз экранын бөлісіп, ой ұшағын айтады. Басқа қатысушылар көшбасшының ойларын қадағалайды, консольден трюктерді тыңдайды, журналдағы жолды жіберіп алмағандарын тексереді және жүйе туралы жаңа нәрселерді біледі. Бұл тәсіл жиі жұмыс істеді.

Кодты қарау

Субъективті түрде кодты қарап шығу арқылы инфрақұрылым және оның қалай жұмыс істейтіні туралы білімді тарату тиімдірек болды:

• Инфрақұрылым репозиторийдегі кодпен сипатталады.
• Өзгерістер бөлек филиалда орын алады.
• Біріктіру сұрауы кезінде инфрақұрылымдағы өзгерістердің дельтасын көре аласыз.

Мұндағы ерекше жағдай рецензенттер кесте бойынша бірінен соң бірі таңдалды, яғни. белгілі бір ықтималдық дәрежесімен сіз инфрақұрылымның жаңа бөлігіне көтерілесіз.

код стилі

Уақыт өте келе шолулар кезінде даулар пайда бола бастады, өйткені... шолушылардың өзіндік стилі болды және шолушылардың айналуы оларды әртүрлі стильдермен біріктірді: 2 бос орын немесе 4, camelCase немесе snake_case. Мұны бірден жүзеге асыру мүмкін болмады.

• Бірінші идея линтерді пайдалануды ұсыну болды, өйткені бәрі инженер, бәрі ақылды. Бірақ әртүрлі редакторлар, ОЖ, ыңғайлы емес
• Бұл ботқа айналды, ол әрбір проблемалық міндеттемені орындамай жазады және линтер шығысын қосады. Бірақ көп жағдайда маңыздырақ істер болды және код түзетілмеген күйінде қалды.

Жасыл құрылыс шебері

Уақыт өтіп жатыр және біз белгілі бір сынақтардан өтпеген міндеттемелерді шеберге жіберуге болмайды деген қорытындыға келдік. Voila! Біз ұзақ уақыт бойы бағдарламалық жасақтаманы әзірлеуде тәжірибеден өткен Green Build Master бағдарламасын ойлап таптық:

• Бөлек салада даму жүріп жатыр.
• Бұл ағында сынақтар жүргізілуде.
• Егер сынақтар сәтсіз болса, код оны шеберге енгізбейді.

Бұл шешім қабылдау өте ауыр болды, өйткені... көп дау тудырды, бірақ бұл тұрды, өйткені... Пікірлер стильде айырмашылықтарсыз біріктіру туралы өтініштер ала бастады және уақыт өте келе проблемалық аймақтардың саны азая бастады.

IaC тестілеу

Стильді тексеруге қоса, сіз басқа нәрселерді пайдалана аласыз, мысалы, инфрақұрылымыңыздың нақты орналастыра алатынын тексеру үшін. Немесе инфрақұрылымдағы өзгерістер ақшаны жоғалтуға әкелмейтінін тексеріңіз. Бұл не үшін қажет болуы мүмкін? Сұрақ күрделі және философиялық, қандай да бір түрде Powershell-де шекаралық шарттарды тексермейтін авто-масштабшы бар екендігі туралы әңгімемен жауап берген дұрыс => қажет болғаннан көп VM құрылды => клиент жоспарланғаннан көп ақша жұмсады. Бұл өте жағымды емес, бірақ бұл қатені ертерек кезеңдерде ұстау әбден мүмкін еді.

Неліктен күрделі инфрақұрылымды одан да күрделі етіп жасау керек деген сұрақ туындауы мүмкін. Инфрақұрылымға арналған сынақтар, код сияқты, жеңілдету туралы емес, сіздің инфрақұрылымыңыздың қалай жұмыс істейтінін білу үшін.

IaC тестілеу пирамидасы

IaC сынағы: статикалық талдау

Бүкіл инфрақұрылымды бірден орналастырып, оның жұмыс істеп тұрғанын тексерсеңіз, бұл көп уақытты қажет ететінін және көп уақытты қажет ететінін байқауыңыз мүмкін. Сондықтан, негіз тез жұмыс істейтін нәрсе болуы керек, ол көп және ол көптеген қарабайыр жерлерді қамтиды.

Bash қиын

Тривиальды мысалды қарастырайық. ағымдағы каталогтағы барлық файлдарды таңдап, басқа орынға көшіріңіз. Бірінші ойға келетін нәрсе:

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

Статикалық талдау құралдары

Алдыңғы қадамдағы мәселе тырнақшаларды ұмытып кеткен кезде туындауы мүмкін, бұл үшін табиғатта көптеген құралдар бар. Shellcheck, жалпы алғанда олардың көпшілігі бар және IDE астында стек үшін линтер таба аласыз.

Тіл
аспап

bash
Shellcheck

лағыл
RuboCop

питон
Пилинт

мүмкін емес
Ansible Lint

IaC тестілері: бірлік сынақтары

Алдыңғы мысалдан көргеніміздей, линтерлер құдіретті емес және барлық проблемалық аймақтарды көрсете алмайды. Әрі қарай, бағдарламалық жасақтаманы әзірлеудегі тестілеуге ұқсастық арқылы біз бірлік сынақтарын еске түсіре аламыз. Бірден ойға келетіні шунит, жасөспірім, rspec, питест. Бірақ ansible, chef, saltstack және басқалар сияқты не істеу керек?

Ең басында біз әңгімелестік ҚАТТЫ және біздің инфрақұрылым ұсақ кірпіштерден тұруы керек. Олардың уақыты келді.

1. Инфрақұрылым шағын кірпіштерге бөлінген, мысалы, Ansible рөлдері.
2. Докер немесе VM болсын ортаның қандай да бір түрі орналастырылған.
3. Біз Ansible рөлімізді осы сынақ ортасына қолданамыз.
4. Барлығы біз күткендей жұмыс істегенін тексереміз (тесттерді жүргіземіз).
5. Жақсы ма, жоқ па деп шешеміз.

IaC тестілеу: бірлік сынау құралдары

Сұрақ, CFM үшін сынақтар дегеніміз не? Сіз жай ғана сценарийді іске қоса аласыз немесе бұл үшін дайын шешімдерді пайдалана аласыз:

СІМК
аспап

Қажет
Testinfra

бас
Ашық емес

бас
Serverspec

тұз үйіндісі
Өсек

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

Не таңдау керек? Сұрақ күрделі және түсініксіз, 2018-2019 жылдарға арналған github жобаларындағы өзгерістердің мысалы:

IaC тестілеу құрылымдары

Сұрақ туындайды: мұның бәрін біріктіріп, оны қалай іске қосу керек? мүмкін алыңыз және өзіңіз жасаңыз инженерлердің жеткілікті саны болса. Немесе дайын шешімдерді қабылдауға болады, бірақ олардың саны көп емес:

СІМК
аспап

Қажет
молекуласы

бас
Сынақ асханасы

Terraform
Терратест

2018-2019 жылдарға арналған github жобаларындағы өзгерістердің мысалы:

Молекула қарсы Сынақ асханасы

Бастапқыда біз сынақ асханасын қолданып көрді:

1. Параллельді VM жасаңыз.
2. Ansible рөлдерін қолданыңыз.
3. Тексеруді іске қосыңыз.

25-35 рөлге 40-70 минут жұмыс істеді, бұл ұзақ болды.

Келесі қадам Дженкинс/докер/ансибл/молекулаға көшу болды. Идиологиялық тұрғыдан бәрі бірдей

1. Линт ойын кітаптары.
2. Рөлдерді сапқа тұрғызу.
3. Контейнерді іске қосыңыз
4. Ansible рөлдерін қолданыңыз.
5. Testinfra іске қосыңыз.
6. Импотенттілікті тексеріңіз.

40 рөлге арналған линтинг және оншақты рөлге арналған сынақтар шамамен 15 минутты алады.

Нені таңдау керектігі көптеген факторларға байланысты, мысалы, пайдаланылған стек, командадағы тәжірибе және т.б. мұнда әркім Бірлікті тестілеу сұрағын қалай жабу керектігін өзі шешеді

IaC тестілері: интеграциялық сынақтар

Инфрақұрылымдық тестілеу пирамидасының келесі қадамы интеграциялық сынақтар болады. Олар бірлік сынақтарына ұқсас:

1. Инфрақұрылым шағын кірпіштерге бөлінген, мысалы, Ansible рөлдері.
2. Докер немесе VM болсын ортаның қандай да бір түрі орналастырылған.
3. Бұл сынақ ортасы үшін қолданылады жиынтығы Маңызды рөлдер.
4. Барлығы біз күткендей жұмыс істегенін тексереміз (тесттерді жүргіземіз).
5. Жақсы ма, жоқ па деп шешеміз.

Шамамен айтқанда, біз жүйенің жеке элементінің өнімділігін бірлік сынақтарындағыдай тексермейміз, сервердің тұтастай конфигурациялануын тексереміз.

IaC тестілеу: соңына дейін сынақтар

Пирамиданың жоғарғы жағында бізді End to End сынақтары қарсы алады. Анау. Біз жеке сервердің, бөлек сценарийдің немесе инфрақұрылымымыздың бөлек кірпішінің өнімділігін тексермейміз. Біз көптеген серверлердің бір-біріне қосылғанын тексереміз, біздің инфрақұрылым біз күткендей жұмыс істейді. Өкінішке орай, мен дайын қораптағы шешімдерді ешқашан көрген емеспін, бәлкім... Инфрақұрылым жиі бірегей және үлгілеу және тестілеу үшін негіз құру қиын. Нәтижесінде әркім өз шешімдерін жасайды. Сұраныс бар, бірақ жауап жоқ. Сондықтан мен сізге басқаларды дұрыс ойға итермелеу немесе мұрнымды уқалау үшін не бар екенін айтып беремін, өйткені бәрі бізден бұрын ойлап табылған.

Тарихы бай жоба. Ол ірі ұйымдарда қолданылады және сіздердің әрқайсысыңыз онымен жанама түрде қиылысатын шығарсыз. Қолданба көптеген дерекқорларды, интеграцияларды және т.б. Инфрақұрылымның қандай болуы мүмкін екенін білу - көптеген докерлік файлдарды құрастыру және Дженкинс қай ортада қандай сынақтарды орындау керектігін білу.

Бұл схема шеңберде болғанға дейін ұзақ уақыт жұмыс істеді зерттеу біз оны Openshift-ке көшіруге тырыспадық. Контейнерлер өзгеріссіз қалады, бірақ іске қосу ортасы өзгерді (қайтадан сәлем DRY).

Зерттеу идеясы одан әрі дамыды және олар ашық ауысымда инфрақұрылымды контейнерге орналастыру туралы білімді жинақтауға мүмкіндік беретін APB (Ansible Playbook Bundle) сияқты нәрсені тапты. Анау. инфрақұрылымды қалай орналастыру керектігі туралы білімнің қайталанатын, тексерілетін нүктесі бар.

Мұның бәрі біз гетерогенді инфрақұрылымға тап болғанша жақсы болды: бізге сынақтар үшін Windows қажет болды. Нәтижесінде нені, қайда, қалай орналастыру және сынау туралы білім Дженкинсте.

қорытынды

Кодекс сияқты инфрақұрылым

• Репозиторийдегі код.
• Адамның өзара әрекеттесуі.
• Инфрақұрылымдық тестілеу.

сілтемелер

• Ағылшынша нұсқа
• Жеке блогтан көлденең жазба
• Құрғақ жүгіру 2019 ж SpbLUG
• DevopsConf ұсынған бейне(RU) 2019
• Бейне(RU) DINS DevOps кешінен 2019 ж
• 300,000 XNUMX-нан астам инфрақұрылымдық кодты жазудан алынған сабақтар & мәтіндік нұсқасы
• Инфрақұрылымды үздіксіз жеткізу құбырына код ретінде біріктіру
• Инфрақұрылымды код ретінде сынау
• Ansible рөлдерін тиімді дамыту және қолдау
• Ansible bash емес!

Ақпарат көзі: www.habr.com