ProHoster > blog > Utawala > Utangulizi wa GitOps kwa OpenShift

Utangulizi wa GitOps kwa OpenShift

Leo tutazungumzia kuhusu kanuni na mifano ya GitOps, pamoja na jinsi mifano hii inatekelezwa kwenye jukwaa la OpenShift. Mwongozo wa mwingiliano juu ya mada hii unapatikana по ссылке.

Utangulizi wa GitOps kwa OpenShift

Kwa kifupi, GitOps ni seti ya mazoea ya kutumia maombi ya kuvuta ya Git kudhibiti miundombinu na usanidi wa programu. Hifadhi ya Git katika GitOps inachukuliwa kama chanzo kimoja cha habari kuhusu hali ya mfumo, na mabadiliko yoyote katika hali hii yanaweza kufuatiliwa kikamilifu na kukaguliwa.

Wazo la ufuatiliaji wa mabadiliko katika GitOps sio mpya; njia hii imetumika kwa muda mrefu karibu ulimwenguni kote wakati wa kufanya kazi na nambari ya chanzo cha programu. GitOps hutekelezea tu vipengele sawa (ukaguzi, maombi ya kuvuta, lebo, n.k.) katika miundombinu na usimamizi wa usanidi wa programu na hutoa manufaa sawa na katika usimamizi wa msimbo wa chanzo.

Hakuna ufafanuzi wa kitaaluma au seti iliyoidhinishwa ya sheria za GitOps, seti ya kanuni tu ambayo mazoezi haya yamejengwa:

  • Maelezo ya kutangaza mfumo yamehifadhiwa kwenye hazina ya Git (mipangilio, ufuatiliaji, nk).
  • Mabadiliko ya serikali hufanywa kupitia maombi ya kuvuta.
  • Hali ya mifumo inayoendesha inaletwa sambamba na data kwenye hazina kwa kutumia maombi ya kushinikiza ya Git.

Kanuni za GitOps

  • Ufafanuzi wa mfumo unaelezewa kama msimbo wa chanzo

Usanidi wa mifumo huchukuliwa kama msimbo ili iweze kuhifadhiwa na kubadilishwa kiotomatiki kwenye hazina ya Git, ambayo hutumika kama chanzo kimoja cha ukweli. Mbinu hii hurahisisha kusambaza na kurejesha mabadiliko katika mifumo.

  • Hali inayotakiwa na usanidi wa mifumo umewekwa na kubadilishwa katika Git

Kwa kuhifadhi na kubadilisha hali inayotakiwa ya mifumo katika Git, tunaweza kusambaza kwa urahisi na kurejesha mabadiliko kwenye mifumo na programu. Tunaweza pia kutumia njia za usalama za Git kudhibiti umiliki wa msimbo na kuthibitisha uhalisi wake.

  • Mabadiliko ya usanidi yanaweza kutumika kiotomatiki kupitia maombi ya kuvuta

Kwa kutumia ombi la Git kuvuta, tunaweza kudhibiti kwa urahisi jinsi mabadiliko yanatumika kwa usanidi kwenye hazina. Kwa mfano, zinaweza kutolewa kwa washiriki wengine wa timu kwa ukaguzi au kuendeshwa kupitia majaribio ya CI, nk.

Na wakati huo huo, hakuna haja ya kusambaza nguvu za admin kushoto na kulia. Ili kufanya mabadiliko ya usanidi, watumiaji wanahitaji tu ruhusa zinazofaa kwenye hazina ya Git ambapo usanidi huo huhifadhiwa.

  • Kurekebisha tatizo la kuteleza bila kudhibitiwa kwa usanidi

Mara tu hali inayotakiwa ya mfumo inapohifadhiwa kwenye hazina ya Git, tunachopaswa kufanya ni kupata programu ambayo itahakikisha kwamba hali ya sasa ya mfumo inalingana na hali inayotaka. Ikiwa sivyo, basi programu hii inapaswa - kulingana na mipangilio - iondoe tofauti yenyewe, au itujulishe kuhusu drift ya usanidi.

