Kynning á GitOps fyrir OpenShift

Í dag munum við fjalla um meginreglur og líkön GitOps, sem og hvernig þessi líkön eru útfærð á OpenShift kerfinu. Gagnvirk leiðarvísir um þetta efni er í boði. по ссылке.

Í stuttu máli er GitOps safn af aðferðum til að nota Git pull requests til að stjórna innviðum og forritastillingum. Innan GitOps er Git geymsla meðhöndluð sem ein upplýsingaveita um stöðu kerfisins, þar sem allar breytingar á þeirri stöðu eru að fullu raktar og endurskoðaðar.

Hugmyndin um breytingarmælingar í GitOps er ekki ný af nálinni; þessi aðferð hefur lengi verið notuð nánast alhliða við vinnu með frumkóða forrita. GitOps útfærir einfaldlega svipaðar aðgerðir (endurskoðunarprófanir, pull requests, tags o.s.frv.) til að stjórna innviðum og stillingum forrita og býður upp á svipaða kosti og stjórnun frumkóða.

Það er engin fræðileg skilgreining eða regluverk fyrir GitOps, aðeins safn meginreglna sem leiðbeina framkvæmdinni:

• Yfirlýsingarlýsing kerfisins er geymd í Git geymslunni (stillingar, eftirlit o.s.frv.).
• Breytingar á stöðu eru framkvæmdar með pull requests (e. pull requests).
• Staða keyrandi kerfa er færð í samræmi við gögnin í gagnageymslunni með því að nota Git push beiðnir.

Meginreglur GitOps

• Kerfisskilgreiningar eru lýstar sem frumkóði

Kerfisstillingar eru meðhöndlaðar sem kóði, þannig að hægt er að geyma þær og breyta útgáfum sjálfkrafa í Git-geymslu, sem þjónar sem ein uppspretta sannleikans. Þessi aðferð gerir kleift að ræsa og afturkalla kerfisbreytingar auðveldlega.

• Æskilegt ástand og stillingar kerfa eru skilgreindar og útgáfustýrðar í Git.

Með því að geyma og útgáfustýra æskilegri kerfisstöðu í Git getum við auðveldlega fram og til baka breytingar á kerfum og forritum. Við getum einnig notað öryggiskerfi Git til að stjórna eignarhaldi kóða og staðfesta áreiðanleika hans.

• Hægt er að framkvæma breytingar á stillingum sjálfkrafa með því að nota pull requests.

Með því að nota Git pull requests getum við auðveldlega stjórnað því hvernig breytingar eru settar upp á stillingar í geymslunni. Til dæmis geta aðrir teymismeðlimir yfirfarið þær eða keyrt þær í gegnum CI prófanir o.s.frv.

Og það er engin þörf á að úthluta stjórnunarréttindum til hægri og vinstri. Til að framkvæma breytingar á stillingum þurfa notendur aðeins viðeigandi réttindi í Git-geymslunni þar sem þessar stillingar eru geymdar.

• Að laga vandamálið með stjórnlausum stillingarbreytingum

Þegar æskilegt kerfisástand hefur verið geymt í Git-geymslu þurfum við aðeins að finna hugbúnað sem getur staðfest að núverandi kerfisástand passi við það. Ef það gerir það ekki, ætti þessi hugbúnaður - allt eftir stillingum - annað hvort sjálfkrafa að laga misræmið eða láta okkur vita af stillingarbreytingum.

GitOps líkön fyrir OpenShift

Samræmingaraðili auðlinda í klasa

Samkvæmt þessu líkani hefur klasinn stjórnanda sem ber ábyrgð á að bera saman Kubernetes auðlindir (YAML skrár) í Git geymslunni við raunverulegar klasaauðlindir. Ef misræmi greinist sendir stjórnandinn tilkynningar og grípur hugsanlega til aðgerða til að leysa þau. Þetta GitOps líkan er notað í Anthos Config Management og Weaveworks Flux.

Ytri auðlindaafstemming (Push)

