JON: Ty to pises jako by git byla firma co se stara o intrastrukturu. Git je zdroj pravdy, ale tooling a procesy si musis udelat sam.

JON: Ten git je pravne jedinej deklarativni zdroj pravdy, skutecnej stav veci te z pohledu toho gitu nezajima - to uz je vec toolu kterej ten kod/predpis/manifest z toho gitu aplikuje.
Kdyz tam budes mit predpis pro Ansible aby na serveru XY vytocil nejake docker kontejnery a shodou okolnosti je server zrovna v plamenech tak ti Ansible, potazmo tvoje CI/CD bude rvat ze je neco v neporadku, ze se danej playbook nepovedlo aplikovat. Pak se uz jen rozhodnout jestli vzit do ruky hasicak nebo commitnout do gitu, ze te server XY nezajima a ze ty dockery chces na serveru XZ ;)

ADMIX: Persistentni storage je persistentni. Tu rozhodne nechces kazdej vikend vytacet znovu :) I kdyz mas stateless deployment tak (temer) vzdycky potrebujes nejaky data ukladat.

JON: V ramci GitOps se prave pouziva Argo, nebo Flux. Ale dovedu si prestavit, ze Ansible, nebo podpobnej automatizacni nastroj udela podobnou sluzbu. Jenom to bude trochu vic prace.

SAMGARR: jo, ale potom ten git neni jedinej zdroj "pravdy" - musim mit este nejakej dalsi tool, kterej mi povi, jaka je situace doopravdy. Kdyz ten stroj politej kafem shori, a my se rozhodnem ze ho uz nepotrebujeme, jak se to dostane do gitu v popisu infrastruktury?
A na zaklade gitu (jedineho zdroje pravdy), si pak nekdo naplanuje, ze muze databazi jejiz jedna replika ma bezet na tom politem stroji, odstranit odjinud, kde potrebuje vic mists (a furt to budr safe). No a pruser je na svete. Je to hodne extremni a zjednoduseny priklad (a tomu problemu se snadno predejde prostym flagem, ze realita neni in sync s gitem) , ale hezky ilustruje ten problem s tim "single source of truth".
Ale jak rikam, jdu si k tomu nacist posledni vyvoj, pac jako koncept mi to prijde super.

JON: Ty v tom gitu mas popsano jaky by ten stav mel byt, ne jaky je. Cesta jak toho stavu dosahnout je pak uz odvisla od toho jake nastroje pouzivas.

INDIAN: Kolik vas to delalo, jestli se muzu zeptat (a jestli to jde nejak odhadnout)? Ty plus dva az tri dalsi lidi, odhaduju.

ALMAD: tam myslim jde o reseni toho odvekeho problemu - ok mam comit s appkou (infrastrukturou, whatever) ktery se ma nasadit - tedy popis stavu v jakym to "ma byt", tak se to nejak samo nasadi, ale ouha - na jeden ze stroju se to nepovedlo, protoze ten stroj nekdo polil kafem, nebo je proste jen chyba v kodu - takze co je v gitu se zacina vzdalovat realite, tomu "co je".
A co ted? Nejakej automat commitne zmeny, aby to situaci reflektovalo?
Ale ja chci aby to tam bylo nasazeny (jen to nejde), az nekdo ten stroj fyzicky vymeni, tak se to tam ma hned nasypat (nejlip samo).
Imo typickej (a zajimavej) problem slepice a vejce.
Musim se ale podivat, jak vyvoj pokrocil s tim Argo a Fluxem, delsi dobu jsem to nezkoumal.

ALMAD: Asi se shodneme na to, ze git je standard pro uchovavani techhle veci (kdyz to nekdo mysli s IaaC vazne).

FALLENANGEL: castecne i pro deployment, ikdyz v detailu ten pull ze serveru nejde primo do adresare kde ty conf soubory sou, ale do /tmp/foo/id-instance a pak se to kopiruje dodatecne odtud ... navic se musi zajistit, aby ten pull tahal jenom instance ktery sou na danym serveru, takze je tam trochu upravena konfigurace gitu pomoci sparse-checkout
nicmene deployment je globalne spis v rezii ansible, je treba delat naky pre/post operace

FALLENANGEL: jo vsechno v gitu. dvakrat za hodinu si to saltmaster pullne z gitu. nektery servery si zmeny aplikuji samy. jinde je potreba jeste manualni approval. mame to hlavne pro klasicky servery, ale dockery v tom budeme delat taky. ono je uplne jedno co pouzijes, dulezity je navrhnout ten process a zacit po castech. zacinalo se s puppet, ale pak se to prehodilo na salt.

