Подход IaC (Инфраструктура като код) се състои не само от кода, който се съхранява в хранилището, но и от хората и процесите, които обграждат този код. Възможно ли е повторно използване на подходи от разработването на софтуер до управлението и описанието на инфраструктурата? Би било добра идея да имате предвид тази идея, докато четете статията.

Angielski версия

Това е моят препис представления на DevopsConf 2019-05-28.

Слайдове и видеоклипове

• Angielski версия
• Руска версия
• Пробег на сухо 2019-04-24 SpbLUG
• Видео (RU) от DevopsConf 2019-05-28
• Видео (RU) от DINS DevOps EVENING 2019-06-20
• Пързалки

Инфраструктура като bash история

Да предположим, че идвате на нов проект и те ви казват: „Имаме Инфраструктурата като код". В действителност се оказва Инфраструктура като bash история или например Документация като bash история. Това е съвсем реална ситуация, например подобен случай беше описан от Денис Лисенко в реч Как да сменим цялата инфраструктура и да започнем да спим спокойно, той разказа как са получили съгласувана инфраструктура за проекта от историята на bash.

С известно желание можем да го кажем Инфраструктура като bash история това е като код:

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

Какво да правя?

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

Дори такъв странен случай като Инфраструктура като bash история можете да го дърпате за ушите Инфраструктурата като код, но когато искаме да направим нещо по-сложно от добрия стар LAMP сървър, ще стигнем до извода, че този код трябва по някакъв начин да бъде модифициран, променен, подобрен. След това бихме искали да разгледаме паралелите между Инфраструктурата като код и разработка на софтуер.

ИЗСУШАВАНЕ

В проект за разработка на система за съхранение имаше подзадача периодично конфигурирайте SDS: пускаме нова версия - тя трябва да бъде пусната за по-нататъшно тестване. Задачата е изключително проста:

• влезте тук чрез ssh и изпълнете командата.
• копирайте файла там.
• коригирайте конфигурацията тук.
• стартирайте услугата там
• ...
• ПЕЧАЛБА!

За описаната логика bash е повече от достатъчен, особено в ранните етапи на проекта, когато той тепърва започва. Това не е лошо да използваш bash, но с течение на времето има заявки за внедряване на нещо подобно, но малко по-различно. Първото нещо, което идва на ум е copy-paste. И сега вече имаме два много подобни скрипта, които правят почти едно и също нещо. С течение на времето броят на скриптовете нарасна и се сблъскахме с факта, че има определена бизнес логика за внедряване на инсталация, която трябва да се синхронизира между различни скриптове, това е доста сложно.

Оказва се, че има такава практика като DRY (Не се повтаряйте). Идеята е да се използва повторно съществуващ код. Звучи просто, но не стигнахме до това веднага. В нашия случай това беше банална идея: да се отделят конфигурациите от скриптовете. Тези. бизнес логика за това как инсталацията се внедрява отделно, конфигурациите отделно.

ТВЪРД за CFM

С течение на времето проектът се разраства и естествено продължение беше появата на Ansible. Основната причина за появата му е, че има експертиза в екипа и че bash не е предназначен за сложна логика. Ansible също започна да съдържа сложна логика. За да се предотврати превръщането на сложната логика в хаос, има принципи за организиране на кода при разработването на софтуер ТВЪРД Също така, например, Григорий Петров в доклада „Защо един ИТ специалист се нуждае от лична марка“ повдигна въпроса, че човек е проектиран по такъв начин, че да му е по-лесно да работи с някои социални единици, при разработването на софтуер тези са обекти. Ако комбинираме тези две идеи и продължим да ги развиваме, ще забележим, че можем също да използваме ТВЪРД за да улесним поддържането и модифицирането на тази логика в бъдеще.

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

Всеки клас изпълнява само една задача.

