GitOps: alia furorvorto aŭ sukceso en aŭtomatigo?

La plej multaj el ni, rimarkante alian novan terminon en la IT-blogosfero aŭ konferenco, pli aŭ malpli frue faras similan demandon: “Kio estas ĉi tio? Ĉu nur alia furorvorto, "vortvorto" aŭ io vere atentinda, studi kaj promesi novajn horizontojn? La sama afero okazis al mi kun la termino GitOps antaŭ iom da tempo. Armita kun multaj ekzistantaj artikoloj, same kiel la scio de kolegoj de la kompanio GitLab, Mi provis eltrovi kia besto ĉi tio estas, kaj kiel ĝia uzo povus aspekti en la praktiko.

Cetere, pri la noveco de la termino GitOps Nia lastatempa enketo ankaŭ diras: pli ol duono de la enketitaj ankoraŭ ne eklaboris kun ĝiaj principoj.

Do, la problemo de infrastruktura administrado ne estas nova. Multaj nubaj provizantoj estis haveblaj al la ĝenerala publiko dum bona dekduo da jaroj kaj, ŝajne, devus fari la laboron de la teamoj respondecaj pri la infrastrukturo simpla kaj simpla. Tamen, se komparite kun la aplikaĵa evoluprocezo (kie aŭtomatigo atingas ĉiam novajn nivelojn), infrastrukturprojektoj daŭre ofte implikas multajn manajn taskojn kaj postulas specialecan scion kaj kompetentecon, precipe konsiderante la hodiaŭajn postulojn por faŭltoleremo, fleksebleco, skaleblo kaj elasteco.

Nubaj servoj tre sukcese plenumis ĉi tiujn postulojn kaj estis ili, kiuj donis gravan impulson al la evoluo de la aliro. IaC. Ĉi tio estas komprenebla. Post ĉio, ili ebligis agordi tute virtualan datumcentron: ne ekzistas fizikaj serviloj, rakoj aŭ retaj komponantoj; la tuta infrastrukturo povas esti priskribita per skriptoj kaj agordaj dosieroj.

Do kio precize estas la diferenco? GitOps el IaC? Ĝuste per ĉi tiu demando mi komencis mian esploron. Parolinte kun kolegoj, mi povis elpensi la jenan komparon:

GitOps

IaC

Ĉiu kodo estas konservita en git-deponejo

Kodversiado estas laŭvola

Deklara Kodo Priskribo / Idempotenco

Kaj deklaraj kaj imperativoj priskriboj estas akcepteblaj

Ŝanĝoj efektiviĝas per la mekanismoj Kunfanda Peto / Tiro-Peto

Interkonsento, aprobo kaj kunlaboro estas laŭvolaj

La ĝisdatiga lanĉa procezo estas aŭtomatigita

La ĝisdatiga lanĉa procezo ne estas normigita (aŭtomata, manlibro, kopiado de dosieroj, uzante la komandlinion, ktp.)

Alivorte GitOps naskiĝis ĝuste per la aplikado de la principoj IaC. Unue, infrastrukturo kaj agordoj nun povus esti stokitaj en la sama maniero kiel aplikoj. La kodo estas facile stokebla, facila por kundividi, kompari kaj uzi versionajn kapablojn. Versioj, branĉoj, historio. Kaj ĉio ĉi en loko publike alirebla por la tuta teamo. Tial, la uzo de versio-kontrolsistemoj iĝis tute natura evoluo. Aparte, git, kiel la plej populara.

Aliflanke, fariĝis eble aŭtomatigi infrastrukturajn administradprocezojn. Nun ĉi tio povas esti farita pli rapide, pli fidinde kaj pli malmultekosta. Krome, la principoj de CI/KD jam estis konataj kaj popularaj inter programistoj. Necesis nur transdoni kaj apliki jam konatajn sciojn kaj kapablojn al nova areo. Tiuj praktikoj, aliflanke, iris preter la norma difino de Infrastrukturo kiel kodo, tial la koncepto GitOps.