Miundo ya GitOps ya OpenShift

Kiunganishi cha Rasilimali kwenye Nguzo

Kulingana na muundo huu, nguzo ina kidhibiti ambacho kina jukumu la kulinganisha rasilimali za Kubernetes (faili za YAML) kwenye hazina ya Git na rasilimali halisi za nguzo. Ikiwa utofauti utagunduliwa, kidhibiti hutuma arifa na ikiwezekana kuchukua hatua kurekebisha hitilafu hizo. Mtindo huu wa GitOps unatumika katika Anthos Config Management na Weaveworks Flux.

Utangulizi wa GitOps kwa OpenShift

Kipatanishi cha Rasilimali za Nje (Push)

Muundo huu unaweza kuzingatiwa kama badiliko la ule uliopita, tunapokuwa na kidhibiti kimoja au zaidi kinachowajibika kusawazisha rasilimali katika jozi za "Git there - Kubernetes cluster". Tofauti hapa ni kwamba kila nguzo inayosimamiwa sio lazima iwe na kidhibiti chake tofauti. Jozi za nguzo za Git - k8s mara nyingi hufafanuliwa kama CRDs (ufafanuzi wa rasilimali maalum), ambayo inaweza kuelezea jinsi kidhibiti kinapaswa kufanya ulandanishi. Ndani ya muundo huu, vidhibiti vinalinganisha hazina ya Git iliyobainishwa katika CRD na rasilimali za nguzo ya Kubernetes, ambazo pia zimebainishwa katika CRD, na kufanya vitendo vinavyofaa kulingana na matokeo ya ulinganisho. Hasa, mfano huu wa GitOps hutumiwa katika ArgoCD.

Utangulizi wa GitOps kwa OpenShift

GitOps kwenye jukwaa la OpenShift

Usimamizi wa miundombinu ya vikundi vingi vya Kubernetes

Pamoja na kuenea kwa Kubernetes na umaarufu unaokua wa mikakati ya wingu nyingi na kompyuta makali, wastani wa idadi ya vikundi vya OpenShift kwa kila mteja pia inaongezeka.

Kwa mfano, unapotumia kompyuta makali, vikundi vya mteja mmoja vinaweza kutumwa kwa mamia au hata maelfu. Kama matokeo, analazimika kudhibiti vikundi kadhaa vya OpenShift vilivyo huru au vilivyoratibiwa kwenye wingu la umma na kwenye msingi.

Katika kesi hii, shida nyingi zinapaswa kutatuliwa, haswa:

  • Dhibiti kwamba vikundi viko katika hali inayofanana (mipangilio, ufuatiliaji, uhifadhi, n.k.)
  • Unda upya (au rejesha) makundi kulingana na hali inayojulikana.
  • Unda makundi mapya kulingana na hali inayojulikana.
  • Toa mabadiliko kwa vikundi vingi vya OpenShift.
  • Rudisha mabadiliko kwenye vishada vingi vya OpenShift.
  • Unganisha usanidi wa violezo kwa mazingira tofauti.

Mipangilio ya Programu

Wakati wa mzunguko wao wa maisha, programu mara nyingi hupitia msururu wa makundi (dev, hatua, n.k.) kabla ya kuishia katika kundi la uzalishaji. Kwa kuongezea, kwa sababu ya upatikanaji na mahitaji ya kuongeza kasi, wateja mara nyingi hutuma programu kwenye vikundi vingi vya juu-msingi au maeneo mengi ya jukwaa la wingu la umma.

Katika kesi hii, kazi zifuatazo zinapaswa kutatuliwa:

  • Hakikisha uhamishaji wa programu (binaries, usanidi, n.k.) kati ya vikundi (dev, hatua, n.k.).
  • Toa mabadiliko kwa programu (mbinu, usanidi, n.k.) katika vikundi kadhaa vya OpenShift.
  • Rejesha mabadiliko kwa programu kwa hali inayojulikana hapo awali.

Kesi za Matumizi ya OpenShift GitOps

