Å odien parunÄsim par GitOps principiem un modeļiem, kÄ arÄ« par to, kÄ Å”ie modeļi tiek realizÄti OpenShift platformÄ. Ir pieejams interaktÄ«vs ceļvedis par Å”o tÄmu .
ÄŖsumÄ, GitOps ir prakses kopums Git pull pieprasÄ«jumu izmantoÅ”anai infrastruktÅ«ras un lietojumprogrammu konfigurÄciju pÄrvaldÄ«bai. Git repozitorijs pakalpojumÄ GitOps tiek uzskatÄ«ts par vienotu informÄcijas avotu par sistÄmas stÄvokli, un visas Ŕī stÄvokļa izmaiÅas ir pilnÄ«bÄ izsekojamas un auditÄjamas.
Ideja par izmaiÅu izsekoÅ”anu GitOps nekÄdÄ ziÅÄ nav jauna; Ŕī pieeja jau sen ir izmantota gandrÄ«z universÄli, strÄdÄjot ar lietojumprogrammas pirmkodu. GitOps vienkÄrÅ”i ievieÅ” lÄ«dzÄ«gas funkcijas (atsauksmes, izvilkÅ”anas pieprasÄ«jumus, tagus utt.) infrastruktÅ«ras un lietojumprogrammu konfigurÄcijas pÄrvaldÄ«bÄ un nodroÅ”ina lÄ«dzÄ«gas priekÅ”rocÄ«bas kÄ pirmkoda pÄrvaldÄ«bas gadÄ«jumÄ.
GitOps nav akadÄmiskas definÄ«cijas vai apstiprinÄtu noteikumu kopuma, ir tikai principu kopums, uz kuriem balstÄs Ŕī prakse:
- SistÄmas deklaratÄ«vais apraksts tiek glabÄts Git repozitorijÄ (konfigurÄcijas, uzraudzÄ«ba utt.).
- StÄvokļa izmaiÅas tiek veiktas, izmantojot izvilkÅ”anas pieprasÄ«jumus.
- DarbojoÅ”o sistÄmu stÄvoklis tiek saskaÅots ar datiem repozitorijÄ, izmantojot Git push pieprasÄ«jumus.
GitOps principi
- SistÄmas definÄ«cijas ir aprakstÄ«tas kÄ pirmkods
SistÄmas konfigurÄcija tiek uzskatÄ«ta par kodu, lai to varÄtu glabÄt un automÄtiski veikt versijas Git repozitorijÄ, kas kalpo kÄ vienots patiesÄ«bas avots. Å Ä« pieeja atvieglo izmaiÅu ievieÅ”anu un atcelÅ”anu sistÄmÄs.
- VÄlamais sistÄmu stÄvoklis un konfigurÄcija ir iestatÄ«ta un versijas Git
SaglabÄjot un versijÄjot vÄlamo sistÄmu stÄvokli pakalpojumÄ Git, mÄs varam viegli ieviest un atsaukt izmaiÅas sistÄmÄs un lietojumprogrammÄs. MÄs varam arÄ« izmantot Git droŔības mehÄnismus, lai kontrolÄtu koda Ä«paÅ”umtiesÄ«bas un pÄrbaudÄ«tu tÄ autentiskumu.
- KonfigurÄcijas izmaiÅas var automÄtiski piemÄrot, izmantojot pull pieprasÄ«jumus
Izmantojot Git pull pieprasÄ«jumus, mÄs varam viegli kontrolÄt, kÄ izmaiÅas tiek piemÄrotas konfigurÄcijÄm repozitorijÄ. PiemÄram, tos var nodot citiem komandas locekļiem pÄrskatÄ«Å”anai vai veikt CI testus utt.
Un tajÄ paÅ”Ä laikÄ nav nepiecieÅ”ams sadalÄ«t administratora pilnvaras pa kreisi un pa labi. Lai veiktu konfigurÄcijas izmaiÅas, lietotÄjiem ir nepiecieÅ”amas tikai atbilstoÅ”as āāatļaujas Git repozitorijÄ, kurÄ tiek glabÄtas Ŕīs konfigurÄcijas.
- NekontrolÄtas konfigurÄciju novirzes problÄmas novÄrÅ”ana
Kad vÄlamais sistÄmas stÄvoklis ir saglabÄts Git repozitorijÄ, mums atliek tikai atrast programmatÅ«ru, kas nodroÅ”inÄs, ka paÅ”reizÄjais sistÄmas stÄvoklis atbilst vÄlamajam stÄvoklim. Ja tas tÄ nav, Å”ai programmatÅ«rai atkarÄ«bÄ no iestatÄ«jumiem vajadzÄtu vai nu paÅ”ai novÄrst neatbilstÄ«bu, vai arÄ« informÄt mÅ«s par konfigurÄcijas novirzi.
GitOps modeļi platformai OpenShift
Klastera resursu saskaÅotÄjs
SaskaÅÄ ar Å”o modeli klasterim ir kontrolieris, kas ir atbildÄ«gs par Kubernetes resursu (YAML failu) salÄ«dzinÄÅ”anu Git repozitorijÄ ar reÄlajiem klastera resursiem. Ja tiek konstatÄtas neatbilstÄ«bas, kontrolieris nosÅ«ta paziÅojumus un, iespÄjams, veic darbÄ«bas, lai novÄrstu neatbilstÄ«bas. Å is GitOps modelis tiek izmantots Anthos Config Management un Weaveworks Flux.
ÄrÄjo resursu saskaÅotÄjs (push)
Å o modeli var uzskatÄ«t par iepriekÅ”ÄjÄ variantu, kad mums ir viens vai vairÄki kontrolieri, kas atbild par resursu sinhronizÄciju pÄros āGit repozitorijs - Kubernetes klasterisā. AtŔķirÄ«ba Å”eit ir tÄda, ka katram pÄrvaldÄ«tajam klasterim ne vienmÄr ir savs atseviŔķs kontrolieris. Git un k8s klasteru pÄri bieži tiek definÄti kÄ CRD (pielÄgotas resursu definÄ«cijas), kas var aprakstÄ«t, kÄ kontrolierim jÄveic sinhronizÄcija. Å Ä« modeļa ietvaros kontrolieri salÄ«dzina CRD norÄdÄ«to Git repozitoriju ar Kubernetes klastera resursiem, kas arÄ« ir norÄdÄ«ti CRD, un veic atbilstoÅ”as āādarbÄ«bas, pamatojoties uz salÄ«dzinÄÅ”anas rezultÄtiem. Jo Ä«paÅ”i Å”is GitOps modelis tiek izmantots ArgoCD.
GitOps OpenShift platformÄ
VairÄku klasteru Kubernetes infrastruktÅ«ras administrÄÅ”ana
LÄ«dz ar Kubernetes izplatÄ«bu un vairÄku mÄkoÅu stratÄÄ£iju un malu skaitļoÅ”anas pieaugoÅ”o popularitÄti palielinÄs arÄ« vidÄjais OpenShift klasteru skaits uz vienu klientu.
PiemÄram, izmantojot malu skaitļoÅ”anu, viena klienta kopas var tikt izvietotas simtos vai pat tÅ«kstoÅ”os. RezultÄtÄ viÅÅ” ir spiests pÄrvaldÄ«t vairÄkas neatkarÄ«gas vai koordinÄtas OpenShift kopas publiskajÄ mÄkonÄ« un lokÄlajÄ vidÄ.
Å ajÄ gadÄ«jumÄ ir jÄatrisina daudzas problÄmas, jo Ä«paÅ”i:
- KontrolÄjiet, lai kopas bÅ«tu identiskÄ stÄvoklÄ« (konfigurÄcijas, uzraudzÄ«ba, glabÄÅ”ana utt.)
- AtkÄrtoti izveidojiet (vai atjaunojiet) kopas, pamatojoties uz zinÄmu stÄvokli.
- Izveidojiet jaunas kopas, pamatojoties uz zinÄmu stÄvokli.
- Ieviest izmaiÅas vairÄkos OpenShift klasteros.
- Atsaukt izmaiÅas vairÄkÄs OpenShift klasteros.
- Saistiet veidÅu konfigurÄcijas ar dažÄdÄm vidÄm.
Lietojumprogrammu konfigurÄcijas
Sava dzÄ«ves cikla laikÄ lietojumprogrammas bieži iziet cauri klasteru Ä·Ädei (izstrÄdÄtÄjs, stadija utt.), pirms nonÄk ražoÅ”anas klasterÄ«. TurklÄt pieejamÄ«bas un mÄrogojamÄ«bas prasÄ«bu dÄļ klienti bieži izvieto lietojumprogrammas vairÄkos lokÄlos klasteros vai vairÄkos publiskas mÄkoÅa platformas reÄ£ionos.
Å ajÄ gadÄ«jumÄ ir jÄatrisina Å”Ädi uzdevumi:
- NodroÅ”iniet lietojumprogrammu (binÄro, konfigurÄciju utt.) kustÄ«bu starp klasteriem (izstrÄdÄtÄjs, stadija utt.).
- Ieviest izmaiÅas lietojumprogrammÄs (binÄrie faili, konfigurÄcijas utt.) vairÄkos OpenShift klasteros.
- Atgriezt lietojumprogrammu izmaiÅas uz iepriekÅ”Äjo zinÄmo stÄvokli.
OpenShift GitOps lietoŔanas gadījumi
1. IzmaiÅu piemÄroÅ”ana no Git repozitorija
Klastera administrators var glabÄt OpenShift klasteru konfigurÄcijas Git krÄtuvÄ un automÄtiski lietot tÄs, lai bez piepÅ«les izveidotu jaunas kopas un nonÄktu tÄdÄ stÄvoklÄ«, kas ir identisks zinÄmajam Git repozitorijÄ saglabÄtajam stÄvoklim.
2. SinhronizÄcija ar Secret Manager
Administrators gÅ«s labumu arÄ« no iespÄjas sinhronizÄt OpenShift slepenos objektus ar atbilstoÅ”u programmatÅ«ru, piemÄram, Vault, lai tos pÄrvaldÄ«tu, izmantojot Ä«paÅ”i Å”im nolÅ«kam izveidotus rÄ«kus.
3. Drifta konfigurÄciju kontrole
Administrators atbalstÄ«s tikai tad, ja OpenShift GitOps pats identificÄs un brÄ«dinÄs par neatbilstÄ«bÄm starp reÄlajÄm un repozitorijÄ norÄdÄ«tajÄm konfigurÄcijÄm, lai viÅi varÄtu Ätri reaÄ£Ät uz novirzÄm.
4. PaziÅojumi par konfigurÄcijas novirzi
Tie ir noderÄ«gi gadÄ«jumÄ, ja administrators vÄlas Ätri uzzinÄt par konfigurÄcijas dreifÄÅ”anas gadÄ«jumiem, lai pats Ätri veiktu atbilstoÅ”us pasÄkumus.
5. ManuÄla konfigurÄciju sinhronizÄcija drifta laikÄ
Ä»auj administratoram konfigurÄcijas novirzes gadÄ«jumÄ sinhronizÄt OpenShift klasteru ar Git repozitoriju, lai Ätri atgrieztu klasteru iepriekÅ”ÄjÄ zinÄmÄ stÄvoklÄ«.
6. AutomÄtiska konfigurÄciju sinhronizÄcija dreifÄjot
Administrators var arÄ« konfigurÄt OpenShift klasteru, lai tas automÄtiski sinhronizÄtos ar repozitoriju, kad tiek konstatÄta novirze, lai klastera konfigurÄcija vienmÄr atbilstu Git konfigurÄcijÄm.
7. VairÄki klasteri - viens repozitorijs
Administrators var saglabÄt vairÄku dažÄdu OpenShift klasteru konfigurÄcijas vienÄ Git repozitorijÄ un pÄc vajadzÄ«bas tÄs selektÄ«vi lietot.
8. Klasteru konfigurÄciju hierarhija (mantoÅ”ana)
Administrators var iestatÄ«t klasteru konfigurÄciju hierarhiju krÄtuvÄ (posms, prod, lietotÅu portfelis utt. ar mantoÅ”anu). Citiem vÄrdiem sakot, tas var noteikt, vai konfigurÄcijas ir jÄpiemÄro vienam vai vairÄkiem klasteriem.
PiemÄram, ja administrators Git repozitorijÄ iestata hierarhiju āRažoÅ”anas klasteri (prod) ā X sistÄmas klasteri ā X sistÄmas ražoÅ”anas klasteriā, sistÄmas X ražoÅ”anas klasteriem tiek piemÄrota Å”Ädu konfigurÄciju kombinÄcija:
- VisÄm ražoÅ”anas klasteriem kopÄ«gas konfigurÄcijas.
- System X klastera konfigurÄcijas.
- X sistÄmas ražoÅ”anas klastera konfigurÄcijas.
9. Veidnes un konfigurÄcijas ignorÄÅ”ana
Administrators var ignorÄt mantoto konfigurÄciju kopu un to vÄrtÄ«bas, piemÄram, lai precÄ«zi pielÄgotu konfigurÄciju konkrÄtiem klasteriem, kuriem tie tiks lietoti.
10. SelektÄ«vÄ iekļauÅ”ana un izslÄgÅ”ana konfigurÄcijÄm, lietojumprogrammu konfigurÄcijÄm
Administrators var iestatÄ«t nosacÄ«jumus noteiktu konfigurÄciju lietoÅ”anai vai nepiemÄroÅ”anai klasteriem ar noteiktiem raksturlielumiem.
11. VeidÅu atbalsts
IzstrÄdÄtÄji gÅ«s labumu no iespÄjas izvÄlÄties, kÄ tiks definÄti lietojumprogrammu resursi (Helm Chart, tÄ«rÄ Kubernetes yaml utt.), lai katrai konkrÄtai lietojumprogrammai izmantotu vispiemÄrotÄko formÄtu.
GitOps rÄ«ki OpenShift platformÄ
ArgoCD
ArgoCD ievieÅ” ÄrÄjo resursu saskaÅoÅ”anas modeli un piedÄvÄ centralizÄtu lietotÄja saskarni, lai organizÄtu attiecÄ«bas starp klasteriem un Git krÄtuvÄm. Å Ä«s programmas trÅ«kumi ietver nespÄju pÄrvaldÄ«t lietojumprogrammas, kad ArgoCD nedarbojas.
Plūdums
Flux ievieÅ” On-Cluster Resource Reconcile modeli, un rezultÄtÄ nav centralizÄtas definÄ«ciju repozitorija pÄrvaldÄ«bas, kas ir vÄjÄ vieta. No otras puses, tieÅ”i centralizÄcijas trÅ«kuma dÄļ, iespÄja pÄrvaldÄ«t lietojumprogrammas saglabÄjas pat tad, ja kÄds klasteris neizdodas.
ArgoCD instalÄÅ”ana programmÄ OpenShift
ArgoCD piedÄvÄ izcilu komandrindas interfeisu un tÄ«mekļa konsoli, tÄpÄc mÄs Å”eit neaplÅ«kosim Flux un citas alternatÄ«vas.
Lai izvietotu ArgoCD platformÄ OpenShift 4, veiciet Ŕīs darbÄ«bas kÄ klastera administrators:
ArgoCD komponentu izvietoÅ”ana OpenShift platformÄ
# 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}')ArgoCD servera uzlaboÅ”ana, lai to varÄtu redzÄt OpenShift marÅ”rutÄ
# 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=RedirectArgoCD Cli rīka izvietoŔana
# 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/argocdArgoCD Server administratora paroles maiÅa
# 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
PÄc Å”o darbÄ«bu veikÅ”anas varat strÄdÄt ar ArgoCD Server, izmantojot ArgoCD WebUI tÄ«mekļa konsoli vai ArgoCD Cli komandrindas rÄ«ku.
GitOps ā nekad nav par vÄlu
āVilciens ir aizgÄjisā - tÄ viÅi saka par situÄciju, kad tiek palaists garÄm iespÄja kaut ko darÄ«t. OpenShift gadÄ«jumÄ vÄlme nekavÄjoties sÄkt lietot Å”o forÅ”o jauno platformu bieži vien rada tieÅ”i Å”Ädu situÄciju ar marÅ”rutu, izvietoÅ”anu un citu OpenShift objektu pÄrvaldÄ«bu un uzturÄÅ”anu. Bet vai iespÄja vienmÄr ir pilnÄ«bÄ garÄm?
Turpinot rakstu sÄriju par , Å”odien mÄs jums parÄdÄ«sim, kÄ ar rokÄm izveidotu lietojumprogrammu un tÄs resursus pÄrveidot par procesu, kurÄ visu pÄrvalda GitOps rÄ«ki. Lai to izdarÄ«tu, vispirms manuÄli izvietosim httpd lietojumprogrammu. TÄlÄk esoÅ”ajÄ ekrÄnuzÅÄmumÄ ir parÄdÄ«ts, kÄ mÄs izveidojam nosaukumvietu, izvietoÅ”anu un pakalpojumu un pÄc tam atklÄjam Å”o pakalpojumu, lai izveidotu marÅ”rutu.
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-appTÄtad mums ir ar rokÄm izstrÄdÄta lietojumprogramma. Tagad tas ir jÄpÄrsÅ«ta GitOps pÄrvaldÄ«bÄ, nezaudÄjot pieejamÄ«bu. ÄŖsÄk sakot, tas darbojas Å”Ädi:
- Izveidojiet koda Git repozitoriju.
- MÄs eksportÄjam savus paÅ”reizÄjos objektus un augÅ”upielÄdÄjam tos Git repozitorijÄ.
- GitOps rīku atlase un izvietoŔana.
- MÄs pievienojam savu repozitoriju Å”im rÄ«ku komplektam.
- MÄs definÄjam lietojumprogrammu mÅ«su GitOps rÄ«ku komplektÄ.
- MÄs veicam lietojumprogrammas testa darbÄ«bu, izmantojot GitOps rÄ«ku komplektu.
- MÄs sinhronizÄjam objektus, izmantojot GitOps rÄ«ku komplektu.
- IespÄjot objektu apgrieÅ”anu un automÄtisko sinhronizÄciju.
KÄ minÄts iepriekÅ”ÄjÄ , GitOps ir viens un tikai viens informÄcijas avots par visiem objektiem Kubernetes klasterÄ«(-os) - Git repozitorijs. TÄlÄk mÄs izejam no pieÅÄmuma, ka jÅ«su organizÄcija jau izmanto Git repozitoriju. Tas var bÅ«t publisks vai privÄts, taÄu tam ir jÄbÅ«t pieejamam Kubernetes klasteriem. Tas var bÅ«t tas pats repozitorijs, kas lietojumprogrammas kodam, vai atseviŔķs repozitorijs, kas izveidots Ä«paÅ”i izvietoÅ”anai. RepozitorijÄ ieteicams iegÅ«t stingras atļaujas, jo tajÄ tiks glabÄti noslÄpumi, marÅ”ruti un citas ar droŔību saistÄ«tas lietas.
MÅ«su piemÄrÄ mÄs izveidosim jaunu publisku repozitoriju vietnÄ GitHub. Varat to saukt, kÄ vien vÄlaties, mÄs izmantojam nosaukumu blogpost.
Ja YAML objektu faili netika saglabÄti lokÄli vai Git, jums bÅ«s jÄizmanto oc vai kubectl binÄrie faili. TÄlÄk esoÅ”ajÄ ekrÄnuzÅÄmumÄ mÄs pieprasÄm YAML mÅ«su nosaukumvietai, izvietoÅ”anai, pakalpojumam un marÅ”rutam. Pirms tam mÄs tajÄ klonÄjÄm jaunizveidoto repozitoriju un kompaktdisku.
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.yamlTagad rediÄ£Äsim failu deployment.yaml, lai noÅemtu lauku, kuru Argo CD nevar sinhronizÄt.
sed -i '/sgeneration: .*/d' deployment.yamlTurklÄt marÅ”ruts ir jÄmaina. Vispirms iestatÄ«sim daudzrindu mainÄ«go un pÄc tam aizvietosim ingress: null ar Ŕī mainÄ«gÄ saturu.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlTÄtad, mÄs esam sakÄrtojuÅ”i failus, atliek tikai tos saglabÄt Git repozitorijÄ. PÄc tam Ŕī krÄtuve kļūst par vienÄ«go informÄcijas avotu, un jebkÄdas manuÄlas objektu izmaiÅas ir stingri jÄaizliedz.
git commit -am āinitial commit of objectsā
git push origin masterTÄlÄk mÄs balstÄmies uz faktu, ka jÅ«s jau esat izvietojis ArgoCD (kÄ to izdarÄ«t - skatiet iepriekÅ”Äjo ). TÄpÄc mÄs Argo kompaktdiskam pievienosim mÅ«su izveidoto repozitoriju, kurÄ ir lietojumprogrammas kods no mÅ«su piemÄra. VienkÄrÅ”i pÄrliecinieties, ka esat norÄdÄ«jis tieÅ”i to repozitoriju, kuru izveidojÄt iepriekÅ”.
argocd repo add https://github.com/cooktheryan/blogpostTagad izveidosim lietojumprogrammu. Lietojumprogramma iestata vÄrtÄ«bas tÄ, lai GitOps rÄ«kkopa saprastu, kuru repozitoriju un ceļus izmantot, kurÅ” OpenShift ir nepiecieÅ”ams, lai pÄrvaldÄ«tu objektus, kura konkrÄta repozitorija filiÄle ir nepiecieÅ”ama un vai resursi ir jÄsinhronizÄ automÄtiski.
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
Kad lietojumprogramma ir norÄdÄ«ta Argo kompaktdiskÄ, rÄ«kkopa sÄk pÄrbaudÄ«t jau izvietotos objektus, salÄ«dzinot ar repozitorijÄ esoÅ”ajÄm definÄ«cijÄm. MÅ«su piemÄrÄ automÄtiskÄ sinhronizÄcija un tÄ«rÄ«Å”ana ir atspÄjota, tÄpÄc elementi vÄl nemainÄs. LÅ«dzu, Åemiet vÄrÄ, ka Argo CD saskarnÄ mÅ«su lietojumprogrammai bÅ«s statuss āOut of Syncā, jo nav nevienas etiÄ·etes, ko nodroÅ”ina ArgoCD.
TÄpÄc, kad mÄs sÄkam sinhronizÄciju nedaudz vÄlÄk, objekti netiks pÄrvietoti.
Tagad veiksim testa palaiÅ”anu, lai pÄrliecinÄtos, ka mÅ«su failos nav kļūdu.
argocd app sync simple-app --dry-runJa kļūdu nav, varat pÄriet uz sinhronizÄciju.
argocd app sync simple-appPÄc komandas argocd get palaiÅ”anas mÅ«su lietojumprogrammÄ mums vajadzÄtu redzÄt, ka lietojumprogrammas statuss ir mainÄ«ts uz VeselÄ«gs vai SinhronizÄts. Tas nozÄ«mÄs, ka visi resursi Git repozitorijÄ tagad atbilst tiem resursiem, kas jau ir izvietoti.
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
... Tagad varat iespÄjot automÄtisko sinhronizÄciju un tÄ«rÄ«Å”anu, lai nodroÅ”inÄtu, ka nekas netiek izveidots manuÄli un ka katru reizi, kad objekts tiek izveidots vai atjauninÄts repozitorijÄ, tiks veikta izvietoÅ”ana.
argocd app set simple-app --sync-policy automated --auto-prune
TÄtad, mÄs esam veiksmÄ«gi nodevuÅ”i lietojumprogrammu GitOps kontrolÄ, kas sÄkotnÄji nekÄdÄ veidÄ neizmantoja GitOps.
Avots: www.habr.com