Бир мамиле IaC (Код катары инфраструктура) репозиторийде сакталган коддон гана эмес, ошондой эле бул кодду курчап турган адамдардан жана процесстерден турат. Программалык камсыздоону иштеп чыгуудан инфраструктураны башкарууга жана сыпаттамага чейинки ыкмаларды кайра колдонуу мүмкүнбү? Макаланы окуп жатканда ушул ойду эстен чыгарбоо жакшы болмок.

Кыргызча версия

Бул менин стенограммам аткаруулар боюнча DevopsConf 2019.

Слайддар жана видеолор

• Кыргызча версия
• Орус версиясы
• Кургак чуркоо 2019 SpbLUG
• Video(RU) from DevopsConf 2019
• Video(RU) from DINS DevOps WEVENG 2019-06-20
• слайддар

Инфраструктура баш тарыхы катары

Сиз жаңы долбоорго келдиңиз дейли, алар сизге: “Бизде бар Инфраструктура код катары". Чындыгында ал чыгат Инфраструктура баш тарыхы катары же мисалы Документация bash тарыхы катары. Бул абдан реалдуу жагдай, мисалы, ушундай эле окуяны Денис Лысенко өз сөзүндө баяндаган Кантип бүт инфраструктураны алмаштырып, тынч уктай баштаса болот, ал баш тарыхынан долбоор үчүн ырааттуу инфраструктураны кантип алышканын айтып берди.

Кандайдыр бир каалоо менен биз муну айта алабыз Инфраструктура баш тарыхы катары бул код сыяктуу:

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

Эмне кылыш керек?

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

Ал тургай ушундай кызыктай окуя Инфраструктура баш тарыхы катары сиз аны кулактан тартсаңыз болот Инфраструктура код катары, бирок биз эски жакшы LAMP серверине караганда татаалыраак нерсени кылгыбыз келгенде, биз бул кодду кандайдыр бир түрдө өзгөртүү, өзгөртүү, жакшыртуу керек деген жыйынтыкка келебиз. Андан ары биз ортосундагы параллелдерди карап чыгууну каалайбыз Инфраструктура код катары жана программалык камсыздоону иштеп чыгуу.

КУРГАК

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

• ssh аркылуу бул жерге кириңиз жана буйрукту аткарыңыз.
• файлды ошол жерге көчүрүңүз.
• бул жерде конфигурацияны оңдоңуз.
• ошол жерден кызматты баштоо
• ...
• ПАЙДА!

Сүрөттөлгөн логика үчүн, bash, айрыкча, долбоордун алгачкы этаптарында, ал жаңыдан башталганда, жетиштүү. Бул bash колдонгонуңуз жаман эмес, бирок убакыттын өтүшү менен окшош, бирок бир аз башкачараак нерсени жайылтуу өтүнүчү бар. Акылга биринчи келген нерсе - көчүрүп чаптоо. Ал эми азыр бизде дээрлик бирдей нерсени аткарган эки окшош скрипт бар. Убакыттын өтүшү менен скрипттердин саны өстү жана биз ар кандай скрипттердин ортосунда синхрондоштурууну талап кылган орнотууну жайылтуу үчүн белгилүү бир бизнес логикасы бар экендигине туш болдук, бул абдан татаал.

КУРГАК (Өзүңдү кайталаба) деген практика бар экен. Идея бар кодду кайра колдонуу болуп саналат. Бул жөнөкөй угулат, бирок биз буга дароо келген жокпуз. Биздин учурда, бул баналдык идея болгон: конфигурацияларды скрипттерден бөлүү. Ошол. орнотуу өзүнчө, конфигурациялоо өзүнчө кантип орнотулганынын бизнес логикасы.

CFM үчүн SOLID

Убакыттын өтүшү менен долбоор өстү жана табигый уландысы Ansible пайда болгон. Анын пайда болушунун негизги себеби, командада тажрыйба бар жана баш татаал логикага ылайыкташкан эмес. Ansible да татаал логиканы камтый баштады. Татаал логиканын башаламандыкка айлануусуна жол бербөө үчүн программалык камсыздоону иштеп чыгууда кодду уюштуруу принциптери бар СОЛИД Ошондой эле, мисалы, Григорий Петров "Эмне үчүн IT адисине жеке бренд керек" деген докладында адам кээ бир социалдык объектилер менен иштөө оңой боло тургандай кылып түзүлгөн деген суроону койду. объектилер болуп саналат. Бул эки идеяны бириктирип, аларды өнүктүрө берсек, биз да колдоно аларыбызды байкайбыз СОЛИД келечекте бул логиканы сактоону жана өзгөртүүнү жеңилдетүү үчүн.

