🥇GitOps: сравнение между методите Pull и Push

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

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

(всъщност, формално това се случи през август 2017 г. — пояснение на преводача) се появи нов подход към разполагане на приложения в Kubernetes. Той се нарича GitOps, а в основата му стои основна идея, че версиите на deployment-ите се проследяват в безопасна среда на Git-репозитория. Основните предимства на този подход са следните

Версиониране на deployment-ите и история на изменението:

. Състоянието на целия клъстер се съхранява в Git-репозитория, а deployment-ите се обновяват само чрез комити. Освен това, всички изменения могат да се проследяват с помощта на историята на комитите.Възстановяване с използване на познатите команди на Git
. Простопозволява връщане на измененията в deployment-ите; винаги са достъпни предишни състояния. и поставя командата Готов контрол на достъпа
. Обикновено Git-системата съдържа много конфиденциални данни, затова повечето компании обръщат специално внимание на нейното защита. Съответно, тази защита важи и за операциите с deployment-ите.Политики за разполагания
. Повечето Git-системи първоначално поддържат политики за различни клонове — например, само pull request-ите могат да обновяват master, а измененията трябва да бъдат проверени и приети от друг член на екипа. Както и с контрола на достъпа, същите политики се прилагат и за обновленията на deployment-ите.Както виждате, методът GitOps има множество предимства. През последната година особена популярност набраха два подхода. Един е основан на push, а другият — на pull. Преди да ги разгледаме, нека първо видим как изглеждат типичните deployment-и на Kubernetes.

Начини на разполагане

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

На база родни шаблони Kubernetes/Kustomize

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

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

Pull & Push

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

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

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

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

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

Предимства:

Нито един външен клиент няма права да извършва промени в кластера, всички актуализации се прилагат отвътре.
Някои инструменти също така позволяват синхронизиране на актуализации на Helm-чартове и свързването им с кластера.
Docker Registry може да се сканира за нови версии. Ако се появи нов образ, Git-репозиториите и разгръщането се обновяват до новата версия.
Pull-инструментите могат да бъдат разпределени в различни пространства от имена с различни Git репозитории и права за достъп. Благодарение на това може да се приложи многоподемна (multitenant) модел. Например, екип А може да използва пространство от имена А, екип В — пространство от имена В, а екипът, отговорен за инфраструктурата, може да използва глобална зона.
Обикновено инструментите са доста леки.
В комбинация с инструменти като оператора Bitnami Sealed Secrets, секретите могат да бъдат съхранявани в криптиран вид в Git репозитория и извлечени в клъстера.
Липсва връзка с CD пайплайни, тъй като разгръщанията се случват в клъстера.

Минуси:

Управлението на секретите за разгръщания от Helm-чартове е по-сложно отколкото с обикновените, тъй като първо трябва да бъдат генерирани под формата на sealed secrets, след това да бъдат разшифровани от вътрешния оператор и едва след това те стават достъпни за pull инструмента. След това може да се стартира релиз в Helm с ценности, включени в вече разгръщаните секрети. Най-простият начин е да се създаде секрет със всички Helm стойности, използвани за разгръщането, да се разшифрова и да се комитне в Git.
Прилагането на pull-подхода ви привързва към инструменти, които работят с pull-ове. Това ограничава възможността за настройване на процеса на разгръщане на deployment-и в кластера. Например, работата с Kustomize е затруднена, тъй като той трябва да се изпълнява преди окончателните шаблони да бъдат качени в Git. Не казвам, че не можете да използвате отделни инструменти, но тяхната интеграция в процеса на разгръщане е по-трудна.

Подход на базата на Push

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

В push-подхода външната система (главно CD-пайплайни) стартира разгръщания в кластера след комит в Git-репозитория или при успешното приключване на предишен CI-пайплайн. В този подход системата има достъп до кластера.

Плюсове:

Сигурността е определяна от Git-репозитория и пайплайна за изграждане.
Разгръщането на Helm чартове е по-лесно, с поддръжка на Helm плъгини.
Управлението на тайни е по-лесно, тъй като тайните могат да се използват в пайплайни и да се съхраняват в Git в криптиран вид (в зависимост от предпочитанията на потребителя).
Липса на привързаност към конкретен инструмент, тъй като може да се използват всякакви типове.
Актуализациите на версиите на контейнерите могат да бъдат инициирани от пайплайна за изграждане.

Минуси:

Данните за достъп до кластера са вътре в системата за изграждане.
Актуализацията на контейнерите за deployment-и все още е по-лесна с pull-процеса.
Силната зависимост от 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 вие сте твърде обвързани с CI/CD системата и, вероятно, е по-добре да не го правите, за да бъде по-лесно извършването на миграции в бъдеще.

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

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

P.S. Бележка от преводача

В минусите на pull модела има точка, че е трудно да се поставят в Git отрендерените манифести, но няма недостатък, че CD pipeline в pull модела живее отделно от деплоймента и по същество става pipeline от категорията Continuous Apply. Затова ще са необходими още повече усилия, за да се събира статусът от всички deployment-и и да се осигури достъп до логовете/статуса, като е желателно с привязка към CD системата.

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

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

Pull моделът подхожда за организиране на обновленията на системни компоненти на голям брой кластери (вижте статията за addon-operator).
Push моделът на база GitLab CI е подходящ за деплойване на приложения с помощта на Helm chart. При това деплойментите в рамките на pipelines се проследяват с помощта на инструмента werf. Между другото, в контекста на този наш проект чухме постоянно "GitOps", когато обсъждахме наболелите проблеми на DevOps инженерите на нашия стенд на KubeCon Europe’19.