Kas yra ArgoCD ir kodėl jis keičia žaidimo taisykles
Kubernetes ekosistemoje deployment’ų valdymas gali tapti tikru košmaru, ypač kai jūsų infrastruktūra auga kaip ant mielių. Tradiciniai metodai, kai developmentas rankiniu būdu taiko `kubectl apply` komandas arba rašo sudėtingus CI/CD pipeline’us, greitai tampa nebepalaikomi. Čia ir ateina į pagalbą ArgoCD – vienas populiariausių GitOps įrankių, kuris iš esmės pakeičia požiūrį į aplikacijų diegimą Kubernetes klasteriuose.
ArgoCD veikia pagal paprastą, bet genialią idėją: jūsų Git repozitorija yra vienintelis tiesos šaltinis (single source of truth). Visos Kubernetes manifestų konfigūracijos, Helm chartai, Kustomize failai – viskas gyvena Git’e. ArgoCD nuolat stebi šias repozitorijas ir automatiškai sinchronizuoja bet kokius pasikeitimus su jūsų klasteriu. Jei kas nors bando pakeisti kažką tiesiogiai klasteryje – ArgoCD tai pamato ir gali automatiškai grąžinti į norimą būseną.
Pats ArgoCD yra Kubernetes native aplikacija, parašyta Go kalba, ir veikia kaip kontroleris jūsų klasteryje. Jis turi puikią web UI sąsają, kur galite vizualiai stebėti visų savo aplikacijų būseną, matyti deployment istoriją ir atlikti rollback’us vienu mygtuko paspaudimu. Bet tai tik ledkalnio viršūnė.
GitOps filosofija praktikoje
Prieš gilinantis į techninius ArgoCD aspektus, verta suprasti GitOps filosofiją. Tai nėra vien įrankis – tai metodologija, kuri fundamentaliai keičia deployment procesus. Tradiciškai CI/CD pipeline’ai turėdavo „push” teises į production aplinką. Jūsų Jenkins ar GitLab CI turėjo kubectl credentials ir tiesiogiai diegdavo aplikacijas. Problema? Tai saugumo košmaras ir audito pragaras.
GitOps apverčia šią paradigmą aukštyn kojomis. Vietoj to, kad CI sistema „stumtų” pakeitimus į klasterį, ArgoCD „traukia” (pull) konfigūracijas iš Git repozitorijos. Jūsų CI pipeline’as tik atnaujina Docker image tag’us Git’e arba keičia Helm values failus – o ArgoCD pats pastebi šiuos pakeitimus ir atlieka deployment’ą.
Praktiškai tai reiškia, kad production klasteris niekada neturi outbound prieigos prie jūsų CI sistemų. ArgoCD veikia klasteryje ir turi tik read-only prieigą prie Git repozitorijų. Tai drastiškai sumažina attack surface ir padaro auditą trivialiu – tiesiog pažiūrėkite į Git commit istoriją, ir žinosite kas, kada ir kodėl pakeitė production aplinką.
Diegimas ir pradinė konfigūracija
ArgoCD diegimas yra stebėtinai paprastas. Pirmiausia, jums reikia veikiančio Kubernetes klasterio. Nesvarbu ar tai local Minikube, cloud EKS, GKE ar AKS – ArgoCD veiks visur vienodai. Paprasčiausias būdas pradėti:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Šios dvi komandos sukuria atskirą namespace’ą ir įdiegia visus reikalingus ArgoCD komponentus: API serverį, repository serverį, application controllerį ir dex serverį autentifikacijai. Po kelių minučių turėtumėte matyti, kad visi podai sėkmingai veikia.
Norėdami pasiekti ArgoCD UI, galite naudoti port-forward:
kubectl port-forward svc/argocd-server -n argocd 8080:443
Pradinis admin slaptažodis automatiškai generuojamas ir saugomas kaip secret. Jį galite gauti su:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
Pirmą kartą prisijungę, pakeiskite šį slaptažodį! Production aplinkose rekomenduoju integruoti su OIDC provider’iu kaip Okta, Auth0 ar net Google OAuth. ArgoCD turi puikią SSO palaikymą.
Pirmosios aplikacijos deployment’as
Dabar pats įdomiausias dalykas – deploykime realią aplikaciją. ArgoCD operuoja „Application” objektais – tai custom resource definition (CRD), kuris aprašo, iš kur traukti konfigūraciją ir kur ją deplointi.
Sukurkime paprastą pavyzdį. Tarkime, turite Git repozitorijoje Kubernetes manifestus:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/jusu-org/kubernetes-manifests
targetRevision: HEAD
path: apps/my-app
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
Šis Application objektas sako ArgoCD: stebėk GitHub repozitoriją, `apps/my-app` directory, ir deployk viską kas ten yra į `production` namespace’ą. `automated` sync policy reiškia, kad ArgoCD automatiškai taikys pakeitimus – nereikės rankiniu būdu spausti „Sync” mygtuko.
`prune: true` parametras yra ypač svarbus – jis nurodo ArgoCD ištrinti resursus, kurie buvo pašalinti iš Git. Pavyzdžiui, jei ištrynėte Deployment iš savo manifestų, ArgoCD jį ištryns ir iš klasterio. `selfHeal: true` reiškia, kad jei kas nors rankiniu būdu pakeis resursą klasteryje (pvz., pakeičia replica count), ArgoCD automatiškai grąžins į būseną, apibrėžtą Git’e.
Darbas su Helm ir Kustomize
Realybėje retai kas rašo plain Kubernetes YAML manifestus. Dažniausiai naudojami Helm chartai arba Kustomize. Gera žinia – ArgoCD puikiai palaiko abu.
Helm chart deployment’ui pakanka nurodyti chart repozitoriją:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: nginx-ingress
namespace: argocd
spec:
project: default
source:
chart: nginx-ingress
repoURL: https://kubernetes.github.io/ingress-nginx
targetRevision: 4.8.3
helm:
values: |
controller:
replicaCount: 3
service:
type: LoadBalancer
destination:
server: https://kubernetes.default.svc
namespace: ingress-nginx
ArgoCD automatiškai atpažįsta Helm chartus ir naudoja `helm template` komandą generuoti finalius manifestus. Galite override’inti values tiesiogiai Application spec’e arba nurodyti atskirą values failą Git repozitorijoje.
Kustomize darbas dar paprastesnis – jei jūsų directory turi `kustomization.yaml` failą, ArgoCD automatiškai jį atpažins ir naudos. Nereikia jokios papildomos konfigūracijos. Tai ypač patogu, kai turite base konfigūraciją ir skirtingus overlay’us development, staging ir production aplinkoms.
Vienas iš mano mėgstamiausių pattern’ų – naudoti Helm chartus kaip base ir Kustomize overlay’us specifiniams aplinkos pakeitimams. Pavyzdžiui, base Helm chart’as apibrėžia pagrindinę aplikacijos struktūrą, o Kustomize overlay’ai prideda environment-specific ConfigMaps, Secrets ar resource limits.
Multi-cluster valdymas ir App of Apps pattern
Kai jūsų infrastruktūra auga, greičiausiai turėsite ne vieną Kubernetes klasterį. Development, staging, production, galbūt skirtingi regionai – ArgoCD puikiai tvarko multi-cluster scenarijus.
Galite pridėti papildomus klasterius į ArgoCD naudojant CLI:
argocd cluster add my-production-cluster --name production
Po to tiesiog nurodykite destination server URL Application spec’e. ArgoCD naudoja service account token’us komunikacijai su remote klasteriais, taigi nereikia dalintis kubectl config failais ar credentials.
Bet kas nutinka, kai turite 50 ar 100 aplikacijų? Nenorite gi rašyti 100 atskirų Application YAML failų. Čia praverčia „App of Apps” pattern’as. Idėja paprasta: sukuriate vieną „root” Application, kuri deployna kitas Applications.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: root-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/jusu-org/argocd-apps
targetRevision: HEAD
path: applications
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
prune: true
selfHeal: true
`applications` directory tiesiog turi daugybę Application YAML failų. Kai pridedame naują aplikaciją, tiesiog commit’iname naują failą – ArgoCD automatiškai sukuria naują Application objektą ir pradeda jį valdyti. Tai labai elegant’as būdas valdyti didelius deployment’us.
Dar pažangesnis variantas – ApplicationSet. Tai ArgoCD feature, leidžiantis generuoti daugybę panašių Applications naudojant templates. Pavyzdžiui, galite turėti vieną ApplicationSet, kuris automatiškai sukuria Application kiekvienam microservice’ui, kuris atitinka tam tikrą Git repository struktūrą.
Secrets valdymas ir saugumo aspektai
Viena didžiausių GitOps problemų – kaip valdyti secrets? Negalite gi commit’inti plain text slaptažodžių į Git. Yra keletas sprendimų, ir kiekvienas turi savo trade-off’us.
Pirmas variantas – Sealed Secrets. Tai Bitnami projektas, kuris leidžia užšifruoti Kubernetes Secrets naudojant public key. Rezultatas – SealedSecret objektas, kurį galima saugiai commit’inti į Git. Sealed Secrets controller’is, veikiantis klasteryje, dešifruoja juos į normalius Secrets naudodamas private key.
kubeseal --format=yaml < secret.yaml > sealed-secret.yaml
Antras populiarus variantas – External Secrets Operator. Vietoj to, kad saugotumėte secrets Git’e (net užšifruotus), jūs saugote juos external secrets management sistemoje kaip AWS Secrets Manager, HashiCorp Vault ar Azure Key Vault. External Secrets Operator sinchronizuoja juos į Kubernetes Secrets.
ArgoCD puikiai veikia su abiem sprendimais. Jis tiesiog deployna SealedSecret ar ExternalSecret objektus, o atitinkami operator’iai pasirūpina tikrųjų secrets sukūrimu.
Saugumo aspektu, ArgoCD palaiko RBAC (Role-Based Access Control) tiek savo UI, tiek API lygyje. Galite apibrėžti, kad developmentas gali deplointi tik į dev namespace’us, o production deployment’us gali atlikti tik tam tikri vartotojai ar automatizuoti procesai. Tai integruojasi su Kubernetes RBAC, taigi turite dvigubą apsaugos sluoksnį.
Monitoring, troubleshooting ir best practices
ArgoCD turi puikią integraciją su Prometheus ir Grafana. Jis exportuoja daugybę metrikų: sync status, health status, application count, API request latency ir t.t. Oficialus ArgoCD Grafana dashboard’as duoda gerą overview visų jūsų aplikacijų.
Kai kažkas negerai, ArgoCD UI yra pirmoji vieta, kur žiūrėti. Kiekviena aplikacija turi detailed view, rodantį visus Kubernetes resursus kaip tree struktūrą. Galite matyti, kurie podai healthy, kurie crashina, kokios events’ai įvyko. Tai neįkainojama troubleshooting’ui.
Jei aplikacija „Out of Sync”, ArgoCD parodo tikslų diff tarp to, kas Git’e, ir kas klasteryje. Galite matyti, kurie field’ai skiriasi, kas buvo pakeista. Tai labai padeda suprasti, kodėl automatinis sync nepavyko arba kas rankiniu būdu pakeitė konfigūraciją.
Keli praktiški patarimai iš asmeninės patirties:
Pirma, naudokite Projects organizuoti aplikacijas. Vietoj to, kad visos aplikacijos būtų `default` project’e, sukurkite atskirus projektus skirtingoms komandoms ar aplikacijų grupėms. Tai leidžia taikyti skirtingas RBAC politikas ir source/destination restrictions.
Antra, būtinai naudokite health checks. ArgoCD turi built-in health assessment daugeliui standard Kubernetes resursų, bet galite apibrėžti custom health checks savo CRD’ams. Tai užtikrina, kad ArgoCD teisingai reportuoja aplikacijos būseną.
Trečia, sync waves ir hooks yra jūsų draugai. Kai turite sudėtingus deployment’us, kur tam tikri resursai turi būti sukurti prieš kitus (pvz., database migration job prieš application deployment), naudokite annotations kontroliuoti deployment tvarką:
metadata:
annotations:
argocd.argoproj.io/sync-wave: "1"
Ketvirta, reguliariai review’inkite sync policies. Ar tikrai norite `automated` sync su `prune` ir `selfHeal` production’e? Kai kuriose organizacijose geriau turėti manual approval step’ą kritinėms aplikacijoms.
Kai viskas susideda į vieną paveikslą
ArgoCD nėra tik įrankis – tai paradigmos pokytis, kaip galvojame apie deployment’us ir infrastructure management. Kai pradedi jį naudoti, greitai supranti, kad grįžti atgal į senus metodus beveik neįmanoma. Vizualus aplikacijų būsenos vaizdavimas, automatinis drift detection, lengvas rollback’as – visa tai tampa natūralia darbo dalimi.
Žinoma, ArgoCD nėra sidabrinė kulka. Jis prideda papildomą complexity layer’į – dar vienas komponentas, kurį reikia prižiūrėti, dar viena sistema, kuri gali sugesti. Bet praktikoje, naudos yra nepalyginamai daugiau nei trade-off’ų. Ypač didelėse organizacijose, kur deployment’ų skaičius siekia šimtus per dieną.
Jei dar nenaudojate GitOps ir ArgoCD, rekomenduoju pradėti nuo mažo. Paimkite vieną ne-kritinę aplikaciją, sukurkite jai Git repozitoriją su manifestais, ir setup’inkite ArgoCD development klasteryje. Žaiskite su skirtingais sync policies, išbandykite Helm ir Kustomize integraciją. Po kelių savaičių jau turėsite pakankamai patirties, kad galėtumėte planuoti didesnį rollout’ą.
GitOps ir ArgoCD ateitis atrodo šviesi. Community aktyviai plėtoja naujus feature’us, integraciją su kitais cloud-native įrankiais gerėja, o adoption rate’as tik auga. Tai jau tapo de facto standartu daugelyje organizacijų, ir yra geros priežasties kodėl. Kai jūsų infrastruktūra aprašyta kaip kodas, versijuojama Git’e, ir automatiškai sinchronizuojama – jūs turite ne tik geresnį deployment procesą, bet ir geresnę visibility, auditability ir disaster recovery galimybes. Ir tai, galų gale, yra tai, ko visi norime.
