Більшість із нас, помічаючи черговий новий термін в IT блогосфері чи конференції, рано чи пізно задається таким питанням: “Що це? Чергове модне слово, “buzzword” чи дійсно щось варте пильної уваги, вивчення та обіцяючого нові горизонти?” Так само вийшло у мене і з терміном GitOps деякий час тому. Озброївшись безліччю вже існуючих статей, а також знанням колег із компанії я спробував розібратися, що ж це за звір, і як його застосування може виглядати на практиці.
До речі, про новизну терміна GitOps також каже нещодавно проведене нами опитування: більше половини опитаних ще не розпочинали роботи з його принципами.
Отже, проблема управління інфраструктурою не є новою. Безліч хмарних провайдерів вже добрий десяток років доступні широкому загалу і, здавалося б, повинні були зробити роботу команд, що відповідають за інфраструктуру, простою і невигадливою. Однак при порівнянні з процесом розробки додатків (де рівень автоматизації досягає нових і нових горизонтів), інфраструктурні проекти все ще часто включають безліч виконуваних вручну завдань і вимагають особливих знань і фахівців, особливо з урахуванням сучасних вимог до відмовостійкості, гнучкості, масштабованості та еластичності.
Хмарні сервіси дуже успішно виконували ці вимоги, і саме вони дали значний поштовх розвитку підходу. IaC. Воно й зрозуміло. Адже саме вони дали можливість конфігурувати повністю віртуальний центр обробки даних: немає фізичних серверів, стійок, мережевих компонентів, всю інфраструктуру можна описати за допомогою скриптів та конфігураційних файлів.
Так у чому власне відмінність GitOps від IaC? Саме з цього питання я почав своє розслідування. Поспілкувавшись із колегами, мені вдалося виробити таке порівняння:
GitOps
IaC
Весь код зберігається в git репозиторії
Версійність коду необов'язкова
Декларативний опис коду / Ідемпотентність
Допустимо як декларативний, так і імперативний опис
Зміни набувають чинності з використанням механізмів Merge Request / Pull Request
Погодження, затвердження та колаборація необов'язкові
Процес викочування оновлень автоматизований
Процес викочування оновлень не нормований (автоматичний, ручний, копіювання файлів, з використанням командного рядка і т.д.)
Іншими словами GitOps народився саме завдяки застосуванню принципів IaC. По-перше, інфраструктуру і конфігурації тепер можна було зберігати так само, як і програми. Код легко зберігати, легко ділитися, порівнювати, користуватися можливостями версійності. Версії, гілки, історія. І все це у загальнодоступному для всієї команди місці. Тому закономірним розвитком стало використання систем контролю версій. Зокрема, git, як найбільш популярний.
З іншого боку, виникла можливість автоматизувати процеси управління інфраструктурою. Тепер це можна зробити швидше, надійніше та дешевше. Тим більше принципи CI/CD вже були відомі та популярні серед розробників програмного забезпечення. Необхідно було лише перенести та застосувати вже відомі знання та навички у нову область. Ці практики, однак, виходили за рамки стандартного визначення Інфраструктури як коду, звідси й народилося поняття. GitOps.
Цікавість GitOps, звичайно, ще й у тому, що це не продукт, плагін або платформа, пов'язана з будь-яким вендором. Це радше парадигма і набір принципів, аналогічно до іншого знайомого нам терміном: DevOps.
У компанії ми виробили два визначення цього нового терміна: теоретичний та практично. Почнемо з теоретичного:
GitOps — це методологія, яка використовує передові принципи DevOps, які використовуються для розробки програм, такі як контроль версій, взаємодія, узгодження, CI/CD, та застосовує їх для вирішення задач автоматизації управління інфраструктурою.
Усі процеси GitOps працюю з використанням наявних інструментів. Весь інфраструктурний код зберігаються у вже знайомому git репозиторії, зміни проходять той самий процес узгодження, що й будь-який інший програмний код, а процес викату автоматизований, що дозволяє мінімізувати помилки людського фактора, підвищити надійність і відтворюваність.
З практичної точки зору ми описуємо GitOps наступним чином:
Інфраструктуру як код ми вже обговорили як одну з ключових складових цієї формули. Давайте уявимо інших учасників.
Merge Request (альтернативна назва Pull Request). У плані процесу MR — це запит застосування змін коду і подальше злиття гілок. Але в плані інструментів, якими ми користуємося, це швидше можливість для отримання повної картини всіх змін, що вносяться: не тільки code diff, зібраний з якоїсь кількості коммітів, а й контекст, результати тестів, кінцевий очікуваний результат. Якщо ми говоримо про інфраструктурний код, нам цікаво, як саме зміниться інфраструктура, скільки нових ресурсів буде додано або видалено, змінено. Бажано в якомусь зручнішому та легко читаному форматі. У випадку з хмарними провайдерами непогано було б знати, які фінансові наслідки зазнає цієї зміни.
Але MR це ще й засіб спільної роботи, взаємодії, спілкування. Те місце, де набирає чинності система стримувань і противаг. Від простих коментарів до формальних схвалень та тверджень.
Ну і остання складова: CI/CD, як ми вже знаємо, дає можливість автоматизувати процес внесення інфраструктурних змін, тестування (від простої перевірки синтаксису до складнішого статичного аналізу коду). А також і в подальшому виявлення дрейфу: відмінностей реального та бажаного стану системи. Наприклад, в результаті несанкціонованих ручних змін або відмови систем.
Так, термін GitOps не знайомить нас ні з чим абсолютно новим, не винаходить велосипед, а лише застосовує вже накопичений досвід у новій області. Але в цьому й полягає його сила.
А якщо вам раптом стане цікаво, як це все виглядає на практиці, то запрошую подивитись наш , в якому я покроково розповідаю, як за допомогою GitLab:
-
Реалізувати основні засади GitOps
-
Створювати та вносити зміни до хмарної інфраструктури (на прикладі Yandex Cloud)
-
Автоматизувати виявлення дрейфу системи від бажаного стану за допомогою активного моніторингу
https://bit.ly/34tRpwZ
Джерело: habr.com