Sziasztok!
Lehet a nem tökéletes a téma címe, de valami ilyesmire keresek megoldást, vagy inkább ötletet. Adott egy olyan környezet ami _még_ nem Kubernetes, de már konténerizált. Podman pod-ok, GIT-ből jön a konfiguráció (git-sync), tehát mondhatjuk kezdetleges GitOps-nak is akár. A problémám az, hogy addig oké, hogy a konfiguráció Git-ben van és automatán "lemegy" a megfelelő konténer konfig volume-jára. A probléma az, hogy adott egy alkalmazás, amit tekintsünk a konfigurációs repositorynak, aminek egy API kimenetéből kellene a konfigurációt generálni és a git master-be pusholni, hogy onnan továbbmenjen a megfelelő konténerbe.
A régi világban ez úgy volt megoldva, hogy egy ansible playbook az adott szerverre legenerálta a konfigot jinja template-ek alapján és kész, de akkor ugye nem volt beiktatva a workflow-ba a Git, mint konfig tároló.
Egy ilyen egyszerű konténeres felállásban van valami jó megoldás erre h. a konfiguráció generátor (legyen az akármi) beküldje a tárolóba a konfigurációt? Akár Ansible, akármi más ötlet jöhet. Tudom, hogy problémás az h. automatán történjen olyan h. "merge to master", de már ez is sokkal jobb mint adott vm-en mindenféle tracking nélkül szerkesztgetni a konfigot.
A lényeg az, hogy van olyan része a konfignak, amit kézzel szerkeszt az üzemeltetés, és lenne néhány olyan ami automatán generálódik valamilyen triggerre.
Remélem kb. érthetően leírtam a problémám :)
Köszi előre is mindenkinek!
Hozzászólások
Hat nekem kicsit a terminologia zavaros, hogy most akkor az egyik kontenar config repository (ala. git) vagy csak egy API, ami egy POST/PUT-ra git push-ol?
Mert akkor csak annyi kell, hogy az API csinal egy git pull-t, atirja amit kell, majd egy git push. Mondjuk kerdes hogy hogyan kezelitek az API-ban a conflict-okat, mikor ketten is azonos idoben valtoztatnak adott konfiguracion. Az API vegulis meg tudja oldani, na de melyik konfig lesz a valos?
De amugy en erre egy workflow eszkozt hasznalnek, mint Jenkins, github/gitlab piplines, etc, whatever
Lehet kicsit sok lett az infó és ezért zavarosnak tűnik.
Sztem kb. jól érted, de nagyon röviden: adott egy GIT repo, amiben kézzel is szerkesztünk néha-néha, de automatizáltan is szeretnénk benne változtatni egy alkalmazásból.
Ez most úgy van h. az alkalmazás "megpingeli" az Ansible Towert, ami elindít egy playbookot, a playbook lekéri a konfigot jsonben és elkészíti belőle a jinja template alapján a konfigot, amit kirak egy VM-re.
Gyakorlatilag a VM-re kirakás helyett kellene GIT-be commitolni. Hosszabb távon én is pipeline-ban gondolkodom (a végeredmény meg Kubernetes ConfigMap lenne majd), de most ezt kéne valahogy nem túl gány módon megoldani. A conflict problémakört ismerem, de szerencsére nagyon minimális manuális módosítás van, így a conflict kezelést most akár el is engedhetjük, mert leginkább az automata által generált rész változik.
Kubernetes COnfigMap is jöhet _majd_ git-ből, ArgoCD lesz a barátod (vagy bármely más ilyen, nekem ezzel van tapasztalatom).
A tényleges problémára nem megoldás az, hogy a config generátor ugyanúgy commit-ol mint a kézi megoldás. Git kliens sok rendszernek része, elfogadott megoldás. A commit során pedig dönthettek, hogy forcepush a main-re (ilyen felhasználóval git-tel a tool) vagy az is csak egy MR/PR-t csinál, amit egy üzemeltetőnek jóvá kell hagynia.
Példaként hozhatom valamelyik i18n tool-t (weblate, lokalise), ami repo-k i18n.js fájljai módosítgatja, majd arról MR/PR-t csinál.
Igen, egészen konkrétan az ArgoCD a terv, máshol üzemeltetek ilyesmi setupot, de ott az alkalmazás és a körítés egészen más, a konfig nem változik, gyakorlatilag egyszer kellett jól összerakni a ConfigMap-eket mindenhez és azóta kb csak frissítgetünk mindent és működik.
Egyébként ez a rendszer is oda tart, csak kisebb lépésekben, hogy szociolazidáljon az üzemeltetés is kicsit a konténerek világában, meg a filozófiával h. nem matatsz a prodban, repoban van a konfig, stb. Ezt egyszerűbb egy ilyen faék egyszerű Podman-es környezetben csinálni, mint egy meglehetősen bonyolult Kubernetesben, ráadásul onprem.
Picit ambivalens amit írsz, de lehet csak nem értem: "nem megoldás az, hogy a config generátor ugyanúgy commit-ol" vs elfogadott megoldás és a weblate is csinálja. Akkor most megoldás mégiscsak? :) Btw. a weblate-et ezer éve használtam és tényleg így ment már akkor is h. a repo-ba kommitolt automatán.
Alapvetően az jutott eszembe h. mikor generálódik a konfig akkor forcepush Ansible-ből, ahelyett h. kirakja a template-et a VM-re. Csak gondoltam hátha van erre valami elegánsabb megoldás, amit még nem láttam.
A "nem megoldás az, hogy a config generátor ugyanúgy commit-ol?" a végén kérdőjellel már azt jelentette volna, amit szerettem volna közölni, azaz hogy ez lehetne az egyik út.
1. Legyen gitops.
2. Kézzal oda kell betenni mindent.
3. Lehetne-e automatizálni szigorúan gitops-ban dolgokat?
Én ezt a logikai utat jártam végig.
Igen, így kb. értem a gondolatmenetet :)
Az a helyzet h. egy utat kell végigjárni, aminek ez az első lépése. Lassan építkezünk, hogy belerázódjon mindenki, meg nyilván a változások mindig kockázattal is járnak. Szóval igen, az elképzelés h. legyen GitOps, kézzel töltjük, de mégiscsak kell automatizmus is. Aztán meg jöhet a K8s, meg a többi szépség, amivel ez már kevéssé lesz idegen.
Hat ha csak ez a gond, akkor a VM kirakasa helyett mehet a git_push az ansible-lel. A file-t tudjatok igy csak a local repoban kell folulirni a rendered content-el es kesz is.
En nem irnek egy uj valamit akkor ehelyett, hiszen csak egy lepes modositasaval megh is oldhato.
Igen, csak gondoltam hátha van valami szebb megoldás rá, mert ahogy már írta is valaki, nekem is a conflict kezelés, meg a többi dolog ugrott be, még ha ennek nagyon minimális az esélye is, mert automatán generált konfigban nincs kézzel matatás alapvetően, már most sem.
Egyébként pont a conflict kezelés és a járulékos problémák miatt nincs igazán elegáns megoldás erre Ansible-ben sem, értsd: nincs olyan modul aminek azt mondod h. git force commit and push, leginkább CLI-vel kell bűvészkedni egy working copyn.
Nem pontosan arra válasz amit kérdeztél, de Terraform és ArgoCD házasítására most jött szembe egy poszt (elég a végére ugrani, gyakorlatilag a Terraform által generált IP címeket még a Terraform egy helm values fájl képében beküldi az ArgoCD-nek): https://medium.com/@Irori/terraform-and-argocd-in-beautiful-harmony-73c…
Ugyan (még) nem ezt próbálod megcsinálni (én egyébként lehet, hogy megugratnám a csapattal az on-prem Kubernetest podman helyett, csak az elején fáj :) ), de hátha inspirációnak jó.
Ez tök jó megoldás így ránézésre, majd alaposabban átolvasom.
Azért nem akarom egyben megugrani a váltást, mert erre is limitált nyitottság van és nagyon oldworld hozzáállásból érkezünk. Első körben ennyi új technológia elég lesz (Ansible, GitLab, Podman). Ha még Kubernetest is rá akarnám erőltetni az üzemeltetésre, akkor ugye a lista bővülne Kubernetes, Helm, Kustomize, ArgoCD, netán Terraform elemekkel. Így két részletben meg lehet lépni és talán kevésbé fáj az átmenet.
Tudok olyan helyről, ahol a selfhosted k8s-t megelőzi 2-3 évnyi AWS, edukációs célból.
Ez most itt nem opció sajnos. Annál jobb evolúciót meg nem tudok kitalálni h. VM -> "mezítlábas" konténerek/pod-ok -> K8S.
Fogalmazzunk úgy h. megörököltem egy "jó stabil" rendszert, csak ennek az az ára h. nem változott benne semmi az elmúlt 10 évben kb., csak a komponensek verziói. Viszont már eredendően is voltak ebben a koncepcióban hibák és sok-sok single point of failure. Ezt próbáljuk behozni.
Én általában low-budget megoldást keresek, és nemrég futottam bele a kube-hetzner projektbe, ami egy elég jónak tűnő K8S megoldás a Hetzner felhőjéhez: https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner
Címszavakban:
- SUSE MicroOS-re épül (ez kb. a K3OS szellemi örökösének tűnik)
- K3S-t használ
- Automatikusan frissíti magát
- Támogat Longhornt és Hetzner CSI-t
- 3 féle CNI-t támogat, de engem csak a Cillium érdekel ebből :)
- Cilliummal még Egress kontrollert is támogat
Ami egyelőre talán hiányzik belőle az a Hetzner fizikai szervereinek támogatása, de a Github issuek alapján lenne fogadókészség a fejlesztőkben, ha valaki ilyen PR-ekkel árasztaná el őket.
Hogy mi köze ennek az on-prem K8S-hez? Az, hogy vagy akár ebből, vagy csak a MicroOS + K3S kombóból kiindulva elég kellemes on-prem K8S megoldást össze lehetne kalapálni.
PS: Mondom ezt úgy, hogy 1998 óta Debian / Ubuntut használok Linuxként kb. mindenhol, de valahogy az Ubuntu Core + Snap irány nem annyira jön be - próbálnám használni, de mindig szembejönnek hülye limitációk.
Egyébként ez egy egészen punk dolog lenne és tetszik is a megközelítésük. Sajnos ahhoz ami nekem kell kicsit túlságosan is punk, privát projektben biztosan kipróbálnám.
Durva mennyire kő alatt élek, hogy alig értek valamit a posztodból. :)
Csak h. álljon itt a "megoldás". Végül az lett h. az Ansible playbook az adott konténer hoszton pull-ol egyet h. mindig a friss repoban matasson. Ott matat a meglévő VM-ekre szabott taskokkal, amik kaptak egy delegate_to -t. Ezen felül minden task kapott egy notify: commit and push -t, a végén pedig egyszer lefut a working copyban egy force commit and push, így felmegy a változás a gitlab szerverre.
Onnan meg kubernetes git-sync konténer kikapja, majd "sidecarként" tcp-n betol egy reload-ot a service-nek aki alá pakolássza a konfigurációt.
Nem a legszebb, de nevezhetjük fapados gitopsnak.
Itt mintha kicsit túl lenne komplikálva és/vagy a meglévő megoldást próbálná meg valaki áttenni Kubernetesre. Ez nem javasolt. Használni kell az adott rendszer lehetőségeit és igazodni/transzformálni kell a meglévő megoldást.
Én a fenti megoldás mellett azt mondanám, hogy at kéne gondolni ezt a túlbonyolított struktúrát, ami VM-en lehet jó megoldás volt.
Én íratnék a fejlesztőkkel (vagy megírhatja az üzemeltető is) egy egyszerű config management appot, ami annyit templatek alapján legenerálja a konfigurációt (git push is beépíthető, de akkor változna a funkcionalitás és máshonnan közelíteném meg a dolgot), majd betolja egy ConfigMap-ba vagy Secretbe a konfigot, amit például annotationnel lehet triggerelni , hogy az app induljon újra, mert a konfiguráció megváltozott.
Amennyiben GitOps irányba szeretnél menni, akkor ha már minden Git-ben van, akkor a neked tetszőleges GitOps tool (FluxCD, ArgoCD) megoldja a problémák többségét és elég lehet egy egyszerűbb config management microservice és lehet teljesen független az Apptól akár. A deploymentet lehet finomhangolni Helm chart segítségével akár.
Így a Kubernetes node-k nem lesznek tovább terhelve és csak azzal foglalkoznak, ami a feladatuk.
Természetesen ez nem egy máról holnapra megoldási lehetőség, hanem egy út ami felé javasolt elindulni, hogy később is fenntartható legyen a rendszer.
Egészen pontosan ez a cél amit leírsz, ezért került a konfig Git-be (minden tiltakozás ellenére). Viszont ezért nem lesz most Kubernetes, ArogCD, Helm, mert ez mind-mind az a kategória amit a meglévő mérnökcsapatnak el kell tudnia üzemeltetni. Egy podman környezet ehhez képest viszonylag egyszerű, de még ez is az a kategória amit első blikkre nehézkesen ért meg aki az elmúlt 10 évet 200 VM-el való napi küzdelemben élte.
Ezen kívül az a gond h. ha szolgáltatsz X usernek, akkor nem mondhatod azt h. akkor bocs, 2 nap szünet, mert költözünk Kubernetesbe, így viszont látok egyfajta útvonalat odafelé. Ha már a workload nagyobb része végre konténerizálva van, megy az alapvető üzemeltetés, akkor már h. Podman, Kubernetes, Nomad, majdnem mindegy is lesz. Remélem :fingers_crossed:
Sajnos néha muszáj áldozatokat hozni, hogy egy komoly infra átállás ne vezessen üzemeltethetetlenséghez és/vagy lázadáshoz, stb,stb.
Ez most nagyon nem mérnöki és IT szemlélettel készült post volt, csak sajnos a való életben ezeket a faktorokat is figyelembe kell venni, pláne KKV-nál, ahol nem az van h. berántok egy olyan csapatot, aki majd az általam elképzelt tuti megoldást azonnal üzemelteti is.
Ahol az Ansible is nehézkesen indul be és 2 éve még devops-1,2,3.sh volt a megoldás mindenre, ott ez is nagyon komoly előrelépés. Ahhoz képest ennyi "hack" sztem belefért most. Aztán jöhet az amit leírtál. Baby steps :)