GitOps: порівняння методів Pull та Push

Прим. перев.: У спільноті Kubernetes явну популярність набирає тренд під назвою GitOps, в чому ми особисто переконалися, відвідавши KubeCon Europe 2019. Цей термін був відносно нещодавно придуманий главою компанії Weaveworks - Alexis Richardson - і означає застосування звичних для розробників інструментів (насамперед - Git, звідки і сама назва) для вирішення завдань експлуатації. Зокрема, мова про експлуатацію Kubernetes через зберігання його конфігурацій у Git та автоматичного викочування змін у кластер. Про два підходи до цього викату і розповідає Matthias Jg у цій статті.

У минулому році (насправді, формально це сталося у серпні 2017 р. — прим. перекл.) з'явився новий підхід до розгортання додатків у Kubernetes. Він називається GitOps, а в його основі лежить базове уявлення про те, що відстеження версій deployment'ів ведеться у безпечному середовищі Git-репозиторію.

Основні переваги цього підходу такі:

1. Версіонування deployment'ів та історія змін. Стан всього кластера зберігається в Git-репозиторії, а deployment'и оновлюються лише шляхом коммітів. Крім того, всі зміни можна відслідковувати за допомогою історії комітів.
2. Відкати з використанням звичних команд Git. простий git reset дозволяє скидати зміни у deployment'ах; завжди доступні попередні стани.
3. Готовий контроль доступу. Зазвичай Git-система містить безліч конфіденційних даних, тому більшість компаній приділяють особливу увагу її захисту. Відповідно, цей захист поширюється і на операції з deployment'ами.
4. Політики для розгортань. Більшість Git-систем спочатку підтримують політики для різних гілок - наприклад, тільки pull request'и можуть оновлювати master, а зміни повинен перевірити та прийняти інший член команди. Як і з контролем доступу, ті ж політики застосовуються до оновлень deployment'ів.

Як бачите, метод GitOps має безліч переваг. За останній рік особливу популярність набрали два підходи. Один заснований на push, інший на pull. Перш ніж їх розглянути, давайте спочатку подивимося, як виглядають типові deployment'и Kubernetes.

Способи розгортання

За останні роки в Kubernetes устоялися різні способи та інструменти для розгортань:

1. На основі рідних шаблонів Kubernetes/Kustomize. Це найпростіший спосіб розгортання додатків у Kubernetes. Розробник створює базові YAML-файли та застосовує їх. Щоб позбутися постійного переписування тих самих шаблонів, був розроблений Kustomize (він перетворює шаблони Kubernetes на модулі). Прим. перев.: Kustomize був інтегрований у kubectl з релізом Kubernetes 1.14.
2. Чарти Helm. Чарти Helm дозволяють створювати набори шаблонів, init-контейнерів, sidecar'ів тощо, які застосовуються для деплою додатків із більш гнучкими можливостями налаштування, ніж у підході на основі шаблонів. В основі цього методу лежать шаблонизовані YAML-файли. Helm заповнює їх різними параметрами і потім відправляє Tiller'у — кластерному компоненту, який розгортає їх у кластері та дозволяє виконувати оновлення та відкати. Важливо те, що по суті Helm просто вставляє потрібні значення шаблони і потім застосовує їх так само, як це робиться в традиційному підході (Докладніше про те, як це все працює і як можна використовувати, читайте в нашій статті з Helm - прим. перев.). Існує велика різноманітність готових Helm-чартів, що охоплюють широкий спектр завдань.
3. Альтернативні інструменти. Є багато альтернативних інструментів. Усіх їх поєднує те, що вони перетворюють деякі файли-шаблони на зрозумілі Kubernetes YAML-файли і потім використовують їх.

У своїй роботі ми постійно використовуємо Helm-чарти для важливих інструментів (оскільки в них вже багато чого готове, що значно спрощує життя) і «чисті» YAML-файли Kubernetes для розгортання власних додатків.

Pull & Push

В одній із своїх недавніх публікацій у блозі я представив інструмент Плетіння флюсу, що дозволяє комити шаблони в Git-репозиторій і оновлювати deployment після кожного комміту або push'а контейнера. Мій досвід показує, що цей інструмент - один з основних у справі просування pull-підходу, тому часто посилатимуся на нього. Якщо хочете дізнатися більше про те, як його використати, ось посилання на статтю.

