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

Ово је мој препис представе на ДевопсЦонф 2019-05-28.

Слајдови и видео снимци

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

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

Уз одређену жељу, можемо то рећи Инфраструктура као басх историја ово је као код:

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

Шта да радим?

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

Чак и тако чудан случај као Инфраструктура као басх историја можете га повући за уши Инфраструктура као код, али када желимо да урадимо нешто компликованије од доброг старог ЛАМП сервера, доћи ћемо до закључка да овај код треба некако модификовати, променити, побољшати. Затим бисмо желели да размотримо паралеле између Инфраструктура као код и развој софтвера.

СУВ.

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

пријавите се овде преко ссх-а и извршите команду.
копирајте датотеку тамо.
исправите конфигурацију овде.
тамо започните услугу
...
ДОБИТ!

За описану логику, басх је више него довољан, посебно у раним фазама пројекта, када тек почиње. Ово није лоше што користите басх, али временом се јављају захтеви да се примени нешто слично, али мало другачије. Прва ствар која пада на памет је цопи-пасте. А сада већ имамо две веома сличне скрипте које раде скоро исту ствар. Временом је број скрипти растао, а ми смо се суочили са чињеницом да постоји одређена пословна логика за постављање инсталације која треба да се синхронизује између различитих скрипти, то је прилично компликовано.

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

ЧВРСТ. за ЦФМ

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

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

Сваки разред обавља само један задатак.

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

Отворено затворено начело

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

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

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

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

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

Ако погледате шире, то није одлика ниједног пројекта који се тамо може применити ЧВРСТ., генерално се ради о ЦФМ-у, на пример, на другом пројекту је потребно да се на разне Јава апликације, сервера апликација, база података, ОС итд. Користећи овај пример, размотрићу даље принципе ЧВРСТ.

У нашем случају постоји договор унутар инфраструктурног тима да ако смо инсталирали улогу имбјава или орацлејава, онда имамо јава бинарну извршну датотеку. Ово је неопходно јер Упстреам улоге зависе од овог понашања; они очекују јава. У исто време, ово нам омогућава да заменимо једну имплементацију/верзију јава са другом без промене логике примене апликације.

Проблем овде лежи у чињеници да је то немогуће имплементирати у Ансибле-у, услед чега се појављују неки договори унутар тима.

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

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

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

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

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

Овде ће пример бити заснован на антиузорку.

Један од купаца је имао приватни облак.
Наручили смо виртуелне машине унутар облака.
Али због природе облака, примена апликације је била везана за који хипервизор је био на ВМ.

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

Интеракција

Инфраструктура као код се не односи само на код, већ и на однос између кода и људи, на интеракције између програмера инфраструктуре.

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

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

Паир Девопсинг

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

Још један посебан случај је инцидентни позив. Током проблема, окупља се група дежурних и укључених, именује се један вођа, који дели свој екран и изговара ток мисли. Остали учесници прате мисли вође, шпијунирају трикове са конзоле, проверавају да нису пропустили ред у дневнику и уче нове ствари о систему. Овај приступ је радио чешће него не.

Код

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

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

Врхунац је био да су рецензенти бирани један по један, по распореду, тј. са извесним степеном вероватноће ћете се попети у нови део инфраструктуре.

Цоде Стиле

Временом су почеле да се појављују свађе током прегледа, јер... рецензенти су имали свој стил и ротација рецензената их је слагала са различитим стиловима: 2 размака или 4, цамелЦасе или снаке_цасе. Ово није било могуће спровести одмах.

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

Греен Буилд Мастер

Време пролази, а ми смо дошли до закључка да комите које не прођу одређене тестове не могу бити дозвољене у мастер. Воила! Измислили смо Греен Буилд Мастер, који се већ дуго практикује у развоју софтвера:

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

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

ИаЦ Тестинг

