текст перекладу

Вступ

У сучасному швидко змінюваному бізнес-середовищі застосування принципів інфраструктури як коду (IaC) зазвичай автоматизується за допомогою конвеєрів або GitOps. Цикл життя інфраструктури має деякі схожі риси з циклом життя розробки програмного забезпечення: все починається з визначення мети, за якою слідує написання коду, перевірки та тестування, а також етап перегляду коду.

Однак є й деякі аспекти, які роблять розгортання інфраструктури як коду зовсім іншим порівняно з розробкою звичайного програмного забезпечення. Ці труднощі несуть ризики, які можуть сповільнювати команди. Ці ризики також обмежують практичне використання інфраструктури як коду лише для «експертних» команд, обмежуючи співпрацю в межах організації.

Покращивши процес перегляду, ми можемо зробити зміни в інфраструктурі такими ж простими, як і безперервне доставлення програмного забезпечення.

Давайте розглянемо, що ми можемо покращити і як це вписується в інженерію платформ і Team Topologies.

Ви не хочете випадково замінити базу даних

Труднощі

Які ж це труднощі, які відрізняють доставку IaC від «звичайного програмного забезпечення»?

Труднощі: Зміна коду не завжди є зміною інфраструктури

Коли ви змінюєте ім’я змінної в функції, ви отримуєте краще назване значення. Однак, коли ви змінюєте ім’я S3 бакету в проекті Terraform, ваш бакет буде замінений.

Тому може бути велика розбіжність між (малими) змінами в коді та реальним ефектом під час розгортання цієї зміни.

Це ускладнюється різними абстракціями, які використовуються з хороших причин: модулі Terraform, CDK конструкції, Helm charts утворюють повторно використовувані пакети, інкапсулюючи багато ресурсів. Тож невелике завдання з обслуговування, як оновлення версії модуля Terraform, ймовірно, спричинить кілька змін. Тепер автор такого модуля має відповідальність уникати непотрібних поломок, але в кінцевому підсумку ви несете відповідальність при використанні пакету.

Варто зазначити, що несподівані зміни можуть статися навіть тоді, коли код не змінювався. Одним з джерел, яких слід уникати, є click-ops. Іншим джерелом є автоматизовані системи, що конкурують за володіння. Але приклад більш тонкого джерела, з яким я стикався раніше, — це автоматичні незначні оновлення версії AWS ElastiCache автоматичні незначні оновлення версії (за замовчуванням). Якщо інші параметри не налаштовані відповідно, ви раптом стикаєтесь з заміною вашої конфігурації ElastiCache. Це точно не те, чого ви хочете.

Інший механізм, що ускладнює прогнозованість, — це накладення значень. Наприклад, Kustomize дозволяє використовувати накладки. Чудова концепція, але вона може ускладнити передбачення ефекту зміни коду на певне середовище. Щоб проілюструвати: зміна значення в базі може не мати жодного ефекту на виробниче середовище, оскільки воно вже визначено в накладці для виробництва. Це неможливо передбачити, просто переглядаючи зміну коду, оскільки це не показує незмінну накладку.

Підсумуємо:

• Малі зміни в коді можуть призвести до великих і несподіваних побічних ефектів, таких як видалення ресурсів
• Оновлення модулів призводять до важко передбачуваних змін в інфраструктурі
• Ефект накладок значень важко передбачити

Труднощі: Великі розгортання за раз

У традиційному програмному забезпеченні ми маємо різні методи, щоб убезпечити нас від помилок у виробництві. Ми можемо запускати різні тести в CI-конвеєрі, а потім дозволити CD-конвеєру переміщати той самий артефакт через різні середовища до виробництва¹.
текст перекладу
Розгортання в продакшн може використовувати методи, такі як канарейкові розгортання та поетапні оновлення.

Зміни інфраструктури відрізняються: немає єдиного артефакту, який можна перенести з середовища в середовище. Натомість кожне середовище має свій власний артефакт у вигляді запланованих змін. Також немає концепції поетапного розгортання. Крім того, розгортання інфраструктури іноді є незворотними або руйнівними. Наприклад, зниження версії бази даних зазвичай неможливе.

Звісно, зміни можуть бути спочатку розгорнуті в не-продакшн середовищах. І це працює до певної міри. Але зміна, яка стосується тільки продакшн середовища, наприклад зміна типу екземпляра, важко тестується. Крім того, якщо точно не відомо, що змінилося під час оновлення модуля, то як правильно протестувати ефект цих змін?

Труднощі: Доступ

