Í dag munum við tala um meginreglur og gerðir GitOps, svo og hvernig þessi líkön eru útfærð á OpenShift pallinum. Gagnvirk leiðarvísir um þetta efni er fáanlegur .
Í hnotskurn, GitOps er sett af venjum til að nota Git pull beiðnir til að stjórna innviðum og stillingum forrita. Meðhöndlað er með Git geymslan í GitOps sem eina uppsprettu upplýsinga um stöðu kerfisins og allar breytingar á þessu ástandi eru að fullu rekjanlegar og endurskoðanlegar.
Hugmyndin um að fylgjast með breytingum í GitOps er alls ekki ný; þessi aðferð hefur lengi verið notuð nánast almennt þegar unnið er með frumkóða forrita. GitOps útfærir einfaldlega svipaða eiginleika (umsagnir, dráttarbeiðnir, merki o.s.frv.) í innviða- og stillingarstjórnun forrita og veitir svipaðan ávinning og í tilviki frumkóðastjórnunar.
Það er engin fræðileg skilgreining eða viðurkennt sett af reglum fyrir GitOps, aðeins sett af meginreglum sem þessi framkvæmd er byggð á:
- Yfirlýsingalýsing kerfisins er geymd í Git geymslunni (stillingar, eftirlit osfrv.).
- Ríkisbreytingar eru gerðar með dráttarbeiðnum.
- Staða keyrslukerfa er færð í samræmi við gögnin í geymslunni með því að nota Git push beiðnir.
GitOps meginreglur
- Kerfisskilgreiningum er lýst sem frumkóða
Kerfisstillingar eru meðhöndlaðar sem kóða svo hægt sé að geyma hann og útgáfa hann sjálfkrafa í Git geymslu, sem þjónar sem ein uppspretta sannleikans. Þessi nálgun gerir það auðvelt að útfæra og afturkalla breytingar á kerfum.
- Æskilegt ástand og uppsetning kerfa er stillt og útfærð í Git
Með því að geyma og útgáfa æskilegt ástand kerfa í Git, getum við auðveldlega rúllað út og afturkallað breytingar á kerfum og forritum. Við getum líka notað öryggiskerfi Git til að stjórna eignarhaldi kóða og sannreyna áreiðanleika hans.
- Hægt er að beita stillingarbreytingum sjálfkrafa með dráttarbeiðnum
Með því að nota Git pull beiðnir getum við auðveldlega stjórnað því hvernig breytingum er beitt á stillingar í geymslunni. Til dæmis er hægt að gefa þeim öðrum liðsmönnum til skoðunar eða keyra í gegnum CI próf osfrv.
Og á sama tíma er engin þörf á að dreifa stjórnunarvaldi til vinstri og hægri. Til að framkvæma breytingar á stillingum þurfa notendur aðeins viðeigandi heimildir í Git geymslunni þar sem þessar stillingar eru geymdar.
- Leysir vandamálið með stjórnlausu reki stillinga
Þegar æskilegt ástand kerfisins er geymt í Git geymslu, þurfum við bara að finna hugbúnað sem tryggir að núverandi ástand kerfisins passi við æskilegt ástand. Ef þetta er ekki raunin, þá ætti þessi hugbúnaður - allt eftir stillingum - annaðhvort að útrýma misræminu á eigin spýtur, eða láta okkur vita um stillingarferli.
GitOps líkan fyrir OpenShift
Tilfangasamræmi í klasa
Samkvæmt þessu líkani er þyrpingin með stjórnanda sem ber ábyrgð á að bera saman Kubernetes auðlindir (YAML skrár) í Git geymslunni við raunveruleg auðlind þyrpingarinnar. Ef ósamræmi uppgötvast sendir stjórnandi tilkynningar og grípur hugsanlega til aðgerða til að leiðrétta misræmið. Þetta GitOps líkan er notað í Anthos Config Management og Weaveworks Flux.
Ytri auðlindajafnari (Push)
Líta má á þetta líkan sem afbrigði af því fyrra, þegar við erum með einn eða fleiri stýringar sem bera ábyrgð á samstillingu auðlinda í „Git geymslunni - Kubernetes klasa“ pörunum. Munurinn hér er sá að hver stýrður klasi hefur ekki endilega sinn sérstaka stjórnanda. Git - k8s klasapör eru oft skilgreind sem CRD (sérsniðnar auðlindaskilgreiningar), sem geta lýst því hvernig stjórnandi ætti að framkvæma samstillingu. Innan þessa líkans bera stjórnendur saman Git geymsluna sem tilgreind er í CRD við Kubernetes klasaauðlindirnar, sem einnig eru tilgreindar í CRD, og framkvæma viðeigandi aðgerðir byggðar á niðurstöðum samanburðarins. Sérstaklega er þetta GitOps líkan notað í ArgoCD.
GitOps á OpenShift pallinum
Umsjón með Kubernetes innviðum margra klasa
Með útbreiðslu Kubernetes og vaxandi vinsældum fjölskýjaaðferða og brúntölvu, eykst meðalfjöldi OpenShift klasa á hvern viðskiptavin líka.
Til dæmis, þegar brúntölvu er notuð, er hægt að dreifa þyrpingum eins viðskiptavinar í hundruðum eða jafnvel þúsundum. Fyrir vikið neyðist hann til að stjórna nokkrum sjálfstæðum eða samræmdum OpenShift klösum í almenningsskýinu og á staðnum.
Í þessu tilfelli þarf að leysa mörg vandamál, sérstaklega:
- Stjórna því að klasarnir séu í eins ástandi (stillingar, eftirlit, geymsla osfrv.)
- Endurskapa (eða endurheimta) klasa byggt á þekktu ástandi.
- Búðu til nýja klasa byggða á þekktu ástandi.
- Settu út breytingar á mörgum OpenShift þyrpingum.
- Afturkalla breytingar yfir marga OpenShift klasa.
- Tengdu sniðmátsstillingar við mismunandi umhverfi.
Stillingar forrita
Á lífsferli þeirra fara forrit oft í gegnum keðju klasa (dev, stage, osfrv.) áður en þær lenda í framleiðsluklasa. Þar að auki, vegna krafna um framboð og sveigjanleika, dreifa viðskiptavinir oft forritum yfir marga staðbundna klasa eða mörg svæði á opinberum skýjapalli.
Í þessu tilviki þarf að leysa eftirfarandi verkefni:
- Tryggja hreyfingu forrita (tvíundir, stillingar osfrv.) á milli klasa (dev, stage, osfrv.).
- Rúllaðu út breytingar á forritum (tvíundir, stillingar osfrv.) í nokkrum OpenShift þyrpingum.
- Afturkalla breytingar á forritum í fyrra þekkt ástand.
OpenShift GitOps notkunartilvik
1. Að beita breytingum frá Git geymslunni
Klasastjórnandi getur geymt OpenShift klasastillingar í Git geymslu og notað þær sjálfkrafa til að búa til nýja klasa á áreynslulausan hátt og koma þeim í sama ástand og þekkta ástandið sem er geymt í Git geymslunni.
2. Samstilling við Secret Manager
Stjórnandinn mun einnig njóta góðs af getu til að samstilla OpenShift leynda hluti með viðeigandi hugbúnaði eins og Vault til að stjórna þeim með því að nota verkfæri sem eru sérstaklega búin til fyrir þetta.
3. Stjórnun á rekstillingum
Stjórnandinn verður aðeins hlynntur ef OpenShift GitOps sjálft auðkennir og varar við misræmi milli raunverulegra stillinga og þeirra sem tilgreindar eru í geymslunni, svo að þeir geti fljótt brugðist við reki.
4. Tilkynningar um stillingarsvif
Þær eru gagnlegar í þeim tilfellum þegar kerfisstjórinn vill fljótt læra um tilvik um stillingarbreytingar til að gera fljótt viðeigandi ráðstafanir sjálfur.
5. Handvirk samstilling stillinga á reki
Leyfir stjórnandanum að samstilla OpenShift þyrpinguna við Git geymsluna ef stillingar reka, til að skila þyrpingunni fljótt í fyrra þekkt ástand.
6.Sjálfvirk samstilling á stillingum þegar rekur
Kerfisstjórinn getur líka stillt OpenShift klasann þannig að hann samstillist sjálfkrafa við geymsluna þegar rek greinist, þannig að klasastillingin passi alltaf við stillingarnar í Git.
7. Nokkrir klasar - ein geymsla
Kerfisstjórinn getur geymt stillingar á nokkrum mismunandi OpenShift þyrpingum í einni Git geymslu og beitt þeim valinn eftir þörfum.
8. Stigveldi klasastillinga (arfleifð)
Stjórnandinn getur stillt stigveldi klasastillinga í geymslunni (stig, framleiðslu, appasafn osfrv. með arfleifð). Með öðrum orðum, það getur ákvarðað hvort stillingar eigi að nota á einn eða fleiri klasa.
Til dæmis, ef stjórnandi setur stigveldið „Framleiðsluklasa (framleiðsla) → System X klasar → Framleiðsluklasar kerfis X“ í Git geymslunni, þá er samsetning af eftirfarandi stillingum beitt á framleiðsluklasa kerfis X:
- Stillingar sem eru sameiginlegar fyrir alla framleiðsluklasa.
- Stillingar fyrir System X þyrpinguna.
- Stillingar fyrir X kerfisframleiðsluklasann.
9. Sniðmát og stillingar hnekkja
Kerfisstjórinn getur hnekið setti af erfðum stillingum og gildum þeirra, til dæmis til að fínstilla stillingar fyrir tiltekna klasa sem þeim verður beitt á.
10. Valhæft innihalda og útiloka fyrir stillingar, stillingar forrita
Stjórnandinn getur sett skilyrði fyrir beitingu eða óbeitingu ákveðinna stillinga á klasa með ákveðna eiginleika.
11. Stuðningur við sniðmát
Hönnuðir munu njóta góðs af hæfileikanum til að velja hvernig forritaauðlindir verða skilgreindar (Helm Chart, hreint Kubernetes yaml, osfrv.) til að nota viðeigandi snið fyrir hvert tiltekið forrit.
GitOps verkfæri á OpenShift pallinum
ArgoCD
ArgoCD innleiðir External Resource Reconcile líkanið og býður upp á miðstýrt notendaviðmót til að skipuleggja eins til margra tengsl milli klasa og Git geymslu. Ókostirnir við þetta forrit eru meðal annars vanhæfni til að stjórna forritum þegar ArgoCD virkar ekki.
Flux
Flux innleiðir On-Cluster Resource Reconcile líkan og þar af leiðandi er engin miðlæg stjórnun á skilgreiningargeymslunni, sem er veikur punktur. Á hinn bóginn er það einmitt vegna skorts á miðstýringu að getan til að stjórna forritum er áfram þó einn klasi bresti.
Að setja upp ArgoCD á OpenShift
ArgoCD býður upp á frábært skipanalínuviðmót og vefstjórnborð, svo við munum ekki fjalla um Flux og aðra valkosti hér.
Til að dreifa ArgoCD á OpenShift 4 pallinum skaltu fylgja þessum skrefum sem klasastjórnandi:
Að dreifa ArgoCD íhlutum á OpenShift pallinum
# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')Endurbætur á ArgoCD Server þannig að hægt sé að sjá hann með OpenShift Route
# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=RedirectSetur inn ArgoCD Cli tól
# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocdAð breyta ArgoCD Server stjórnanda lykilorðinu
# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password
Eftir að hafa lokið þessum skrefum geturðu unnið með ArgoCD Server í gegnum ArgoCD WebUI vefborðið eða ArgoCD Cli skipanalínutólið.
GitOps - Það er aldrei of seint
„Lestin er farin“ - þetta er það sem þeir segja um aðstæður þegar tækifæri til að gera eitthvað er sleppt. Þegar um OpenShift er að ræða, skapar löngunin til að byrja strax að nota þennan flotta nýja vettvang oft nákvæmlega þessar aðstæður með stjórnun og viðhaldi á leiðum, dreifingum og öðrum OpenShift hlutum. En er tækifærið alltaf algjörlega glatað?
Áframhaldandi greinaröð um , í dag munum við sýna þér hvernig á að umbreyta handunnu forriti og auðlindum þess í ferli þar sem öllu er stjórnað af GitOps verkfærum. Til að gera þetta munum við fyrst dreifa httpd forritinu handvirkt. Skjámyndin hér að neðan sýnir hvernig við búum til nafnrými, dreifingu og þjónustu og birtum síðan þessa þjónustu til að búa til leið.
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-appÞannig að við erum með handunnið forrit. Nú þarf að flytja það undir GitOps stjórnun án þess að missa framboð. Í stuttu máli, það gerir þetta:
- Búðu til Git geymslu fyrir kóðann.
- Við flytjum út núverandi hluti okkar og hlaðum þeim upp í Git geymsluna.
- Velja og dreifa GitOps verkfærum.
- Við bætum geymslunni okkar við þetta verkfærasett.
- Við skilgreinum forritið í GitOps verkfærakistunni okkar.
- Við gerum prufukeyrslu á forritinu með því að nota GitOps verkfærakistuna.
- Við samstillum hluti með því að nota GitOps verkfærakistuna.
- Virkjaðu klippingu og sjálfvirka samstillingu hluta.
Eins og getið er um í fyrri , í GitOps er ein og aðeins ein uppspretta upplýsinga um alla hluti í Kubernetes þyrpingunni(-flokkunum) - Git geymslunni. Næst förum við út frá þeirri forsendu að fyrirtækið þitt noti nú þegar Git geymslu. Það getur verið opinbert eða einkarekið, en það verður að vera aðgengilegt fyrir Kubernetes klasa. Þetta getur verið sama geymsla og fyrir forritakóða, eða aðskilin geymsla sem er búin til sérstaklega fyrir uppsetningar. Mælt er með því að hafa strangar heimildir í geymslunni þar sem leyndarmál, leiðir og aðrir öryggisviðkvæmir hlutir verða geymdir þar.
Í dæminu okkar munum við búa til nýja opinbera geymslu á GitHub. Þú getur kallað það hvað sem þú vilt, við notum nafnið bloggpóstur.
Ef YAML hlutaskrárnar voru ekki geymdar á staðnum eða í Git, þá verður þú að nota oc eða kubectl tvöfaldana. Í skjámyndinni hér að neðan erum við að biðja um YAML fyrir nafnrýmið okkar, uppsetningu, þjónustu og leið. Áður en þetta klónuðum við nýstofnaða geymsluna og geisladisk inn í hana.
oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yamlNú skulum við breyta deployment.yaml skránni til að fjarlægja reitinn sem Argo CD getur ekki samstillt.
sed -i '/sgeneration: .*/d' deployment.yamlAuk þess þarf að breyta leiðinni. Við setjum fyrst marglínu breytu og skipta síðan út ingress: null fyrir innihald þeirrar breytu.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlSvo við höfum flokkað skrárnar, allt sem er eftir er að vista þær í Git geymslunni. Eftir það verður þessi geymsla eina uppspretta upplýsinga og allar handvirkar breytingar á hlutum ættu að vera stranglega bönnuð.
git commit -am ‘initial commit of objects’
git push origin masterEnnfremur höldum við áfram frá þeirri staðreynd að þú hefur þegar sett ArgoCD (hvernig á að gera þetta - sjá fyrri ). Þess vegna munum við bæta við Argo geisladiskinn geymslunni sem við bjuggum til, sem inniheldur forritakóðann frá dæminu okkar. Gakktu úr skugga um að þú tilgreinir nákvæmlega geymsluna sem þú bjóst til áður.
argocd repo add https://github.com/cooktheryan/blogpostNú skulum við búa til forritið. Forritið setur gildi þannig að GitOps verkfærakistan skilji hvaða geymslu og slóðir á að nota, hvaða OpenShift þarf til að stjórna hlutum, hvaða sérstaka grein geymslunnar er þörf og hvort tilföng ættu að samstilla sjálfkrafa.
argocd app create --project default
--name simple-app --repo https://github.com/cooktheryan/blogpost.git
--path . --dest-server https://kubernetes.default.svc
--dest-namespace simple-app --revision master --sync-policy none
Þegar forrit hefur verið tilgreint á Argo geisladisknum, byrjar verkfærakistan að athuga hluti sem þegar hafa verið settir í notkun á móti skilgreiningum í geymslunni. Í dæminu okkar eru sjálfvirk samstilling og hreinsun óvirk, þannig að þættirnir breytast ekki ennþá. Vinsamlegast athugaðu að í Argo CD viðmótinu mun forritið okkar hafa stöðuna „Out of Sync“ vegna þess að það er enginn merkimiði sem ArgoCD veitir.
Þetta er ástæðan fyrir því að þegar við byrjum samstillingu aðeins seinna verða hlutirnir ekki endurdreifðir.
Nú skulum við prófa að keyra til að ganga úr skugga um að engar villur séu í skránum okkar.
argocd app sync simple-app --dry-runEf það eru engar villur geturðu haldið áfram í samstillingu.
argocd app sync simple-appEftir að hafa keyrt argocd get skipunina á forritinu okkar ættum við að sjá að umsóknarstaðan hefur breyst í Heilbrigt eða Samstillt. Þetta mun þýða að öll auðlindir í Git geymslunni samsvara nú þeim auðlindum sem þegar hefur verið dreift.
argocd app get simple-app
Name: simple-app
Project: default
Server: https://kubernetes.default.svc
Namespace: simple-app
URL: https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo: https://github.com/cooktheryan/blogpost.git
Target: master
Path: .
Sync Policy: <none>
Sync Status: Synced to master (60e1678)
Health Status: Healthy
... Nú geturðu virkjað sjálfvirka samstillingu og hreinsun til að tryggja að ekkert sé búið til handvirkt og að í hvert skipti sem hlutur er búinn til eða uppfærður í geymsluna muni dreifing eiga sér stað.
argocd app set simple-app --sync-policy automated --auto-prune
Þannig að við höfum fært forrit undir GitOps stjórn sem upphaflega notaði ekki GitOps á nokkurn hátt.
Heimild: www.habr.com