NB! Всі переваги використання GitOps зберігаються для обох підходів.

Підхід на основі Pull

У основі підходу pull лежить те що, що це зміни застосовуються зсередини кластера. Усередині кластера є оператор, який регулярно перевіряє пов'язані репозиторії Git та Docker Registry. Якщо в них відбуваються зміни, стан кластера оновлюється зсередини. Зазвичай вважається, що подібний процес дуже безпечний, оскільки в жодного зовнішнього клієнта немає доступу до прав адміністратора кластера.

Плюси:

1. Жоден зовнішній клієнт не має прав на внесення змін до кластера, всі оновлення накочуються зсередини.
2. Деякі інструменти також дозволяють синхронізувати оновлення Helm-чартів та прив'язувати їх до кластера.
3. Ви можете сканувати Docker Registry на наявність нових версій. Якщо з'являється новий образ, Git-репозиторій та deployment оновлюються на нову версію.
4. Pull-інструменти можуть бути розподілені різними просторами імен з різними репозиторіями Git та правами доступу. Завдяки цьому можна використовувати мультиорендну (multitenant) модель. Наприклад, команда А може використовувати простір імен А, команда — простір імен В, а команда, що займається інфраструктурою, може використовувати глобальний простір.
5. Як правило, інструменти дуже легкі.
6. У поєднанні з такими інструментами, як оператор Bitnami Sealed Secretsсекрети можуть зберігатися в зашифрованому вигляді в репозиторії Git і витягуватися всередині кластера.
7. Відсутній зв'язок із CD-пайплайнами, оскільки розгортання відбуваються усередині кластера.

Мінуси:

1. Керувати секретами deployment'ів з Helm-чартів складніше, ніж звичайними, оскільки спочатку їх доводиться генерувати у вигляді, скажімо, sealed secrets, потім розшифровувати внутрішнім оператором і тільки після цього вони стають доступними для pull-інструменту. Потім можна запускати реліз у Helm'і зі значеннями у вже розгорнутих секретах. Найпростіший спосіб — створити секрет з усіма значеннями Helm, що використовуються для deployment'а, розшифрувати його і закоммітити в Git.
2. Застосовуючи pull-підхід, ви прив'язані до інструментів, що оперують pull'ами. Це обмежує можливість налаштування процесу розгортання deployment'ів у кластері. Наприклад, робота з Kustomize ускладнюється тим, що він повинен виконуватися до того, як остаточні шаблони надходять до Git. Я не кажу, що не можна використовувати окремі інструменти, але їх складніше інтегрувати у процес розгортання.

Підхід на основі Push

У push-підході зовнішня система (переважно CD-пайплайни) запускає розгортання в кластер після коміту Git-репозиторій або у разі успішного виконання попереднього CI-пайплайну. У цьому підході система має доступ до кластера.

Плюси:

1. Безпека визначається Git-репозиторієм та пайплайним складанням.
2. Розгортати чарти Helm простіше, є підтримка плагінів Helm.
3. Керувати секретами легше, оскільки секрети можна застосовувати в пайплайнах, а також зберігати в Git у зашифрованому вигляді (залежно від уподобань користувача).
4. Відсутність прив'язки до конкретного інструменту, оскільки можна використовувати будь-які типи.
5. Оновлення версій контейнерів можуть бути ініційовані пайплайном складання.

Мінуси:

1. Дані для доступу до кластера знаходяться всередині системи збирання.
2. Оновлення контейнерів deployment'ів, як і раніше, простіше проводити з pull-процесом.
3. Сильна залежність від CD-системи, оскільки потрібні нам пайплайни, можливо, спочатку написані під Gitlab Runners, а потім команда вирішить перейти на Azure DevOps або Jenkins... і доведеться проводити міграцію великої кількості пайплайнів складання.

Підсумки: Push чи Pull?

