GitOps: Сравнение на методите Pull и Push

Забележка. превод: В общността на Kubernetes тенденция, наречена GitOps, набира очевидна популярност, както лично видяхме, гостуващ KubeCon Europe 2019. Този термин беше сравнително скорошен изобретен от ръководителя на Weaveworks - Алексис Ричардсън - и означава използването на инструменти, познати на разработчиците (предимно Git, откъдето идва и името) за решаване на оперативни проблеми. По-специално, ние говорим за работата на Kubernetes чрез съхраняване на неговите конфигурации в Git и автоматично въвеждане на промени в клъстера. Matthias Jg говори за два подхода към това внедряване в тази статия.

Миналата година (всъщност формално това се случи през август 2017 г. - прибл. прев.) Има нов подход за внедряване на приложения в Kubernetes. Нарича се GitOps и се основава на основната идея, че версиите за внедряване се проследяват в защитената среда на Git хранилище.

Основните предимства на този подход са следните::

1. Разгръщане на версии и история на промените. Състоянието на целия клъстер се съхранява в Git хранилище, а внедряванията се актуализират само чрез ангажименти. В допълнение, всички промени могат да бъдат проследени с помощта на хронологията на ангажиментите.
2. Връщане назад с помощта на познати Git команди... Обикновен git reset позволява ви да нулирате промените в внедряванията; минали състояния винаги са налични.
3. Готов контрол на достъпа. Обикновено системата Git съдържа много чувствителни данни, така че повечето компании обръщат специално внимание на защитата им. Съответно тази защита важи и за операции с внедрявания.
4. Политики за внедрявания. Повечето Git системи изначално поддържат политики за клон по клон – например, само заявки за изтегляне могат да актуализират master, а промените трябва да бъдат прегледани и приети от друг член на екипа. Както при контрола на достъпа, същите правила се прилагат и за актуализациите за внедряване.

Както можете да видите, има много предимства на метода GitOps. През последната година два подхода добиха особена популярност. Единият е базиран на натискане, другият е базиран на изтегляне. Преди да ги разгледаме, нека първо да разгледаме как изглеждат типичните внедрявания на Kubernetes.

Методи за внедряване

През последните години в Kubernetes се наложиха различни методи и инструменти за внедряване:

1. Базиран на собствените шаблони на Kubernetes/Customize. Това е най-лесният начин за внедряване на приложения в Kubernetes. Програмистът създава основните YAML файлове и ги прилага. За да се отървете от постоянното пренаписване на едни и същи шаблони, беше разработен Kustomize (превръща шаблоните на Kubernetes в модули). Забележка. превод: Kustomize е интегриран в kubectl с издание на Kubernetes 1.14.
2. Helm Charts. Helm диаграмите ви позволяват да създавате набори от шаблони, инициализиращи контейнери, странични колички и т.н., които се използват за внедряване на приложения с по-гъвкави опции за персонализиране, отколкото при подход, базиран на шаблони. Този метод се основава на шаблонни YAML файлове. Helm ги изпълва с различни параметри и след това ги изпраща на Tiller, клъстерен компонент, който ги внедрява в клъстера и позволява актуализации и връщания назад. Важното е, че Helm по същество просто вмъква желаните стойности в шаблоните и след това ги прилага по същия начин, както се прави при традиционния подход (прочетете повече за това как работи всичко и как можете да го използвате в нашия статия от Helm - прибл. превод). Има голямо разнообразие от готови диаграми на Helm, покриващи широк спектър от задачи.
3. Алтернативни инструменти. Има много алтернативни инструменти. Общото между всички тях е, че превръщат някои шаблонни файлове в четими от Kubernetes YAML файлове и след това ги използват.

В нашата работа ние постоянно използваме диаграми на Helm за важни инструменти (тъй като те имат много готови неща, което прави живота много по-лесен) и „чисти“ YAML файлове на Kubernetes за внедряване на нашите собствени приложения.

Дърпам бутам