1. Kutumia mabadiliko kutoka kwa hazina ya Git

Msimamizi wa nguzo anaweza kuhifadhi usanidi wa nguzo za OpenShift kwenye hazina ya Git na kuzitumia kiotomatiki kuunda vikundi vipya bila shida na kuzileta katika hali inayofanana na hali inayojulikana iliyohifadhiwa kwenye hazina ya Git.

2. Usawazishaji na Meneja wa Siri

Msimamizi pia atafaidika kutokana na uwezo wa kusawazisha vitu vya siri vya OpenShift na programu inayofaa kama Vault ili kuvidhibiti kwa kutumia zana zilizoundwa mahususi kwa hili.

3. Udhibiti wa usanidi wa drift

Msimamizi atakubali tu ikiwa OpenShift GitOps yenyewe itatambua na kuonya kuhusu utofauti kati ya usanidi halisi na ule uliobainishwa kwenye hazina, ili waweze kujibu kwa haraka kwa kuteleza.

4. Arifa kuhusu kuteleza kwa usanidi

Ni muhimu katika kesi wakati msimamizi anataka kujifunza haraka juu ya kesi za kuteleza kwa usanidi ili kuchukua hatua zinazofaa peke yake.

5. Usawazishaji wa mikono wa usanidi wakati wa kuteleza

Huruhusu msimamizi kusawazisha nguzo ya OpenShift na hazina ya Git katika tukio la kuteleza kwa usanidi, ili kurudisha kundi hilo kwa hali inayojulikana hapo awali.

6. Usawazishaji wa kiotomatiki wa usanidi wakati wa kusogea

Msimamizi pia anaweza kusanidi nguzo ya OpenShift ili kusawazisha kiotomatiki na hazina wakati mteremko unapogunduliwa, ili usanidi wa nguzo ulingane na usanidi katika Git kila wakati.

7. Nguzo kadhaa - hifadhi moja

Msimamizi anaweza kuhifadhi usanidi wa nguzo kadhaa tofauti za OpenShift kwenye hazina moja ya Git na kuzitumia kwa kuchagua inavyohitajika.

8. Daraja la usanidi wa nguzo (urithi)

Msimamizi anaweza kuweka safu ya usanidi wa vikundi kwenye hazina (hatua, prod, jalada la programu, n.k. pamoja na urithi). Kwa maneno mengine, inaweza kuamua ikiwa usanidi unapaswa kutumika kwa nguzo moja au zaidi.

Kwa mfano, ikiwa msimamizi ataweka daraja la "Vikundi vya uzalishaji (prod) → Nguzo za Mfumo X → Nguzo za uzalishaji za mfumo X" kwenye hazina ya Git, basi mchanganyiko wa usanidi ufuatao unatumika kwa vikundi vya uzalishaji vya mfumo X:

  • Inasanidi kawaida kwa vikundi vyote vya uzalishaji.
  • Mipangilio ya nguzo ya Mfumo X.
  • Mipangilio ya kundi la uzalishaji wa mfumo wa X.

9. Violezo na usanidi hubatilishwa

Msimamizi anaweza kubatilisha seti ya usanidi uliorithiwa na thamani zake, kwa mfano, kurekebisha usanidi kwa makundi maalum ambayo yatatumika.

10. Kuchagua ni pamoja na na kutenga kwa usanidi, usanidi wa programu

Msimamizi anaweza kuweka masharti ya utumaji au kutotumia usanidi fulani kwa vikundi vyenye sifa fulani.

11. Msaada wa kiolezo

Wasanidi programu watafaidika kutokana na uwezo wa kuchagua jinsi rasilimali za programu zitakavyofafanuliwa (Chati ya Helm, Kubernetes yaml safi, n.k.) ili kutumia umbizo linalofaa zaidi kwa kila programu mahususi.

Zana za GitOps kwenye jukwaa la OpenShift

ArgoCD

