• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    RUDOLF
    RUDOLF --- ---
    MORTAELTH: za mě je to furt jen IaC a devops jen tooling se vyvíjí. Ale po téměř roční zkušenosti, že jsme v enterprise psali python wrapper kolem terrafromu, který řešil multiaccount, multitenant appraoch, kde máme koncept jednoho prostředí v kterým je n+ užitavatelských prostředí. Mi Pulumi přijde že je to správný řešení IaC v cloudu. A ústup od deklarací mi dává smysl, už z principu, jaký monstrum jsem tím wrapperem TF vytvořili:-)
    MORTAELTH
    MORTAELTH --- ---
    2 odpovědi+2
    v cesku je devops kapacita Tomas Kubica. Jeho clanky byvaji dost podrobne na spoustu temat. doporucuji jeho blog:

    Infrastructure as code v Azure: Bicep (ARM) vs. Terraform vs. Pulumi vs. Crossplane - Tomáš Kubica
    https://www.tomaskubica.cz/post/2021/infra-as-code-azure-srovnani/
    MORTAELTH
    MORTAELTH --- ---
    1 odpověď
    ALMAD: a taky uz se od terraformu postupne odvazbuji. Jejich SDK byl puvodne automaticky konvertovany terraform. Ted treba pro Azure uz ale maji novou knihovnu, ktera je generovana z Azure ARM template. Tzn maji v rozumne dobre pokryte 100% azure api a nejsou zavisly na terraformu, ktery ma vetsi zpozdeni
    MORTAELTH
    MORTAELTH --- ---
    ALMAD: nejvetsi vyhoda je vyuziti evoluce programovacich jazyku a toolu kolem toho. Vyuziti typovosti, interfacu, atd.

    a ten bonus sideffect u nas bylo zapojeni vyvojaru do infrastruktury. Ucit se ansible / terraform byl problem.
    ALMAD
    ALMAD --- ---
    2 odpovědi
    MORTAELTH: Ad Pulumi, jaký to má výhody proti terraformu?

    Já mám většinou pocit, že deklaarativní tooly maj omezenou flexibilitu a v nějakej moment do něj lidi začnou rvát imperativní funkce aby se nezbláznili, ale přijde mi, že v TF to s modulame et al funguje rozumně dobře a zrovna pro účel deklarace zdrojů mi deklarativní přístup přijde...odpovídající?

    A jenom ta struktura, rozumim tomu dobře že jsou pořád oddělená repa pro definici kódu a definici infrastuktury? (což mi přijde rozumný, jenom ze stránek Pulumi to dává trochu jinej dojem)
    INDIAN
    INDIAN --- ---
    +1
    MORTAELTH: dik za tip!
    MORTAELTH
    MORTAELTH --- ---
    JON: gitops je principialne svazany s tim ze prostredi (bezici instance nejake aplikace) je plne popsane a konfigurovatelne gitem. + do toho nekdo radi automatiku provadeni zmen (git push spusti pipelinu, ktera tu zmenu zajisti)
    MORTAELTH
    MORTAELTH --- ---
    3 odpovědi+6
    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 --- ---
    +1
    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 --- ---
    2 odpovědi
    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 --- ---
    2 odpovědi
    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 --- ---
    1 odpověď+2
    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 --- ---
    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?
    MUXX
    MUXX --- ---
    1 odpověď
    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 --- ---
    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/
    Kliknutím sem můžete změnit nastavení reklam