В една от последните ми публикации в блога представих инструмента Weave Flux, което ви позволява да ангажирате шаблони в хранилището на Git и да актуализирате внедряването след всяко ангажиране или натискане на контейнера. Моят опит показва, че този инструмент е един от основните в насърчаването на подхода на изтегляне, така че често ще се позовавам на него. Ако искате да научите повече за това как да го използвате, тук връзка към статията.

NB! Всички предимства от използването на GitOps остават еднакви и за двата подхода.

Подход, базиран на изтегляне

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

плюсове:

1. Никой външен клиент няма права да прави промени в клъстера; всички актуализации се въвеждат отвътре.
2. Някои инструменти също ви позволяват да синхронизирате актуализациите на диаграмата на Helm и да ги свържете към клъстера.
3. Docker Registry може да се сканира за нови версии. Ако е налично ново изображение, Git хранилището и внедряването се актуализират до новата версия.
4. Инструментите за изтегляне могат да бъдат разпределени в различни пространства от имена с различни Git хранилища и разрешения. Благодарение на това може да се използва мултитенантен модел. Например екип А може да използва пространство от имена A, екип B може да използва пространство от имена B, а инфраструктурният екип може да използва глобално пространство.
5. По правило инструментите са много леки.
6. В комбинация с инструменти като оператор Запечатани тайни на Bitnami, тайните могат да се съхраняват криптирани в Git хранилище и да се извличат в рамките на клъстера.
7. Няма връзка с CD тръбопроводи, тъй като внедряванията се извършват в рамките на клъстера.

Против:

1. Управлението на тайни за разполагане от диаграми на Helm е по-трудно от обикновените, тъй като те първо трябва да бъдат генерирани под формата на, да речем, запечатани тайни, след това декриптирани от вътрешен оператор и едва след това те стават достъпни за инструмента за изтегляне. След това можете да стартирате изданието в Helm със стойностите във вече внедрените тайни. Най-лесният начин е да създадете тайна с всички стойности на Helm, използвани за внедряване, да я дешифрирате и да я ангажирате към Git.
2. Когато предприемете подход на издърпване, вие се обвързвате с инструменти за изтегляне. Това ограничава възможността за персонализиране на процеса на внедряване в клъстер. Например, Kustomize се усложнява от факта, че трябва да се изпълнява, преди окончателните шаблони да бъдат ангажирани към Git. Не казвам, че не можете да използвате самостоятелни инструменти, но те са по-трудни за интегриране в процеса на внедряване.

Подход, базиран на натискане

При подхода на натискане външна система (главно CD тръбопроводи) стартира внедрявания към клъстера след ангажиране към Git хранилището или ако предишният CI тръбопровод е успешен. При този подход системата има достъп до клъстера.

Професионалисти:

1. Сигурността се определя от хранилището на Git и конвейера за изграждане.
2. Внедряването на диаграми на Helm е по-лесно и поддържа плъгини на Helm.
3. Тайните са по-лесни за управление, тъй като тайните могат да се използват в конвейери и могат също да се съхраняват криптирани в Git (в зависимост от предпочитанията на потребителя).
4. Няма връзка с конкретен инструмент, тъй като може да се използва всеки тип.
5. Актуализациите на версията на контейнера могат да бъдат инициирани от конвейера за изграждане.

Против:

1. Данните за достъп до клъстера са вътре в системата за изграждане.
2. Актуализирането на контейнерите за внедряване е все още по-лесно с процес на изтегляне.
3. Силна зависимост от CD системата, тъй като тръбопроводите, от които се нуждаем, може да са били първоначално написани за Gitlab Runners и след това екипът решава да премине към Azure DevOps или Jenkins... и ще трябва да мигрира голям брой конвейери за изграждане.

Резултати: Бутане или дърпане?

