• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    Docker aneb přístupný provoz kontejnerizovaných aplikací
    Docker(Hub), Compose, Swarm, boot2docker, DevOps, LXC, ECS, TumTum a jiné buzzwordy
    Bezpečnost v prostředí kontejnerů
    Related: automatizace [ Centralizovaná správa stanic a ostatních prvků v síti konfigurace/inventarizace/instalace/aktualizace/zalohovani ]
    rozbalit záhlaví
    JON
    JON --- ---
    1 odpověď
    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?
    SAMGARR
    SAMGARR --- ---
    1 odpověď
    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 --- ---
    1 odpověď
    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 --- ---
    1 odpověď+1
    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 --- ---
    1 odpověď
    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 --- ---
    2 odpovědi+1
    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 --- ---
    3 odpovědi
    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.
    ADMIX
    ADMIX --- ---
    2 odpovědi+3
    JON: to co pises je presne duvod proc kontejnerovy deploymenty potrebujou bejt cattle, not pets. Neni to ciste jen o kontejnerech (taky to v praci delam, na urovni VM), ale zaklad je ze kdyz se cokoliv stane (git ti vyleje kafe do virtualu) tak prvni vec co udelas je ze ten virtual/kontejner vyhodis a roztocis novej, z image kterej vis ze je funkcni a otestovanej (system testy, UAT, whatever).
    Ma to zabavny edgecases (treba jak moc chces IaC pro persistent resources jako DB nebo disky), ale kdyz mas stateful a stateless spravne oddeleny, tak kazdej rozumnej orchestrator umi delat to cos napsal, tj. kdyz se nekde neco nepovede, zrecyklovat a zkusit znova - a ty jen popises jak chces aby to vypadalo jako to bude hotovy, jak pise SAMGARR.
    SAMGARR
    SAMGARR --- ---
    1 odpověď
    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.
    JON
    JON --- ---
    1 odpověď
    INDIAN: Kolik vas to delalo, jestli se muzu zeptat (a jestli to jde nejak odhadnout)? Ty plus dva az tri dalsi lidi, odhaduju.
    JON
    JON --- ---
    2 odpovědi
    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.
    FALLENANGEL
    FALLENANGEL --- ---
    ALMAD: Asi se shodneme na to, ze git je standard pro uchovavani techhle veci (kdyz to nekdo mysli s IaaC vazne).
    MUXX
    MUXX --- ---
    +1
    ALMAD: Jsou odbornici co to treba cely napisou jako bash/groovy v jenkinsu a historii kodu resi zalohovanim serveru kde bezi jenkins. Videl jsem i jiny enterprise reseni ktery melo vlastni “VCS” a dohledat tam zmeny bylo peklo.
    ALMAD
    ALMAD --- ---
    3 odpovědi+1
    Mě nenapadlo, že by se IaaC dělalo jinak, než v gitu nebo ekvivalentu...kde ten kód jinak leží?
    INDIAN
    INDIAN --- ---
    1 odpověď
    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
    MUXX
    MUXX --- ---
    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.
    FALLENANGEL
    FALLENANGEL --- ---
    2 odpovědi
    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?
    Kliknutím sem můžete změnit nastavení reklam