Бирдиктүү жоопкерчилик принциби

Ар бир класс бир гана тапшырманы аткарат.

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

Ачык жабык принцип

Ачык/жабык принцип.

• Кеңейтүү үчүн ачык: объекттин жүрүм-турумун жаңы объект түрлөрүн түзүү аркылуу кеңейтүүгө болот дегенди билдирет.
• Өзгөртүү үчүн жабык: Объекттин жүрүм-турумун кеңейтүүнүн натыйжасында, ал объекттерди колдонгон кодго эч кандай өзгөртүүлөр киргизилбеши керек.

Башында биз тесттик инфраструктураны виртуалдык машиналарга орноттук, бирок жайылтуунун бизнес логикасы ишке ашыруудан өзүнчө болгондуктан, биз baremetall'га эч кандай көйгөйсүз чыгууну коштук.

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

Барбара Лисковдун алмаштыруу принциби. программадагы объекттер программанын туура аткарылышын өзгөртпөстөн, алардын түрчөлөрүнүн инстанциялары менен алмаштырылышы керек.

Эгер кененирээк карасаңыз, ал жерде колдонула турган кандайдыр бир конкреттүү долбоордун өзгөчөлүгү эмес СОЛИД, бул жалпысынан CFM жөнүндө, мисалы, башка долбоордо ар кандай Java, тиркеме серверлеринин, маалымат базаларынын, OS ж.б. үстүнө кутуга салынган Java тиркемесин орнотуу керек. Бул мисалды колдонуу менен мен мындан аркы принциптерди карап чыгам СОЛИД

Биздин учурда, инфраструктуралык команданын ичинде биз imbjava же oraclejava ролун орноткон болсок, анда бизде Java бинардык аткарылуучусу бар деген келишим бар. Бул зарыл, анткени Жогорку агымдагы ролдор бул жүрүм-турумга жараша болот; алар Java күтүшөт. Ошол эле учурда, бул бизге тиркемени жайылтуу логикасын өзгөртпөстөн бир Java ишке ашыруу/версиясын башкасына алмаштырууга мүмкүндүк берет.

Бул жерде көйгөй Ansible муну ишке ашыруу мүмкүн эмес экендигинде, анын натыйжасында команданын ичинде кээ бир макулдашуулар пайда болот.

Interface Segregation Principle

Интерфейстерди бөлүү принциби: “Көптөгөн кардарларга тиешелүү интерфейстер бир жалпы максаттагы интерфейске караганда жакшыраак.

Башында, биз тиркемени жайылтуунун бардык өзгөрүлмөлүүлүгүн бир Ansible окуу китебине киргизүүгө аракет кылдык, бирок аны колдоо кыйын болду жана бизде тышкы интерфейс көрсөтүлгөндө (кардар 443-портту күтөт), андан кийин инфраструктураны жекеден чогултса болот. конкреттүү ишке ашыруу үчүн кирпич.

Көз карандылыктын инверсия принциби

Көз карандылыктын инверсия принциби. Жогорку деңгээлдеги модулдар төмөнкү деңгээлдеги модулдардан көз каранды болбошу керек. Модулдардын эки түрү тең абстракциялардан көз каранды болушу керек. Абстракциялар майда-чүйдөсүнө чейин көз каранды болбошу керек. Детальдар абстракцияларга көз каранды болушу керек.

Бул жерде мисал антипаттернге негизделет.

1. Кардарлардын биринде жеке булут бар болчу.
2. Биз булуттун ичиндеги виртуалдык машиналарга буйрук бердик.
3. Бирок булуттун мүнөзүнөн улам, тиркемени жайылтуу VM күйгүзүлгөн гипервизорго байланыштуу болгон.

Ошол. Жогорку деңгээлдеги тиркемени жайылтуу логикасы гипервизордун төмөнкү деңгээлдерине көз карандылык менен агып, бул логиканы кайра колдонууда көйгөйлөрдү билдирген. Мындай кылба.

өз ара аракеттенүү

Код катары инфраструктура код жөнүндө гана эмес, ошондой эле код менен адамдардын ортосундагы мамилелер, инфраструктураны иштеп чыгуучулардын ортосундагы өз ара аракеттенүү жөнүндө.

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