Scivolemo GitOps, kompreneble, ankaŭ en la fakto, ke ĝi ne estas produkto, kromaĵo aŭ platformo asociita kun iu ajn vendisto. Ĝi estas pli de paradigmo kaj aro de principoj, simila al alia termino, kiun ni konas: DevOps.

En la kompanio GitLab ni evoluigis du difinojn de ĉi tiu nova termino: teoria kaj praktika. Ni komencu per la teoria:

GitOps estas metodaro, kiu prenas la plej bonajn principojn de DevOps uzataj por evoluigo de aplikaĵoj, kiel versio-kontrolo, kunlaboro, instrumentado, CI/KD, kaj aplikas ilin al la defioj de aŭtomatigo de infrastruktura administrado.

Ĉiuj procezoj GitOps Mi laboras uzante ekzistantajn ilojn. Ĉiu infrastruktura kodo estas konservita en la jam konata git-deponejo, ŝanĝoj trapasas la saman aprobprocezon kiel iu ajn alia programkodo, kaj la elŝuta procezo estas aŭtomatigita, kio ebligas al ni minimumigi homajn erarojn, pliigi fidindecon kaj reprodukteblecon.

El praktika vidpunkto, ni priskribas GitOps kiel sekvas:

Ni jam diskutis infrastrukturon kiel kodon kiel unu el la ĉefaj komponantoj de ĉi tiu formulo. Ni prezentu la ceterajn partoprenantojn.

Kunfanda Peto (alternativa nomo Pull Request). Laŭ procezaj terminoj, MR estas peto apliki kodŝanĝojn kaj poste kunfandi branĉojn. Sed rilate al la iloj, kiujn ni uzas, ĉi tio estas pli multe da ŝanco akiri kompletan bildon de ĉiuj ŝanĝoj faritaj: ne nur la kodo-diferenco kolektita de certa nombro da komitaĵoj, sed ankaŭ la kunteksto, testrezultoj, kaj la fina atendata rezulto. Se ni parolas pri infrastruktura kodo, tiam ni interesiĝas pri kiel ĝuste la infrastrukturo ŝanĝos, kiom da novaj rimedoj estos aldonitaj aŭ forigitaj, ŝanĝitaj. Prefere en iu pli oportuna kaj facile legebla formato. Por nubaj provizantoj, estas bona ideo scii, kia estos la financa efiko de ĉi tiu ŝanĝo.

Sed MR ankaŭ estas rimedo de kunlaboro, interago kaj komunikado. La loko kie la sistemo de ĉekoj kaj ekvilibroj eniras en ludon. De simplaj komentoj ĝis formalaj aproboj kaj aproboj.

Nu, la lasta komponanto: CI/KD, kiel ni jam scias, ebligas aŭtomatigi la procezon de farado de infrastrukturaj ŝanĝoj kaj testado (de simpla sintaksa kontrolo ĝis pli kompleksa statika koda analizo). Kaj ankaŭ en la posta detekto de drivo: diferencoj inter la reala kaj dezirata stato de la sistemo. Ekzemple, kiel rezulto de neaŭtorizitaj manaj ŝanĝoj aŭ sistema fiasko.

Jes, la termino GitOps ne prezentas al ni ion tute novan, ne reinventas la radon, sed simple aplikas la jam akumulitan sperton en nova areo. Sed ĉi tie kuŝas lia forto.

Kaj se vi subite interesiĝas pri kiel ĉio ĉi aspektas en la praktiko, tiam mi invitas vin rigardi nian majstro, en kiu mi diras al vi paŝon post paŝo kiel uzi GitLab:

• Efektivigu la bazajn principojn de GitOps

• Kreu kaj faru ŝanĝojn al la nuba infrastrukturo (uzante la ekzemplon de Yandex Cloud)

• Aŭtomatigu detekton de sistemo-drivo de dezirata stato uzante aktivan monitoradon

https://bit.ly/34tRpwZ

fonto: www.habr.com