Як завжди це буває, у кожного підходу є свої плюси та мінуси. Деякі завдання легше здійснити з одним і складніше – з іншим. Спочатку я проводив розгортання вручну, але після того, як натрапив на кілька статей про Weave Flux, вирішив запровадити GitOps-процеси для всіх проектів. Для базових шаблонів це виявилося легко, але потім я почав стикатися з труднощами у роботі з Helm-чартами. У той час Weave Flux пропонував лише зародкову версію Helm Chart Operator, але навіть зараз деякі завдання складніші через необхідність вручну створювати секрети та застосовувати їх. Ви можете сказати, що pull-підхід набагато захищеніший, оскільки облікові дані кластера недоступні за його межами, а це настільки підвищує безпеку, що вартує додаткових зусиль.

Подумавши трохи, я дійшов несподіваного висновку, що це не так. Якщо говорити про компоненти, що вимагають максимального захисту, до такого списку увійдуть сховища секретів та CI/CD-системи, Git-репозиторії. Інформація всередині них дуже вразлива і потребує максимального захисту. Крім того, якщо хтось проникне у ваш репозиторій Git і зможе push'ити туди код, то він зможе розгорнути все, що забажає (незалежно від обраного підходу, це буде pull або push), і впровадитися в системи кластера. Таким чином, найбільш важливими компонентами, що вимагають захисту, є Git-репозиторій та CI/CD-системи, а не облікові дані кластеру. Якщо у вас добре налаштовані політики та заходи безпеки для систем такого типу, а облікові дані кластера витягуються в пайплайни лише у вигляді секретів, додаткова безпека pull-підходу може виявитися не такою цінною, як передбачалося.

Отже, якщо pull-підхід є більш трудомістким і не дає виграшу в безпеці, чи не логічно використовувати тільки push-підхід? Але хтось може заявити, що в push-підході ви занадто зав'язані на CD-систему і, можливо, краще так не робити, щоб у майбутньому було простіше здійснювати міграції.

На мій погляд (як і завжди) слід використовувати те, що більше підходить до конкретного випадку або комбінувати. Особисто я користуюсь обома підходами: Weave Flux для deployment'ів на основі pull, які в основному включають наші власні сервіси, та push-підхід з Helm'ом та плагінами, що спрощує застосування Helm-чартів до кластера і дозволяє без проблем створювати секрети. Думаю, ніколи не буде єдиного рішення, що підходить для всіх випадків, тому що нюансів завжди дуже багато і вони залежать від конкретного варіанту застосування. При цьому я наполегливо рекомендую GitOps – він сильно полегшує життя та підвищує безпеку.

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

PS Примітка від перекладача

У мінусах pull-моделі є пункт про те, що складно покласти в Git відрендеровані маніфести, проте немає мінуса, що CD-пайплайн в pull-моделі живе окремо від викату і по суті стає пайплайною категорії Continuous Apply. Тому потрібно ще більше зусиль для того, щоб збирати з усіх deployment'ів їх статус і якось давати доступ до логів/статусу, причому бажано з прив'язкою до CD системи.

У цьому сенсі push-модель дозволяє дати хоч якісь гарантії викочування, тому що час життя pipeline'а можна зробити рівним часу життя викату.

Ми випробували обидві моделі і дійшли тих самих висновків, що й автор статті:

1. Pull-модель підходить для організації оновлення системних компонентів на великій кількості кластерів (див. статтю про addon-operator).
2. Push-модель на основі GitLab CI добре підходить для викочування додатків за допомогою Helm-чартів. При цьому викочування deployment'ів у рамках пайплайнів відстежується за допомогою інструмента werf. До речі, у контексті цього нашого проекту ми й чули постійне «GitOps», коли обговорювали нагальні проблеми DevOps-інженерів біля свого стенду на KubeCon Europe'19.

PPS від перекладача

Читайте також у нашому блозі:

• «Kubernetes tips & tricks: переклад ресурсів, що працюють у кластері, під управління Helm 2»;
• «Представляємо бібліотеку kubedog для стеження за ресурсами Kubernetes»;
• «Розширюємо та доповнюємо Kubernetes (огляд та відео доповіді)»;
• «Поради щодо створення нестандартних робочих процесів у GitLab CI».

Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.

Чи використовуєте ви GitOps?

• Так, підхід

• Так, push

• Так, pull + push

• Так, щось інше

• Ні

Проголосували 30 користувачів. Утрималися 10 користувачів.

Джерело: habr.com