Tänään puhumme GitOpsin periaatteista ja malleista sekä siitä, kuinka nämä mallit toteutetaan OpenShift-alustalla. Tästä aiheesta on saatavilla interaktiivinen opas .
Lyhyesti sanottuna GitOps on joukko käytäntöjä Git pull -pyyntöjen käyttämiseksi infrastruktuurin ja sovelluskokoonpanojen hallintaan. GitOpsin Git-tietovarastoa käsitellään yhtenä tietolähteenä järjestelmän tilasta, ja kaikki muutokset tähän tilaan ovat täysin jäljitettävissä ja tarkastettavissa.
Ajatus muutosten seurannasta GitOpsissa ei ole mitenkään uusi, tätä lähestymistapaa on käytetty pitkään lähes yleisesti sovelluksen lähdekoodin kanssa työskennellessä. GitOps yksinkertaisesti toteuttaa samanlaisia ominaisuuksia (arvostelut, vetopyynnöt, tagit jne.) infrastruktuurin ja sovellusten kokoonpanon hallinnassa ja tarjoaa samanlaisia etuja kuin lähdekoodin hallinnassa.
GitOpsille ei ole akateemista määritelmää tai hyväksyttyä sääntöjoukkoa, vain joukko periaatteita, joille tämä käytäntö rakentuu:
- Järjestelmän deklaratiivinen kuvaus tallennetaan Git-tietovarastoon (konfiguraatiot, valvonta jne.).
- Tilamuutokset tehdään vetopyyntöjen kautta.
- Käynnissä olevien järjestelmien tila mukautetaan arkistossa olevien tietojen kanssa Git push -pyyntöjen avulla.
GitOps-periaatteet
- Järjestelmän määritelmät kuvataan lähdekoodina
Järjestelmän konfiguraatiota käsitellään koodina, joten se voidaan tallentaa ja versioida automaattisesti Git-tietovarastoon, joka toimii yhtenä totuuden lähteenä. Tämä lähestymistapa helpottaa järjestelmien muutosten käyttöönottoa ja palauttamista.
- Järjestelmien haluttu tila ja kokoonpano asetetaan ja versioitetaan Gitissä
Tallentamalla ja versioimalla halutun järjestelmän tilan Gitissä voimme helposti ottaa käyttöön ja peruuttaa muutoksia järjestelmiin ja sovelluksiin. Voimme myös käyttää Gitin suojausmekanismeja koodin omistajuuden hallintaan ja sen aitouden tarkistamiseen.
- Konfiguraatiomuutokset voidaan ottaa käyttöön automaattisesti vetopyyntöjen kautta
Git pull -pyyntöjen avulla voimme helposti hallita, kuinka muutoksia sovelletaan arkiston kokoonpanoihin. Ne voidaan esimerkiksi antaa muille tiimin jäsenille tarkistettavaksi tai suorittaa CI-testejä jne.
Ja samaan aikaan ei tarvitse jakaa järjestelmänvalvojan valtuuksia vasemmalle ja oikealle. Määritysmuutosten tekemiseksi käyttäjät tarvitsevat vain asianmukaiset oikeudet Git-tietovarastoon, johon kyseiset kokoonpanot on tallennettu.
- Konfiguraatioiden hallitsemattoman siirtymisen ongelman korjaaminen
Kun järjestelmän haluttu tila on tallennettu Git-tietovarastoon, meidän tarvitsee vain löytää ohjelmisto, joka varmistaa, että järjestelmän nykyinen tila vastaa haluttua tilaa. Jos näin ei ole, tämän ohjelmiston pitäisi - asetuksista riippuen - joko poistaa ristiriita itsestään tai ilmoittaa meille konfiguraatiovirheestä.
GitOps-mallit OpenShiftille
Cluster Resource Conciler
Tämän mallin mukaan klusterissa on ohjain, joka vastaa Git-tietovaraston Kubernetes-resurssien (YAML-tiedostojen) vertaamisesta klusterin todellisiin resursseihin. Jos poikkeavuuksia havaitaan, ohjain lähettää ilmoituksia ja mahdollisesti ryhtyy toimenpiteisiin poikkeamien korjaamiseksi. Tätä GitOps-mallia käytetään Anthos Config Managementissa ja Weaveworks Fluxissa.
Ulkoisten resurssien täsmäytys (push)
Tätä mallia voidaan pitää muunnelmana edellisestä, kun meillä on yksi tai useampi ohjain, joka vastaa resurssien synkronoinnista "Git-varasto - Kubernetes-klusteri" -pareissa. Erona tässä on se, että jokaisella hallitulla klusterilla ei välttämättä ole omaa erillistä ohjainta. Git - k8s -klusteriparit määritellään usein CRD:ksi (custom Resource Definition), jotka voivat kuvata kuinka ohjaimen tulee suorittaa synkronointi. Tässä mallissa ohjaimet vertaavat CRD:ssä määritettyä Git-tietovarastoa Kubernetes-klusteriresursseihin, jotka myös on määritelty CRD:ssä, ja suorittavat tarvittavat toimenpiteet vertailun tulosten perusteella. Erityisesti tätä GitOps-mallia käytetään ArgoCD: ssä.
GitOps OpenShift-alustalla
Moniklusterin Kubernetes-infrastruktuurin hallinta
Kubernetesin leviämisen sekä monipilvistrategioiden ja reunalaskennan kasvavan suosion myötä myös OpenShift-klusterien keskimääräinen määrä asiakasta kohti kasvaa.
Esimerkiksi reunalaskentaa käytettäessä yhden asiakkaan klustereita voidaan ottaa käyttöön satoja tai jopa tuhansia. Tämän seurauksena hän joutuu hallitsemaan useita itsenäisiä tai koordinoituja OpenShift-klustereita julkisessa pilvessä ja paikan päällä.
Tässä tapauksessa on ratkaistava monia ongelmia, erityisesti:
- Hallitse, että klusterit ovat samassa tilassa (kokoonpanot, valvonta, tallennus jne.)
- Luo (tai palauta) klusterit tunnetun tilan perusteella.
- Luo uusia klustereita tunnetun tilan perusteella.
- Ota muutokset käyttöön useisiin OpenShift-klustereihin.
- Palauta muutokset useissa OpenShift-klustereissa.
- Linkitä mallikonfiguraatiot eri ympäristöihin.
Sovellusmääritykset
Elinkaarinsa aikana sovellukset kulkevat usein klusteriketjun (kehittäjä, vaihe jne.) läpi ennen kuin ne päätyvät tuotantoklusteriin. Lisäksi saatavuus- ja skaalautuvuusvaatimusten vuoksi asiakkaat ottavat usein käyttöön sovelluksia useille paikallisille klusteille tai julkisen pilvialustan useille alueille.
Tässä tapauksessa seuraavat tehtävät on ratkaistava:
- Varmista sovellusten (binäärit, konfiguraatiot jne.) liikkuminen klusterien välillä (kehittäjä, vaihe jne.).
- Ota käyttöön muutokset sovelluksiin (binäärit, konfiguraatiot jne.) useissa OpenShift-klustereissa.
- Palauta sovellusten muutokset aikaisempaan tunnettuun tilaan.
OpenShift GitOps -käyttötapaukset
1. Muutosten käyttöönotto Git-arkistosta
Klusterin ylläpitäjä voi tallentaa OpenShift-klusterimääritykset Git-säilöön ja käyttää niitä automaattisesti uusien klustereiden luomiseen vaivattomasti ja ne tilaan, joka on identtinen Git-tietovarastoon tallennetun tunnetun tilan kanssa.
2. Synkronointi Secret Managerin kanssa
Järjestelmänvalvoja hyötyy myös mahdollisuudesta synkronoida OpenShift-salaisia objekteja sopivien ohjelmistojen, kuten Vaultin, kanssa, jotta niitä voidaan hallita erityisesti tätä varten luoduilla työkaluilla.
3. Ohjauskokoonpanojen ohjaus
Järjestelmänvalvoja kannattaa vain, jos OpenShift GitOps itse tunnistaa ja varoittaa eroista todellisten kokoonpanojen ja arkistossa määritettyjen välillä, jotta ne voivat reagoida nopeasti ajautumiseen.
4. Ilmoitukset konfiguraatiomuutoksesta
Ne ovat hyödyllisiä siinä tapauksessa, että järjestelmänvalvoja haluaa nopeasti oppia kokoonpanon ajautumisesta voidakseen ryhtyä nopeasti tarvittaviin toimenpiteisiin itse.
5. Konfiguraatioiden manuaalinen synkronointi ajautuessa
Antaa järjestelmänvalvojan synkronoida OpenShift-klusterin Git-tietovaraston kanssa kokoonpanon ajautuessa, jotta klusteri palautetaan nopeasti aikaisempaan tunnettuun tilaan.
6. Automaattinen konfiguraatioiden synkronointi ajautuessa
Järjestelmänvalvoja voi myös määrittää OpenShift-klusterin synkronoitumaan automaattisesti arkiston kanssa, kun poikkeama havaitaan, jotta klusterin kokoonpano vastaa aina Gitin konfiguraatioita.
7. Useita klustereita - yksi arkisto
Ylläpitäjä voi tallentaa useiden eri OpenShift-klustereiden kokoonpanot yhteen Git-tietovarastoon ja käyttää niitä valikoivasti tarpeen mukaan.
8. Klusterikokoonpanojen hierarkia (periytys)
Järjestelmänvalvoja voi asettaa hierarkian arkiston klusterikokoonpanoille (vaihe, tuote, sovellusportfolio jne. perinnöllisesti). Toisin sanoen se voi määrittää, tuleeko määrityksiä soveltaa yhteen vai useampaan klusteriin.
Jos järjestelmänvalvoja esimerkiksi asettaa hierarkian "Tuotantoklusterit (tuote) → Järjestelmän X klusterit → Järjestelmän X tuotantoklusterit" Git-tietovarastoon, seuraavien asetusten yhdistelmää sovelletaan järjestelmän X tuotantoklustereihin:
- Kaikille tuotantoklustereille yhteiset konfiguraatiot.
- System X -klusterin asetukset.
- X-järjestelmän tuotantoklusterin asetukset.
9. Mallit ja asetusten ohitukset
Järjestelmänvalvoja voi ohittaa joukon perittyjä määrityksiä ja niiden arvoja esimerkiksi hienosäätääkseen tiettyjen klustereiden määrityksiä, joihin niitä sovelletaan.
10. Valikoiva sisällyttäminen ja poissulkeminen kokoonpanoille, sovelluskokoonpanoille
Järjestelmänvalvoja voi asettaa ehdot tiettyjen konfiguraatioiden käyttöön tai käyttämättä jättämiselle klustereille, joilla on tietyt ominaisuudet.
11. Mallin tuki
Kehittäjät hyötyvät mahdollisuudesta valita, miten sovellusresurssit määritellään (Helm Chart, puhdas Kubernetes yaml jne.), jotta he voivat käyttää sopivinta muotoa kullekin tietylle sovellukselle.
GitOps-työkalut OpenShift-alustalla
ArgoCD
ArgoCD toteuttaa External Resource Reconcile -mallin ja tarjoaa keskitetyn käyttöliittymän klusterien ja Git-tietovarastojen välisten yksi-moneen-suhteiden järjestämiseen. Tämän ohjelman haittoja ovat kyvyttömyys hallita sovelluksia, kun ArgoCD ei toimi.
Vuo
Flux toteuttaa On-Cluster Resource Reconcile -mallin, ja sen seurauksena määritysvaraston keskitettyä hallintaa ei ole, mikä on heikko kohta. Toisaalta juuri keskittämisen puutteen vuoksi kyky hallita sovelluksia säilyy, vaikka yksi klusteri epäonnistuu.
ArgoCD:n asentaminen OpenShiftiin
ArgoCD tarjoaa erinomaisen komentorivikäyttöliittymän ja verkkokonsolin, joten emme käsittele Fluxia ja muita vaihtoehtoja tässä.
Ota ArgoCD käyttöön OpenShift 4 -alustalla noudattamalla näitä ohjeita klusterin järjestelmänvalvojana:
ArgoCD-komponenttien käyttöönotto OpenShift-alustalla
# 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-palvelimen parannus, jotta se voidaan nähdä OpenShift-reitillä
# 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 -työkalun käyttöönotto
# 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 -järjestelmänvalvojan salasanan vaihtaminen
# 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
Kun olet suorittanut nämä vaiheet, voit työskennellä ArgoCD Serverin kanssa ArgoCD WebUI -verkkokonsolin tai ArgoCD Cli -komentorivityökalun kautta.
GitOps - Koskaan ei ole liian myöhäistä
"Juna on lähtenyt" - näin he sanovat tilanteesta, jossa mahdollisuus tehdä jotain menetetään. OpenShiftin tapauksessa halu heti aloittaa tämän hienon uuden alustan käyttö luo usein juuri tämän tilanteen reittien, käyttöönottojen ja muiden OpenShift-objektien hallinnassa ja ylläpidossa. Mutta onko mahdollisuus aina kokonaan menetetty?
Jatkamme artikkelisarjaa aiheesta , tänään näytämme sinulle, kuinka käsintehty sovellus ja sen resurssit muunnetaan prosessiksi, jossa kaikkea hallinnoidaan GitOps-työkaluilla. Tätä varten otamme ensin manuaalisesti käyttöön httpd-sovelluksen. Alla oleva kuvakaappaus näyttää, kuinka luomme nimitilan, käyttöönoton ja palvelun ja paljastamme tämän palvelun reitin luomiseksi.
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-appMeillä on siis käsintehty sovellus. Nyt se on siirrettävä GitOps-hallinnan alle käytettävyyden menettämättä. Lyhyesti sanottuna se tekee näin:
- Luo koodille Git-arkisto.
- Viemme nykyiset objektimme ja lataamme ne Git-arkistoon.
- GitOps-työkalujen valinta ja käyttöönotto.
- Lisäämme arkistomme tähän työkalupakettiin.
- Määrittelemme sovelluksen GitOps-työkalupakkissamme.
- Suoritamme sovelluksen testiajon GitOps-työkalupakin avulla.
- Synkronoimme objektit GitOps-työkalupakin avulla.
- Ota käyttöön objektien karsiminen ja automaattinen synkronointi.
Kuten jo edellisessä mainittiin , GitOpsissa on yksi ja vain yksi tietolähde kaikista Kubernetes-klustereiden objekteista - Git-arkisto. Seuraavaksi lähdemme siitä olettamuksesta, että organisaatiosi käyttää jo Git-tietovarastoa. Se voi olla julkinen tai yksityinen, mutta sen on oltava Kubernetes-klusterien käytettävissä. Tämä voi olla sama arkisto kuin sovelluskoodille tai erillinen arkisto, joka on luotu erityisesti käyttöönottoja varten. On suositeltavaa, että arkistossa on tiukat käyttöoikeudet, koska salaisuudet, reitit ja muut turvallisuuden kannalta arkaluontoiset asiat tallennetaan sinne.
Esimerkissämme luomme uuden julkisen arkiston GitHubiin. Voit kutsua sitä miksi haluat, käytämme nimeä blogipostaus.
Jos YAML-objektitiedostoja ei tallennettu paikallisesti tai Gitissä, sinun on käytettävä oc- tai kubectl-binääriä. Alla olevassa kuvakaappauksessa pyydämme YAML:a nimiavaruuteen, käyttöönottoon, palveluun ja reittiin. Ennen tätä kloonattiin äskettäin luotu arkisto ja cd siihen.
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.yamlMuokkaa nyt deployment.yaml-tiedostoa poistamaan kenttä, jota Argo CD ei voi synkronoida.
sed -i '/sgeneration: .*/d' deployment.yamlLisäksi reittiä on muutettava. Asetamme ensin monirivisen muuttujan ja korvaamme sitten ingress: null kyseisen muuttujan sisällöllä.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlJoten olemme lajitelleet tiedostot, jäljellä on vain tallentaa ne Git-arkistoon. Tämän jälkeen tästä arkistosta tulee ainoa tietolähde, ja kaikki manuaaliset objektien muuttaminen tulisi ehdottomasti kieltää.
git commit -am ‘initial commit of objects’
git push origin masterLisäksi lähdemme siitä tosiasiasta, että olet jo ottanut käyttöön ArgoCD:n (miten tämä tehdään - katso edellinen ). Siksi lisäämme Argo-CD:lle luomamme arkiston, joka sisältää esimerkissämme olevan sovelluskoodin. Varmista vain, että määrität tarkalleen aiemmin luomasi arkiston.
argocd repo add https://github.com/cooktheryan/blogpostLuodaan nyt sovellus. Sovellus asettaa arvot niin, että GitOps-työkalupakki ymmärtää, mitä arkistoa ja polkuja käytetään, mitä OpenShift-toimintoa tarvitaan objektien hallintaan, mitä tiettyä arkiston haaraa tarvitaan ja pitäisikö resurssit synkronoida automaattisesti.
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
Kun sovellus on määritetty Argo CD:llä, työkalupakki alkaa tarkistaa jo käyttöön otettuja objekteja arkistossa olevien määritelmien perusteella. Esimerkissämme automaattinen synkronointi ja puhdistus on poistettu käytöstä, joten elementit eivät vielä muutu. Huomaa, että Argo CD -käyttöliittymässä sovelluksemme tila on "Out of Sync", koska ArgoCD:llä ei ole tarraa.
Tästä syystä kun aloitamme synkronoinnin hieman myöhemmin, objekteja ei sijoiteta uudelleen.
Tehdään nyt testiajo varmistaaksemme, ettei tiedostoissamme ole virheitä.
argocd app sync simple-app --dry-runJos virheitä ei ole, voit jatkaa synkronointia.
argocd app sync simple-appKun olet suorittanut argocd get -komennon sovelluksessamme, meidän pitäisi nähdä, että sovelluksen tila on muuttunut terveeksi tai synkronoituksi. Tämä tarkoittaa, että kaikki Git-tietovaraston resurssit vastaavat nyt niitä resursseja, jotka on jo otettu käyttöön.
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
... Nyt voit ottaa käyttöön automaattisen synkronoinnin ja puhdistamisen varmistaaksesi, että mitään ei luoda manuaalisesti ja että aina kun objekti luodaan tai päivitetään arkistoon, käyttöönotto tapahtuu.
argocd app set simple-app --sync-policy automated --auto-prune
Olemme siis saaneet onnistuneesti GitOps-hallinnan alle sovelluksen, joka ei alun perin käyttänyt GitOpsia millään tavalla.
Lähde: will.com