Поред провере стила, можете користити и друге ствари, на пример, да проверите да ли ваша инфраструктура заиста може да се примени. Или проверите да промене у инфраструктури неће довести до губитка новца. Зашто би ово могло бити потребно? Питање је сложено и филозофско, боље је одговорити причом да је на Поверсхелл-у некако постојао ауто-скалер који није проверавао граничне услове => креирано је више ВМ-ова него што је потребно => клијент је потрошио више новца него што је планирано. Ово није баш пријатно, али би било сасвим могуће ухватити ову грешку у ранијим фазама.

Могло би се запитати, зашто сложену инфраструктуру чинити још сложенијом? Тестови за инфраструктуру, баш као и за код, нису у вези са поједностављењем, већ са сазнањем како ваша инфраструктура треба да функционише.

Пирамида за тестирање ИаЦ-а

ИаЦ тестирање: статичка анализа

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

Басх је лукав

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

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

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

Проблем из претходног корака могао би се уочити када смо заборавили цитате, јер за то постоје многи лекови у природи Схеллцхецк, генерално их има много, и највероватније можете пронаћи линтер за свој стек под вашим ИДЕ.

Језик
Алатка

треснути
Схеллцхецк

рубин
РубоЦоп

питон
Пилинт

ансибле
Ансибле Линт

ИаЦ тестирање: Јединични тестови

Као што смо видели из претходног примера, линтери нису свемоћни и не могу да укажу на сва проблематична подручја. Даље, по аналогији са тестирањем у развоју софтвера, можемо се присетити јединичних тестова. Оно што ми одмах пада на памет је шунит, јунит, рспец, питест. Али шта да се ради са ансиблеом, цхефом, салтстацком и другима попут њих?

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

Инфраструктура је подељена на мале цигле, на пример, улоге Ансибле.
Нека врста окружења је распоређена, било да је то доцкер или ВМ.
Примењујемо нашу Ансибле улогу на ово тестно окружење.
Проверавамо да ли је све функционисало како смо очекивали (покрећемо тестове).
Одлучујемо у реду или не у реду.

ИаЦ тестирање: Алати за тестирање јединица

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

ЦФМ
Алатка

Могуће
Тестинфра

главни кувар
Инспец

главни кувар
Серверспец

солистацк
Госс

Пример за тестинфра, провера да ли корисници 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:

ИаЦ оквири за тестирање

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

ЦФМ
Алатка

Могуће
молекул

главни кувар
Тест Китцхен

Терраформ
Терратест

Пример промена у пројектима на гитхуб-у за 2018-2019:

Молецуле вс. Тесткитцхен

У почетку ми покушао да користим тестну кухињу:

Креирајте ВМ паралелно.
Примените Ансибле улоге.
Покрени инспекцију.

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

Следећи корак је био прелазак на јенкинс/доцкер/ансибле/молекул. Идиолошки све је исто

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

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

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

ИаЦ тестирање: Интеграциони тестови

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

Инфраструктура је подељена на мале цигле, на пример Ансибле улоге.
Нека врста окружења је распоређена, било да је то доцкер или ВМ.
За ово тестно окружење важи сет оф Ансибле роле.
Проверавамо да ли је све функционисало како смо очекивали (покрећемо тестове).
Одлучујемо у реду или не у реду.

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

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

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

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

Ова шема је функционисала доста дуго, све до оквира истраживање нисмо покушали да ово пренесемо на Опенсхифт. Контејнери остају исти, али окружење за лансирање се променило (поново здраво Д.Р.И.).

Идеја истраживања је отишла даље, и у опенсхифт-у су пронашли нешто попут АПБ (Ансибле Плаибоок Бундле), који вам омогућава да спакујете знање о томе како да поставите инфраструктуру у контејнер. Оне. постоји поновљива, проверљива тачка знања о томе како применити инфраструктуру.

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

Zakljucak

Инфраструктура каква јесте

Код у спремишту.
Интеракција међу људима.
Испитивање инфраструктуре.

линкови

Извор: ввв.хабр.цом

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