Karamihan sa atin, na napansin ang isa pang bagong termino sa IT blogosphere o conference, maaga o huli ay nagtatanong ng katulad na tanong: "Ano ito? Isa pang buzzword, isang "buzzword," o isang bagay na talagang nagkakahalaga ng pagtutuunan ng pansin, pag-aaral, at pag-asa ng mga bagong abot-tanaw?" Ganun din ang nangyari sa akin sa term GitOps kanina. Gamit ang maraming umiiral na mga artikulo, pati na rin ang kaalaman ng mga kasamahan mula sa kumpanya , sinubukan kong malaman kung anong uri ng hayop ito, at kung ano ang maaaring hitsura ng paggamit nito sa pagsasanay.
Sa pamamagitan ng paraan, tungkol sa pagiging bago ng termino GitOps Sinasabi rin ng aming kamakailang survey: higit sa kalahati ng mga na-survey ay hindi pa nagsimulang magtrabaho sa mga prinsipyo nito.
Kaya, ang problema sa pamamahala ng imprastraktura ay hindi bago. Maraming mga cloud provider ang naging available sa pangkalahatang publiko sa loob ng isang dosenang taon at, tila, dapat ginawang simple at diretso ang gawain ng mga koponan para sa imprastraktura. Gayunpaman, kung ihahambing sa proseso ng pag-develop ng application (kung saan ang automation ay umaabot sa mga bagong antas), ang mga proyekto sa imprastraktura ay madalas pa ring kinasasangkutan ng maraming manu-manong gawain at nangangailangan ng espesyal na kaalaman at kadalubhasaan, lalo na sa mga kinakailangan ngayon para sa fault tolerance, flexibility, scalability at elasticity.
Matagumpay na natupad ng mga serbisyo ng Cloud ang mga kinakailangang ito at sila ang nagbigay ng makabuluhang impetus sa pagbuo ng diskarte IaC. Ito ay naiintindihan. Pagkatapos ng lahat, ginawa nilang posible na i-configure ang isang ganap na virtual data center: walang mga pisikal na server, rack, o mga bahagi ng network; ang buong imprastraktura ay maaaring ilarawan gamit ang mga script at configuration file.
Kaya ano nga ba ang pagkakaiba? GitOps mula sa IaC? Sa tanong na ito nagsimula ang aking pagsisiyasat. Pagkatapos makipag-usap sa mga kasamahan, nakagawa ako ng sumusunod na paghahambing:
GitOps
IaC
Ang lahat ng code ay naka-imbak sa isang git repository
Opsyonal ang bersyon ng code
Deklarasyon ng Code na Deklarasyon / Idempotency
Parehong katanggap-tanggap ang mga declarative at imperative na paglalarawan
Nagkakabisa ang mga pagbabago gamit ang mga mekanismo ng Merge Request / Pull Request
Ang kasunduan, pag-apruba at pakikipagtulungan ay opsyonal
Ang proseso ng paglulunsad ng pag-update ay awtomatiko
Ang proseso ng paglulunsad ng pag-update ay hindi na-standardize (awtomatiko, manu-mano, pagkopya ng mga file, gamit ang command line, atbp.)
Sa ibang salita GitOps ay ipinanganak nang eksakto sa pamamagitan ng aplikasyon ng mga prinsipyo IaC. Una, ang imprastraktura at mga pagsasaayos ay maaari na ngayong maimbak sa parehong paraan tulad ng mga application. Ang code ay madaling iimbak, madaling ibahagi, ihambing, at gamitin ang mga kakayahan sa pag-bersyon. Mga bersyon, sangay, kasaysayan. At lahat ng ito sa isang lugar na naa-access ng publiko sa buong team. Samakatuwid, ang paggamit ng mga version control system ay naging ganap na natural na pag-unlad. Sa partikular, ang git, bilang pinakasikat.
Sa kabilang banda, naging posible na i-automate ang mga proseso ng pamamahala sa imprastraktura. Ngayon ito ay maaaring gawin nang mas mabilis, mas maaasahan at mas mura. Bukod dito, ang mga prinsipyo ng CI / CD ay kilala na at tanyag sa mga developer ng software. Kinailangan lamang na ilipat at ilapat ang alam na kaalaman at kasanayan sa isang bagong lugar. Ang mga kasanayang ito, gayunpaman, ay lumampas sa karaniwang kahulugan ng Infrastructure bilang code, kaya ang konsepto GitOps.
Pagkausyoso GitOps, siyempre, gayundin sa katotohanan na ito ay hindi isang produkto, plugin o platform na nauugnay sa anumang vendor. Ito ay higit pa sa isang paradigma at isang hanay ng mga prinsipyo, katulad ng isa pang termino na pamilyar sa atin: DevOps.
Ang kumpanya nakabuo kami ng dalawang kahulugan ng bagong terminong ito: teoretikal at praktikal. Magsimula tayo sa teoretikal:
Ang GitOps ay isang pamamaraan na kumukuha ng pinakamahusay na mga prinsipyo ng DevOps na ginagamit para sa pagbuo ng application, gaya ng kontrol sa bersyon, pakikipagtulungan, orkestrasyon, CI/CD, at inilalapat ang mga ito sa mga hamon ng pag-automate ng pamamahala sa imprastraktura.
Lahat ng proseso GitOps Nagtatrabaho ako gamit ang mga umiiral na tool. Ang lahat ng code ng imprastraktura ay naka-imbak sa pamilyar na git repository, ang mga pagbabago ay dumaan sa parehong proseso ng pag-apruba tulad ng anumang iba pang code ng programa, at ang proseso ng rollout ay awtomatiko, na nagbibigay-daan sa amin upang mabawasan ang mga pagkakamali ng tao, dagdagan ang pagiging maaasahan at muling paggawa.
Mula sa praktikal na pananaw, inilalarawan namin GitOps tulad ng sumusunod:
Napag-usapan na natin ang imprastraktura bilang code bilang isa sa mga pangunahing bahagi ng formula na ito. Ipakilala natin ang iba pang kalahok.
Pagsamahin ang Kahilingan (alternatibong pangalan na Pull Request). Sa mga tuntunin ng proseso, ang MR ay isang kahilingan na ilapat ang mga pagbabago sa code at pagkatapos ay pagsamahin ang mga sangay. Ngunit sa mga tuntunin ng mga tool na ginagamit namin, ito ay higit na isang pagkakataon upang makakuha ng kumpletong larawan ng lahat ng mga pagbabagong ginagawa: hindi lamang ang pagkakaiba ng code na nakolekta mula sa isang tiyak na bilang ng mga commit, kundi pati na rin ang konteksto, mga resulta ng pagsubok, at ang huling inaasahang resulta. Kung pinag-uusapan natin ang tungkol sa code ng imprastraktura, kung gayon kami ay interesado sa kung paano eksaktong magbabago ang imprastraktura, kung gaano karaming mga bagong mapagkukunan ang idaragdag o aalisin, binago. Mas mabuti sa ilang mas maginhawa at madaling basahin na format. Para sa mga cloud provider, magandang ideya na malaman kung ano ang magiging epekto sa pananalapi ng pagbabagong ito.
Ngunit ang MR ay isa ring paraan ng pakikipagtulungan, pakikipag-ugnayan, at komunikasyon. Ang lugar kung saan pumapasok ang sistema ng checks and balances. Mula sa mga simpleng komento hanggang sa pormal na pag-apruba at pag-apruba.
Well, ang huling bahagi: CI/CD, tulad ng alam na natin, ay ginagawang posible na i-automate ang proseso ng paggawa ng mga pagbabago sa imprastraktura at pagsubok (mula sa simpleng pagsusuri ng syntax hanggang sa mas kumplikadong pagsusuri ng static na code). At gayundin sa kasunod na pagtuklas ng drift: mga pagkakaiba sa pagitan ng tunay at ninanais na estado ng system. Halimbawa, bilang resulta ng hindi awtorisadong mga pagbabago sa manu-manong o pagkabigo ng system.
Oo, ang termino GitOps ay hindi nagpapakilala sa amin sa anumang ganap na bago, hindi muling likhain ang gulong, ngunit inilalapat lamang ang naipon na karanasan sa isang bagong lugar. Ngunit dito nakasalalay ang kanyang lakas.
At kung bigla kang naging interesado sa kung ano ang hitsura ng lahat ng ito sa pagsasanay, pagkatapos ay inaanyayahan kita na tingnan ang aming , kung saan sasabihin ko sa iyo ang hakbang-hakbang kung paano gamitin ang GitLab:
-
Ipatupad ang mga pangunahing prinsipyo ng GitOps
-
Lumikha at gumawa ng mga pagbabago sa imprastraktura ng ulap (gamit ang halimbawa ng Yandex Cloud)
-
I-automate ang pag-detect ng system drift mula sa ninanais na estado gamit ang aktibong pagsubaybay
https://bit.ly/34tRpwZ
Pinagmulan: www.habr.com