Сиздин долбоордо Вася бар деп ойлойлу. Вася сиздин инфраструктураңыз жөнүндө баарын билет, эгер Вася күтүлбөгөн жерден жок болуп кетсе эмне болот? Бул абдан реалдуу жагдай, анткени аны автобус сүзүшү мүмкүн. Кээде ушундай болот. Эгер ушундай болуп калса жана код, анын структурасы, анын иштеши, көрүнүштөр жана сырсөздөр тууралуу билим команда арасында бөлүштүрүлбөсө, анда сиз бир катар жагымсыз кырдаалдарга туш болушуңуз мүмкүн. Бул тобокелдиктерди азайтуу жана команданын ичинде билимди жайылтуу үчүн, ар кандай ыкмаларды колдоно аласыз

Pair Devopsing

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

Дагы бир өзгөчө жагдай - окуя чалуу. Көйгөй учурунда нөөмөттөгүлөр жана ага катышкандар чогулуп, бир лидер дайындалат, ал өзүнүн экранын бөлүшүп, ой поездин үндөйт. Башка катышуучулар лидердин ойлорун ээрчип, консолдон трюктарды аңдып, журналда бир сапты өткөрүп жибербегенин текшерип, система жөнүндө жаңы нерселерди үйрөнүшөт. Бул ыкма көп учурда иштеген.

Кодду карап чыгуу

Субъективдүү түрдө инфраструктура жана ал кодду карап чыгуу аркылуу анын иштеши жөнүндө билимди жайылтуу натыйжалуураак болду:

• Инфраструктура репозиторийдеги код менен сүрөттөлөт.
• Өзгөрүүлөр өзүнчө бутакта болот.
• Бириктирүү өтүнүчү учурунда инфраструктурадагы өзгөрүүлөрдүн дельтасын көрө аласыз.

Бул жердеги өзгөчөлүгү, рецензенттер график боюнча бирден тандалып алынган, б.а. кандайдыр бир ыктымалдуулук менен сиз инфраструктуранын жаңы бөлүгүнө чыгасыз.

код стили

Убакыттын өтүшү менен, сын-пикирлер учурунда чыр-чатактар ​​пайда боло баштады, анткени... серепчилердин өз стили болгон жана кароочулардын ротациясы аларды ар кандай стилдер менен бириктирген: 2 боштук же 4, camelCase же snake_case. Муну дароо ишке ашыруу мүмкүн болгон жок.

• Биринчи идея линтерди колдонууну сунуштоо болчу, анткени баары инженер, баары акылдуу. Бирок ар кандай редакторлор, OS, ыңгайлуу эмес
• Бул ар бир көйгөйлүү тапшырма үчүн боштук үчүн жазган жана линтер натыйжасын кошкон ботко айланган. Бирок көпчүлүк учурда маанилүү нерселер аткарыла турган жана код оңдолбогон.

Green Build Master

Убакыт өтүп, биз белгилүү бир сыноолордон өтпөй калган милдеттенмелерди кожоюнга киргизүүгө болбойт деген жыйынтыкка келдик. 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

Мыкты жасалды? Жок! Эгерде каталогдо эч нерсе жок болсо, б.а. globbing иштебейт.

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 астынан стекиңиз үчүн линтер таба аласыз.

тил
курал

Баш
Shellcheck

лаал
RuboCop

код
Пилинт

түшүнүктүү
Ansible Lint

IaC Testing: Unit Tests

Мурунку мисалдан көргөнүбүздөй, линтер кудуреттүү эмес жана бардык көйгөйлүү аймактарды көрсөтө албайт. Андан ары, программалык камсыздоону иштеп чыгуудагы тестирлөө менен салыштыруу менен биз бирдик тесттерин эстей алабыз. Ошол замат оюма келет шунит, жунит, rspec, питест. Бирок ansible, ашпозчу, saltstack жана аларга окшогондор менен эмне кылуу керек?

Биз башында сүйлөшкөнбүз СОЛИД биздин инфраструктурабыз майда кирпичтен турушу керек. Алардын убагы келди.

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

IaC Testing: Unit Testing Tools

Суроо, CFM үчүн тесттер деген эмне? Сиз жөн гана сценарийди иштете аласыз же бул үчүн даяр чечимдерди колдоно аласыз:

ТЧЖЖ
курал

Ansible
Testinfra

баш
Inspect

баш
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 тестирлөө алкактары

Суроо туулат: мунун баарын кантип бириктирип, ишке киргизүү керек? мүмкүн аны алып, өзүң кыл инженер-техник кызматкерлердин жетиштуу саны болсо. Же сиз даяр чечимдерди кабыл ала аласыз, бирок алардын саны көп эмес:

ТЧЖЖ
курал

Ansible
Молекула

баш
Test Kitchen

Terraform
Терратест

2018-2019-жылдары github боюнча долбоорлордогу өзгөртүүлөрдүн мисалы:

Молекула vs. Testkitchen

Башында биз testkitchen колдонууга аракет кылды:

1. Параллелдүү VM түзүңүз.
2. Ansible ролдорун колдонуңуз.
3. Текшерүүнү жүргүзүү.

25-35 ролго 40-70 мүнөт иштечү, бул узакка созулган.

Кийинки кадам jenkins/docker/ansible/molecule өтүү болду. Идиологиялык жактан баары бирдей

1. Lint окуу китептери.
2. Ролдорду тизгиле.
3. Контейнерди ишке киргизиңиз
4. Ansible ролдорун колдонуңуз.
5. Testinfra иштетиңиз.
6. Импотенттүүлүгүн текшерүү.

40 ролдор үчүн линтинг жана ондогон ролдор үчүн тесттер 15 мүнөттөй созула баштады.

Эмнени тандоо керектиги көптөгөн факторлордон көз каранды, мисалы, колдонулган стек, командадагы тажрыйба ж.б. Бул жерде ар бир адам бирдикти тестирлөө маселесин кантип жабууну өзү чечет

IaC тестирлөө: интеграциялык тесттер

Инфраструктураны тестирлөө пирамидасынын кийинки кадамы интеграциялык тесттер болот. Алар бирдик тесттерине окшош:

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

Болжол менен айтканда, биз системанын айрым элементинин иштешин бирдик тесттериндегидей текшербейбиз, сервер бүтүндөй конфигурацияланганын текшеребиз.

IaC Testing: End to End Tests

Пирамиданын чокусунда бизди End to End тесттери тосуп алат. Ошол. Биз өзүнчө сервердин, өзүнчө скрипттин же инфраструктурабыздын өзүнчө кирпичинин иштешин текшербейбиз. Биз көптөгөн серверлердин бири-бирине туташкандыгын текшеребиз, биздин инфраструктура биз күткөндөй иштейт. Тилекке каршы, мен эч качан даяр кутуланган чечимдерди көргөн эмесмин, балким, анткени... Инфраструктура көбүнчө уникалдуу жана тестирлөө үчүн калыпка салуу жана негиз түзүү кыйын. Натыйжада, ар ким өзүнүн чечимдерин түзөт. Талап бар, бирок жооп жок. Ошондуктан, мен сизге эмне бар экенин айтып берейин, башкаларды туура ойлорго түртүп же мурдумду ушалап, баары бизден мурун эле ойлоп табылган.

Бай тарыхы бар долбоор. Бул чоң уюмдарда колдонулат жана ар бириңиздер аны менен кыйыр түрдө кесилишкен. Колдонмо көптөгөн маалымат базаларын, интеграцияларды ж.б. Инфраструктура кандай болушу мүмкүн экенин билүү - бул көптөгөн докер-түзүүчү файлдар жана Дженкинс кайсы чөйрөдө кайсы тесттерди иштетүүнү билүү.

Бул схема алкагында чейин, бир топ убакыт бою иштеген изилдөө биз муну Openshiftге өткөрүүгө аракет кылган жокпуз. Контейнерлер ошол эле бойдон калууда, бирок ишке киргизүү чөйрөсү өзгөрдү (кайрадан салам DRY).

Изилдөө идеясы мындан ары да алдыга жылды жана openshiftте алар APB (Ansible Playbook Bundle) сыяктуу нерсени табышты, бул сизге инфраструктураны контейнерге кантип жайгаштыруу боюнча билимдерди топтоого мүмкүндүк берет. Ошол. инфраструктураны кантип жайылтуу керектиги боюнча кайталануучу, сыналуучу билим пункту бар.

Мунун баары биз гетерогендик инфраструктурага туш болмоюнча жакшы угулду: бизге тесттер үчүн Windows керек болчу. Натыйжада, эмне, кайда, кантип жайгаштыруу жана сынап билүү Женкинсте.

жыйынтыктоо

Код сыяктуу инфраструктура

• Репозиторийдеги код.
• Адамдын өз ара аракеттенүүсү.
• Инфраструктураны сыноо.

шилтемелер

• English Version
• Жеке блогдон кайчылаш пост
• Кургак чуркоо 2019 SpbLUG
• Video(RU) from DevopsConf 2019
• Video(RU) from DINS DevOps WEVENG 2019-06-20
• 300,000 XNUMX саптан ашык инфраструктуралык кодду жазуудан алынган сабактар & текст версиясы
• Инфраструктураны код катары үзгүлтүксүз жеткирүү түтүгүнө интеграциялоо
• Код катары инфраструктураны сыноо
• Ansible ролдорун эффективдүү өнүктүрүү жана колдоо
• Ansible bash эмес!

Source: www.habr.com