Röviden: A GitOps nem ArgoCD-kötelező. Kettes magyar csapatnál a lényeg: ami élesben fut, az a repóból jött, review-zható, és visszafordítható. A konzol a vészajtó, nem a nappali.
A GitOps-ról szóló cikkek többsége egy platformcsapatnak szól, ahol van ArgoCD, van cluster-flotta, van külön SRE. A magyar valóság gyakran kettes-hármas: egy repo, egy staging, egy prod, és valaki, aki pénteken a konzolon „csak gyorsan” átír egy security groupot. A GitOps ettől a mondattól kezdődik, nem az operator-telepítéstől. Ami élesben fut, az a gitből jött. Ami a gitben nincs, az nem létezik — vagy időzített incidens.
Először a szabály, aztán az eszköz
A minimum három mondat. Az infrastruktúra kódban van (Terraform, OpenTofu, CloudFormation — a név másodlagos). A változás pull request, nem SSH. A titok nem a repóban van, hanem referencia. Ha ez a három megvan, már GitOps-szerűen élsz, akkor is, ha a deployt GitHub Actions viszi, nem egy clusterben futó reconciler. Az ArgoCD és a Flux akkor jön, ha a Kubernetes-állapotot akarod folyamatosan visszaterelni a githez. Ha nincs clustered, ne vegyél magadnak operátort, hogy „gitopsos” légy.
A konzol a vészajtó. Incidensnél kinyitod, dokumentálod, és hétfőn visszavezeted kódba. Ha a vészajtó a nappali, a drift a lakberendezés. Hat hónap múlva senki nem tudja, miért nyílt az a port, és mindenki fél lezárni.
Kettes csapat: a review a gyenge pont
Kettem emberrel a GitOps gyenge pontja nem a tool, hanem a második szempár. Ha ugyanaz merge-eli, aki írta, a PR színház. Megoldás, ami működik kicsiben: kötelező checklist (destroy van-e, state lock, plan csatolva), és a pénteki prod-tiltás. A plan kimenete a PR-en legyen, ne a fejben. A terraform apply a CI-ből fusson, nem a laptopról, ahol más a plugin-verzió.
A state legyen távoli, zárolt, titkosított. A backend-hiba a GitOps csendes halála: ha a state szétcsúszik, a git hazudik, a valóság más, és innentől minden plan gyanús. Kettes csapatnál ez a nap, amikor valaki a konzolon „javít”, és a következő apply visszaépíti a hibát.
A GitOps nem az, hogy van YAML-od. Az, hogy a YAML nélkül a production nem magyarázható.
ArgoCD, Actions, vagy mindkettő
Ha van Kubernetesed, az ArgoCD (vagy Flux) a folyamatos egyeztetés: a cluster állapota a githez húz vissza, nemcsak akkor, amikor valaki deployol. Ez a GitOps eredeti ígérete. Ha nincs clustered, a GitHub Actions + Terraform ugyanazt a lelket adja az infra-rétegre: PR → plan → apply, naplóval. A kettő keverhető: az app a clusterbe GitOps-szal megy, az account-szintű IAM és hálózat Terraformmal. A hiba az, amikor az IAM a konzolon él, az app meg a gitben — a kettő határa lesz a következő outage.
A secret: SOPS, SSM, Secrets Manager — de soha plaintext a gitben, soha .env a artifactban. A GitOps a titokra is vonatkozik: a referencia mehet a gitbe, az érték nem. A rotáció legyen kódolt, ne kézi.
És a rollback. Ha a git a forrás, a rollback egy revert, nem egy emlékezetből összerakott konzol-lépéssor. Ezért éri meg a fegyelem. Incidensnél a percek a git-historyban vannak, nem abban, hogy ki emlékszik a délutáni klikkelésre.
Környezetek, OpenTofu, és a drift, amit mersz nézni
Staging és prod legyen ugyanaz a kód, más változókkal — nem más repo, nem más kézi kivétel. A „prod-on már más a security group, mert egyszer kellett” a GitOps ellentéte. Promotion: a merge a mainre a staging apply, a tag vagy a manuális approval a prod. Kettes csapatnál az approval lehet a másik ember, naptárban, nem egy enterprise-kapu. A lényeg, hogy a prod ne a laptopról menjen.
Terraform versus OpenTofu 2026-ban már nem identitásháború a magyar kettes csapat asztalán. Ha a provider-ök és a state-workflow stimmel, a motor cseréje másodlagos a fegyelemhez képest. A licencváltás óta sokan mérlegelnek; a migráció valós költsége a CI, a lock, a provider pin, nem a bináris neve. Ne válts motort abban a sprintben, amikor a state-et viszed S3-ba. Egy változás egyszerre.
A drift detection legyen heti, ne éves. Egy plan a CI-ben, ami nem apply-ol, csak riaszt, ha a valóság eltér a gittől. Ha a plan mindig „11 to change”, a GitOps már színház. Akkor állj meg, vidd vissza a konzolos kivételeket, és csak utána merge-elj új feature-t. A tiszta plan unalmas. Az unalom itt is a siker.
A delivery-ágak ugyanígy. Long-lived feature branch az infra-repon a drift rokona: minél tovább él, annál kevésbé merge-elhető a state-hez. Rövid ág, kicsi PR, plan a kommentben. A modellvasút-metafora szándékos: az elágazás akkor ér valamit, ha a szerelvény visszaér a fővonalra. Ami a fűben végződik, az a pénteki security group. Ugyanez a szabály az alkalmazás-repo és az infra-repo határán: ha az app a gitből megy, az IAM pedig a konzolról, a határ lesz a következő outage. Vagy mindkettő git, vagy fogadd el, hogy a rollback fele emlékezet. Kettes csapatnál az emlékezet péntek este szokott elfogyni — pont amikor a vészajtót kinyitnád, és már nem emlékszel, melyik rule-t nyitottad ki délután, és melyiket hagytad zárva szándékosan. Írj utólagos PR-t akkor is, ha a javítás öt perc volt. Az öt perc a gitben öt perc. A fejben jövő kedden már egy másik incidens.
Mit jelent ez neked?
Ha ketten vagytok, ne ArgoCD-vel kezdj. Zárd a state-et, vidd PR-be az infra-változást, tiltsd a pénteki kézi apply-t, és a konzolt minősítsd vészajtónak. Ha van clustered, akkor jön a reconciler. A GitOps a kettes csapatnak az a megállapodás, hogy a jövőbeli éntek képes lesz megérteni, miért van ez a security group. A konzol ezt a megállapodást minden alkalommal felmondja. Írj egy README-mondatot a repo tetejére: „ami nincs itt, az nincs élesben”. Ha ez a mondat kínos, már tudod, hol a drift. A kínos mondat a legolcsóbb incident-prevention, amit ketten meg tudtok írni — olcsóbb, mint egy operator, és őszintébb, mint egy slide a „GitOps-érettségről”. A slide-ot senki nem reverteli. A gitet igen. Ez a különbség a kultúra és a prezentáció között — kettes csapatnál csak a kultúra visz át egy szabadságot, amikor a másik ember nincs a gépnél. Írd le ezt.