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?

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

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?

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.

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

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?

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!

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 ]

MUXX: vida :) tak dej vedet, rad zahodim tu obfuskaci, co jsem musel kvuli chybejicimu wildcard searchi delat

URPUTNIK: ano :)

tak zkusim zas z jineho soudku :) verzujete s branchi i maven superpomy? u vytvareni branch je pak problem, ze je potreba superpomy zbuildit explicitne jeden po druhym driv, nez clovek zacne buildit celou vetev .. ale mozna je to tim, ze se na ne odkazujem bez relativni cesty, takze se musi stahovat z nexusu ..

mimochodem, stale hledam nejaky duvody, proc prejit na embedded tomcat/jetty misto standalone tomcatu .. mate nejaky pekny tip na srovnani treba narocnosti na zdroje? asi nejvystiznejsi srovnani tomcat/jetty jsem nasel tady, kazdopadne z toho pro mne vypadlo, ze embedded tomcat/jetty jsou (uz) srovnatelne ..

a jestli embedded, nebo ne, zalezi spis od toho, kdo se vam stara o deployment ..
- standalone tomcat bude asi lip konfigurovatelnejsi na danym serveru ('vypnout, prenastavit, pustit' narozdil od 'vypnout, prenastavit, prebuildit, nahrat, pustit')
- na standalone je mozne pustit vic waru naraz, kdyby to bylo potreba (my u SOA nepotrebujem)
- v deployi bude embedded tomcat cistsi, nemusite se starat o webovy server
- zkusili jsme nejaky testovaci spusteni a tam do dokonce vypadalo, ze embedded zraly vic pameti nez standalone, ale nedelal jsem to ja, tak nevim detaily

neco by jste doplnili?

a jeste, docetl jsem se, ze tomcat v oficialni dokumentaci vyzdvihuje mod_ajp nad mod_proxy, narozdil od jetty, ktery to zminuji obracene .. co pouzivate vy? pokud tam teda mate nejaky loadbalancer ..

a treba to nekomu pomuze, na nexus 3 nezapomente poustet pravidelne ten 'compact store' task, coz je ten, ktery skutecne maze stare artefakty .. vsechny ostatni to jen oznacuji ke smazani :)

mimochodem, stava se vam, ze REST api k Nexus3 obcas funguje podivne? tim jak neumi fulltext search a navic spatne pracuji s verzema u snapshotu, tak nejdriv musim vyhledat vsechny artefakty stejneho jmena a ve vysledcich pak grepem hledam ten spravny .. a stava se mi, ze treba na prvni zavolani vrati 4 stranky vysledku (maji to API navic strankovany :/ ) ale artefakt ve spravne verzi v nich neni a o minutu pozdeji vrati jenom 2 stranky a artefakt tam je ..

MUXX: asi nerozumim :) snazime se o kontinualni integraci a drzet 'build once, run/deploy everywhere', tzn jednou se sestavi a kdyz projdou testy, sype se to do nexusu. Deploy na libovolny prostredi si pak taha posledni verzi z nexusu. Ten kdo je zodpovedny za deploy nic nemusi vedet o buildu a naopak. Ze pouzivame snapshoty misto tagovany verze je nase zjednoduseni, master je stabilni vetev deploynutelna kdykoli a ma tak ma stale stejnou snapshot verzi (vyvijime interni system, takze nepotrebujem 'verzovat')..

URPUTNIK: No ale co resis za problem? Deploy starsich snapshotu do environmentu? Ja se na to vykaslal protoze build bez testu mi na environmentu trva o 20 vterin dyl nez kdyz to budu tahat z nexusu. Takze stahovani finalniho buildu z nexusu nemelo nikdy prioritu k predelani. Zavislosti se tahaji pres maven a npm.

MUXX: zajimalo mne jak stahujete vybuildene zdrojaky z nexusu3 .. protoze maven-dependency-plugin zabere jenom na javovy zdrojaky (nebo bych musel napriklad i do javascript buildu cpat pom.xml) .. a primou url na build poskladat nemuzu (viz gist), protoze pouzivame jenom snapshoty .. kazdopadne jsem to uz vyresil, skutecne jsem to zavolal krz to jejich search api z shellu (vytahnout vsechny, seradit podle buildu, vzit nejnovejsi) .. a nastesti nemusim resit strankovani, drzime jenom 2 posledni snapshoty od kazdy verze ..