používáte někdo na tagování: git rev-parse --short HEAD ?

Asi není pravděpodobný že při 1000-10000 buildech se ten hash zopakuje dvakrát?

JON: "by mel" :) ale stavalo se nam, ze jsme meli treba neuplny pom (takze nejaky nastaveni sly 'z defaultu', ktery se ale mohlo podle lisit na kazdem stroji co to buildil) .. taky nam obcas litaly konkretni verze javy (resp patche), napriklad jdk1.8.0_131 a jdk1.8.0_181 (btw, da se to nejak lip specifikovat v pomu? nasel jsem ze muzu nastavit JAVA_HOME, ale na co vlastne bude ukazovat neomezim)
u nas je to jeste specificky tim, ze 'netagujeme' maven buildy (aka v masteru je snapshot a mel by byt nasaditelny kdykoli) .. ale to nas nuti napriklad na nexusu zahazovat starsi verze snapshotu (aby se to zbytecne nehromadilo, kdyz si maven stejne stahuje tu nejnovejsi verzi) .. do dusledku, kdyz se nasazuje dalsi verze do produkce, clovek ma 2 buildy, ktery jsou oba snapshot, ale ten co je nahrazovan uz nemusi byt v nexusu (protoze od ty doby bylo vic commitu, aka buildu), proto ta zaloha

WOODMAKER: CI/CD :)

JON: v gitu jsou zdrojaky, maven to zbuildi a nasype do nexusu .. vysledny binarky uz do gitu nesypem ..

URPUTNIK: proc tam mate zalohu minule verze? ta by mela byt v gitu, ne?

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?

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.

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 :)

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!