• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    MORTAELTH
    MORTAELTH --- ---
    FALLENANGEL: jedeme ve firme gitops asi rok. Neni to jen buzzword, jsem presvedceny ze je to prakticka vec a smer na ktery do par let prejdou vsichni (od rozumne velikosti nahoru). Bude se to jeste rozvijet a posouvat, ostatne jako vsechno v IT, ale ten zaklad zustane. Neni to modla s jasnyma pravidlama, muze to mit mnoho podob, ale to jadro (ridit chovani / zmeny aplikace commitama do gitu, vcetne infrastruktury) to zustane.

    Jak to vypada u nas:
    Primarni nastroj pro infrastrukturu je Pulumi. To je prulom o kterem se take zatim tolik nemluvi, ale bude :) Stavi to na terraformu, u nas to zpusobilo revoluci v tom, ze najednou vyvoj muze ovladat infrastrukturu nastrojema a zpusobem, ktery je jim vlastni. Predtim dochazelo k problemum ze aplikace potrebovala zmenu do infrastuktury, ale infrastrukturu "vlastnilo" OPS (pres Ansible). Pulumi prevedlo terraform do normalniho programovani (maji typescript, go, tusim i php a dalsi)

    mame jedno repo ve ktery jsou moduly pro infrastrukturu (standard)
    a pak mame dalsi repo pro konfigurace konkretniho prostredi. Kdyz potrebujem udelat zmenu (prenastavit aplikaci, updatnout verzi infrastruktury, updatnout verzi aplikace, ...), znamena to upravit to v gitu a dat "pulumi up". Pulumi detekuje kde se stala zmena a snazi se ji naplnit => tzn plny "Desired State" pristup.

    jedeme na Azure a jejich managed Kubernetes.
    MUXX
    MUXX --- ---
    JON: Asi komu se podari udelat zmenu na nejmin pull requestu. Jako vykladam to tu jak nejaky hrdina, ale mame DNS/MAC/IP v gitu a odstranoval jsem ted nejake rok stare zaznamy, kde se odstranilo zelezo, ale DNS zustalo. Takze nejsme dokonali. Zjistoval jsem proc a zjistil jsem ze kolegove mezitim udelali skript na odstraneni hw. Pusti skript a ten jim naseka pull requesty na DNS, monitoring i asset management system. Mergnou, vypnou, odvezou.
    FALLENANGEL
    FALLENANGEL --- ---
    What is GitOps? Extending devops to Kubernetes and beyond | InfoWorld
    https://www.infoworld.com/article/3566555/what-is-gitops-extending-devops-to-kubernetes-and-beyond.html
    JON
    JON --- ---
    MUXX: rozumim - akorat to z GitOps dela pouhej buzzword, protoze jak se to potom lisi od toho co vicemene vsichni mame? Nejake testovani, nejakej tooling pro on-demand deploy, postupy jak resit nestandardni situace, skripty pro bootstrap cisteho zeleza, to je vsechno v gitu.
    Nebo se k tomu da pristoupit tak, ze GitOps je nejakej "ideal" kte kterymu stoji za to smerovat, protoze to prinese spoustu vyhod atd. atd.
    Ja nejak osciluju mezi temahle dvema chapanima :)
    FALLENANGEL
    FALLENANGEL --- ---
    MUXX: To zni jako dobry tema pro webinar ;)
    MUXX
    MUXX --- ---
    JON: Prijde mi ze ten clovek ceka absolutni reseni vseho. My mame procesy, ktere rikaji co se ma stat a podle toho ty tooly implementujeme. Nemame tak dokonaly testovani, abychom po kazdem commitu delali deploy. Deploy se manualne approvne a musi obsahovat kroky jak udelat revert. Kdyz to failne, dostanu echo a musim rozhodnout ja jestli revert nebo hotfix a novy deploy.
    ADMIX
    ADMIX --- ---
    JON: tak to tady nejspis placam kraviny, pac evidentne mate dost srandy sami o sobe :))
    JON
    JON --- ---
    ADMIX: zadna hyperbola :-) pul dne zadna mira - jsme navic lehce paranoidni, takze restart fyzickeho serveru po outage vyzaduje rozsifrovani disku, a k tomu jsou potreba nadpolovicni vetsina opravnenych (plus jsou nejake rezervni klice v trezorech) - no a kdyz to tramtarie2 mezitim zvlada odbavovat, tak neni duvod tahat lidi z dovoleny. :shrug:
    JON
    JON --- ---
    SAMGARR:
    MUXX:
    tak nejsem sam kdo narazil na nejake trable: https://thenewstack.io/more-problems-with-gitops-and-how-to-fix-them/
    Treba zde popisovany rollback kdyz se deploy nepodari - ma se ten rollback stat automaticky (a pak zanest do gitu), nebo se ma (automatizovane) zanest do gitu a na zaklade toho se stat automaticky? Nebo se nema stat nic - protoze ja jsem preci rekl, za tam tu verzi chci, a system bude v divergentnim stavu - co se stane kdyz nekdo pushne dalsi zmenu, ktera je stejne nenasaditelna jako ta aktualni, ale testama prochazi. Kdo takovou zmenu pozna od zmeny, ktera ma stav opravit?
    MUXX
    MUXX --- ---
    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.
    SAMGARR
    SAMGARR --- ---
    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 ;)
    FALLENANGEL
    FALLENANGEL --- ---
    ALMAD: :)

    Argo CD - Declarative GitOps CD for Kubernetes
    https://argoproj.github.io/argo-cd/

    Flux
    https://fluxcd.io/
    ALMAD
    ALMAD --- ---
    Argo sem neznal a nejdřív to na mě vyhodilo tohle Argo, což musim říct, že mě dost vyděsilo :D

    https://argoapp.live/
    ADMIX
    ADMIX --- ---
    JON: haha, jasny :D git bude vzdycky chvili kecat - to je IMHO odpovednost hlavne toho IaC toolingu, aby ti jasne ukazal state of the world a o co se zrovna ted pokousi, a proc to nejde, pripadne proc to trva.
    Mit dependency v tramtarii kde muzes mit pul dne vypadek (chapu ze je to hyperbola) je trochu mimo moji oblast zkusenosti - to jsou casy a vzdalenosti ktery jsou uplne mimo cokoliv co si muzu dovolit :( ale chapu kam tim miris
    JON
    JON --- ---
    INDIAN: hmm, asi lepsi oddil, trochu zavidim.
    INDIAN
    INDIAN --- ---
    JON: jenom ja ... casove tezko rict na clovekodni, koncepce se menila behem vyvoje a ja to delal bokem vedle dalsich projektu... vicemene do pul roku to bylo hotovy
    JON
    JON --- ---
    JON: no stezuju si hezky, ale ve skutecnosti me to bavi :-)
    JON
    JON --- ---
    ADMIX: Ja ten koncept myslim docela dobre chapu, a rekl bych, ze jsem i jeho zastancem.

    Jen jsem uz zazil nejaky hard limits typu - a nenaspinuju a nenaspinuju, pac jste precerpali limit na pocet virtualu / nemate prachy na karte, mame vypadek na cloudovejch loadbalancerech apod.
    Pripadne bezi mi statefull sluzba nekde v tramtarii, a jsem si celkem jistej ze bezi (mistnaci se na ni dostanou), ale od nas je treba pul dne sitove nedostupna - a ted co? Zabit a naspinovat nova nejde, a i kdyby sla, tak to ssebou prinese nejakou ztratu - je lepsi vetsinou pockat, az se to rozjede (ale taky nemusi).
    Takze jsem X hodin v situaci, kdy git keca, a behem te doby se musim ridit i nejakymi dalsimi informacemi, nez z gitu, abych treba neninkrementoval na verzi, ktera s tou sitove nedostupnou nebude kompatibilni.

    A trochu stranou - ta problematika cattle not pets se jen presouva z urovne kontejneru/virtualu na uroven datacentrum/poskytovatel sluzby.
    FALLENANGEL
    FALLENANGEL --- ---
    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.
    JON
    JON --- ---
    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.
    Kliknutím sem můžete změnit nastavení reklam