Ще однією труднощами є доступ. Припустимо, ми врахували попередні труднощі, і ми, ймовірно, хочемо попередньо переглянути наші зміни перед поданням pull request. Це часто вимагає рівня доступу, якого ми не повинні мати. Цей доступ може бути на рівні мережі, авторизації або на обох рівнях. Наприклад, можливість використовувати kubectl diff може не бути такою простою, як очікується, і вимагати широких прав. І хоча доступ тільки для читання в багатьох випадках здається допустимим, для секретів це не так.

Покращення робочого процесу

Почнемо з основного робочого процесу для інфраструктури як коду:

Приклад базового робочого процесу для інфраструктури як коду

• Остання перевірка: Зазвичай це етап у конвеєрі, перед застосуванням, який показує зміни, які будуть застосовані. Потім на платформі автоматизації можна підтвердити запропоновані зміни. Якщо щось виглядає неправильно, це момент, коли процес скасовується, і потрібно створити новий pull request.
• Фокус: Це моменти, коли друга людина повинна змінити фокус на цей робочий процес. Рецензент повинен зрозуміти наміри автора, як під час перегляду, так і під час застосування змін. Автор може бути потрібен, коли зміни ось-ось будуть застосовані, щоб підтвердити питання. Це переключення завдань дороге і збільшує ймовірність помилок.
• Повторення циклів: Повторення можуть виникнути як із pull request, так і з останньою перевіркою. Кожен цикл повторення потребує нового pull request. І це приведе до додаткових переключень завдань.
• Ризик: Безпосередньо перед застосуванням може бути перший момент, коли запропоновані зміни стають видимими. Це вимагає узгодження між автором і тим, хто застосовує, і потребує уваги від обох. Як згадувалося раніше, переключення завдань збільшує ймовірність помилок. Отже, «швидка остання перевірка» може не отримати належної уваги, і люди можуть пропустити важливі деталі.

Тепер давайте подивимося, як ми можемо покращити цей робочий процес за допомогою кількох відносно невеликих змін:

• Ми інтегруємо запропоновані зміни в pull request
• Ми запускаємо перевірки на запропоновані зміни

Приклад покращеного робочого процесу для інфраструктури як коду

Це дає результат:

• Вилучений ризик: Зробивши запропоновані зміни доступними під час перегляду, і забезпечивши, що саме ці зміни будуть застосовані, ми уникнемо несподіваних змін.
• Зменшення переключень завдань: Тепер вся співпраця зводиться до одного випадку: Pull request. Зміни коду, а також результатуючі заплановані зміни інфраструктури, представлені в pull request. Це вимагає від рецензента переключити завдання лише один раз, і надає повний контекст.
• Перший раз правильно: Автор, не маючи доступу чи прав на цільове середовище, може побачити ефект змін коду. Це дозволяє автору виправити будь-які проблеми до подання pull request.
  текст перекладу
  Це значно зменшує ймовірність необхідності додаткових змін у коді, а отже, і нового pull request.
• Огородження через додаткові перевірки: Завдяки тому, що запропоновані зміни стали частиною перегляду, ми можемо виконати додаткові перевірки запропонованих змін. Наприклад: запобігти (небажаному) видаленню певних типів ресурсів або виконати перевірки політик.

У робочому процесі pull request запропоновані зміни доповнюватимуть зміни коду, і в більшості випадків навіть стануть основною точкою фокусу pull request.

Приклад нижче показує виведення terraform plan у pull request. Тут, ймовірно, ми збираємось видалити прослуховувач подій (Event Listener) з Keycloak realm, який тимчасово було додано за допомогою click-ops для тестування чогось². Без виведення плану це або залишилось би непоміченим (відсутність контролю), або потребувало б подальшого розслідування під час застосування (підвищене когнітивне навантаження).

Приклад виведення Terraform plan у GitHub PR

Як це вписується в інженерію платформ?

Що стосується «інженерії платформ», то ви, ймовірно, зіткнетеся з терміном «Внутрішня розробницька платформа» (IDP). Ось одне з визначень, яке можна знайти:

Внутрішня розробницька платформа (IDP) створюється і надається як продукт командою платформ для розробників додатків і решти інженерної організації. IDP об’єднує технології та інструменти підприємства в «золоті шляхи», що знижують когнітивне навантаження та дозволяють розробникам працювати самостійно.

Об’єднання, зниження когнітивного навантаження, самостійне обслуговування... Покращення pull request, як описано вище, відповідає цим вимогам. Щонайменше, до певної міри.

Залежно від того, кого запитати, IDP також може означати «Внутрішній розробницький портал». Ось таке визначення, яке чітко пояснює, як ці два терміни взаємопов’язані:

