Заўв. перав.: У супольнасці Kubernetes відавочную папулярнасць набірае трэнд пад назвай GitOps, у чым мы асабіста пераканаліся, KubeCon Europe 2019. Гэты тэрмін быў адносна нядаўна кіраўніком кампаніі Weaveworks – Alexis Richardson – і азначае прымяненне звыклых для распрацоўшчыкаў інструментаў (у першую чаргу – Git, адкуль і сама назва) для вырашэння задач эксплуатацыі. У прыватнасці, гаворка аб эксплуатацыі Kubernetes праз захоўванне яго канфігурацый у Git і аўтаматычнага выкату змен у кластар. Аб двух падыходах да гэтага выкату і распавядае Matthias Jg у дадзеным артыкуле.
У мінулым годзе (насамрэч, фармальна гэта адбылося ў жніўні 2017 г. — заўв. перакл.) з'явіўся новы падыход да разгортвання прыкладанняў у Kubernetes. Ён называецца GitOps, а ў яго аснове ляжыць базавае ўяўленне аб тым, што адсочванне версій deployment'аў вядзецца ў бяспечным асяроддзі Git-рэпазітара.
Асноўныя перавагі ў гэтага падыходу наступныя:
- Версіянаванне deployment'аў і гісторыя змен. Стан усяго кластара захоўваецца ў Git-рэпазітары, а deployment'ы абнаўляюцца толькі шляхам коммітаў. Акрамя таго, усе змены можна адсочваць з дапамогай гісторыі комітаў.
- Адкаты з выкарыстаннем звыклых каманд Git. Просты
git resetдазваляе скідаць змены ў deployment'ах; заўсёды даступныя мінулыя станы. - Гатовы кантроль доступу. Звычайна Git-сістэма ўтрымоўвае мноства канфідэнцыйных дадзеных, таму большасць кампаній надаюць адмысловую ўвагу яе абароне. Адпаведна, гэтая абарона распаўсюджваецца і на аперацыі з deployment'амі.
- Палітыкі для разгортванняў. Большасць Git-сістэм першапачаткова падтрымліваюць палітыкі для розных галін - напрыклад, толькі pull request'ы могуць абнаўляць master, а змены павінен праверыць і прыняць іншы чалец каманды. Як і з кантролем доступу, тыя ж палітыкі прымяняюцца да абнаўленняў deployment'аў.
Як бачыце, у метаду GitOps ёсць мноства пераваг. За апошні год асаблівую папулярнасць набралі два падыходы. Адзін заснаваны на push, іншы - на pull. Перш чым іх разгледзець, давайце спачатку паглядзім, як выглядаюць тыповыя deployment'ы Kubernetes.
Спосабы разгортвання
За апошнія гады ў Kubernetes устаяліся розныя спосабы і прылады для разгортванняў:
- На аснове родных шаблонаў Kubernetes/Kustomize. Гэта самы просты спосаб разгортвання прыкладанняў у Kubernetes. Распрацоўнік стварае базавыя YAML-файлы і прымяняе іх. Каб пазбавіцца ад сталага перапісвання адных і тых жа шаблонаў, быў распрацаваны Kustomize (ён ператварае шаблоны Kubernetes у модулі). Заўв. перав.: Kustomize быў інтэграваны ў kubectl з .
- Чарты Helm. Чарты Helm дазваляюць ствараць наборы шаблонаў, init-кантэйнераў, sidecar'аў і да т.п., якія прымяняюцца для дэплою прыкладанняў з больш гнуткімі магчымасцямі наладкі, чым у падыходзе на аснове шаблонаў. У аснове гэтага метаду ляжаць шабланізаваныя YAML-файлы. Helm запаўняе іх рознымі параметрамі і затым адпраўляе Tiller'у - кластарнаму кампаненту, які разгортвае іх у кластары і дазваляе выконваць абнаўленні і адкаты. Важна тое, што ў сутнасці Helm проста ўстаўляе патрэбныя значэнні ў шаблоны і затым ужывае іх гэтак жа, як гэта робіцца ў традыцыйным падыходзе (падрабязней пра тое, як гэта ўсё працуе і як можна выкарыстоўваць, чытайце ў нашай - заўв. перав.). Існуе вялікая разнастайнасць гатовых Helm-чартаў, якія ахопліваюць шырокі спектр задач.
- Альтэрнатыўныя інструменты. Ёсць шмат альтэрнатыўных інструментаў. Усіх іх аб'ядноўвае тое, што яны ператвараюць нейкія файлы-шаблоны ў зразумелыя Kubernetes YAML-файлы і затым ужываюць іх.
У сваёй працы мы ўвесь час выкарыстоўваем Helm-чарты для важных прылад (паколькі ў іх шматлікае ўжо гатова, што значна спрашчае жыццё) і «чыстыя» YAML-файлы Kubernetes для разгортвання ўласных прыкладанняў.
Pull & Push
У адной са сваіх нядаўніх публікацый у блогу я прадставіў прыладу , Які дазваляе каміціць шаблоны ў Git-рэпазітар і абнаўляць deployment пасля кожнага комміта або push'а кантэйнера. Мой досвед паказвае, што гэтая прылада — адзін з асноўных у справе пасоўвання pull-падыходу, таму буду часта спасылацца на яго. Калі хочаце даведацца больш аб тым, як яго выкарыстоўваць, вось .
NB! Усе перавагі выкарыстання GitOps захоўваюцца для абодвух падыходаў.
Падыход на аснове Pull
У аснове падыходу pull ляжыць той факт, што ўсе змены прымяняюцца знутры кластара. Унутры кластара ёсць аператар, які рэгулярна правярае звязаныя рэпазітары Git і Docker Registry. Калі ў іх адбываюцца якія-небудзь змены, стан кластара абнаўляецца знутры. Звычайна лічыцца, што падобны працэс вельмі бяспечны, паколькі ні ў аднаго вонкавага кліента няма доступу да правоў адміністратара кластара.
Плюсы:
- Ні адзін вонкавы кліент не мае правоў на занясенне змен у кластар, усё абнаўленні накатваюцца знутры.
- Некаторыя прылады таксама дазваляюць сінхранізаваць абнаўленні Helm-чартаў і прывязваць іх да кластара.
- Docker Registry можна сканаваць на наяўнасць новых версій. Калі з'яўляецца новая выява, Git-рэпазітар і deployment абнаўляюцца на новую версію.
- Pull-інструменты могуць быць размеркаваны па розных прасторах імёнаў з рознымі рэпазітарамі Git і правамі доступу. Дзякуючы гэтаму можна ўжываць мультыарэнднай (multitenant) мадэль. Напрыклад, каманда А можа выкарыстоўваць прастору імёнаў А, каманда В - прастора імёнаў В, а каманда, якая займаецца інфраструктурай, можа выкарыстоўваць глабальную прастору.
- Як правіла, прылады вельмі легкаважныя.
- У спалучэнні з такімі інструментамі, як аператар , сакрэты могуць захоўвацца ў зашыфраваным выглядзе ў рэпазітары Git і здабывацца ўнутры кластара.
- Адсутнічае сувязь з CD-пайплайнамі, паколькі разгортванні адбываюцца ўсярэдзіне кластара.
Мінусы:
- Кіраваць сакрэтамі deployment'аў з Helm-чартаў складаней, чым звычайнымі, паколькі спачатку іх даводзіцца генераваць у выглядзе, скажам, sealed secrets, затым расшыфроўваць унутраным аператарам і толькі пасля гэтага яны становяцца даступныя для pull-інструмента. Затым можна запускаць рэліз у Helm'е са значэннямі ва ўжо разгорнутых сакрэтах. Самы просты спосаб - стварыць сакрэт са ўсімі значэння Helm, выкарыстоўванымі для deployment'а, расшыфраваць яго і закаміціць у Git.
- Ужываючы pull-падыход, вы апыняецеся прывязаныя да прылад, якія аперуюць pull'амі. Гэта абмяжоўвае магчымасць наладкі працэсу разгортвання deployment'аў у кластары. Напрыклад, праца з Kustomize ускладняецца тым, што ён павінен выконвацца да таго, як канчатковыя шаблоны паступаюць у Git. Я не кажу, што нельга выкарыстоўваць асобныя інструменты, але іх больш складана інтэграваць у працэс разгортвання.
Падыход на аснове 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-падыходзе вы занадта завязаныя на CD-сістэму і, магчыма, лепш так не рабіць, каб у будучыні было прасцей ажыццяўляць міграцыі.
На мой погляд (як і заўсёды), варта выкарыстоўваць тое, што больш падыходзіць да канкрэтнай нагоды ці камбінаваць. Асабіста я карыстаюся абодвума падыходамі: Weave Flux для deployment'аў на аснове pull, якія ў асноўным уключаюць нашы ўласныя сэрвісы, і push-падыход з Helm'ам і плягінамі, які спрашчае ўжыванне Helm-чартаў да кластара і які дазваляе без праблем ствараць сакрэты. Думаю, ніколі не будзе адзінага рашэння, прыдатнага для ўсіх выпадкаў, таму што нюансаў заўсёды вельмі шмат і яны залежаць ад канкрэтнага варыянту прымянення. Пры гэтым я настойліва рэкамендую GitOps - ён моцна палягчае жыццё і падвышае бяспеку.
Спадзяюся, мой досвед па дадзенай тэме дапаможа вызначыцца, які метад больш падыходзіць для вашага тыпу deployment'ов, а я буду рады пазнаць ваша меркаванне.
PS Заўвага ад перакладчыка
У мінусах pull-мадэлі ёсць пункт пра тое, што складана пакласці ў Git адрэндэраваныя маніфесты, аднак няма мінусу, што CD-пайплайн у pull-мадэлі жыве асобна ад выкату і па сутнасці становіцца пайплайным катэгорыі. Continuous Apply. Таму запатрабуецца яшчэ больш высілкаў для таго, каб збіраць са ўсіх deployment'ов іх статут і неяк даваць доступ да логаў/статусу, прычым пажадана з прывязкай да CD сістэмы.
У гэтым сэнсе push-мадэль дазваляе даць хоць нейкія гарантыі выкату, таму што час жыцця pipeline'а можна зрабіць роўным часу жыцця выкату.
Мы апрабавалі абедзве мадэлі і прыйшлі да тых жа высноваў, што і аўтар артыкула:
- Pull-мадэль падыходзіць нам для арганізацыі абнаўлення сістэмных кампанентаў на вялікай колькасці кластараў (гл. ).
- Push-мадэль на аснове GitLab CI добра падыходзіць для выкату прыкладанняў з дапамогай Helm-чартаў. Пры гэтым выкат deployment'аў у рамках пайплайнаў адсочваецца з дапамогай прылады . Дарэчы, у кантэксце гэтага нашага праекту мы і чулі сталае "GitOps", калі абмяркоўвалі надзённыя праблемы DevOps-інжынераў у свайго стэнда на KubeCon Europe'19.
PPS з перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «.
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. , Калі ласка.
Карыстаецеся Ці вы GitOps?
-
Так, падыход pull
-
Так, push
-
Так, pull + push
-
Так, нешта іншае
-
Няма
Прагаласавалі 30 карыстальнікаў. Устрымаліся 10 карыстальнікаў.
Крыніца: habr.com