Няма нужда да смесвате код и да правите монолитни божествени спагети чудовища. Инфраструктурата трябва да се състои от прости тухли. Оказва се, че ако разделите книгата за игри на Ansible на малки части, прочетете ролите на Ansible, тогава те са по-лесни за поддържане.

Принципът Отворено Затворено

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

• Отворено за разширение: означава, че поведението на даден обект може да бъде разширено чрез създаване на нови типове обекти.
• Затворено за промяна: В резултат на разширяване на поведението на даден обект не трябва да се правят промени в кода, който използва тези обекти.

Първоначално внедрихме тестовата инфраструктура на виртуални машини, но поради факта, че бизнес логиката на внедряване беше отделна от изпълнението, добавихме внедряване към baremetall без никакви проблеми.

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

Принципът на заместване на Барбара Лисков. обектите в програмата трябва да могат да се заменят с екземпляри на техните подтипове, без да се променя правилното изпълнение на програмата

Ако го погледнете по-широко, това не е характеристика на конкретен проект, който може да се приложи там ТВЪРД, обикновено става въпрос за CFM, например, в друг проект е необходимо да се разположи Java приложение в кутия върху различни Java, сървъри за приложения, бази данни, ОС и т.н. Използвайки този пример, ще разгледам допълнителни принципи ТВЪРД

В нашия случай има споразумение в рамките на инфраструктурния екип, че ако сме инсталирали ролята imbjava или oraclejava, тогава имаме двоичен изпълним файл на Java. Това е необходимо, тъй като Ролите нагоре по веригата зависят от това поведение; те очакват java. В същото време това ни позволява да заменим една реализация/версия на Java с друга, без да променяме логиката за внедряване на приложението.

Проблемът тук се крие във факта, че е невъзможно да се приложи това в Ansible, в резултат на което се появяват някои споразумения в екипа.

Принципът на разделяне на интерфейса

Принцип на разделяне на интерфейса: „Много специфични за клиента интерфейси са по-добри от един интерфейс с общо предназначение.

Първоначално се опитахме да поставим цялата променливост на внедряването на приложения в една Ansible playbook, но беше трудно да се поддържа и подходът, когато имаме указан външен интерфейс (клиентът очаква порт 443), тогава инфраструктура може да бъде сглобена от отделни тухли за конкретно изпълнение.

Принципът на инверсия на зависимостта

Принципът на инверсия на зависимостта. Модулите на по-високи нива не трябва да зависят от модули на по-ниски нива. И двата вида модули трябва да зависят от абстракциите. Абстракциите не трябва да зависят от детайлите. Подробностите трябва да зависят от абстракциите.

Тук примерът ще се основава на антимодел.

1. Един от клиентите имаше частен облак.
2. Поръчахме виртуални машини в облака.
3. Но поради естеството на облака, внедряването на приложението беше обвързано с това на кой хипервайзор е включена виртуалната машина.

Тези. Логиката за внедряване на приложения на високо ниво протичаше със зависимости към по-ниските нива на хипервайзора и това означаваше проблеми при повторното използване на тази логика. Не правете така.

Взаимодействие

Инфраструктурата като код не е само за код, но и за връзката между код и хора, за взаимодействията между разработчиците на инфраструктура.

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

Да приемем, че имате Вася във вашия проект. Вася знае всичко за вашата инфраструктура, какво ще стане, ако Вася внезапно изчезне? Това е съвсем реална ситуация, защото може да бъде блъснат от автобус. Понякога се случва. Ако това се случи и знанията за кода, неговата структура, как работи, изяви и пароли не се разпределят между екипа, тогава може да срещнете редица неприятни ситуации. За да минимизирате тези рискове и да разпределите знанията в екипа, можете да използвате различни подходи

Девопсинг по двойки

Не е като като на шега, че админите пили бира, сменяли пароли и аналог на програмирането по двойки. Тези. двама инженери сядат на един компютър, една клавиатура и започват да настройват вашата инфраструктура заедно: настройка на сървър, писане на Ansible роля и т.н. Звучи добре, но не ни се получи. Но специални случаи на тази практика работеха. Идва нов служител, менторът му поема реална задача заедно с него, работи и предава знания.

