• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    SPACEANGELContinuous integration, App Deployment
    ADMIX
    ADMIX --- ---
    WOODMAKER: CI/CD :)
    WOODMAKER
    WOODMAKER --- ---
    A máte nějaký způsob, abych už jednou vydanou image už nikdy neztratil? Abych ji jako omylem nepřepsal.
    JON
    JON --- ---
    URPUTNIK: ok, jasny - ale ten build z mavenu by mel bejt 100% deterministickej podle dodanejch zdrojaku, ne? Ale chapu, ze pro sichr to tam jeste zazalohujete..
    Jinak presne jak rika ZOID - protoze (s dockerem) i minula verze byla nasazovana pomoci image, tak je automaticky zazalohovana tim imagem.
    ZOID
    ZOID --- ---
    URPUTNIK: Ta „původní verze" může být otagovaná už z buildu. Takže by to pak odpovídalo tomu spustit bud image:puvodni_verze nebo image:nova_verze.
    Osobně se domnívám, že je v produkčním prostředí výhodné vždy explicitně specifikovat tag určující verzi. Předejde se tak nepříjemným překvapením.
    Osobně používám k tagování část commit hash, abych si svázal bežící službu s kódem.


    URPUTNIK
    URPUTNIK --- ---
    JON: v gitu jsou zdrojaky, maven to zbuildi a nasype do nexusu .. vysledny binarky uz do gitu nesypem ..
    JON
    JON --- ---
    URPUTNIK: proc tam mate zalohu minule verze? ta by mela byt v gitu, ne?
    URPUTNIK
    URPUTNIK --- ---
    jsem v noci nemohl spat a zamyslel se nad deploymentem .. ted (bez dockerizace) nase deployment skripty nejdriv zalohujou puvodni verzi, pak ji premazou novou verzi a pusti ji .. kdyz je problem, clovek se vrati k zaloze ..
    rekneme ze bychom to dockerizovali a zdrojaky budou zabaleny uvnitr image .. jak se "zalohuje predchozi verze", kdyz se budem bavit o imagich? zatim mne napada vygenerovat nejaky unikatni id (ktery odpovida instanci deploymentu), tim otaguju stavajici image, pullnu novej, pustim ho .. kdyz bude problem, aktualne pusteny vypnu a pustim ten puvodni pres tag .. tak nejak?
    JON
    JON --- ---
    ADMIX: aha, tem filosofickejm duvodum rozumim, to je celkem jasny a pochopitelny.
    me slo spis o to, ze ten pripad, kdy to pouziju jako deployment mechanismus a data ukladam do mountovaneho volume, je taky nedoporucovany. Me tam napada jen nadbytecna vrstva mezi databazi a diskem, ale to mi prijde jako malej duvod proti.
    kazdopadne stejne pouzivame db v dockeru na development, a na produkci jsou db, kafky apod. normalne instalovane.
    tak kdyby i nekdo dalsi vedel proc se tomuvyhnout, nebo jaka rizika hrozi, tak by me to zajimalo.
    ADMIX
    ADMIX --- ---
    JON: To je takovy tema na delsi povidani :)) Ale pro me osobne je potencialni problem treba to, ze kontejner v ramci beznejch deploymentu typu kubernetes je zavrenej do cgroupy s jasnyma limitama, a pokud ti treba databaze vybehne v pameti, tak kontejner dostane OOM a nazdar.
    A deployment typu "vezmu si celej stroj a do nej si pustim jeden kontejner bez omezeni zdroju a mimo scheduler" pro me neni dobrej priklad kontejnerizace, ktera by (opet podle me) mela bejt dynamicka, immutable a co nejvic stateless, aby byl ten system schopnej reagovat rychle a bez dependenci.
    Dalsi vec je ze databaze obvykle neni neco, co budes zapinat a vypinat v ramci autoscalingu.

    Asi by se dalo uvazovat o kontejnerovy databazi ciste jako deployment mechanismus, ve smyslu ze to spusti nakej skript z cloud-initu tim, ze stahne docker image a pripoji si nakej EBS volume, ale s tim popravde zkusenost nemam.

    V minuly praci jsem delal prototyp docker image pro developery, kde meli oracle databazi v kontejneru, kterej trval par minut stahnout a spustit, na dev ucely uplne v pohode.

    Zadnou vetsi zkusenost bohuzel nemam, muj projekt v minuly praci management utratil jeste v postylce, a v soucasny praci jsme sice The Cloud, ale interne se jedou stary, stabilni systemy z dob, kdy kontejnery jeste nebyly :)
    JON
    JON --- ---
    ADMIX: o problemech s databazemi v kontejnerech jsem slysel, ale informace ktere k tomu mam jsou takove "kargokulticke": proste to nedelejte, je to spatny a shnijou vam nehty na nohou. you were warned.
    Mas k tomu nejaky blizsi info? Nerkuli snad osobni zkusenost?
    ADMIX
    ADMIX --- ---
    URPUTNIK: Pro me osobne je diskutabilni uz samotna databaze v kontejneru, ale jinak obecne cokoliv co potrebuje persistenci (mimo databaze treba MQ, veci typu grafana nebo prometheus) musi mit namapovanej volume do kontejneru, pak to jde
    URPUTNIK
    URPUTNIK --- ---
    ted mne napada .. nase aplikace je tvorena z nekolika service/image, ktere se navzajem potrebujou, jedna z nich je databaze .. predpokladam ze u databazoveho image v podstate nema smysl "balit" databazi dovnitr do image (mazimalne u D z predchozi odpovedi), protoze jinak neprezije databazovy obsah produkcni release (~ swap image) .. jsem mimo?
    URPUTNIK
    URPUTNIK --- ---
    WOODMAKER: ahoj, mam mozna jeste min zkusenosti nez ty, ale moje zacatecnicka predstava je, ze:

    a) kontejner s OS (v tvem pripade napr alpine + python), kde muze aplikace bezet
    b) developer image z a, ktery ma navic primountovany adresar zvenci (a mozna napriklad i SVC), v kterem muze vyvojar aplikaci upravovat a zkouset jak bezi v kontejneru ..
    c) deployment image z a, ktery obsahuje enavic i zdrojaky
    d) integration test image z c, proti nemu se budou poustet integracni testy apod, protoze tim se ten image 'zaspini', takze bych ho pak nechtel nasazovat do produkce ..

    zjednodusene, A je definice prostredi, B je A pro vyvojare, D jde na testy driv, nez C pujde do produkce
    WOODMAKER
    WOODMAKER --- ---
    Ahoj ahoj, máme zdrojáky python služby v adresáři na hostu. Adresář je pomocí `docker run ... --mount type=bind...` připojený zároveň do "runtime containeru", ve kterém ta služba jde otestovat a spustit. Každá služba má specifický runtime container, každý runtime container je závislý na common containeru. Mountování používáme, abychom mohli na hostu upravovat kód a zároveň ho spouštět v containeru (nebo naopak).

    Ale teď bych rád, aby šel runtime container i s aplikací někam deployovat. Ale ta aplikace není v containeru, je jen připojená. Jak tohle vyřešit?

    Napadá mě release runtime containeru a následné vytvoření a release "deployment containeru", který by byl na runtime containeru závislý a navíc by měl v Dockerfile zadefinované, že má udělat `COPY zdrojáky`, `RUN make build`, `RUN make check` a nakonec `ENTRYPOINT make run`.

    Docker se teprve pomalu učím a zatím nevím nic o deploymentu ani o vrstvách, které spravují docker containery a fakt si nejsem jistý ničím okolo, tak bych rád Vaše rady. Nelíbí se mi, že takhle budu mít pro tu službu v registru dvě image - v registru by stačila "deployment" image. Přemýšlím nad tou věcí dobře? uniká mi něco podstatného? Děláme při tvorbě environmentu nějaké zásadní chyby? Děkuju za každý tip.
    ADM
    ADM --- ---
    DWICH: u nas delame ze testy bezi pouze na feature-branch (v docker image), pokud projdou, tak je mozno branch merge do master, a na masteru je uz jina build procedura bez testu, ktera vyplivne doker image obsahujici kod z masteru.
    jinymi slovy, je jina build procedura pro CI build (s testy) a finalni build
    MICTECH
    MICTECH --- ---
    DWICH: Best practice je urcite to co popisujes. Ze pokud projdou testy, tak se build resp. docker image oznaci jako OK.

    Musi ty testovaci data nebo dalsi veci obsahovat ten image nebo muzes vzit image a do nej tyhle veci nahrat a pustit testy, pripadne vytvorit testovaci image, ktery bude dedit z toho buildnuteho?
    DWICH
    DWICH --- ---
    Zdravíčko vespolek, dotaz ohledně best practices. Píšeme kód v pythonu, řekněme knihovny a aplikace. Ty chceme průběžně testovat po každém commitu, proto máme docker image s verzí pythonu 3.6 a 3.7. Používáme Bitbucket Pipelines, po commitu se kód automaticky nahraje do docker image, tam se spustí testy, a to pro verzi py36 a v dalším docker image pro verzi py37. Vývojář hnedka ví výsledek.

    Každá knihovna nebo appka může mít seznam závislostí v requirements.txt, které se instalují během testu. Během testu se nebuildí docker image s tou appkou, jen se doinstalují závislosti, spustí testy a zjistí výsledek.

    Když test projde, tak víme, že ta appka neobsahuje chyby a že je schopna běžet v tom obecném docker image. Kdybychom ji chtěli nasadit, tak ji buildneme jako docker image a mělo (!) by to fungovat. Jenže během toho buildu na míru se může něco stát jinak a už to není úplně bezpečný.

    Přijde mi lepší, když se vybuildí docker image přímo s tou aplikací, s tou konkrétní verzí. Pak se spustí testy a když testy projdou, tak se ten buildnutej image označí za OK a může se později nasadit, nic na něm se už měnit nebude.

    Ale i tady cejtím pár nevýhod - pro testy ta knihovna/aplikace může potřebovat nějaký testovací data nebo další věci, který nejsou potřebný pro provoz - pro provoz stačí opravdu jen kód. A tyhle věci navíc by zbytečně byly součástí toho docker image nebo by se po testech musely z toho docker image nějak mazat (?)

    Tak jsem se chtěl zeptat, jak tohle řešíte. Díky!
    URPUTNIK
    URPUTNIK --- ---
    MUXX: jak to dopadlo?

    a z jineho soudku, poskladal jsem par dotazu na rozhrani docker/CI, zatim v docker klubu .. ocenim kdyz odpovite tam, at to nemusim kopirovat :) [ URPUTNIK @ Docker a kontejnery ]
    URPUTNIK
    URPUTNIK --- ---
    MUXX: vida :) tak dej vedet, rad zahodim tu obfuskaci, co jsem musel kvuli chybejicimu wildcard searchi delat
    MUXX
    MUXX --- ---
    tak to vypada ze Nexus3 ma konecne search:
    Search Improvements Available in Nexus Repository Manager 3.14
    https://blog.sonatype.com/search-improvements-coming-to-nexus-repository-manager-3
    O API se teda primo nezminuji, ale zkusim to pristi tyden asi upgradnout a vyzkouset.
    Kliknutím sem můžete změnit nastavení reklam