Както обикновено се случва, всеки подход има своите плюсове и минуси. Някои задачи са по-лесни за изпълнение с един и по-трудни с друг. Първоначално правех внедрявания ръчно, но след като попаднах на няколко статии за Weave Flux, реших да внедря GitOps процеси за всички проекти. За основни шаблони това беше лесно, но след това започнах да срещам трудности с диаграмите на Helm. По онова време Weave Flux предлагаше само елементарна версия на Helm Chart Operator, но дори сега някои задачи са по-трудни поради необходимостта от ръчно създаване на тайни и прилагането им. Може да се твърди, че подходът на изтегляне е много по-сигурен, тъй като идентификационните данни на клъстера не са достъпни извън клъстера, което го прави толкова по-сигурен, че си струва допълнителните усилия.

След кратък размисъл стигнах до неочакваното заключение, че това не е така. Ако говорим за компоненти, които изискват максимална защита, този списък ще включва тайно хранилище, CI/CD системи и Git хранилища. Информацията в тях е много уязвима и се нуждае от максимална защита. Освен това, ако някой влезе във вашето Git хранилище и може да прокара код там, той може да разположи каквото пожелае (независимо дали е изтегляне или натискане) и да проникне в системите на клъстера. По този начин най-важните компоненти, които трябва да бъдат защитени, са Git хранилището и CI/CD системите, а не идентификационните данни на клъстера. Ако имате добре конфигурирани политики и контроли за сигурност за тези типове системи и идентификационните данни на клъстера се извличат само в конвейери като тайни, добавената сигурност на подхода на изтегляне може да не е толкова ценна, колкото се смяташе първоначално.

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

Според мен (както винаги) трябва да използвате това, което е най-подходящо за конкретен случай или комбинация. Лично аз използвам и двата подхода: Weave Flux за внедрявания, базирани на изтегляне, които включват най-вече наши собствени услуги, и подход на натискане с Helm и плъгини, което улеснява прилагането на Helm диаграми към клъстера и ви позволява да създавате тайни безпроблемно. Мисля, че никога няма да има едно решение, подходящо за всички случаи, защото винаги има много нюанси и те зависят от конкретното приложение. Като се има предвид това, силно препоръчвам GitOps - прави живота много по-лесен и подобрява сигурността.

Надявам се, че опитът ми по тази тема ще ви помогне да решите кой метод е по-подходящ за вашия тип внедряване и ще се радвам да чуя вашето мнение.

PS Забележка от преводача

Недостатъкът на модела на изтегляне е, че е трудно да се поставят изобразени манифести в Git, но няма недостатък, че тръбопроводът на CD в модела на изтегляне съществува отделно от внедряването и по същество се превръща в тръбопровод на категория Непрекъснато прилагане. Следователно ще са необходими още повече усилия за събиране на техния статус от всички внедрявания и по някакъв начин осигуряване на достъп до регистрационни файлове/състояние, за предпочитане по отношение на CD системата.

В този смисъл моделът на натискане ни позволява да предоставим поне някои гаранции за внедряване, тъй като животът на тръбопровода може да бъде равен на живота на разгръщането.

Пробвахме и двата модела и стигнахме до същите заключения като автора на статията:

1. Моделът на изтегляне е подходящ за нас, за да организираме актуализации на системни компоненти на голям брой клъстери (вижте. статия за addon-operator).
2. Push моделът, базиран на GitLab CI, е много подходящ за внедряване на приложения с помощта на Helm диаграми. В същото време внедряването на внедрявания в конвейери се наблюдава с помощта на инструмента werf. Между другото, в контекста на този наш проект чухме постоянното „GitOps“, когато обсъждахме належащите проблеми на инженерите на DevOps на нашия щанд на KubeCon Europe'19.

PPS от преводача

Прочетете също в нашия блог:

• «Съвети и трикове на Kubernetes: прехвърляне на ресурси, работещи в клъстер, към управление на Helm 2»;
• «Представяме ви kubedog, библиотека за проследяване на ресурси на Kubernetes»;
• «Разширяване и допълване на Kubernetes (преглед и видео отчет)»;
• «Съвети за създаване на персонализирани работни потоци в GitLab CI".

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Използвате ли GitOps?

• Да, дръпнете подход

• Да, натиснете

• Да, дърпане + натискане

• Да, нещо друго

• Не

30 потребители гласуваха. 10 потребители се въздържаха.

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