URPUTNIK: a tech pripravenych image bude samozrejme vic, protoze db bude potrebovat neco jineho, webovy kontejner taky atp ..

HOUMLES: ono to ani nedava smysl treba v kubernetes, tam se vsechny kontejnery restartem mazou, a upravu kodu v bezicim kontejneru bez restartu stejne neudelas (jen kdyz tam mas nejakej pid 1 proces manager). use case stateful kontejneru neznam (datova persistence je neco jinyho)

ADM: aha, tak ok, ja to tak z toho tvyho textu pochopil :)

ADMIX: ale jo, to asi zni rozumne. Demokracie je v takovym pripade nepouzitelna ;-)

ADMIX: ted se asi chytam v pohode;
jasne, tak to i pouzivam, mam jakysi base image, ktery pak pouzivam dal.
Situace je pomerne velmi jednoducha, existuje jeden base image z ktereho je postaveno par kontejneru.

Jen porad mi neni jasne, jak to bude resit muj problem s tim, aby to vevnitr bylo aktualni. Spolehat se na to, ze lenivi developeri neco nekdy udelaji - tak to moc nelze; developerum je u prdele, ze to, co tam jede, je zastaraly, jde jim primarne o vlastni pohodli, co si budeme nalhavat. Resi si jen svuj pisecek (coz castecne i chapu)

Takze je jednak potreba, at uz behem buildu nebo tak, ze se zkontroluje bezici prostredi - zjistit, ze neco neni aktualni a vyreportovat to v dostatecne nahlas tak, aby se to nasledne vyresilo.

ADM: tak to si rozumime :D

ADMIX:
HOUMLES:
tak priznam se, ze varianta ze by to nekdo delal v bezicim kontejneru, me vubec nenapadla kvuli tomu ze to je nesmysl, myslel jsem samozrejme v build imagi

ONLINEQUE: tak nejjednodussi priklad je, ze mas proste userland se vsim vsudy, kterej si buildis jednou za tejden z upstream repa, co si natahne par RPM, nejaky pip moduly a nasere nejaky veci do /etc: base-os:latest, base-os:20200610
a pak mas tu samotnou aplikaci, ktera ty veci pouziva, ktera se buildi v CI, treba app:latest, app:commitId

ted nevim jak je to v dockeru, FROM?
v aplikaci mas v repu docker file kterej zacina FROM base-os:20200610 a ten ti buildi po kazdym commitu app:latest kontejner, kterej pokazdy pouziva ten samej base-os (takze ten nacachujes jednou a pak uz jen updatujes ten app)

a jednou za tejden, za mesic, nebo kdyz se to developerovi chce delat, tak udela commit co updatne tu app FROM dependency na FROM base-os:20200714, a tenhle novej chain pak prozenete testama apod.

To je takovej nejjednodussi priklad multistage buildu kde si drzis platform image nezavisle od aplikace, a aplikace si definuje ten FROM base image, na kterym pak certifikujete/testujete/rolujete.
V zavislosti na tom jak vase appka vypada se to da rozbit do mnohem vic komponent, muj priklad z $job-1 byl
- base-os
- custom interpreter
- proprietary set of libraries
- app-common
- per-daemon code

ten per-daemon code mel jako dependency konkretni verze app-common, libs a interpreteru a interpreter/libs mely base-os. Tohle vyzaduje dobrej release management, jinak se z toho diagramu poserete :D

ADMIX: muzes dat nejakej konkretni priklad toho, jak tohle myslis, a jaky dusledek by to pak melo pro to upgradovani ? U tyhle myslenky se mozna uplne nechytam, dik.

HOUMLES: tak to bylo mysleno, vybuilduju si image tak ze do nej behem buildu vrznu co potrebuju (at uz nejake "OS" balicky navic, plus PIPem to, co je treba pro python kod. Jakmile vybuilduju, tak uz nesaham na to, co je vevnitr. Berme jako fakt, ze kontejner, ktery se jednou pusti z image, uz se dal nebude modifikovat. Tenhle problem tu neresim ;-). Resim to, jak zajistit, aby bezici kontejner byl up-to-date, resp. abych zjistil dostatecne vcas, ze tomu tak neni a mohl ho pripadne znovu rebuildovat.

ADMIX: ok, pokud budou potrebovat dostat do kontejneru nejakej kus pythonovskyho kodu se spoustou modulu, resis to jak ? Zbuildujes si po vlastni ose vedle toho OS balicky, pokud ty moduly v takovy podobe vubec neexistujou ?