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 ?

Ahoj, jak zabezpecite, ze to, co bezi vevnitr v kontejneru bude z pohledu patch managementu up-to-date ?
Me napadaji postupy typu:
- definovat striktne z ktereho image lze stavet kontejnery a podle toho se chovat k "OS" balickum, tj. lze je upgradovat napr. pomoci APT, YUM...
- pokud se treba vevnitr v kontejneru pouzije python a jeho PIP, tak nastava trosku schizofrenie.. dokazu to zkontrolovat treba pomoci pip-check; ale kdo vi, co kdo kde schova do nejakych pythonovskych virtualnich prostredi; ty pravda dokazu najit pomoci nejake radoby heuristiky (to ze nekde je "/bin/activate" mi zpravidla nabonzuje, ze je tam i virtualni prostredi, ale neni to uplne zaruceny postup
- aktualizace image samotneho - watchtower ?

Napada nekoho z vas nejaky co nejvic obecny postup ? Dik za pripadnou debatu / namety.

Ahoj, je tu nekdo kdo se Dockerem zivi, mel bych nejspis kseft

U klienta na serveru potrebujeme rozbehnout docker na produkci a nastavit server

MUXX: skus do nazvu WARu pridat commit id z gitu

Potreboval bych poradit s jednou silenosti co jsem zdedil. Mam vetsi Java projekt, ktery pres maven (multimodule project) vyplivne 30 docker images (protoze microservices, 30x WAR pro tomcat). Potrebuju to nejak verzovat a nasazovat na kubernetes/openshift. Z tech triceti dockeru je cca dve tretiny beze zmeny kodu a tedy diky docker cache se zbuildi vdycky stejny image. Hledam nejaky tip jak tyhle dve tretiny odfiltrovat, otagovat jenom zmeny a do helm chartu pak davat jenom zmeny. Aktualne releasuju vsechno jako novou verzi a na k8s pak helm vsechno re-deployne i kdyz neni zmena v kodu (ale zmeni se tag). Je na toto nejaky tool nebo obecny pristup? Developeri jsou hloupy lopaty a nemuzu se spolehnout na to, ze mi daji spolehlivou odpoved na to, ktere image je potreba releasnout. Beru jakekoli napady co to alespon trochu zjednodusi.