• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    VELDRANE
    VELDRANE --- ---
    MORTAELTH: Problem Tomase je trosku v tom ze je zamestnanec MS a tak imho dost tlaci Azure a ekosystem kolem nej, i kdyz je to nepochybne hodne chytrej typek.
    RUDOLF
    RUDOLF --- ---
    Hele a co porovnání TF CDK a pulumi? Máte někdo zkušenosti?
    ALMAD
    ALMAD --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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?
    Kliknutím sem můžete změnit nastavení reklam