У нас в компанії триває процес онбордінгу SRE-команди. Я зайшов на всю цю історію з боку розробки. У процесі у мене з'явилися думки та інсайти, якими хочу поділитися з іншими розробниками. У цій статті-роздумі я говорю про те, що відбувається, як відбувається, і як усім далі з цим жити.
Продовження серії статей, написаних за мотивами виступів на нашому внутрішньому заході :
2. Infrastructure as code. (You are here)
3. Генерація Typescript контрактів за моделями. (In progress…)
4. Введення у алгоритм консенсусу Raft. (In progress…)
...
Ми вирішили зробити команду SRE, втіливши ідеї . Набрали програмістів зі своїх розробників і відправили їх навчатися на кілька місяців.
Перед командою стояли такі навчальні завдання:
- Описати нашу інфраструктуру, яка здебільшого Microsoft Azure у вигляді коду (Terraform і все, що навколо).
- Навчити розробників роботи з інфраструктурою.
- Підготувати розробників до чергувань.
Вводимо поняття Infrastructure as code
У звичайній моделі світу (класичному адмініструванні) знання про інфраструктуру знаходяться у двох місцях:
- Або у вигляді знань у головах експертів.
- Або ці відомості знаходяться на якихось машинках, частина з яких знають експерти. Але не факт, що людина збоку (якщо вся наша команда раптово помре) зможе розібратися, що і як працює. На машині може бути багато відомостей: аксесуари, кронджоби, підмаучені (див. ) диск та просто нескінченний список того, що може відбуватися. Нею складно зрозуміти, що насправді відбувається.
В обох випадках ми опиняємось у пастці, стаючи залежними:
- або від людини, яка смертна, схильна до хвороб, закоханостей, перепадів настрою і просто банальних звільнень;
- або від фізично працюючої машини, яка теж падає, крадеться, підносить несподіванки та незручності.
Само собою напрошується рішення, що в ідеалі все треба перевести в людину, підтримуваний, якісно написаний код.
Таким чином інфраструктура як код (Incfastructure as Code – IaC) – це опис всієї наявної інфраструктури у вигляді коду, а також супутні засоби по роботі з ним та втілення з нього реальної інфраструктури.
Навіщо перекладати все на кодЛюди – не машини. Вони можуть запам'ятати все. Реакція у людини та машини різна. Все автоматизоване потенційно працює швидше, ніж усе, що робить людина. Найголовніше - це одне джерело правди (single source of truth).
Звідки беруться нові SRE-інженериОтже, ми вирішили підключити нових SRE-інженерів, але звідки їх купувати? Книга з правильними відповідями () каже нам: з розробників. Адже вони працюють із кодом, а ви досягаєте ідеального стану.
Ми багато і довго шукали їх на кадровому ринку за межами нашої компанії. Але змушені визнати, що не знайшли жодного під наші запити. Довелося пошерстити серед своїх.
Проблеми Infrastructure as code
Тепер давайте подивимося приклади того, як інфраструктура може бути зашита в код. Код добре написаний, якісно, з коментами та відступами.
Приклад коду Terraforma.
Приклад коду з Ansible.
Панове, але якби все було так просто! Ми ж з вами у реальному світі, а він завжди готовий здивувати вас, піднести сюрпризи, проблеми. Не обходиться без них тут.
1. Перша проблема у тому, що здебільшого IaC – це якийсь dsl.
А DSL, своєю чергою, – це опис структури. Точніше того, що в тебе має бути: Json, Yaml, модифікації від якихось великих компаній, які вигадали свій dsl (у тераформі використовується HCL).
Погано те, що в ньому може легко не бути таких звичних нам речей як:
- змінні;
- умови;
- десь немає коментарів, наприклад, у Json, дефолту їх не передбачено;
- функції;
- і це я ще не кажу про такі високорівневі речі, як класи, успадкування і таке інше.
2. Друга проблема такого коду – найчастіше це гетерогенне середовище. Зазвичай сидите і працюєте з C#, тобто. з однією мовою, одним стеком, однією екосистемою. А тут у вас величезна різноманітність технологій.
Цілком реальна ситуація, коли баш із пітоном запускає якийсь процес, у який підсовується Json. Ви його аналізуєте, потім якийсь генератор видає ще 30 файлів. Для всього цього надходять вхідні змінні з Azure Key Vault, які стягнуті плагіном до drone.io, написаним на Go, і ці змінні проходять через yaml, який вийшов в результаті генерації з шаблонизатора jsonnet. Досить складно мати строго добре описаний код, коли у вас настільки різноманітне середовище.
Традиційна розробка в рамках одного завдання йде однією мовою. Тут ми працюємо з великою кількістю мов.
3. Третя проблема – це тулінг. Ми звикли до крутих редакторів (Ms Visual Studio, Jetbrains Rider), які роблять за нас. І навіть, якщо ми затупили, вони скажуть, що ми не маємо рації. Здається, що це нормально та природно.
Але десь поряд є VSCode, в якому є якісь плагіни, які якось ставляться, підтримуються чи не підтримуються. Вийшли нові версії і їх не підтримали. Банальний перехід до імплементації функції (навіть якщо вона є) стає складною та нетривіальною проблемою. Простий ренейм змінної – це реплейс у проекті із десятка файлів. Пощастить, якщо він те, що треба зареплейсить. Є, звичайно, де-не-де підсвічування, є автокомплішн, десь є форматинг (правда у мене в тераформі на вінді не завівся).
На момент написання статті ще не випустили для підтримки версії 0.12, хоч вона зарелижена вже як 3 місяці.
Настав час забути про…
- Налагодження.
- Refactoring tool.
- Auto completion.
- Виявлення помилок під час компіляції.
Смішно, але це збільшує час на розробку і збільшує кількість помилок, які неминуче відбуваються.
Найстрашніше, що ми змушені думати не про те, як спроектувати, розкласти файли по папочках, декомпозувати, зробити підтримуваним, читаним і так далі код, а про те, як мені коректно написати цю команду, бо я її якось неправильно написав. .
Як новачок ви намагаєтеся пізнати тераформ, а IDE вам у цьому анітрохи не допомагає. Коли є документація – зайшли, подивились. Але якби ви в'їжджали в нову мову програмування, то IDE підказала б, що такий тип, а такого немає. Принаймні на рівні int або string. Це часто буває корисним.
А як же випробування?
Ви запитаєте: «Як же тести, панове програмісти?» Серйозні хлопці тестують все на продажі, і це жорстко. Ось приклад юнітесту для тераформ-модуля із сайту .
Вони мають гарну документацію. Microsoft мені завжди подобалися своїм підходом до документації та навчання. Але не треба бути дядечком Бобом, щоб зрозуміти, що тут не ідеальний код. Зверніть увагу на валідацію, винесену праворуч.
Проблема unit-тесту в тому, що ми з вами можемо перевірити коректність Json на виході. Я кинув 5 параметрів, мені видалася онучка Json на 2000 рядків. Я можу проаналізувати, що відбувається, validate test result…
Важко аналізувати Json у Go. А треба писати в Go, тому що тераформ на Go – це хороша практика того, що тестуєш тією мовою, якою ти пишеш. Сама організація коду дуже слабка. При цьому це найкраща бібліотека для тестування.
Сам Microsoft пише свої модулі, тестуючи їх у такий спосіб. Звісно, це Open Source. Все, про що я говорю, ви можете прийти і відремонтувати. Я можу сісти і за тиждень все полагодити, заопенсорсить плагіни VS-коду, тераформ, зробити плагін для райдера. Можливо, написати парочку аналізаторів, прикрутити лінтери, законтриб'ютити бібліотеку для тестування. Все можу зробити. Але я не цим маю займатися.
Найкращі практики Infrastructure as code
Їдемо далі. Якщо в IaC немає тестів, погано з IDE та тулінгом, то мають бути хоча б найкращі практики. Я просто пішов у гугл-аналітику та провів порівняння двох пошукових запитів: Terraform best practices та c# best practices.
Що ми бачимо? Нещадну статистику не на нашу користь. За кількістю матеріалу – те саме. У C# розробці ми просто купаємось у матеріалах, у нас є надкращі практики, є книги написані експертами, а також книжки, написані на книжки іншими експертами, які критикують ті книжки. Море офіційної документації, статей, які навчають курсів, зараз ще й open source розробка.
Що стосується запиту по IaC: тут ви по крихтах намагаєтеся зібрати інфу з доповідей хайлоада або HashiConf, з офіційної документації та численних issue на гітхабі. Як загалом ці модулі розкидати, що з ними робити? Здається, що це реальна проблема... Є ж ком'юніті, панове, де на будь-яке запитання тобі дадуть 10 коментів на гітхабі. Але це не точно.
На жаль, зараз експерти тільки починають з'являтися. Поки що їх замало. А саме комьюніті бовтається лише на рівні зачатків.
Куди це все рухається і що робити
Можна все кинути та піти назад на C#, у світ райдера. Але немає. Навіщо ви взагалі стали б цим займатися, якщо не знайти рішення. Далі я наводжу свої суб'єктивні висновки. Можете посперечатися зі мною у коментарях, буде цікаво.
Особисто я ставлю на кілька речей:
- Розвиток у цій сфері відбувається дуже швидко. Наводжу графік запитів з DevOps.
Можливо, тема хайпова, але сам факт того, що сфера зростає, вселяє деяку надію.Якщо щось росте настільки швидко, то обов'язково з'являться розумні люди, які скажуть, як треба робити, а як не треба. Збільшення популярності веде до того, що в когось буде час дописати нарешті плагін до jsonnet для vscode, який дозволить переходити до імплементації функції, а не шукати її через ctrl+shift+f. Коли все розвивається, з'являється більше матеріалів. Той же вихід книги від гугла про SRE чудовий приклад.
- Є розроблені методики та практики у звичайній розробці, які ми можемо успішно застосовувати тут. Так, є нюанси з тестуванням та гетерогенним середовищем, недостатній тулінг, але накопичено величезну кількість практик, які можуть стати в нагоді та допомогти.
Банальний приклад: спільна робота через pair programming. Він дуже допомагає розібратися. Коли в тебе є сусід, який теж щось намагається зрозуміти, разом ви зрозумієте краще.
Розуміння про те, як робиться рефакторинг, допомагає навіть у такій ситуації виробляти його. Тобто, ти можеш поміняти не все відразу, а поміняти неймінг, потім поміняти прихильність, потім може виділити якусь частину, ой, а тут не вистачає коментарів.
Висновок
Незважаючи на те, що мої міркування можуть здатися песимістичною, я з надією дивлюся в майбутнє і щиро сподіваюся, що у нас (і у вас) все вийде.
Слідом готується друга частина статті. У ній я розповім про те, як ми спробували застосовувати практики гнучкої розробки, щоб покращити наш процес навчання та роботу з інфраструктурою.
Джерело: habr.com