Друг специален случай е инцидентно обаждане. По време на проблем се събира група от дежурни и замесени, назначава се един лидер, който споделя своя екран и озвучава хода на мислите. Други участници следват мислите на лидера, шпионират трикове от конзолата, проверяват дали не са пропуснали ред в дневника и научават нови неща за системата. Този подход работеше по-често, отколкото не.

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

Субективно беше по-ефективно да се разпространяват знания за инфраструктурата и как тя работи с помощта на преглед на кода:

• Инфраструктурата е описана чрез код в хранилището.
• Промените настъпват в отделен клон.
• По време на заявка за сливане можете да видите делтата на промените в инфраструктурата.

Акцентът тук беше, че рецензентите се избираха един по един, по график, т.е. с известна степен на вероятност ще се изкачите в нова част от инфраструктурата.

кодов стил

С течение на времето започнаха да се появяват дрязги по време на прегледи, защото... рецензентите имаха свой собствен стил и ротацията на рецензентите ги подреждаше с различни стилове: 2 интервала или 4, camelCase или snake_case. Не беше възможно това да се приложи веднага.

• Първата идея беше да се препоръча използването на linter, в крайна сметка всеки е инженер, всеки е умен. Но различните редактори, OS, не са удобни
• Това се превърна в бот, който пишеше в slack за всеки проблемен комит и прикачваше изхода от linter. Но в повечето случаи имаше по-важни неща за вършене и кодът оставаше непоправен.

Майстор на зеленото строителство

Времето минава и ние стигнахме до заключението, че ангажименти, които не преминават определени тестове, не могат да бъдат допуснати до главния. Ето! Ние изобретихме Green Build Master, който се практикува в разработката на софтуер от дълго време:

• Разработката е в ход в отделен клон.
• В тази тема се провеждат тестове.
• Ако тестовете се провалят, кодът няма да влезе в главния.

Вземането на това решение беше много болезнено, защото... предизвика много спорове, но си заслужаваше, защото... Отзивите започнаха да получават заявки за сливания без различия в стила и с течение на времето броят на проблемните области започна да намалява.

Тестване на IAC

В допълнение към проверката на стила, можете да използвате други неща, например, за да проверите дали вашата инфраструктура действително може да се разгърне. Или проверете дали промените в инфраструктурата няма да доведат до загуба на пари. Защо това може да е необходимо? Въпросът е сложен и философски, по-добре е да се отговори с история, че по някакъв начин е имало автоматичен скалер на Powershell, който не е проверявал граничните условия => създадени са повече виртуални машини от необходимото => клиентът е похарчил повече пари от планираното. Това не е много приятно, но би било напълно възможно да се хване тази грешка на по-ранни етапи.

Някой може да попита, защо да правим сложната инфраструктура още по-сложна? Тестовете за инфраструктура, точно както за кода, не са за опростяване, а за това да знаете как трябва да работи вашата инфраструктура.

Пирамида за тестване на 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.

Език
Инструмент

тряскам
Shellcheck

Рубин
Рубокоп

питон
Пилинт

ansible
Ansible Lint

IaC тестване: Единични тестове

Както видяхме от предишния пример, линтерите не са всемогъщи и не могат да посочат всички проблемни области. Освен това, по аналогия с тестването в разработката на софтуер, можем да си припомним модулните тестове. Това, което веднага идва на ум е шунит, джунит, rspec, pytest. Но какво да правим с ansible, chef, saltstack и други като тях?

В самото начало говорихме за ТВЪРД и че нашата инфраструктура трябва да се състои от малки тухли. Дойде им времето.

