Повеќето од нас, забележувајќи уште еден нов термин во ИТ блогосферата или конференцијата, порано или подоцна поставуваат слично прашање: „Што е ова? Само уште еден збор, „збор“ или нешто навистина достојно за големо внимание, проучување и ветување за нови хоризонти?“ Истото ми се случи и со терминот GitOps пред некое време. Вооружени со многу постоечки статии, како и знаење на колегите од компанијата , се обидов да сфатам каков вид ѕвер е ова и како може да изгледа неговата употреба во пракса.
Патем, за новината на терминот GitOps Нашата неодамнешна анкета исто така вели: повеќе од половина од анкетираните сè уште не почнале да работат со нејзините принципи.
Значи, проблемот со управувањето со инфраструктурата не е нов. Многу провајдери на облак беа достапни за широката јавност десетина години и, се чини, требаше да ја направат работата на тимовите одговорни за инфраструктурата едноставна и јасна. Меѓутоа, кога се споредуваат со процесот на развој на апликации (каде што автоматизацијата достигнува сè уште нови нивоа), инфраструктурните проекти сè уште често вклучуваат многу рачни задачи и бараат специјализирано знаење и експертиза, особено со оглед на денешните барања за толеранција на грешки, флексибилност, приспособливост и еластичност.
Cloud услугите многу успешно ги исполнија овие барања и токму тие дадоа значителен поттик за развојот на пристапот IaC. Ова е разбирливо. На крајот на краиштата, тие овозможија да се конфигурира целосно виртуелен центар за податоци: нема физички сервери, лавици или мрежни компоненти; целата инфраструктура може да се опише со помош на скрипти и датотеки за конфигурација.
Значи, што точно е разликата? GitOps од IaC? Токму со ова прашање ја започнав мојата истрага. Откако разговарав со колегите, успеав да ја дојдам до следната споредба:
GitOps
IaC
Целиот код е зачуван во git складиште
Верзијата на кодот е изборна
Декларативен код Опис / Идемпотенција
Прифатливи се и декларативните и императивните описи
Промените стапуваат на сила со помош на механизмите Барање за спојување / барање за повлекување
Договорот, одобрувањето и соработката се опционални
Процесот на објавување ажурирања е автоматизиран
Процесот на објавување ажурирања не е стандардизиран (автоматски, рачно, копирање датотеки, користење на командната линија итн.)
Со други зборови GitOps се роди токму преку примената на принципите IaC. Прво, инфраструктурата и конфигурациите сега може да се складираат на ист начин како и апликациите. Кодот е лесен за складирање, лесен за споделување, споредување и користење на можностите за верзии. Верзии, гранки, историја. И сето тоа на место јавно достапно за целиот тим. Затоа, употребата на системи за контрола на верзии стана сосема природен развој. Особено, git, како најпопуларен.
Од друга страна, стана возможно да се автоматизираат процесите за управување со инфраструктурата. Сега ова може да се направи побрзо, посигурно и поевтино. Покрај тоа, принципите на CI / CD беа веќе познати и популарни меѓу развивачите на софтвер. Беше потребно само да се пренесат и применат веќе познатите знаења и вештини во нова област. Овие практики, сепак, ја надминаа стандардната дефиниција за Инфраструктура како код, па оттука и концептот GitOps.
Љубопитност GitOps, се разбира, и во фактот дека тоа не е производ, приклучок или платформа поврзана со кој било продавач. Тоа е повеќе парадигма и збир на принципи, сличен на друг термин што ни е познат: DevOps.
Компанијата развивме две дефиниции за овој нов поим: теоретска и практична. Да почнеме со теоретски:
GitOps е методологија која ги зема најдобрите принципи на DevOps што се користат за развој на апликации, како што се контрола на верзијата, соработка, оркестрација, CI/CD и ги применува на предизвиците на автоматизирање на управувањето со инфраструктурата.
Сите процеси GitOps Работам користејќи ги постоечките алатки. Целиот инфраструктурен код е зачуван во веќе познатото складиште за git, промените минуваат низ истиот процес на одобрување како и секој друг програмски код, а процесот на пуштање е автоматизиран, што ни овозможува да ги минимизираме човечките грешки, да ја зголемиме доверливоста и репродуктивноста.
Од практична гледна точка, ние опишуваме GitOps како што следува:
Веќе разговаравме за инфраструктурата како код како една од клучните компоненти на оваа формула. Да ги претставиме останатите учесници.
Барање за спојување (алтернативно име Повлекување барање). Во однос на процесот, MR е барање да се применат промени во кодот и потоа да се спојат гранките. Но, во однос на алатките што ги користиме, ова е повеќе можност да се добие целосна слика за сите промени што се прават: не само кодот се разликува од одреден број на обврски, туку и контекстот, резултатите од тестот и конечниот очекуван резултат. Ако зборуваме за инфраструктурен код, тогаш нè интересира како точно ќе се промени инфраструктурата, колку нови ресурси ќе се додадат или отстранат, сменат. По можност во некој поудобен и лесен за читање формат. За давателите на облак, добро е да знаат какво ќе биде финансиското влијание на оваа промена.
Но, МР е исто така средство за соработка, интеракција и комуникација. Местото каде што стапува во игра системот на проверки и рамнотежи. Од едноставни коментари до формални одобрувања и одобрувања.
Па, последната компонента: CI/CD, како што веќе знаеме, овозможува автоматизирање на процесот на правење промени во инфраструктурата и тестирање (од едноставна проверка на синтаксата до посложена статичка анализа на кодот). И, исто така, во последователното откривање на нанос: разлики помеѓу вистинската и посакуваната состојба на системот. На пример, како резултат на неовластени рачни промени или дефект на системот.
Да, терминот GitOps не воведува во ништо сосема ново, не го измислува повторно тркалото, туку едноставно го применува веќе акумулираното искуство во нова област. Но, тука е неговата сила.
И ако одеднаш се заинтересирате како сето ова изгледа во пракса, тогаш ве повикувам да го погледнете нашето , во кој ви кажувам чекор по чекор како да користите GitLab:
-
Спроведување на основните принципи на GitOps
-
Креирајте и правете промени во инфраструктурата на облакот (користејќи го примерот на Yandex Cloud)
-
Автоматизирајте го откривањето на оддалечувањето на системот од посакуваната состојба користејќи активно следење
https://bit.ly/34tRpwZ
Извор: www.habr.com