Þetta líkan má líta á sem afbrigði af því fyrra, þar sem við höfum einn eða fleiri stýringar sem bera ábyrgð á samstillingu auðlinda í Git-geymslu-Kubernetes klasapörum. Munurinn hér er sá að hver stýrður klasi þarf ekki endilega sinn eigin stýringar. Git-K8S klasapör eru oft skilgreind sem sérsniðnar auðlindaskilgreiningar (CRDs), sem geta lýst því hvernig stýringarnar ættu að framkvæma samstillingu. Í þessu líkani bera stýringar saman Git-geymsluna sem tilgreind er í CRD við Kubernetes klasaauðlindirnar, sem einnig eru tilgreindar í CRD, og ​​framkvæma viðeigandi aðgerðir út frá samanburðarniðurstöðunum. Þetta GitOps líkan er notað í ArgoCD, til dæmis.

GitOps á OpenShift kerfinu

Að stjórna fjölþyrpinga Kubernetes innviði

Með notkun Kubernetes og vaxandi vinsældum fjölskýjaáætlana og jaðartölvunarfræði, er meðalfjöldi OpenShift-klasa á hvern viðskiptavin einnig að aukast.

Til dæmis, þegar jaðartölvuvinnsla er notuð, gæti einn viðskiptavinur sett upp hundruð eða jafnvel þúsundir klasa. Þar af leiðandi verður hann að stjórna mörgum sjálfstæðum eða samhæfðum OpenShift-klösum í almenningsskýinu og á staðnum.

Á sama tíma þarf að leysa mörg vandamál, einkum:

• Gakktu úr skugga um að klasar séu í sömu stöðu (stillingar, eftirlit, geymsla o.s.frv.)
• Endurskapa (eða endurheimta) klasa úr þekktri stöðu.
• Búa til nýja klasa byggða á þekktri stöðu.
• Innleiða breytingar á marga OpenShift klasa.
• Afturkalla breytingar í mörgum OpenShift-klösum.
• Tengja sniðmátstillingar við mismunandi umhverfi.

Stillingar forrita

Á líftíma sínum fara forrit oft í gegnum keðju klasa (þróunarstig, stig o.s.frv.) áður en þau komast í framleiðsluklasann. Þar að auki, vegna krafna um framboð og sveigjanleika, dreifa viðskiptavinir oft forritum yfir marga klasa á staðnum eða yfir mörg svæði almenningsskýja.

Í þessu tilviki þarf að leysa eftirfarandi verkefni:

• Tryggja flutning forrita (tvíundaskrár, stillingar o.s.frv.) milli klasa (þróunarforrit, stig o.s.frv.).
• Rúlla út breytingum á forritum (tvöföldum skrám, stillingum o.s.frv.) í mörgum OpenShift klösum.
• Afturkalla breytingar í forritum í fyrra þekkt ástand.

Notkunartilvik OpenShift GitOps

1. Að beita breytingum úr Git geymslu

Klasastjóri getur geymt OpenShift klasastillingar í Git geymslu og sjálfkrafa beitt þeim til að búa til nýja klasa auðveldlega og koma þeim í þekkt ástand sem er eins og í Git geymslunni.

2. Samstilling við leyniþjónustuna

Stjórnandi mun einnig finna það gagnlegt að geta samstillt OpenShift leyndarmál við viðeigandi hugbúnað eins og Vault, sem gerir kleift að stjórna þeim með verkfærum sem eru sérstaklega hönnuð í þessum tilgangi.

3. Stillingarstýring á reki

Stjórnandinn væri alveg sammála því ef OpenShift GitOps greindi sjálfkrafa og varaði við ósamræmi milli raunverulegra stillinga og þeirra sem tilgreindar eru í geymslunni, svo hægt væri að bregðast fljótt við breytingum.

4. Tilkynningar um stillingarbreytingar

Þetta er gagnlegt þegar stjórnandi vill fljótt fræðast um tilvik stillingarbreytinga til að geta gripið fljótt til viðeigandi aðgerða.

5. Handvirk samstilling stillinga við rek

Leyfir kerfisstjóra að samstilla OpenShift klasa við Git geymsluna ef stillingar breytast, til að koma klasanum fljótt aftur í þekkt ástand.

6. Sjálfvirk samstilling stillinga við rek

Kerfisstjórinn getur einnig stillt OpenShift klasann þannig að hann samstillist sjálfkrafa við geymsluna þegar drift greinist, þannig að stillingar klasans passi alltaf við stillingarnar í Git.

7. Margir klasar – eitt geymsla

Stjórnandi getur geymt stillingar fyrir nokkra mismunandi OpenShift klasa í einni Git geymslu og valið að nota þær eftir þörfum.

8. Stigveldi klasastillinga (erfðir)