1. Инфраструктурата е разделена на малки тухли, например Ansible роли.
2. Внедрява се някакъв вид среда, независимо дали е докер или виртуална машина.
3. Ние прилагаме нашата Ansible роля към тази тестова среда.
4. Проверяваме дали всичко работи както очаквахме (пускаме тестове).
5. Ние решаваме добре или не.

IaC тестване: Инструменти за тестване на единици

Въпрос, какви са тестовете за CFM? Можете просто да стартирате скрипта или можете да използвате готови решения за това:

CFM
Инструмент

Ansible
Тестинфра

Главният ни готвач
Проверете

Главният ни готвач
Спецификация на сървъра

солник
Гос

Пример за 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
молекула

Главният ни готвач
Тестова кухня

тераформира
Terratest

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

Молекула срещу. Тестова кухня

Първоначално ние опитах да използвам 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 минути.

Какво да изберете зависи от много фактори, като например използвания стек, опит в екипа и т.н. тук всеки сам решава как да затвори въпроса за Unit testing

Тестване на IAC: Интеграционни тестове

Следващата стъпка в пирамидата за тестване на инфраструктура ще бъдат интеграционните тестове. Те са подобни на Unit тестовете:

1. Инфраструктурата е разделена на малки тухли, например Ansible роли.
2. Внедрява се някакъв вид среда, независимо дали е докер или виртуална машина.
3. За тази тестова среда се прилага много Анзибилни роли.
4. Проверяваме дали всичко работи както очаквахме (пускаме тестове).
5. Ние решаваме добре или не.

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

Тестване на IAC: Тестове от край до край

На върха на пирамидата ни посрещат тестове от край до край. Тези. Ние не проверяваме производителността на отделен сървър, отделен скрипт или отделна тухла от нашата инфраструктура. Проверяваме дали много сървъри са свързани заедно, нашата инфраструктура работи както очакваме. За съжаление никога не съм виждал готови решения в кутия, вероятно защото... Инфраструктурата често е уникална и трудна за шаблониране и създаване на рамка за тестване. В резултат на това всеки създава свои собствени решения. Искане има, но отговор няма. Затова ще ви кажа какво има, за да подтикна другите към здрави мисли или да натрия носа си във факта, че всичко е измислено отдавна преди нас.

Проект с богата история. Използва се в големи организации и вероятно всеки от вас индиректно се е сблъсквал с него. Приложението поддържа много бази данни, интеграции и др. Да знаеш как може да изглежда инфраструктурата е много файлове за композиране на докери, а да знаеш кои тестове да изпълняваш в коя среда е Дженкинс.

Тази схема работи доста дълго време, докато влезе в рамките проучване не сме опитвали да прехвърлим това в Openshift. Контейнерите остават същите, но средата за стартиране се промени (здравей DRY отново).

Идеята за изследване отиде по-далеч и в openshift те откриха нещо като APB (Ansible Playbook Bundle), което ви позволява да опаковате знания за това как да разположите инфраструктура в контейнер. Тези. има повторяема, тествана точка от знания за това как да се разгърне инфраструктурата.

Всичко това звучеше добре, докато не се натъкнахме на хетерогенна инфраструктура: Windows ни трябваше за тестове. В резултат на това знанието за това какво, къде, как да внедрите и тествате е в jenkins.

Заключение

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

• Код в хранилището.
• Човешко взаимодействие.
• Тестване на инфраструктурата.

Връзки

• На английски език
• Кръстосана публикация от личен блог
• Пробег на сухо 2019-04-24 SpbLUG
• Видео (RU) от DevopsConf 2019-05-28
• Видео (RU) от DINS DevOps EVENING 2019-06-20
• Уроци, извлечени от писането на над 300,000 XNUMX реда инфраструктурен кодекс & текстова версия
• Интегриране на инфраструктурата като код в тръбопровод за непрекъсната доставка
• Тестване на инфраструктура като код
• Ефективно развитие и поддръжка на Ansible роли
• Ansible не е баш!

Източник: www.habr.com