ArgoCD inatekeleza modeli ya Upatanisho wa Rasilimali za Nje na inatoa UI ya kati kwa ajili ya kupanga uhusiano wa moja hadi nyingi kati ya makundi na hazina za Git. Hasara za programu hii ni pamoja na kutokuwa na uwezo wa kusimamia programu wakati ArgoCD haifanyi kazi.

Tovuti rasmi

Flux

Flux hutumia kielelezo cha Upatanisho wa Rasilimali Kwenye Nguzo na, kwa hivyo, hakuna usimamizi wa kati wa hazina ya ufafanuzi, ambayo ni hatua dhaifu. Kwa upande mwingine, haswa kwa sababu ya ukosefu wa ujumuishaji, uwezo wa kusimamia programu unabaki hata ikiwa nguzo moja itashindwa.

Tovuti rasmi

Kufunga ArgoCD kwenye OpenShift

ArgoCD inatoa kiolesura bora cha mstari wa amri na kiweko cha wavuti, kwa hivyo hatutashughulikia Flux na njia zingine mbadala hapa.

Ili kupeleka ArgoCD kwenye jukwaa la OpenShift 4, fuata hatua hizi kama msimamizi wa nguzo:

Inapeleka vipengele vya ArgoCD kwenye jukwaa la OpenShift

# 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}')

Uboreshaji wa Seva ya ArgoCD ili iweze kuonekana na Njia ya OpenShift

# 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

Inapeleka ArgoCD Cli Tool

# 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

Kubadilisha nenosiri la msimamizi wa Seva ya ArgoCD

# 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

Baada ya kukamilisha hatua hizi, unaweza kufanya kazi na ArgoCD Server kupitia koni ya wavuti ya ArgoCD WebUI au zana ya mstari wa amri ya ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Haijachelewa

"Treni imeondoka" - hivi ndivyo wanasema juu ya hali wakati nafasi ya kufanya kitu imekosa. Kwa upande wa OpenShift, hamu ya kuanza mara moja kutumia jukwaa hili jipya la baridi mara nyingi hujenga hali hii hasa kwa usimamizi na matengenezo ya njia, upelekaji na vitu vingine vya OpenShift. Lakini je, nafasi hiyo huwa inapotea kabisa?

Kuendelea mfululizo wa makala kuhusu GitOps, leo tutakuonyesha jinsi ya kubadilisha programu iliyotengenezwa kwa mikono na rasilimali zake kuwa mchakato ambapo kila kitu kinasimamiwa na zana za GitOps. Ili kufanya hivyo, kwanza tutatumia programu ya httpd. Picha ya skrini iliyo hapa chini inaonyesha jinsi tunavyounda nafasi ya majina, matumizi na huduma, na kisha kufichua huduma hii ili kuunda njia.

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

Kwa hivyo tunayo programu iliyotengenezwa kwa mikono. Sasa inahitaji kuhamishwa chini ya usimamizi wa GitOps bila kupoteza upatikanaji. Kwa kifupi, hufanya hivi:

  • Unda hazina ya Git ya nambari.
  • Tunasafirisha vitu vyetu vya sasa na kuvipakia kwenye hazina ya Git.
  • Kuchagua na kupeleka zana za GitOps.
  • Tunaongeza hazina yetu kwenye zana hii ya zana.
  • Tunafafanua programu katika zana yetu ya zana za GitOps.
  • Tunafanya jaribio la programu kwa kutumia zana ya GitOps.
  • Tunasawazisha vitu kwa kutumia zana ya GitOps.
  • Washa kupogoa na kusawazisha kiotomatiki kwa vitu.

Kama ilivyotajwa hapo awali Ibara ya, katika GitOps kuna chanzo kimoja na kimoja tu cha habari kuhusu vitu vyote kwenye (s) za Kubernetes - hazina ya Git. Kisha, tunaendelea kutoka kwa dhana kwamba shirika lako tayari linatumia hazina ya Git. Inaweza kuwa ya umma au ya faragha, lakini lazima ipatikane kwa makundi ya Kubernetes. Hili linaweza kuwa hazina sawa na la msimbo wa programu, au hazina tofauti iliyoundwa mahsusi kwa upelekaji. Inapendekezwa kuwa na ruhusa kali katika hazina kwa kuwa siri, njia, na mambo mengine ambayo ni nyeti kwa usalama yatahifadhiwa hapo.