Stjórnandinn getur skilgreint stigveldi klasastillinga í geymslunni (stig, framleiðsla, appasafn o.s.frv. með erfðum). Með öðrum orðum, þeir geta ákvarðað hvernig stillingum skuli beitt - á einn eða fleiri klasa.

Til dæmis, ef stjórnandi skilgreinir stigveldi í Git geymslu: "Framleiðsluklasar (prod) → System X klasar → System X framleiðsluklasar", þá eru eftirfarandi stillingar sameinaðar fyrir framleiðsluklasa System X:

• Stillingar sem eru sameiginlegar öllum framleiðsluklasum.
• Stillingar fyrir X kerfisklasa.
• Stillingar fyrir framleiðsluklasa X kerfisins.

9. Sniðmát og stillingarhnekkingar

Stjórnandi getur hnekkt safni af erfðum stillingum og gildum þeirra, til dæmis til að fínstilla stillingar fyrir tiltekna klasa sem þær verða notaðar á.

10. Sértækt innifalið og útilokað fyrir stillingar, forritastillingar

Stjórnandinn getur sett skilyrði fyrir því að beita eða ekki beita ákveðnum stillingum á klasa með ákveðna eiginleika.

11. Stuðningur við sniðmát

Forritarar munu njóta góðs af möguleikanum á að velja hvernig forritaauðlindir eru skilgreindar (Helm Chart, einfalt Kubernetes yaml, o.s.frv.) til að nota viðeigandi snið fyrir hvert forrit.

GitOps verkfæri á OpenShift kerfinu

ArgoCD

ArgoCD útfærir External Resource Reconcile líkanið og býður upp á miðlægt notendaviðmót til að skipuleggja einn-til-margra tengsl milli klasa og Git gagnagrunna. Galli við þetta forrit er vanhæfni til að stjórna forritum án þess að ArgoCD sé í gangi.

Opinber vefsíða

Flux

Flux notar On-Cluster Resource Reconcile líkanið og þar af leiðandi er engin miðstýrð stjórnun á skilgreiningargeymslunni, sem er veikleiki. Hins vegar tryggir þessi skortur á miðstýringu að forritastjórnun sé möguleg jafnvel þótt einn klasi bili.

Opinber vefsíða

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ð setja upp ArgoCD á OpenShift 4 kerfinu skaltu ljúka eftirfarandi skrefum sem klasastjóri:

Að setja upp ArgoCD íhluti á 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}')

Að breyta ArgoCD netþjóni til að vera sýnilegur OpenShift leiðinni

# 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=Redirect

Að setja upp ArgoCD Cli tólið

# 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/argocd

Að breyta lykilorði stjórnanda ArgoCD netþjónsins

# 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ð þessum skrefum er lokið er hægt að vinna með ArgoCD Server í gegnum ArgoCD WebUI vefstjórnborðið eða ArgoCD Cli skipanalínutólið.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – Það er aldrei of seint

„Lestin er farin af stöðinni“ er hvernig við lýsum aðstæðum þar sem tækifæri til að gera eitthvað hefur verið glatað. Í tilviki OpenShift skapar flýtinn að byrja strax að nota þennan nýja flotta vettvang oft einmitt þessa stöðu þegar stjórnað er og viðhaldið er leiðum, dreifingum og öðrum OpenShift hlutum. En er tækifærið alltaf virkilega glatað?

Framhald greinaröðarinnar um gitopsÍ dag sýnum við þér hvernig á að umbreyta handsmíðuðu forriti og auðlindum þess í ferli sem stjórnað er af GitOps. Til að gera þetta munum við fyrst dreifa httpd forriti handvirkt. Skjámyndin hér að neðan sýnir hvernig við búum til nafnrými, dreifingu og þjónustu og síðan birtum þjónustuna 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

Við höfum því handsmíðað forrit. Nú þurfum við að flytja það yfir í GitOps stjórnun án þess að missa tiltækileika. Í stuttu máli virkar það svona:

• Við skulum búa til Git geymslu fyrir kóðann.
• Við flytjum út núverandi hluti okkar og hleðjum þeim inn í Git geymsluna.
• Að velja og dreifa GitOps verkfærum.
• Við skulum bæta geymslunni okkar við þetta verkfærakistu.
• Við skilgreinum forrit í GitOps verkfærakistunni okkar.
• Við prófuðum forritið með því að nota GitOps verkfærin.
• Samstilling hluta með GitOps verkfærum.
• Við gerum kleift að snyrta og samstilla hluti sjálfkrafa.

