{"id":35941,"date":"2019-10-31T22:07:41","date_gmt":"2019-10-31T19:07:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-zhe-takoe-gitops\/"},"modified":"2019-10-31T22:07:41","modified_gmt":"2019-10-31T19:07:41","slug":"chto-zhe-takoe-gitops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/chto-zhe-takoe-gitops","title":{"rendered":"Ce este GitOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota traduc\u0103torului.<\/b>: Dup\u0103 publicarea recent\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/456754\/\">material<\/a><\/noindex> despre metodele pull \u0219i push \u00een GitOps, am observat un interes \u00een aceast\u0103 model \u00een general, \u00eens\u0103 publica\u021biile \u00een limba rom\u00e2n\u0103 pe acest subiect sunt foarte pu\u021bine (pe Habr nu exist\u0103 practic deloc). Prin urmare, suntem bucuro\u0219i s\u0103 v\u0103 oferim un traducere a unui alt articol \u2014 de\u0219i este aproape de un an! \u2014 de la compania Weaveworks, al c\u0103rei fondator a inventat termenul \u201eGitOps\u201d. \u00cen text se explic\u0103 esen\u021ba abord\u0103rii \u0219i diferen\u021bele cheie fa\u021b\u0103 de cele existente.<\/i><\/p>\n<p>\nAcum un an am publicat <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-operations-by-pull-request\">o introducere \u00een GitOps<\/a><\/noindex>. Atunci am povestit cum echipa Weaveworks a lansat un SaaS, complet bazat pe Kubernetes, \u0219i a dezvoltat un set de bune practici descriptive pentru implementare, gestionare \u0219i monitorizare \u00een medii cloud native.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Articolul a fost popular. Al\u021bi oameni au \u00eenceput s\u0103 discute despre GitOps, au \u00eenceput s\u0103 publice noi instrumente pentru <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/hasura\/gitkube\">git push<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/dzone.com\/articles\/weaveworks-gitops-developer-toolkit-part-one-skaff\">dezvoltare<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/storing-secure-sealed-secrets-using-gitops\">secrete<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.alexellis.io\/introducing-openfaas-cloud\/\">func\u021bii<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/jenkins.io\/blog\/2018\/03\/19\/introducing-jenkins-x\/\">integr\u0103rii continue<\/a><\/noindex> etc. Pe site-ul nostru au ap\u0103rut <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/category\/gitops\/\">o mul\u021bime de<\/a><\/noindex> publica\u021bii \u0219i cazuri de utilizare a GitOps. Dar pentru unii oameni au r\u0103mas \u00eentreb\u0103ri. Cu ce se diferen\u021biaz\u0103 modelul de tradi\u021bionalul <noindex><a rel=\"nofollow\" href=\"https:\/\/puppet.com\/blog\/a-deployment-pipeline-for-infrastructure-a-devops-case-study-at-nbn\">infrastructure as code<\/a><\/noindex> \u0219i livrarea continu\u0103 (<noindex><a rel=\"nofollow\" href=\"https:\/\/puppet.com\/blog\/a-deployment-pipeline-for-infrastructure-a-devops-case-study-at-nbn\">continuous delivery<\/a><\/noindex>)? Este necesar s\u0103 folose\u0219ti Kubernetes?<\/p>\n<p>\u00cen cur\u00e2nd ne-am dat seama c\u0103 este nevoie de o nou\u0103 descriere, care ofer\u0103:<\/p>\n<ol>\n<li> O mul\u021bime de exemple \u0219i pove\u0219ti;<\/li>\n<li> O defini\u021bie clar\u0103 a GitOps;<\/li>\n<li> O compara\u021bie cu livrarea continu\u0103 tradi\u021bional\u0103.<\/li>\n<\/ol>\n<p>\n\u00cen acest articol, am \u00eencercat s\u0103 acoperim toate aceste subiecte. Aici ve\u021bi g\u0103si o introducere actualizat\u0103 \u00een GitOps \u0219i o perspectiv\u0103 asupra acestuia din partea dezvoltatorilor \u0219i CI\/CD. Ne concentr\u0103m \u00een principal pe Kubernetes, de\u0219i modelul poate fi generalizat.<\/p>\n<h2>\u00cent\u00e2lni\u021bi: GitOps<\/h2>\n<p>\nImagina\u021bi-v\u0103-o pe Alice. Ea conduce compania Family Insurance, care ofer\u0103 poli\u021be de asigurare pentru s\u0103n\u0103tate, ma\u0219ini, imobiliare \u0219i asigurare de c\u0103l\u0103torie persoanelor care sunt prea ocupate pentru a \u00een\u021belege nuan\u021bele contractelor pe cont propriu. Afacerea ei a \u00eenceput ca un proiect secundar, c\u00e2nd Alice lucra \u00een banc\u0103 ca data scientist. \u00centr-o zi a realizat c\u0103 poate utiliza algoritmi computa\u021bionali avansa\u021bi pentru a analiza datele mai eficient \u0219i a crea pachete de asigurare. Investitorii au finan\u021bat proiectul, iar acum compania ei genereaz\u0103 peste 20 milioane de dolari pe an \u0219i cre\u0219te rapid. \u00cen prezent, lucreaz\u0103 180 de persoane \u00een diverse func\u021bii. Printre acestea se afl\u0103 o echip\u0103 tehnologic\u0103 care se ocup\u0103 cu dezvoltarea, \u00eentre\u021binerea site-ului, a bazei de date \u0219i analiza bazei de clien\u021bi. Echip\u0103 de 60 de persoane este condus\u0103 de Bob \u2014 directorul tehnic al companiei.<\/p>\n<p>Echipa lui Bob desf\u0103\u0219oar\u0103 sisteme de produc\u021bie \u00een cloud. Aplica\u021biile lor principale func\u021bioneaz\u0103 pe GKE, beneficiind de avantajele Kubernetes \u00een Google Cloud. De asemenea, ei utilizeaz\u0103 diverse instrumente pentru gestionarea datelor \u0219i analitice.<\/p>\n<p>Family Insurance nu avea de g\u00e2nd s\u0103 foloseasc\u0103 containere, dar a fost contagiat\u0103 de entuziasmul din jurul Docker. \u00cen cur\u00e2nd, speciali\u0219tii companiei au descoperit c\u0103 GKE permite desf\u0103\u0219urarea clusterelor pentru testarea noilor func\u021bionalit\u0103\u021bi \u00een mod u\u0219or \u0219i f\u0103r\u0103 dificult\u0103\u021bi. Au fost ad\u0103ugate Jenkins pentru CI \u0219i Quay pentru gestionarea registrului de containere, au fost scrise scripturi pentru Jenkins care push-uiau containerele \u0219i configura\u021biile noi \u00een GKE.<\/p>\n<p>A trecut ceva timp. Alice \u0219i Bob s-au dezam\u0103git de performan\u021ba abord\u0103rii alese \u0219i de impactul acesteia asupra afacerii. Implementarea containerelor nu a \u00eembun\u0103t\u0103\u021bit performan\u021ba at\u00e2t c\u00e2t spera echipa. Uneori, desf\u0103\u0219ur\u0103rile se stric\u0103, iar nu era clar dac\u0103 modific\u0103rile codului erau de vin\u0103. De asemenea, s-a dovedit a fi dificil s\u0103 se urm\u0103reasc\u0103 modific\u0103rile configura\u021biilor. Adesea, era necesar s\u0103 se creeze un nou cluster \u0219i s\u0103 se mute aplica\u021biile \u00een el, deoarece a\u0219a era cel mai u\u0219or s\u0103 se elimine haosul \u00een care se transformase sistemul. Alice se temea c\u0103 situa\u021bia se va \u00eenr\u0103ut\u0103\u021bi pe m\u0103sur\u0103 ce aplica\u021bia se va dezvolta (\u00een plus, un nou proiect bazat pe \u00eenv\u0103\u021barea automat\u0103 era \u00een curs de desf\u0103\u0219urare). Bob a automatizat o mare parte din munc\u0103 \u0219i nu \u00een\u021belegea de ce pipeline-ul r\u0103m\u00e2ne \u00een continuare instabil, se scalareaz\u0103 prost \u0219i necesit\u0103 periodic interven\u021bie manual\u0103.<\/p>\n<p><b>Apoi, au aflat despre GitOps. Aceast\u0103 solu\u021bie s-a dovedit a fi exact ceea ce aveau nevoie pentru a avansa cu \u00eencredere.<\/b><\/p>\n<p>Alice \u0219i Bob au auzit de ani de zile despre fluxurile de lucru bazate pe Git, DevOps \u0219i infrastructure as code. Unicitatea GitOps const\u0103 \u00een faptul c\u0103 aduce o serie de bune practici \u2014 categorice \u0219i normative \u2014 pentru implementarea acestor idei \u00een contextul Kubernetes. Acest subiect <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/search?q=gitops&amp;src=typd\">a fost ridicat de mai multe ori<\/a><\/noindex>, inclusiv \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-high-velocity-cicd-for-kubernetes\">blogul Weaveworks<\/a><\/noindex>.<\/p>\n<p>Family Insurance decide s\u0103 implementeze GitOps. Acum, compania are un model de operare automatizat, compatibil cu Kubernetes \u0219i care \u00eembin\u0103 <i>viteza<\/i> cu <i>stabilitatea<\/i>, deoarece ei:<\/p>\n<ul>\n<li> au descoperit c\u0103 echipa \u0219i-a dublat productivitatea \u0219i nimeni nu \u00ee\u0219i pierde min\u021bile;<\/li>\n<li> au \u00eencetat s\u0103 mai \u00eentre\u021bin\u0103 scripturile. \u00cen loc de asta, acum se pot concentra pe noi func\u021bionalit\u0103\u021bi \u0219i s\u0103 \u00eembun\u0103t\u0103\u021beasc\u0103 metodele de inginerie \u2014 de exemplu, prin implementarea de rollout-uri canar \u0219i \u00eembun\u0103t\u0103\u021birea test\u0103rii;<\/li>\n<li> au perfec\u021bionat procesul de desf\u0103\u0219urare \u2014 acum rareori se stric\u0103;<\/li>\n<li> au ob\u021binut posibilitatea de a restaura desf\u0103\u0219ur\u0103rile dup\u0103 \u00eentreruperi par\u021biale f\u0103r\u0103 interven\u021bie manual\u0103;<\/li>\n<li> au c\u00e2\u0219tigat o<i>mare<\/i>mai mare \u00eencredere \u00een sistemele de livrare. Alice \u0219i Bob au descoperit c\u0103 pot \u00eemp\u0103r\u021bi echipa \u00een grupuri care se ocup\u0103 cu microserviciile \u0219i lucreaz\u0103 simultan;<\/li>\n<li> pot face \u00eentre 30-50 de modific\u0103ri \u00een proiect \u00een fiecare zi prin eforturile fiec\u0103rui grup \u0219i pot \u00eencerca noi tehnici;<\/li>\n<li> atrag u\u0219or noi dezvoltatori \u00een proiect, care au capacitatea de a implementa actualiz\u0103ri \u00een produc\u021bie folosind pull request-uri \u00een termen de c\u00e2teva ore;<\/li>\n<li> trece u\u0219or auditul \u00een cadrul SOC2 <i>(pentru conformitatea furnizorilor de servicii cu cerin\u021bele de gestionare sigur\u0103 a datelor; citi\u021bi \u00een continuare, de exemplu, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.imperva.com\/learn\/data-security\/soc-2-compliance\/\">aici<\/a><\/noindex> \u2014 nota trad.)<\/i>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Ce s-a \u00eent\u00e2mplat?<\/h3>\n<p>\nGitOps este dou\u0103 lucruri:<\/p>\n<ol>\n<li> Un model de operare pentru Kubernetes \u0219i cloud native. Ofer\u0103 un set de bune practici pentru desf\u0103\u0219urarea, gestionarea \u0219i monitorizarea clusterelor \u0219i aplica\u021biilor adunate \u00een containere. O defini\u021bie elegant\u0103 sub forma <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/vitorsilva\/status\/999978906903080961\">unui singur slide<\/a><\/noindex> de la <noindex><a rel=\"nofollow\" href=\"https:\/\/2018.agilept.org\/speaker_luis_faceira.html\">Luis Faceira<\/a><\/noindex>:\n<\/li>\n<li> Calea c\u0103tre crearea unui mediu orientat pe dezvoltatori pentru gestionarea aplica\u021biilor. Aplic\u0103m fluxul de lucru Git at\u00e2t pentru operare, c\u00e2t \u0219i pentru dezvoltare. Re\u021bine\u021bi c\u0103 nu este vorba doar despre Git push, ci despre organizarea \u00eentregului set de unelte CI\/CD \u0219i UI\/UX.<\/li>\n<\/ol>\n<p><\/p>\n<h3>C\u00e2teva cuvinte despre Git<\/h3>\n<p>\nDac\u0103 nu sunte\u021bi familiarizat cu sistemele de control al versiunilor \u0219i fluxul de lucru bazat pe Git, v\u0103 recomand\u0103m cu t\u0103rie s\u0103 le studia\u021bi. La \u00eenceput, lucrul cu ramuri \u0219i pull request-uri poate p\u0103rea magie neagr\u0103, dar beneficiile merit\u0103 efortul. Iat\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/codeburst.io\/trunk-based-development-vs-git-flow-a0212a6cae64\">un articol bun<\/a><\/noindex> pentru \u00eenceput.<\/p>\n<h2>Cum func\u021bioneaz\u0103 Kubernetes<\/h2>\n<p>\n\u00cen povestea noastr\u0103, Alice \u0219i Bob s-au \u00eendreptat spre GitOps, dup\u0103 ce au lucrat ceva timp cu Kubernetes. De fapt, GitOps este str\u00e2ns legat de Kubernetes \u2014 este un model de operare pentru infrastructura \u0219i aplica\u021biile bazate pe Kubernetes.<\/p>\n<h3>Ce ofer\u0103 Kubernetes utilizatorilor?<\/h3>\n<p>\nIat\u0103 c\u00e2teva dintre principalele sale capabilit\u0103\u021bi:<\/p>\n<ol>\n<li> \u00cen modelul Kubernetes, totul poate fi descris \u00eentr-o form\u0103 declarativ\u0103.<\/li>\n<li> API-serverul Kubernetes accept\u0103 o astfel de declara\u021bie ca date de intrare \u0219i apoi \u00eencearc\u0103 constant s\u0103 aduc\u0103 cluster-ul \u00een starea descris\u0103 \u00een declara\u021bie.<\/li>\n<li> Declara\u021biile sunt suficiente pentru a descrie \u0219i gestiona o mare varietate de sarcini de lucru \u2014 \u201eaplica\u021bii\u201d.<\/li>\n<li> Ca rezultat, modific\u0103rile aplica\u021biei \u0219i clusterele au loc din cauza:\n<ul>\n<li> modific\u0103rilor din imaginile containerelor;<\/li>\n<li> modific\u0103rilor din specifica\u021bia declarativ\u0103;<\/li>\n<li> eroare \u00een mediu \u2014 de exemplu, pr\u0103bu\u0219iri de containere.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h3>Capacit\u0103\u021bile extraordinare ale Kubernetes de convergen\u021b\u0103<\/h3>\n<p>\nC\u00e2nd un administrator face modific\u0103ri \u00een configura\u021bie, orchestratorul Kubernetes va aplica aceste modific\u0103ri \u00een cluster p\u00e2n\u0103 c\u00e2nd starea sa <i>se va apropia de noua configura\u021bie.<\/i>. Acest model func\u021bioneaz\u0103 pentru orice resurs\u0103 Kubernetes \u0219i se extinde cu ajutorul Custom Resource Definitions (CRDs). De aceea, desf\u0103\u0219ur\u0103rile Kubernetes dispun de urm\u0103toarele propriet\u0103\u021bi minunate:<\/p>\n<ul>\n<li> <b>Automatizarea<\/b>: actualiz\u0103rile Kubernetes ofer\u0103 un mecanism pentru automatizarea procesului de aplicare a modific\u0103rilor \u00een mod corect \u0219i la timp.<\/li>\n<li> <b>Convergen\u021ba<\/b>: Kubernetes va continua s\u0103 \u00eencerce actualiz\u0103rile p\u00e2n\u0103 la atingerea succesului.<\/li>\n<li> <b>Idempotent\u0103<\/b>: aplic\u0103rile repetate ale convergen\u021bei duc la acela\u0219i rezultat.<\/li>\n<li> <b>Determinism<\/b>: \u00een cazul suficien\u021bei resurselor, starea clusterului actualizat depinde doar de starea dorit\u0103.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Cum func\u021bioneaz\u0103 GitOps<\/h2>\n<p>\nAm \u00eenv\u0103\u021bat suficient despre Kubernetes pentru a explica principiile de func\u021bionare ale GitOps.<\/p>\n<p>S\u0103 ne \u00eentoarcem la echipele Family Insurance, legate de microservicii. Ce trebuie s\u0103 fac\u0103 de obicei? Uita\u021bi-v\u0103 la lista de mai jos (dac\u0103 unele elemente vi se par ciudate sau necunoscute \u2014 v\u0103 rug\u0103m s\u0103 nu critici \u0219i s\u0103 r\u0103m\u00e2ne\u021bi cu noi). Acestea sunt doar exemple de fluxuri de lucru bazate pe Jenkins. Exist\u0103, de asemenea, multe alte procese folosind alte instrumente.<\/p>\n<p>Ceea ce este important \u2014 vedem c\u0103 fiecare actualizare se finalizeaz\u0103 prin modific\u0103ri \u00een fi\u0219ierele de configurare \u0219i \u00een repositoarele Git. Aceste modific\u0103ri din Git determin\u0103 \u201eoperatorul GitOps\u201d s\u0103 actualizeze clusterul:<\/p>\n<p>1. Flux de lucru: \u201e<i>Construire Jenkins \u2014 ramura master<\/i>\u00bb.<br \/>\nLista de sarcini:<\/p>\n<ul>\n<li> Jenkins push-uie\u0219te imagini etichetate \u00een Quay;<\/li>\n<li> Jenkins push-uie\u0219te configura\u021bia \u0219i graficele Helm \u00een bucketul principal;<\/li>\n<li> O func\u021bie cloud copiaz\u0103 configurarea \u0219i graficele din bucket-ul stoc\u0103rii master \u00een repository-ul Git master;<\/li>\n<li> Operatorul GitOps actualizeaz\u0103 clusterul.<\/li>\n<\/ul>\n<p>\n2. <i>Construire Jenkins \u2014 ramura release sau hotfix<\/i>:<\/p>\n<ul>\n<li> Jenkins push-uie\u0219te imagini netichetate \u00een Quay;<\/li>\n<li> Jenkins push-uie\u0219te configura\u021bia \u0219i graficele Helm \u00een bucketul de staging;<\/li>\n<li> O func\u021bie cloud copiaz\u0103 configurarea \u0219i graficele din bucket-ul stoc\u0103rii staging \u00een repository-ul Git staging;<\/li>\n<li> Operatorul GitOps actualizeaz\u0103 clusterul.<\/li>\n<\/ul>\n<p>\n3. <i>Construire Jenkins \u2014 ramura develop sau feature<\/i>:<\/p>\n<ul>\n<li> Jenkins push-uie\u0219te imagini netichetate \u00een Quay;<\/li>\n<li> Jenkins push-uie\u0219te configura\u021bia \u0219i graficele Helm \u00een bucketul de develop;<\/li>\n<li> O func\u021bie cloud copiaz\u0103 configurarea \u0219i graficele din bucket-ul stoc\u0103rii develop \u00een repository-ul Git develop;<\/li>\n<li>Operatorul GitOps actualizeaz\u0103 clusterul.<\/li>\n<\/ul>\n<p>\n4. <i>Ad\u0103ugarea unui nou client<\/i>:<\/p>\n<ul>\n<li> Managerul sau administratorul (LCM\/ops) apeleaz\u0103 Gradle pentru desf\u0103\u0219urarea ini\u021bial\u0103 \u0219i configurarea echilibratoarelor de sarcin\u0103 (NLB);<\/li>\n<li> LCM\/ops comite o nou\u0103 configura\u021bie pentru a preg\u0103ti desf\u0103\u0219urarea pentru actualiz\u0103ri;<\/li>\n<li> Operatorul GitOps actualizeaz\u0103 clusterul.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Prezentare general\u0103 a GitOps<\/h3>\n<p><\/p>\n<ol>\n<li> Descrie starea dorit\u0103 a \u00eentregului sistem, folosind specifica\u021bii declarative pentru fiecare mediu (\u00een povestea noastr\u0103, echipa lui Bob define\u0219te \u00eentreaga configura\u021bie a sistemului \u00een Git).\n<ul>\n<li> Depozitul Git este sursa unic\u0103 de adev\u0103r \u00een ceea ce prive\u0219te starea dorit\u0103 a \u00eentregului sistem.<\/li>\n<li> Toate modific\u0103rile \u00een starea dorit\u0103 se fac prin comituri \u00een Git.<\/li>\n<li> Toate parametrii doriti ai clusterului sunt de asemenea observa\u021bi \u00een cadrul clusterului. Astfel, putem determina dac\u0103 acestea coincid (converge, <i>converge<\/i>) sau difer\u0103 (diverge, <i>diverge<\/i>) starea dorit\u0103 \u0219i cea observat\u0103.<\/li>\n<\/ul>\n<\/li>\n<li> Dac\u0103 starea dorit\u0103 \u0219i cea observat\u0103 difer\u0103, atunci:\n<ul>\n<li> Exist\u0103 un mecanism de convergen\u021b\u0103 care, mai devreme sau mai t\u00e2rziu, va sincroniza automat st\u0103rile \u021bint\u0103 \u0219i cele observate. \u00cen cadrul clusterului, acest lucru este gestionat de Kubernetes.<\/li>\n<li> Procesul porne\u0219te imediat cu notificarea \u201eschimbare comis\u0103\u201d.<\/li>\n<li> Dup\u0103 o anumit\u0103 perioad\u0103 configurabil\u0103, poate fi trimis\u0103 o notificare \u201ediff\u201d, dac\u0103 st\u0103rile difer\u0103.<\/li>\n<\/ul>\n<\/li>\n<li> Astfel, toate comituri din Git genereaz\u0103 actualiz\u0103ri verificabile \u0219i idempotente \u00een cluster.\n<ul>\n<li>Rollback-ul este o convergen\u021b\u0103 c\u0103tre o stare dorit\u0103 anterioar\u0103.<\/li>\n<\/ul>\n<\/li>\n<li> Convergen\u021ba este final\u0103. Indiciile pentru existen\u021ba sa sunt:\n<ul>\n<li> Lipsa notific\u0103rilor \u201ediff\u201d pentru o anumit\u0103 perioad\u0103 de timp.<\/li>\n<li> Notificarea \u201econverged\u201d (de exemplu, webhook, eveniment Git writeback).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h3>Ce este divergen\u021ba?<\/h3>\n<p>\nS\u0103 repet\u0103m \u00eenc\u0103 o dat\u0103: <i>toate propriet\u0103\u021bile dorite ale clusterului trebuie s\u0103 fie observabile \u00een cadrul clusterului<\/i>.<\/p>\n<p>C\u00e2teva exemple de divergen\u021b\u0103:<\/p>\n<ul>\n<li> Modificarea din fi\u0219ierul de configurare din cauza unui merge de ramuri \u00een Git.<\/li>\n<li> Modificarea din fi\u0219ierul de configurare din cauza unui commit \u00een Git, efectuat de un client GUI.<\/li>\n<li> Modific\u0103ri multiple \u00een starea dorit\u0103 din cauza unui PR \u00een Git urmat de construirea unei imagini de container \u0219i schimb\u0103ri \u00een configura\u021bie.<\/li>\n<li> Modificarea st\u0103rii clusterului din cauza unei erori, conflict de resurse, care duce la \u201ecomportament defectuos\u201d, sau pur \u0219i simplu o deviere accidental\u0103 de la starea original\u0103.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Ce reprezint\u0103 mecanismul de convergen\u021b\u0103?<\/h3>\n<p>\nC\u00e2teva exemple:<\/p>\n<ul>\n<li> Pentru containere \u0219i clustere, mecanismul de convergen\u021b\u0103 este furnizat de Kubernetes.<\/li>\n<li> Acela\u0219i mecanism poate fi utilizat pentru gestionarea aplica\u021biilor \u0219i structurilor bazate pe Kubernetes (de exemplu, Istio \u0219i Kubeflow).<\/li>\n<li> Mecanismul pentru gestionarea interac\u021biunii de munc\u0103 \u00eentre Kubernetes, repozitoarele de imagini \u0219i Git ofer\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/weaveworks\/flux\">Operatorul GitOps Weave Flux<\/a><\/noindex>, care face parte din <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.weave.works\/\">Weave Cloud<\/a><\/noindex>.<\/li>\n<li> Pentru ma\u0219inile de baz\u0103, mecanismul de convergen\u021b\u0103 trebuie s\u0103 fie declara\u021biv \u0219i autonom. Din experien\u021ba noastr\u0103, putem spune c\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.gruntwork.io\/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c\">Terraform<\/a><\/noindex> se apropie cel mai mult de aceast\u0103 defini\u021bie, dar necesit\u0103 totu\u0219i control din partea omului. \u00cen acest sens, GitOps extinde tradi\u021biile Infrastructure as Code.<\/li>\n<\/ul>\n<p>\nGitOps combin\u0103 Git cu un mecanism excelent de convergen\u021b\u0103 Kubernetes, oferind un model pentru exploatare.<\/p>\n<p>GitOps ne permite s\u0103 afirm\u0103m: <i>automatisarea \u0219i controlul se aplic\u0103 doar sistemelor care pot fi descrise \u0219i observate<\/i>.<\/p>\n<h3>GitOps este destinat \u00eentregului stack cloud native (de exemplu, Terraform etc.)<\/h3>\n<p>\nGitOps nu este doar Kubernetes. Vrem ca \u00eentregul sistem s\u0103 fie gestionat declara\u021bi \u0219i s\u0103 foloseasc\u0103 convergen\u021ba. Prin \u00eentregul sistem ne referim la ansamblul mediilor care lucreaz\u0103 cu Kubernetes - de exemplu, \u00abdev cluster 1\u00bb, \u00abproduction\u00bb etc. Fiecare mediu include ma\u0219ini, clustere, aplica\u021bii, precum \u0219i interfe\u021be pentru servicii externe care furnizeaz\u0103 date, monitorizare etc.<\/p>\n<p>Observa\u021bi c\u00e2t de important este Terraform pentru problema bootstrapping-ului. Kubernetes trebuie s\u0103 fie desf\u0103\u0219urat undeva, iar utilizarea Terraform \u00eenseamn\u0103 c\u0103 putem aplica acelea\u0219i fluxuri de lucru GitOps pentru a construi un strat de control care st\u0103 la baza Kubernetes \u0219i aplica\u021biilor. Aceasta este o cea mai bun\u0103 practic\u0103 util\u0103.<\/p>\n<p>Se acord\u0103 o mare aten\u021bie aplic\u0103rii conceptelor GitOps la straturile deasupra Kubernetes. P\u00e2n\u0103 \u00een prezent, exist\u0103 solu\u021bii de tip GitOps pentru Istio, Helm, Ksonnet, OpenFaaS \u0219i Kubeflow, precum \u0219i, de exemplu, pentru Pulumi, care creeaz\u0103 un strat pentru dezvoltarea aplica\u021biilor cloud native.<\/p>\n<h2>Kubernetes CI\/CD: compararea GitOps cu alte abord\u0103ri<\/h2>\n<p>\nA\u0219a cum s-a spus, GitOps reprezint\u0103 dou\u0103 lucruri:<\/p>\n<ol>\n<li> Un model de exploatare pentru Kubernetes \u0219i cloud native, descris mai sus.<\/li>\n<li> Calea c\u0103tre organizarea unei medii orientate pe dezvoltatori pentru gestionarea aplica\u021biilor.<\/li>\n<\/ol>\n<p>\nPentru mul\u021bi, GitOps este mai \u00eent\u00e2i de toate un flux de lucru bazat pe Git push-uri. Ne place \u0219i nou\u0103. Dar asta nu e tot: haide\u021bi s\u0103 ne uit\u0103m acum la pipeline-urile CI\/CD.<\/p>\n<h3>GitOps asigur\u0103 desf\u0103\u0219urarea continu\u0103 (CD) sub Kubernetes<\/h3>\n<p>\nGitOps ofer\u0103 un mecanism de desf\u0103\u0219urare continu\u0103, elimin\u00e2nd necesitatea unor \u00absisteme de management al desf\u0103\u0219ur\u0103rilor\u00bb separate. Toat\u0103 munca este realizat\u0103 de Kubernetes.<\/p>\n<ul>\n<li> Actualizarea aplica\u021biei necesit\u0103 o actualizare \u00een Git. Aceasta este o actualizare tranzac\u021bional\u0103 c\u0103tre starea dorit\u0103. \u201eDesf\u0103\u0219urarea\u201d este apoi realizat\u0103 \u00een interiorul cluster-ului de c\u0103tre Kubernetes pe baza descrierii actualizate.<\/li>\n<li> Din cauza specificului func\u021bion\u0103rii Kubernetes, aceste actualiz\u0103ri sunt convergente. Aceasta asigur\u0103 un mecanism pentru implementarea continu\u0103, \u00een care toate actualiz\u0103rile sunt atomice.<\/li>\n<li> Not\u0103: <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.weave.works\/\">Weave Cloud<\/a><\/noindex> ofer\u0103 un operator GitOps care integreaz\u0103 Git \u0219i Kubernetes \u0219i permite realizarea CD prin alinierea st\u0103rii dorite \u0219i a st\u0103rii curente a clusterului.<\/li>\n<\/ul>\n<p><\/p>\n<h3>F\u0103r\u0103 kubectl \u0219i scripturi<\/h3>\n<p>\nEste recomandat s\u0103 evita\u021bi utilizarea Kubectl pentru actualizarea clusterului, \u00een special a scripturilor pentru gruparea comenzilor kubectl. \u00cen schimb, prin intermediul unui pipeline GitOps, utilizatorul poate actualiza clusterul Kubernetes prin Git.<\/p>\n<p>Avantajele includ:<\/p>\n<ol>\n<li> <b>Corectitudinea<\/b>. O grup\u0103 de actualiz\u0103ri poate fi aplicat\u0103, convergen\u021ba, \u0219i \u00een cele din urm\u0103 validat\u0103, ceea ce ne apropie de obiectivul unei implement\u0103ri atomice. Spre deosebire de aceasta, utilizarea scripturilor nu ofer\u0103 nicio garan\u021bie de convergen\u021b\u0103 (mai multe despre acest subiect mai jos).<\/li>\n<li> <b>Securitate<\/b>. <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/kelseyhightower\/status\/939003832805179392?lang=en\">Citat din<\/a><\/noindex> Kelsey Hightower: \"Limita\u021bi accesul la clusterul Kubernetes instrumentelor de automatizare \u0219i administratorilor care sunt responsabili de depanarea sau men\u021binerea acestuia \u00een func\u021biune\". Vezi de asemenea <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-compliance-and-secure-cicd\">publica\u021bia mea<\/a><\/noindex> despre securitate \u0219i conformitatea cu cerin\u021bele tehnice, precum \u0219i <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@vesirin\/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab\">articolul despre hack-ul Homebrew<\/a><\/noindex> prin furtul acreditivelor dintr-un script Jenkins neglijent.<\/li>\n<li> <b>Experien\u021ba utilizatorului<\/b>. Kubectl expune mecanica modelului obiectual Kubernetes, care este destul de complex. \u00cen ideal, utilizatorii ar trebui s\u0103 interac\u021bioneze cu sistemul la un nivel de abstrac\u021bie mai \u00eenalt. Aici m\u0103 voi referi din nou la Kelsey \u0219i recomand s\u0103 viziona\u021bi <noindex><a rel=\"nofollow\" href=\"http:\/\/superuser.openstack.org\/articles\/kubernetes-boring\/\">un astfel de rezumat<\/a><\/noindex>.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Diferen\u021ba \u00eentre CI \u0219i CD<\/h3>\n<p>\nGitOps \u00eembun\u0103t\u0103\u021be\u0219te modelele CI\/CD existente.<\/p>\n<p>Un server CI modern reprezint\u0103 un instrument pentru orchestrare. \u00cen special, este un instrument pentru orchestrarea pipeline-urilor CI. Acestea includ build, test, merge to trunk etc. Serverele CI automatizeaz\u0103 gestionarea unor pipeline-uri complexe, multi-etap\u0103. O tentare frecvent\u0103 este s\u0103 crea\u021bi un script pentru setul de actualiz\u0103ri Kubernetes \u0219i s\u0103-l executa\u021bi ca parte a pipeline-ului pentru push-ul modific\u0103rilor \u00een cluster. Cu adev\u0103rat, a\u0219a procedeaz\u0103 mul\u021bi speciali\u0219ti. Cu toate acestea, nu este optim, \u0219i iat\u0103 de ce.<\/p>\n<p>CI ar trebui s\u0103 fie folosit pentru a aduce actualiz\u0103ri \u00een trunk, iar clusterul Kubernetes ar trebui s\u0103 se schimbe pe baza acestor actualiz\u0103ri, pentru a gestiona CD \u201e\u00een mod intern\u201d. Numim acest lucru <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-compliance-and-secure-cicd\">un model pull pentru CD<\/a><\/noindex>, spre deosebire de modelul push de CI. CD este parte din <i>orchestrarea runtime<\/i>.<\/p>\n<h3>De ce serverele CI nu ar trebui s\u0103 fac\u0103 CD prin actualiz\u0103ri directe \u00een Kubernetes<\/h3>\n<p>\n<i>Nu folosi\u021bi serverul CI pentru orchestrarea actualiz\u0103rilor directe \u00een Kubernetes sub forma unui set de sarcini CI. Acesta este un anti-model despre care noi <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/kubernetes-anti-patterns-let-s-do-gitops-not-ciops\">a povestit deja<\/a><\/noindex> vorbim \u00een blogul nostru.<\/i><\/p>\n<p>S\u0103 ne \u00eentoarcem la Alice \u0219i Bob.<\/p>\n<p>Ce probleme au \u00eent\u00e2mpinat? Serverul CI al lui Bob aplic\u0103 modific\u0103rile \u00een cluster, dar dac\u0103 \u00een proces acesta se pr\u0103bu\u0219e\u0219te, Bob nu va \u0219ti \u00een ce stare se afl\u0103 (sau ar trebui s\u0103 fie) clusterul \u0219i cum s\u0103-l repare. Aceea\u0219i situa\u021bie se aplic\u0103 \u0219i \u00een caz de succes.<\/p>\n<p>S\u0103 presupunem c\u0103 echipa lui Bob a construit o nou\u0103 imagine \u0219i apoi \u0219i-a patch-uit deployment-urile pentru a desf\u0103\u0219ura imaginea (toate acestea din pipeline-ul CI).<\/p>\n<p>Dac\u0103 imaginea se construie\u0219te corect, dar pipeline-ul se pr\u0103bu\u0219e\u0219te, echipa va trebui s\u0103 afle:<\/p>\n<ul>\n<li> S-a desf\u0103\u0219urat actualizarea?<\/li>\n<li> Desf\u0103\u0219ur\u0103m o nou\u0103 construc\u021bie? Va provoca aceasta efecte secundare nedorite \u2014 av\u00e2nd posibilitatea de a ob\u021bine dou\u0103 construc\u021bii ale acelea\u0219i imagini nemodificate? <\/li>\n<li> Ar trebui s\u0103 a\u0219tept\u0103m urm\u0103toarea actualizare \u00eenainte de a desf\u0103\u0219ura construc\u021bia?<\/li>\n<li> Ce anume a mers prost? Ce pa\u0219i trebuie s\u0103 repet\u0103m (\u0219i care dintre ace\u0219tia pot fi repeta\u021bi \u00een siguran\u021b\u0103)?<\/li>\n<\/ul>\n<p>\n<i>Organizarea unui flux de lucru bazat pe Git nu garanteaz\u0103 c\u0103 echipa lui Bob nu se va confrunta cu aceste probleme. Ei pot gre\u0219i \u00een continuare cu push-ul unui commit, cu tag-ul sau cu orice alt parametru; cu toate acestea, aceast\u0103 abordare este totu\u0219i mult mai apropiat\u0103 de un sistem explicit all-or-nothing.<\/i><\/p>\n<p>\u00een concluzie, iat\u0103 de ce serverele CI nu ar trebui s\u0103 se ocupe de CD:<\/p>\n<ul>\n<li> Scripturile de actualizare nu sunt \u00eentotdeauna deterministe; este u\u0219or s\u0103 faci gre\u0219eli \u00een ele.<\/li>\n<li> Serverele CI nu converg c\u0103tre un model declara\u021bional de cluster.<\/li>\n<li> Este greu de garantat idempotentitatea. Utilizatorii trebuie s\u0103 \u00een\u021beleag\u0103 semantica profund\u0103 a sistemului.<\/li>\n<li> Este mai greu s\u0103 recuperezi dup\u0103 o eroare par\u021bial\u0103.<\/li>\n<\/ul>\n<p>\n<i>Not\u0103 privind Helm: dac\u0103 dori\u021bi s\u0103 utiliza\u021bi Helm, v\u0103 recomand\u0103m s\u0103 \u00eel combina\u021bi cu un operator GitOps, cum ar fi <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/managing-helm-releases-the-gitops-way\">Flux-Helm<\/a><\/noindex>. Acest lucru va ajuta la asigurarea convergen\u021bei. Helm, de sine st\u0103t\u0103tor, nu este nici determinist, nici atomic.<\/i><\/p>\n<h2>GitOps ca cea mai bun\u0103 metod\u0103 de a realiza Continuous Delivery pentru Kubernetes<\/h2>\n<p>\nEchipa lui Alice \u0219i Bob implementeaz\u0103 GitOps \u0219i descoper\u0103 c\u0103 este mult mai u\u0219or s\u0103 lucreze cu produsele software, men\u021bin\u00e2nd o performan\u021b\u0103 \u0219i stabilitate ridicate. S\u0103 \u00eencheiem acest articol cu ilustra\u021bii care arat\u0103 cum arat\u0103 noul lor abordare. Re\u021bine\u021bi c\u0103 vorbim \u00een principal despre aplica\u021bii \u0219i servicii, \u00eens\u0103 GitOps poate fi folosit pentru a gestiona \u00eentreaga platform\u0103.<\/p>\n<h3>Modelul de operare pentru Kubernetes<\/h3>\n<p>\nUita\u021bi-v\u0103 la urm\u0103toarea diagram\u0103. Aceasta reprezint\u0103 Git \u0219i depozitul de imagini ale containerelor ca resurse comune pentru cele dou\u0103 cicluri de via\u021b\u0103 orchestrate:<\/p>\n<ul>\n<li> Pipeline-ul de integrare continu\u0103, care cite\u0219te \u0219i scrie fi\u0219iere \u00een Git \u0219i poate actualiza depozitul imaginilor containerelor.<\/li>\n<li> Pipeline-ul Runtime GitOps, care combin\u0103 desf\u0103\u0219urarea cu gestionarea \u0219i observabilitatea. Acesta cite\u0219te \u0219i scrie fi\u0219iere \u00een Git \u0219i poate \u00eenc\u0103rca imagini ale containerelor.<\/li>\n<\/ul>\n<h3>Care sunt principalele concluzii?<\/h3>\n<p><\/p>\n<ol>\n<li> <b>Separarea problemelor<\/b>: Re\u021bine\u021bi c\u0103 ambele pipeline-uri pot face schimb de date, actualiz\u00e2nd doar Git sau depozitul imaginilor. Cu alte cuvinte, exist\u0103 un firewall \u00eentre CI \u0219i mediu de runtime. \u00cel numim \u201efirewall-ul imutabilit\u0103\u021bii\u201d <i>(immutability firewall)<\/i>, deoarece toate actualiz\u0103rile depozitelor creeaz\u0103 versiuni noi. Pentru informa\u021bii suplimentare cu privire la acest subiect, consulta\u021bi slide-urile 72-87 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.slideshare.net\/weaveworks\/continuous-lifecycle-london-2018-event-keynote-97418556\">aceast\u0103 prezentare<\/a><\/noindex>.<\/li>\n<li> <b>Orice server CI \u0219i Git poate fi folosit<\/b>: GitOps func\u021bioneaz\u0103 cu orice componente. Pute\u021bi continua s\u0103 folosi\u021bi serverele \u0219i depozitele de Git preferate, imagini ale containerelor \u0219i seturi de teste. Aproape toate celelalte instrumente pentru Continuous Delivery de pe pia\u021b\u0103 necesit\u0103 propriul server CI\/Git sau depozit de imagini. Acest lucru poate deveni un factor limitativ \u00een dezvoltarea cloud native. \u00cen cazul GitOps, pute\u021bi folosi instrumentele cunoscute.<\/li>\n<li> <b>Evenimentele ca instrument de integrare<\/b>: De \u00eendat\u0103 ce datele din Git sunt actualizate, Weave Flux (sau operatorul Weave Cloud) notific\u0103 despre aceasta runtime-ul. De fiecare dat\u0103 c\u00e2nd Kubernetes prime\u0219te un set de modific\u0103ri, Git este actualizat. Acest lucru asigur\u0103 un model simplu de integrare pentru organizarea fluxurilor de lucru pentru GitOps, a\u0219a cum se arat\u0103 mai jos.<\/li>\n<\/ol>\n<h2>Concluzie<\/h2>\n<p>\nGitOps ofer\u0103 garan\u021bii semnificative de actualizare necesare oric\u0103rui instrument modern de CI\/CD:<\/p>\n<ul>\n<li> automatul;<\/li>\n<li> convergen\u021b\u0103;<\/li>\n<li> idempotent\u0103;<\/li>\n<li> determinism.<\/li>\n<\/ul>\n<p>\nEste important, deoarece ofer\u0103 un model de operare pentru dezvoltatori \u00een domeniul cloud native.<\/p>\n<ul>\n<li> Instrumentele tradi\u021bionale pentru gestionarea \u0219i monitorizarea sistemelor sunt legate de echipele de operare care ac\u021bioneaz\u0103 \u00een cadrul runbook-ului <i>(set de proceduri \u0219i opera\u021biuni de rutin\u0103 - n.red.)<\/i>, legat de un anumit deployment.<\/li>\n<li> \u00cen managementul sistemelor cloud native, instrumentele de observare reprezint\u0103 cea mai bun\u0103 modalitate de a evalua rezultatele desf\u0103\u0219ur\u0103rilor, astfel \u00eenc\u00e2t echipa de dezvoltare s\u0103 poat\u0103 reac\u021biona rapid la acestea.<\/li>\n<\/ul>\n<p>\nImagina\u021bi-v\u0103 numeroase clustere r\u0103sp\u00e2ndite \u00een diferite cloud-uri \u0219i o mul\u021bime de servicii cu propriile echipe \u0219i planuri de desf\u0103\u0219urare. GitOps ofer\u0103 un model invariant \u0219i la scar\u0103 pentru a gestiona toat\u0103 aceast\u0103 abunden\u021b\u0103.<\/p>\n<h2>P.S. de la traduc\u0103tor<\/h2>\n<p>\nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/456754\/\">GitOps: compararea metodelor Pull \u0219i Push<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/434160\/\">V\u0103 prezent\u0103m biblioteca kubedog pentru monitorizarea resurselor Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/449096\/\">Extindem \u0219i complet\u0103m Kubernetes (prezentare general\u0103 \u0219i video al expunerii)<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p class=\"for_users_only_msg\">Numai utilizatorii \u00eenregistra\u021bi pot participa la sondaj. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Conecta\u021bi-v\u0103<\/a><\/noindex>, v\u0103 rug\u0103m.<\/p>\n<h2 class=\"default-block__polling-title\">\u0218tia\u021bi de GitOps \u00eenainte de apari\u021bia acestor dou\u0103 traduceri pe Habr?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Da, \u0219tia(m) tot.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Doar superficial.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Nu<\/p>\n<\/li>\n<\/ul>\n<p>    35 de utilizatori au votat. 10 utilizatori s-au ab\u021binut.<br \/>\n<br \/>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u041f\u043e\u0441\u043b\u0435 \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0439 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 pull \u0438 push \u0432 GitOps \u043c\u044b \u0443\u0432\u0438\u0434\u0435\u043b\u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441 \u043a \u044d\u0442\u043e\u0439 \u043c\u043e\u0434\u0435\u043b\u0438 \u0432 \u0446\u0435\u043b\u043e\u043c, \u043e\u0434\u043d\u0430\u043a\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u044b\u0445 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0439 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443 \u043e\u043a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0441\u043e\u0432\u0441\u0435\u043c \u043c\u0430\u043b\u043e (\u043d\u0430 \u0445\u0430\u0431\u0440\u0435 \u0438\u0445 \u043f\u043e\u043f\u0440\u043e\u0441\u0442\u0443 \u043d\u0435\u0442). \u041f\u043e\u0441\u0435\u043c\u0443 \u0440\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u043f\u0443\u0441\u0442\u044c \u0438 \u0443\u0436\u0435 \u043f\u043e\u0447\u0442\u0438 \u0433\u043e\u0434\u0438\u0447\u043d\u043e\u0439 \u0434\u0430\u0432\u043d\u043e\u0441\u0442\u0438! \u2014 \u043e\u0442 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Weaveworks, \u0433\u043b\u0430\u0432\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35941","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/chto-zhe-takoe-gitops\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0427\u0442\u043e \u0436\u0435 \u0442\u0430\u043a\u043e\u0435 GitOps? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/chto-zhe-takoe-gitops\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Ce este GitOps? | ProHoster","description":"Not\u0103.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/chto-zhe-takoe-gitops","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u0436\u0435 \u0442\u0430\u043a\u043e\u0435 GitOps? | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/chto-zhe-takoe-gitops","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:07:41+00:00","article:modified_time":"2019-10-31T19:07:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35941","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 01:21:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:53:31","updated":"2026-01-22 01:21:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/35941","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=35941"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/35941\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=35941"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=35941"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=35941"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}