Заўв. перав.: Пасля нядаўняй публікацыі аб метадах pull і push у GitOps мы ўбачылі цікавасць да гэтай мадэлі ў цэлым, аднак рускамоўных публікацый на гэтую тэму аказалася зусім мала (на хабры іх папросту няма). Таму рады прапанаваць вашай увазе пераклад іншага артыкула - хай і ўжо амаль гадавой даўнасці! - ад кампаніі Weaveworks, кіраўнік якой прыдумаў тэрмін «GitOps». У тэксце тлумачыцца іста падыходу і ключавыя адрозненні ад ужо існых.
Год таму мы апублікавалі . Тады мы распавялі, як каманда Weaveworks запусціла SaaS, цалкам заснаваную на Kubernetes, і распрацавала набор якія прадпісваюць лепшых практык для разгортвання, кіраванні і маніторынгу ў асяроддзі cloud native.
Артыкул аказаўся папулярным. Іншыя людзі загаварылі аб GitOps, сталі публікаваць новыя прылады для , , , , і да т.п. На нашым сайце з'явілася публікацый і варыянтаў выкарыстання GitOps. Але ў некаторых людзей усё ж засталіся пытанні. Чым мадэль адрозніваецца ад традыцыйнай і бесперапыннай пастаўкі ()? Ці абавязкова выкарыстоўваць Kubernetes?
Неўзабаве мы зразумелі, што неабходна новае апісанне, якое прапануе:
- Вялікая колькасць прыкладаў і гісторый;
- Канкрэтнае вызначэнне GitOps;
- Параўнанне з традыцыйнай continuous delivery.
У гэтым артыкуле мы паспрабавалі ахапіць усе гэтыя тэмы. У ёй вы знойдзеце абноўленае ўвядзенне ў GitOps і погляд на яго са боку распрацоўнікаў і CI/CD. Мы пераважна арыентуемся на Kubernetes, хоць мадэль суцэль можна абагульніць.
Знаёмцеся: GitOps
Уявіце сабе Алісу. Яна кіруе кампаніяй Family Insurance, якая прапануе полісы па страхаванні здароўя, аўтамабіляў, нерухомасці і турыстычную страхоўку людзям, якія занадта занятыя, каб разбірацца ў нюансах кантрактаў самастойна. Яе бізнэс пачынаўся як іншы праект, калі Аліса працавала ў банку як data scientist. Аднойчы яна зразумела, што можа выкарыстоўваць перадавыя камп'ютарныя алгарытмы для больш эфектыўнага аналізу даных і фарміравання страхавых пакетаў. Інвестары прафінансавалі праект, і зараз яе кампанія прыносіць больш за 20 млн долараў за год і імкліва расце. Цяпер у ёй на розных пасадах працуюць 180 чалавек. У іх ліку тэхналагічная каманда, якая займаецца распрацоўкай, абслугоўваннем сайта, базы даных і аналізам кліенцкай базы. Каманду з 60 чалавек узначальвае Боб - тэхнічны дырэктар кампаніі.
Каманда Боба разгортвае production-сістэмы ў воблаку. Іх асноўныя прыкладанні працуюць на GKE, карыстаючыся перавагамі Kubernetes у Google Cloud. Акрамя таго, яны выкарыстоўваюць у працы розныя прылады для працы з дадзенымі і аналітыкі.
Family Insurance не збіралася выкарыстоўваць кантэйнеры, але заразілася энтузіязмам вакол Docker. Неўзабаве спецыялісты кампаніі выявілі, што GKE дазваляе разгортваць кластары для тэсціравання новых функцый лёгка і нязмушана. Былі дададзены Jenkins для CI і Quay для арганізацыі рэестра кантэйнераў, напісаны скрыпты для Jenkins, якія push'ці новыя кантэйнеры і канфігурацыі ў GKE.
Мінуў некаторы час. Аліса і Боб расчараваліся ў прадукцыйнасці абранага падыходу і яго ўплыве на бізнэс. Укараненне кантэйнераў не павысіла прадукцыйнасць настолькі, наколькі спадзявалася каманда. Часам deployment'ы ламаліся, і было незразумела, ці вінаватыя ў гэтым змены кода. Таксама аказалася цяжка адсочваць змены канфігаў. Часта даводзілася ствараць новы кластар і перамяшчаць у яго прыкладанні, паколькі так было прасцей за ўсё ліквідаваць той бардак, у які ператварылася сістэма. Аліса баялася, што сітуацыя пагоршыцца па меры развіцця прыкладання (акрамя таго, наспяваў новы праект на аснове машыннага навучання). Боб аўтаматызаваў большую частку працы і не разумеў, чаму пайплайн па-ранейшаму няўстойлівы, дрэнна маштабуецца і перыядычна патрабуе ручнога ўмяшання?
Затым яны даведаліся аб GitOps. Гэтае рашэнне аказалася менавіта тым, што ім было патрэбна для ўпэўненага руху наперад.
Аліса і Боб ужо не адзін год чулі аб працоўных працэсах на аснове Git, DevOps і infrastructure as code. Унікальнасць GitOps у тым, што ён прыўносіць шэраг лепшых практык – катэгарычных і нарматыўных – па рэалізацыі гэтых ідэй у кантэксце Kubernetes. Гэтая тэма , у тым ліку і ў .
Family Insurance вырашае ўкараніць GitOps. Цяпер у кампаніі ёсць аўтаматызаваная мадэль эксплуатацыі, сумяшчальная з Kubernetes і якая спалучае хуткасць са стабільнасцю, паколькі яны:
- выявілі, што ў каманды ўдвая вырасла прадукцыйнасць і ніхто пры гэтым не вар'яцее;
- перасталі абслугоўваць скрыпты. Замест гэтага зараз яны могуць канцэнтравацца на новых функцыях і ўдасканальваць інжынерныя метады – напрыклад, укараніць канарэечныя выкаты і палепшыць тэставанне;
- удасканалілі працэс разгортвання - зараз ён рэдка ламаецца;
- атрымалі магчымасць аднаўляць deployment'ы пасля частковых збояў без ручнога ўмяшання;
- набылі большую ўпэўненасць у сістэмах пастаўкі. Аліса і Боб выявілі, што можна падзяліць каманду на групы, якія займаюцца мікрасэрвісу і працуюць паралельна;
- могуць уносіць па 30-50 змен у праект кожны дзень намаганнямі кожнай групы і спрабаваць новыя тэхнікі;
- лёгка прыцягваюць да праекту новых распрацоўнікаў, якія маюць магчымасць накатваць абнаўленні на production з дапамогай pull request'аў ужо праз некалькі гадзін;
- лёгка праходзяць аўдыт у рамках SOC2 (на адпаведнасць пастаўшчыкоў паслуг патрабаванням па бяспечным кіраванні даных; больш падрабязна чытайце, напрыклад, - заўв. перав.).
Што адбылося?
GitOps - гэта дзве рэчы:
- Мадэль эксплуатацыі для Kubernetes і cloud native. Яна дае набор лепшых практык для разгортвання, кіравання і маніторынгу сабраных у кантэйнеры кластараў і прыкладанняў. Элегантнае вызначэнне ў выглядзе ад :
- Шлях да стварэння арыентаванага на распрацоўшчыкаў асяроддзя для кіравання праграмамі. Мы ўжываем працоўны працэс Git як да эксплуатацыі, так і да распрацоўкі. Звярніце ўвагу, што гаворка ідзе не проста аб Git push, а аб арганізацыі ўсяго набору прылад CI/CD і UI/UX.
Пара слоў аб Git
Калі вы не знаёмыя з сістэмамі кантролю версій і заснаваным на Git працоўным працэсам, мы настойліва раім вывучыць іх. Спачатку праца з галінамі і pull request'амі можа здацца чорнай магіяй, але плюсы каштуюць затрачаных намаганняў. Вось для пачатку.
Як працуе Kubernetes
У нашай гісторыі Аліса і Боб звярнуліся да GitOps, некаторы час прапрацаваўшы з Kubernetes. Сапраўды, GitOps цесна звязаны з Kubernetes - гэта мадэль эксплуатацыі для інфраструктуры і прыкладанняў, заснаваных на Kubernetes.
Што Kubernetes дае карыстальнікам?
Вось некаторыя асноўныя магчымасці:
- У мадэлі Kubernetes усё можна апісваць у дэкларатыўнай форме.
- API-сервер Kubernetes прымае такую дэкларацыю як уступныя дадзеныя, а затым увесь час спрабуе прывесці кластар у стан, апісанае ў дэкларацыі.
- Дэкларацыі дастатковыя для апісання і кіравання вялікай разнастайнасцю працоўных нагрузак - «прыкладанняў».
- У выніку, унясенне змяненняў у дадатак і кластар адбываецца з-за:
- змен у выявах кантэйнераў;
- змен у дэкларатыўнай спецыфікацыі;
- памылак у асяроддзі - напрыклад, падзенняў кантэйнераў.
Выдатныя здольнасці Kubernetes па канвергенцыі
Калі адміністратар уносіць змены ў канфігурацыю, аркестратар Kubernetes будзе прымяняць іх да кластара да таго часу, пакуль яго стан не наблізіцца да новай канфігурацыі. Гэтая мадэль працуе для любога рэсурсу Kubernetes і пашыраецца з дапамогай Custom Resource Definitions (CRDs). Таму deployment'ы Kubernetes валодаюць наступнымі цудоўнымі ўласцівасцямі:
- Аўтаматызацыя: абнаўленні Kubernetes падаюць механізм для аўтаматызацыі працэсу прымянення зменаў карэктна і своечасова.
- Канвергенцыя: Kubernetes будзе працягваць спробы абнаўленняў да дасягнення поспеху.
- Ідэмпатэнтнасць: паўторныя прымянення канвергенцыі прыводзяць да таго ж выніку.
- Дэтэрмінізм: пры дастатковасці рэсурсаў стан абноўленага кластара залежыць толькі ад жаданага стану.
Як працуе GitOps
Мы дастаткова даведаліся аб Kubernetes, каб растлумачыць прынцыпы працы GitOps.
Давайце вернемся да каманд Family Insurance, злучаным з мікрасэрвісамі. Чым ім звычайна даводзіцца займацца? Паглядзіце на пералік ніжэй (калі нейкія пункты ў ім здадуцца дзіўнымі ці незнаёмымі - калі ласка, пачакайце з крытыкай і заставайцеся з намі). Гэта ўсяго толькі прыклады працоўных працэсаў на аснове Jenkins. Існуе і мноства іншых працэсаў пры працы з іншымі прыладамі.
Галоўнае - мы бачым, што кожнае абнаўленне сканчаецца занясеннем змен у канфігурацыйныя файлы і рэпазітары Git. Гэтыя змены ў Git прыводзяць да таго, што "аператар GitOps" абнаўляе кластар:
1. Працоўны працэс: «Зборка Jenkins - галінка master.
Спіс задач:
- Jenkins push'іт тэгаваныя вобразы ў Quay;
- Jenkins push'іт канфіг і Helm-чарты ў бакет master-сховішчы;
- Воблачная функцыя капіюе канфіг і чарты з бакета master-сховішчы ў Git-рэпазітар master;
- Аператар GitOps абнаўляе кластар.
2. Зборка Jenkins - галінка release або hotfix:
- Jenkins push'іт нетэгіраваныя выявы ў Quay;
- Jenkins push'іт канфіг і Helm-чарты ў бакет staging-сховішчы;
- Воблачная функцыя капіюе канфіг і чарты з бакета staging-сховішчы ў Git-рэпазітар staging;
- Аператар GitOps абнаўляе кластар.
3. Зборка Jenkins - галінка develop або feature:
- Jenkins push'іт нетэгіраваныя выявы ў Quay;
- Jenkins push'іт канфіг і Helm-чарты ў бакет develop-сховішчы;
- Воблачная функцыя капіюе канфіг і чарты з бакета develop-сховішчы ў Git-рэпазітар develop;
- Аператар GitOps абнаўляе кластар.
4. Даданне новага кліента:
- Мэнэджар або адміністратар (LCM/ops) выклікае Gradle для першапачатковага разгортвання і налады сеткавых балансавальнікаў нагрузкі (NLB);
- LCM/ops камiтiт новы канфіг для падрыхтоўкі deployment'а да абнаўленняў;
- Аператар GitOps абнаўляе кластар.
Кароткае апісанне GitOps
- Апішыце жаданае стан усёй сістэмы, выкарыстоўваючы дэкларатыўныя спецыфікацыі для кожнага асяроддзя (у нашай гісторыі каманда Боба вызначае ўсю канфігурацыю сістэмы ў Git).
- Git-рэпазітар з'яўляецца адзінай крыніцай ісціны ў стаўленні жаданага стану ўсёй сістэмы.
- Усе змены ў жаданае стан ажыццяўляюцца шляхам комітаў у Git.
- Усе жаданыя параметры кластара таксама назіраныя ў самім кластары. Такім чынам мы можам вызначыць, супадаюць (канвергуюць, сыходзіцца) або адрозніваюцца (дывергуюць, разыходзяцца) жаданае і назіранае стану.
- Калі жаданае і назіранае стану адрозніваюцца, то:
- Існуе механізм канвергенцыі, які рана ці позна аўтаматычна сінхранізуе мэтавае і назіранае стану. Унутры кластара гэтым займаецца Kubernetes.
- Працэс запускаецца неадкладна з абвесткай "change committed".
- Праз некаторы наладжвальны прамежак часу можа быць паслана апавяшчэнне "diff", калі станы адрозніваюцца.
- Такім чынам, усе коміты ў Git выклікаюць правяраныя і ідэмпатэнтныя абнаўленні ў кластары.
- Адкат - гэта канвергенцыя да раней жаданага стану.
- Канвергенцыя канчатковая. Пра яе наступленне сведчаць:
- Адсутнасць абвестак "diff" на працягу вызначанага прамежку часу.
- Абвестка "converged" (напрыклад, webhook, падзея Git writeback).
Што такое дывергенцыя?
Паўторым яшчэ раз: усе жаданыя ўласцівасці кластара павінны быць назіраныя ў самім кластары.
Некалькі прыкладаў дывергенцыі:
- Змена ў файле канфігурацыі з-за зліцця галінак у Git.
- Змена ў файле канфігурацыі з-за комміта ў Git, зробленага GUI-кліентам.
- Множныя змены ў жаданым стане з-за PR у Git з наступнай зборкай выявы кантэйнера і зменамі канфіга.
- Змена стану кластара з-за памылкі, канфлікту рэсурсаў, які прыводзіць да «дрэнных паводзін», ці проста выпадковага адхілення ад арыгінальнага стану.
Што ўяўляе сабой механізм канвергенцыі?
Некалькі прыкладаў:
- Для кантэйнераў і кластараў механізм канвергенцыі дае Kubernetes.
- Той жа механізм можна выкарыстоўваць для кіравання праграмамі і канструкцыямі на аснове Kubernetes (напрыклад, Istio і Kubeflow).
- Механізм для кіравання працоўным узаемадзеяннем паміж Kubernetes, рэпазітарамі выяў і Git'ом падае , які з'яўляецца часткай .
- Для базавых машын механізм канвергенцыі павінен быць дэкларатыўным і аўтаномным. Па сваім досведзе можам сказаць, што бліжэй за ўсё да гэтага вызначэння, аднак усё ж патрабуе кантролю з боку чалавека. У гэтым сэнсе GitOps пашырае традыцыі Infrastructure as Code.
GitOps аб'ядноўвае Git з выдатным механізмам канвергенцыі Kubernetes, прапануючы мадэль для эксплуатацыі.
GitOps дазваляе нам заявіць: аўтаматызацыі і кантролю паддаюцца толькі тыя сістэмы, якія можна апісваць і назіраць.
GitOps прызначаны для ўсяго cloud native-стэка (напрыклад, Terraform і да т.п.)
GitOps - гэта не толькі Kubernetes. Мы хочам, каб уся сістэма кіравалася дэкларатыўна і выкарыстоўвала канвергенцыю. Пад усёй сістэмай мы маем на ўвазе сукупнасць асяроддзяў, якія працуюць з Kubernetes – напрыклад, "dev cluster 1", "production" і т. п. У кожную сераду ўваходзяць машыны, кластары, прыкладанні, а таксама інтэрфейсы для вонкавых сэрвісаў, якія забяспечваюць дадзеныя, маніторынг і т. п.
Заўважце, наколькі ў дадзеным выпадку Terraform важны для праблемы bootstrapping'а. Kubernetes павінен быць дзесьці разгорнуты, і выкарыстанне Terraform азначае, што мы можам прымяніць тыя ж самыя працоўныя працэсы GitOps для стварэння кіраўніка пласта, які ляжыць у аснове Kubernetes і прыкладанняў. Гэта карысная найлепшая практыка.
Вялікая ўвага надаецца ўжыванню канцэпцый GitOps да пластоў над Kubernetes. На дадзены момант маюцца рашэнні GitOps-тыпу для Istio, Helm, Ksonnet, OpenFaaS і Kubeflow, а таксама напрыклад, для Pulumi, што ствараюць пласт для распрацоўкі прыкладанняў пад cloud native.
Kubernetes CI/CD: параўнанне GitOps з іншымі падыходамі
Як гаварылася, GitOps - гэта дзве рэчы:
- Мадэль эксплуатацыі для Kubernetes і cloud native, апісаная вышэй.
- Шлях да арганізацыі арыентаванай на распрацоўшчыкаў асяроддзя для кіравання праграмамі.
Для шматлікіх GitOps - гэта першым чынам працоўны працэс на аснове Git push'ей. Нам ён таксама падабаецца. Але гэта не ўсё: давайце зараз паглядзім на CI/CD-пайплайны.
GitOps забяспечвае бесперапыннае разгортванне (CD) пад Kubernetes
GitOps прапануе механізм бесперапыннага разгортвання, які ўхіляе неабходнасць у асобных "сістэмах кіравання разгортваннямі". Усю працу за вас выконвае Kubernetes.
- Абнаўленне прыкладання патрабуе абнаўлення ў Git'е. Гэтае транзакцыйнае абнаўленне да жаданага стану. "Разгортванне" затым ажыццяўляецца ўнутры кластара самім Kubernetes на аснове абноўленага апісання.
- З-за спецыфікі працы Kubernetes гэтыя абнаўленні канвергентныя. Так забяспечваецца механізм для бесперапыннага разгортвання, у якім усе абнаўленні атамарны.
- Заўвага: прапануе GitOps-аператар, які інтэгруе Git і Kubernetes і які дазваляе выконваць CD шляхам узгаднення жаданага і бягучага стану кластара.
Без kubectl і скрыптоў
Варта пазбягаць выкарыстанні Kubectl для абнаўлення кластара, а ў асаблівасці — скрыптоў для групавання каманд kubectl. Замест гэтага, з дапамогай GitOps-пайплайна карыстач можа абнавіць свой кластар Kubernetes праз Git.
Перавагі ўключаюць у сябе:
- Правільнасць. Групу абнаўленняў можна прымяніць, канвергаваць і нарэшце валідаваць, што набліжае нас да мэты атамарнага разгортвання. Наадварот, выкарыстанне скрыптоў не дае ніякіх гарантый канвергенцыі (падрабязней пра гэта ніжэй).
- бяспеку. Kelsey Hightower: "Абмяжуйце доступ да кластара Kubernetes інструментам аўтаматызацыі і адміністратарам, у абавязкі якіх уваходзіць яго адладка або падтрыманне працаздольнасці". Глядзіце таксама аб бяспецы і адпаведнасці тэхнічным умовам, а таксама шляхам крадзяжу уліковых дадзеных з нядбайна складзенага Jenkins-скрыпту.
- Карыстацкі досвед. Kubectl агаляе механіку аб'ектнай мадэлі Kubernetes, якая вельмі складана. У ідэале карыстачы павінны ўзаемадзейнічаць з сістэмай на больш высокім узроўні абстракцыі. Тут я зноў спашлюся на Kelsey і рэкамендую паглядзець .
Розніца паміж CI і CD
GitOps паляпшае існуючыя CI/CD-мадэлі.
Сучасны CI-сервер уяўляе сабой інструмент для аркестрацыі. У прыватнасці, гэта прылада для аркестрацыі CI-пайплайнаў. Яны складаюцца з build, test, merge to trunk і т. д. CI-серверы аўтаматызуюць кіраванне складанымі шматкрокавымі пайплайнамі. Распаўсюджаная спакуса складаецца ў тым, каб стварыць скрыпт для набору абнаўленняў Kubernetes і выканаць яго ў якасці элемента пайплайна для push'а змен у кластар. Сапраўды, так робяць многія спецыялісты. Аднак гэта неаптымальна, і вось чаму.
CI павінна выкарыстоўвацца для занясення абнаўленняў у trunk, а кластар Kubernetes павінен змяняць сябе на аснове гэтых абнаўленняў, каб кіраваць CD унутрана . Мы называем гэта , у адрозненне ад CI push-мадэлі. CD з'яўляецца часткай runtime-аркестрацыі.
Чаму CI-серверы не павінны рабіць CD праз прамыя абнаўленні ў Kubernetes
Не выкарыстоўвайце CI-сервер для аркестрацыі прамых абнаўленняў у Kubernetes у выглядзе набору CI-заданняў. Гэта анты-патэрн, пра які мы у сваім блогу.
Давайце вернемся да Алісы і Боба.
З якімі праблемамі яны сутыкнуліся? CI-сервер Боба прымяняе змены да кластара, але калі ў працэсе ён ўпадзе, Боб не будзе ведаць, у якім стане знаходзіцца (або павінен быць) кластар і як яго выправіць. Тое самае справядліва і ў выпадку посьпеху.
Давайце выкажам здагадку, што каманда Боба сабрала новую выяву і затым прапатчыла свае deployment'ы, каб разгарнуць выяву (усё гэта з CI-пайплайна).
Калі вобраз збярэцца нармальна, але пайплайн упадзе, камандзе давядзецца высвятляць:
- Ці разгарнулася абнаўленне?
- Ці запускаем мы новую зборку? Ці прывядзе гэта да непатрэбных пабочных эфектаў - з магчымасцю атрымаць дзве зборкі адной і той жа нязменнай выявы?
- Ці варта нам дачакацца чарговага абнаўлення, перш чым запусціць зборку?
- Што менавіта пайшло не так? Якія крокі трэба паўтарыць (і якія з іх бяспечна паўтараць)?
Арганізацыя заснаванага на Git'е працоўнага працэсу не гарантуе, што каманда Боба не сутыкнецца з гэтымі праблемамі. Яны па-ранейшаму могуць памыліцца з push'ем комміта, з тэгам ці якім-небудзь іншым параметрам; аднак гэты падыход усё ж значна бліжэй да відавочнага ўсё-або-нічога.
Падагульняючы, вось чаму CI-серверы не павінны займацца CD:
- Скрыпты абнаўлення не заўсёды дэтэрмінаваны; у іх лёгка нарабіць памылак.
- CI-серверы не канвергуюць да дэкларатыўнай мадэлі кластара.
- Складана гарантаваць ідэмпатэнтнасць. Карыстальнікі павінны разбірацца ў глыбокай семантыцы сістэмы.
- Больш складана правесці аднаўленне пасля частковага збою.
Заўвага аб Helm'e: калі вы хочаце выкарыстоўваць Helm, мы рэкамендуем аб'яднаць яго з GitOps-аператарам, такім як . Гэта дапаможа забяспечыць канвергентнасць. Сам па сабе Helm не з'яўляецца ні дэтэрмінаваным, ні атамарным.
GitOps як найлепшы спосаб ажыццяўляць Continuous Delivery для Kubernetes
Каманда Алісы і Боба ўкараняе GitOps і выяўляе, што стала значна прасцей працаваць з праграмнымі прадуктамі, падтрымліваць высокую прадукцыйнасць і стабільнасць. Давайце скончым гэты артыкул ілюстрацыямі, якія паказваюць, як выглядае іх новы падыход. Улічыце, што мы ў асноўным гаворым аб прыкладаннях і сэрвісах, аднак GitOps можна выкарыстоўваць для кіравання ўсёй платформай.
Мадэль эксплуатацыі для Kubernetes
Паглядзіце на наступную дыяграму. Яна прадстаўляе Git і сховішча вобразаў кантэйнераў як агульныя рэсурсы для двух аркестраваных жыццёвых цыклаў:
- Пайплайна бесперапыннай інтэграцыі, які счытвае і запісвае файлы ў Git і можа абнаўляць рэпазітар кантэйнерных вобразаў.
- Пайплайн Runtime GitOps, які спалучае дэплой з кіраваннем і назіральнасцю. Ён счытвае і запісвае файлы ў Git і можа загружаць выявы кантэйнераў.
Якія асноўныя высновы?
- Падзел праблем: Звярніце ўвагу, што абодва пайплайн могуць абменьвацца дадзенымі, толькі абнаўляючы Git або рэпазітар вобразаў. Іншымі словамі, існуе сеткавы экран паміж CI і runtime-асяроддзем. Мы называем яго "брандмаўарам нязменлівасці" (immutability firewall), паколькі ўсе абнаўленні рэпазітараў ствараюць новыя версіі. Для атрымання дадатковай інфармацыі па дадзенай тэме звярніцеся да слайдаў 72-87 .
- Можна выкарыстоўваць любы CI-і Git-сервер: GitOps працуе з любымі кампанентамі. Вы можаце працягваць выкарыстоўваць свае любімыя CI- і Git-серверы, рэпазітары вобразаў і наборы тэстаў. Амаль усе астатнія прылады для Continuous Delivery на рынку патрабуюць уласнага CI-/Git-сервера ці сховішчы выяў. Гэта можа стаць абмяжоўвалым фактарам у развіцці cloud native. У выпадку GitOps вы можаце выкарыстоўваць звыклыя прылады.
- Падзеі як інструмент інтэграцыі: Як толькі дадзеныя ў Git абнаўляюцца, Weave Flux (ці аператар Weave Cloud) паведамляе пра гэта runtime. Кожны раз, калі Kubernetes прымае набор змен, Git абнаўляецца. Гэта забяспечвае простую мадэль інтэграцыі для арганізацыі працоўных працэсаў для GitOps, як паказана ніжэй.
Заключэнне
GitOps дае важкія гарантыі абнаўлення, неабходныя любой сучаснай прыладзе CI/CD:
- аўтаматызацыя;
- канвергенцыя;
- ідэмпатэнтнасць;
- дэтэрмінізм.
Гэта важна, паколькі ён прапануе мадэль эксплуатацыі для распрацоўшчыкаў у галіне cloud native.
- Традыцыйныя прылады для кіравання і маніторынгу сістэм звязаныя з камандамі эксплуатацыі, якія дзейнічаюць у рамках runbook'а (Набору руцінных працэдур і аперацый - заўв. перакл.), прывязанага да канкрэтнага deployment'у.
- Ва ўпраўленні cloud native-сістэмамі інструментарый для назірання з'яўляецца лепшым спосабам ацэнкі вынікаў разгортванняў, каб каманда распрацоўшчыкаў змагла аператыўна рэагаваць на іх.
Прадстаўце мноства кластараў, якія былі раскіданыя па розных аблоках і мноства сэрвісаў са сваімі ўласнымі камандамі і планамі разгортванняў. GitOps прапануе маштабна-інварыянтную мадэль для кіравання ўсім гэтым багаццем.
PS ад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «.
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. , Калі ласка.
Вы ведалі пра GitOps да з'яўлення гэтых двух перакладаў на хабры?
-
Так, усё ведаў(ла)
-
Толькі павярхоўна
-
Няма
Прагаласавалі 35 карыстальнікаў. Устрымаліся 10 карыстальнікаў.
Крыніца: habr.com