Eins og þegar hefur verið nefnt í fyrri greinÍ GitOps er ein og aðeins ein upplýsingaveita um alla hluti í Kubernetes klasa (klasa) - Git geymslan. Við gerum ráð fyrir að fyrirtækið þitt noti nú þegar Git geymslu. Hún getur verið opinber eða einkarekin, en hún verður að vera aðgengileg Kubernetes klasa. Þetta getur verið sama geymslan og notuð er fyrir forritakóða, eða sérstök geymsla sem búin er til sérstaklega fyrir dreifingar. Mælt er með að hafa strangar heimildir fyrir geymsluna, þar sem hún mun geyma leyndarmál, leiðir og aðra öryggisviðkvæma hluti.

Í dæminu okkar munum við búa til nýtt opinbert gagnasafn á GitHub. Þú getur nefnt það hvað sem þú vilt, en við munum nota „bloggfærslu“.

Ef YAML skrárnar fyrir hlutinn voru ekki geymdar staðbundið eða í Git, þarftu að nota oc eða kubectl tvíundarskrár. Á skjámyndinni hér að neðan erum við að biðja um YAML fyrir nafnrýmið okkar, dreifingu, þjónustu og leið. Áður en við gerðum þetta klónuðum við nýstofnaða geymsluna og settum cd 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.yaml

Nú skulum við breyta deployment.yaml skránni til að fjarlægja reitinn sem Argo CD getur ekki samstillt.

sed -i '/sgeneration: .*/d' deployment.yaml

Við þurfum líka að breyta leiðinni. Fyrst skilgreinum við fjöllínubreytu og skiptum síðan ingress: null út fyrir innihald þeirrar breytu.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

Nú þegar við höfum flokkað skrárnar er það eina sem eftir er að vista þær í Git-geymslu. Eftir það verður þessi geymslueining eina upplýsingauppspretta og allar handvirkar breytingar á hlutunum ættu að vera stranglega bannaðar.

git commit -am ‘initial commit of objects’
git push origin master

Ennfremur göngum við út frá þeirri staðreynd að ArgoCD er þegar komið fyrir á tölvunni þinni (sjá fyrri hluta um hvernig á að gera þetta). staða). Þess vegna skulum við bæta geymslunni sem við bjuggum til, sem inniheldur forritakóðann úr dæminu okkar, við Argo geisladiskinn. Gakktu bara úr skugga um að þú tilgreinir nákvæmlega geymsluna sem þú bjóst til fyrr.

argocd repo add https://github.com/cooktheryan/blogpost

Nú skulum við búa til forritið. Forritið tilgreinir gildi svo að GitOps skilji hvaða geymslu og slóðir á að nota, hvaða OpenShift er nauðsynlegt fyrir hlutastjórnun, hvaða tiltekna geymslugrein er nauðsynleg og hvort sjálfvirk samstilling auðlinda eigi að vera virk.

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ð skilgreint í Argo CD byrjar tólið að bera saman uppsetta hluti við skilgreiningar geymslunnar. Í okkar dæmi eru sjálfvirk samstilling og hreinsun óvirk, þannig að þættirnir breytast ekki í bili. Athugið að í Argo CD viðmótinu mun forritið okkar hafa stöðuna „Ósamstillt“ vegna þess að Argo CD gefur ekkert merki.
Þess vegna verða hlutirnir ekki endurdreifðir þegar við keyrjum samstillinguna aðeins síðar.

Nú skulum við framkvæma prufukeyrslu til að ganga úr skugga um að engar villur séu í skránum okkar.

argocd app sync simple-app --dry-run

Ef engar villur koma upp geturðu haldið áfram með samstillingu.

argocd app sync simple-app

Eftir að hafa keyrt argocd get skipunina í forritinu okkar, ættum við að sjá stöðu forritsins breytast í Heilbrigt eða Samstillt. Þetta þýðir að allar auðlindir í Git geymslunni passa nú við þær sem þegar hafa verið settar upp.

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ú er hægt að 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 í geymslunni sé útfærsla framkvæmd.

argocd app set simple-app --sync-policy automated --auto-prune

Við höfum því flutt forrit sem notaði ekki GitOps í upphafi yfir í GitOps stjórnun.

Heimild: www.habr.com