Katika mfano wetu, tutaunda hazina mpya ya umma kwenye GitHub. Unaweza kuiita chochote unachopenda, tunatumia jina la blogi.

Ikiwa faili za kitu cha YAML hazikuhifadhiwa ndani au kwenye Git, basi itabidi utumie jozi za oc au kubectl. Katika picha ya skrini iliyo hapa chini, tunaomba YAML kwa nafasi yetu ya majina, matumizi, huduma na njia. Kabla ya hii, tulitengeneza hazina mpya iliyoundwa na cd ndani yake.

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

Sasa hebu tuhariri faili ya deployment.yaml ili kuondoa sehemu ambayo Argo CD haiwezi kusawazisha.

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

Kwa kuongeza, njia inahitaji kubadilishwa. Kwanza tutaweka utofauti wa laini nyingi kisha ubadilishe ingress: null na yaliyomo kwenye kigezo hicho.

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

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

Kwa hivyo, tumepanga faili, kilichobaki ni kuzihifadhi kwenye hazina ya Git. Baada ya hapo hifadhi hii inakuwa chanzo pekee cha habari, na mabadiliko yoyote ya mwongozo kwa vitu yanapaswa kupigwa marufuku kabisa.

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

Zaidi tunaendelea na ukweli kwamba tayari umetuma ArgoCD (jinsi ya kufanya hivyo - tazama uliopita chapisho) Kwa hivyo, tutaongeza kwenye CD ya Argo hazina tuliyounda, iliyo na msimbo wa maombi kutoka kwa mfano wetu. Hakikisha tu kuwa unataja hazina halisi uliyounda hapo awali.

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

Sasa hebu tuunde programu. Programu huweka thamani ili zana ya zana ya GitOps ielewe ni hazina gani na njia za kutumia, ambazo OpenShift inahitajika ili kudhibiti vitu, ni tawi gani mahususi la hazina linahitajika, na kama rasilimali zinapaswa kusawazishwa kiotomatiki.

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

Mara baada ya programu kubainishwa katika Argo CD, zana ya zana huanza kuangalia vitu vilivyotumika tayari dhidi ya ufafanuzi kwenye hazina. Katika mfano wetu, usawazishaji otomatiki na usafishaji umezimwa, kwa hivyo vipengee bado havibadiliki. Tafadhali kumbuka kuwa katika kiolesura cha Argo CD programu yetu itakuwa na hali ya "Haijasawazishwa" kwa sababu hakuna lebo ambayo ArgoCD hutoa.
Hii ndiyo sababu tunapoanza kusawazisha baadaye kidogo, vitu havitatumwa tena.

Sasa hebu tufanye jaribio ili kuhakikisha kuwa hakuna makosa katika faili zetu.

argocd app sync simple-app --dry-run

Ikiwa hakuna makosa, basi unaweza kuendelea na maingiliano.

argocd app sync simple-app

Baada ya kutekeleza amri ya kupata argocd kwenye programu yetu, tunapaswa kuona kwamba hali ya programu imebadilika kuwa Healthy au Synced. Hii itamaanisha kuwa rasilimali zote kwenye hazina ya Git sasa zinalingana na rasilimali hizo ambazo tayari zimetumwa.

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
...

Sasa unaweza kuwezesha kusawazisha na kusafisha kiotomatiki ili kuhakikisha kuwa hakuna kitu kinachoundwa kwa mikono na kwamba kila wakati kitu kinapoundwa au kusasishwa kwenye hazina, uwekaji utafanyika.

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

Kwa hivyo, tumefaulu kuleta programu chini ya udhibiti wa GitOps ambayo hapo awali haikutumia GitOps kwa njia yoyote.

Chanzo: mapenzi.com

Kuongeza maoni