v jiny firme to zas mam na jenkins+git. jeden job pro dev build, jeden pro release, jeden pro deploy. cele je to v Jenkinsu jako Jenkinsfile, takze kdyz do toho nekdo vrta, tak mam prehled, protoze to musi delat pres git.

To mi pripomina, ze jsem videl jednou prednasku typka co mel autmatizovany fakt vsechno. Takovym zpusobem, ze na prednasce smazal cely Jenkins. Ten jenkins pak nahodil skriptem, jenkins rovnou si pullnul jenkinsfiles z gitrepa a zbuildoval a pushnul zmeny na web.

RUDOLF: GitOps je smer uvnitr DevOps, kterej pouziva git (nebo jinej verzovaci system) jako single source of truth. Pro infrastrukturu, i pro aplikace, ktery na ni bezi. Pro deployment se pouzivaji nastroje jako ArgoCD, nebo Flux, ktery hlidaji drift na obou stranach a kdyz dojde k nejake zmene, tak upravi prostredi prave podle 'source of truth'. Takze zatimco IaaC je nadefinovani infrastruktury, GitOps je cesta, jak ji implementovat (mimo jine).

INDIAN: To zni zajimave. Takze to pouzivate jenom pro konfiguraci aplikaci, ne pro deployment?

MUXX: A ty Salt playbooky, nebo co to pouziva, mate hostovany a verzovany nekde v repozitarich?

FALLENANGEL: to zní jako normální IaC. A plus immutable koncept. Asi nerozumím té ops části. Napadá mě jen, že ty commity pouští github actions namísto jenkins nebo co kdo používá na runtime automatizace.

FALLENANGEL: mame skoro vsechno pres saltstack. vcera jsem to zrovna pocital - 10k+ instanci. Daji se nad tim nastavit krasne procesy a SRE vidi presne kdo kdy kam hrabnul kdyz neco nefunguje. Mame to nad klasickym datacentrem i "cloudem". co se tyka toho, ze neco neni "production ready", tak to leda produkt a lidi. produkt musi byt napsanej aspon trochu normalne ( https://12factor.net/ ), jinak se to blbe automatizuje. lidi (sysadmini) se musi naucit myslet jako dev/test jinak je to hrozny prasokod.

FALLENANGEL: ja mam v duchu gitops 2 projekty:
prvni - jde o slozity aplikacni konfigurace, cca 400 ruznejch instanci ... je nad tim umele vytvoreny workflow pomoci skriptu aby to bylo user-friendly - zmeny v konfiguracich muze delat i clovek co dela helpdesk a nasledne je validuje clovek z produkcniho oddeleni ... kazdej commit obsahuje timestamp kdy ma bejt dana konfiguraci aplikovana - z cehoz vyplyva ze se ty commity dodatecne tridi aby sly po sobe - takze je to trosku znasilneny ... pipeline v gittlab CI komunikuje s AWX (ansible frontend) a vytvari joby ktery ty konfigurace aplikujou
druhej - konfigurace sitovejch prvku pres ansible ... pro kazdy DC mam zvlast inventory file a group_vars a soucasne mam klientsky konfigurace napric vicero DC, tam je opet zbastlena cast (tentokrat spis nad ramec ansible nez gitu)

jinak vseobecne se snazim mit vsecko IaC, takze i zbytek infra co mam v rezii je v gitu taky samozrejme (coz se samo tyka i kontejneru abych nebyl OT;))

FALLENANGEL: Primarne AWS Cloudformation. Pak Helm pro K8s.

SINC: A jaky nastroje pouzivate?

INDIAN: Jde mi spis o obecnej nazor, nez ze bych mel na mysli konkretni pouziti. Jeden muj zakaznik planuje mit vsechny definice infrastruktury i kod a nastaveni aplikaci v gitu a vsechno vcetne spravy ridit pres updatovani gitu. Dalsi zakaznik premysli nad docela zajimavym konceptem Dev clusteru, kdy vsechno bude opet nadefinovany v gitu a kazdej tyden stavajici cluster odstrani a z gitu vytvori novej, cimz se vyhnou nejruznejsim problemum, ktery muze hnijici Dev cluster prinest.

Na druhou stranu slycham, ze GitOps jeste nejsou 'production ready', chybi poradnej tooling i standardizace workflow.

FALLENANGEL: pro jaky pouziti? ja neco v podobnym duchu provozuju, ale sou to mozna dost specificky zalezitosti...