Внутрішні розробницькі портали служать інтерфейсом, через який розробники можуть відкривати і отримувати доступ до можливостей внутрішньої розробницької платформи.

Внутрішній розробницький портал об’єднує та інтегрує різні можливості: автоматизацію робочих процесів, каталог послуг, документацію, панелі моніторингу стану проєктів за метриками, такими як покриття тестами і вразливості. Зазвичай вони розташовуються поверх існуючих сервісів, таких як системи контролю версій або конвеєри, і повинні інтегруватися з цими сервісами. Результати можуть бути великими, але для початку потрібно серйозно інвестувати, щоб почати отримувати цю цінність.

Оскільки мова йде про інфраструктуру як код, портали зазвичай вимагають визначення робочих процесів для самостійного обслуговування, потім їх інтеграції в портал. І хоча це може добре інтегруватися в портал, це не означає автоматичної інтеграції в процес перегляду коду.

Метод, описаний в цій статті, використовує базові будівельні блоки, які, ймовірно, вже присутні в будь-якій організації:

• Система контролю версій з можливістю співпраці, така як: GitHub, GitLab, Bitbucket і подібні
• CI платформа, інтегрована з системою контролю версій (наприклад, GitHub actions) або окрема, така як Azure DevOps, AWS Code Pipeline, Argo Workflows тощо
• Інструмент інфраструктури як код. Це може бути що завгодно: Terraform, маніфести Kubernetes через Helm або Kustomize, CloudFormation, CDK, Bicep.

Це можна адаптувати до систем та інструментів, які використовуються, і це відносно легко реалізувати. Досвід розробника (DevEx) може бути хорошим для команд, які регулярно змінюють інфраструктуру як код. Щоб проілюструвати:

Порівняння робочих процесів порталу та покращених pull request

Якщо говорити про інфраструктуру як код, портал має потенціал для кращого DevEx. Але інвестиції в ідентифікацію і реалізацію робочого процесу можуть бути великими. Крім того, обсяг покращеного DevEx зазвичай обмежується впровадженими робочими процесами.

Оцінимо це: вартість проти...
текст перекладу
Завдяки цьому область покращень порталу значно зростає, що може виправдати інвестиції, якщо покращений DevEx і масштаб достатні.

Як це вписується в Team Topologies?

Розглянемо короткий опис Team Topologies:

Team Topologies — це підхід до проєктування організацій типу «команда команд» для швидкого потоку цінності.

Одна з чотирьох топологій, яку можна розглядати як «тип команди», це команда платформи:

Групування інших типів команд, які надають переконливий внутрішній продукт для прискорення доставки командами, орієнтованими на потік.

Отже, допомога командам, орієнтованим на потік, в прискоренні доставки. Це можна зробити, усунувши деякі з точок тертя, які внутрішня розробницька платформа прагне вирішити:

• Високе когнітивне навантаження
• Ticket Ops / Відсутність самостійного обслуговування
• Повільна доставка

Покращення робочого процесу pull request, як описано в цій статті, приносить користь самій команді платформи, але також дозволяє іншим командам легко долучатися. Це повертає їх під контроль над їхнім роадмапом. Замість «видачі квитків» вони можуть «створювати pull request». І в залежності від ситуації, вони можуть навіть самостійно затверджувати pull request.

У поєднанні з ретельно підібраною, упередженою бібліотекою пакетів, такою як модулі Terraform, конструкції CDK або Helm charts, когнітивне навантаження може бути знижено: щоденні зміни тоді стають просто зміною обмеженого набору параметрів. За бажанням, обмеження можуть забезпечити використання цих пакетів, зменшуючи розростання конфігурацій в організації.

Це надає можливість самостійного обслуговування для команд, орієнтованих на потік, а роль команди платформи трохи змінюється на роль «підтримуючої команди», надаючи керівництво та вказуючи на місця, де можливості платформи можуть бути обмежені.

Додаткові переваги та складнощі

Зосередження робочого процесу інфраструктури як коду навколо pull request вирішує труднощі, описані на початку цієї статті. Є деякі додаткові переваги:

• Аудитованість: Залежно від рівня регулювання або відповідності, ваша організація може вимагати наявність «процесу керування змінами», включаючи «принцип чотирьох очей» при застосуванні змін в інфраструктурі. Pull request вже налаштовані для цього: Захист гілки і необхідні рецензенти задовольняють принцип чотирьох очей, а закриті pull request, і багатий контекст, наданий в цих pull request, можуть слугувати як аудитний журнал змін в інфраструктурі.
• Простота інтеграції: Немає необхідності налаштовувати локальні середовища або доступ, щоб почати працювати з системами. Крім того, не потрібно одразу розуміти всі абстракції в проєкті: змінивши деякі змінні, одразу стає зрозуміло, який ефект це матиме. Крім того, попередні pull request можуть надати контекст і керівництво. Це допомагає командам платформи при залученні нових учасників, але також корисно при виконанні рідкісних завдань.
• Підготовка до обслуговування: Кодова база зазнає багатьох змін протягом свого життєвого циклу: частини еволюціонують, частини можуть потребувати видалення. З’являються повторювані патерни, які можуть потребувати рефакторингу. Коли це можна зробити з легкістю, впевнено, що не будуть введені руйнівні зміни, це позитивно впливає на якість коду та здатність до обслуговування в довгостроковій перспективі.

Однак є певні складнощі, які можуть вимагати (досить великої) додаткової роботи для вирішення:

• Що показувати? Що якщо зміна коду впливає на кілька AWS акаунтів? Або: на десятки чи сотні периферійних пристроїв? Залежно від кількості цілей, може бути необхідно вибрати представницький приклад для показу запланованих змін. Це неприродно вимагає, щоб цілі були налаштовані ідентично, слідуючи логічним патернам. Визначити, що показати, або як виявити викиди, може бути складно.
• Шум: Під час порівняння поточного і бажаного стану деякі типи метаданих можуть створювати шум. Це можуть бути зміни метаданих в поточному стані або зміни, введені автоматизацією.
  текст перекладу
  Залежно від природи, це може зробити фактичні зміни менш очевидними.
• Помилки під час застосування: У більшості випадків інструменти виявляють синтаксичні помилки або помилки конфігурації. Однак існують помилки, які виявляються лише під час спроби застосувати зміни. Наприклад, ім’я групи безпеки AWS повинно бути унікальним у межах VPC. У деяких випадках це може бути ознакою підлеглої проблеми: відсутності правил іменування, що гарантують унікальність. В інших випадках можна розглянути можливість додавання перевірок у конвеєр, які «переміщують проблему вліво».

Висновок

Додавання до pull request запланованих змін і використання політик — це, в принципі, не є революційним: платформи, такі як Terraform Cloud та Spacelift, пропонують подібні можливості. Для самостійного хостингу, для Terraform, можна розглянути Atlantis. З вересня 2024 року AWS CloudFormation має цю можливість також.

Хоча такі платформи або внутрішні розробницькі платформи загалом є дуже привабливими, є кілька аспектів, які потрібно враховувати: інтеграція з SSO, моделі RBAC, міграція існуючих робочих процесів, «чи потрібні нам локальні рушії з відповідним доступом до мережі?», «куди йдуть наші дані?» і «хто має ключі від нашого замку?». І це лише кілька.

Багато з цих тем можуть вже бути вирішені за допомогою існуючих інструментів для роботи з конвеєрами та git-робочими процесами, які використовуються. Максимізація їхньої цінності — це те, що можна реалізувати сьогодні, на відміну від закупівлі платформи, яка з’явиться не раніше, ніж завтра. І це можна зробити з майже будь-яким інструментом IaC: Terraform має крок плану. Kustomize і Helm пропонують можливості порівняння. Також це підтримує CDK, а Bicep від Azure має операцію what-if.

Ця стаття ілюструє, як відносно прості покращення можуть дати велику цінність. Якщо це вам цікаво, я раджу прочитати мій попередній блог про ‘Terrible’: у ньому описано інструмент, розроблений всередині компанії, який дозволив командам довгий час з впевненістю працювати з Terraform та Ansible. Як показує ця стаття, в наші дні немає потреби створювати такий інструмент, оскільки кращий DevEx можна досягти за допомогою базових інструментів DevOps, які вже використовуються в кожній організації.

У наступній статті я детальніше розгляну технічні аспекти інтеграції інфраструктури як коду, конвеєрів і GitHub.

Сподіваюся, це дасть натхнення для перегляду робочих процесів DevOps і виявлення можливих покращень. Дякую за увагу!

1. Це припускає окремі CI та CD конвеєри. Добра практика, але насправді ці конвеєри часто переплітаються в один. Проте є етапи, які будують (CI) і етапи, які розгортають (CD).
2. Сором. Сором. Також: прагматично. Але потрібно розуміти, що зміни click-ops можна скасувати в будь-який момент і вони можуть зіпсувати робочий процес інших, показуючи несподівані зміни.
3. Ця стаття в блозі від Humanitec, постачальника IDP, дає контекст щодо плутанини між платформою/порталом IDP.

Перекладено з: Infra pull requests that make a DIFFerence