MUXX: RUDOLF: chapu vas .. ale protoze ted mame konfiguraci vytahanou do vlastnich souboru (a je jich hodne), prijde mi nejlepsi metoda namountovat do image ty spravny soubory (nez abych to cely tahal do promennych a resil to dplnovani, protoze jsou to 3 ruzny technologie apod) ..

kazdopadne, ten duvod "proc nedavat secrety do image" je ten, ze se pak neda reusnout image v jinem prostredi, nebo je to kvuli bezpecnosti (protoze image snadno leakne)?

MUXX: jedna z aplikaci, kterou bude dockerizovat, jsou stare php skripty .. takze jestli te chapu dobre, navrhujes pres environment variables dostat udaje do docker-compose, ktery s nima prepise nejaky prazdny hodnoty ve zdrojacich?

URPUTNIK: Heh to je tak dlouhy ze vlastne nevim co chces :) konfiguraci mas jako environment variables ne? Nastavujes to pri deploy. At uz to dela jenkins nebo ansible. To nestaci?

tak jiny, predpokladam casto pokladany, dotaz :) runtime konfigurace pro kontejnery .. predem - vim ze a proc, nemam konfiguraci cpat do kontejneru :) neresim secrety, ktery potrebuje build (napr pristupy na privatni repo, do gitu ..), ale ty, co jsou potreba v runtime aplikace (pripojeni do databaze, dalsi endpointy v nasi SOA) .. ty zpravidla zalezi na konkretnim prostredi i verzi aplikace

aktualne mame konfigurace soucasti stejny repo jako zdrojaky, kvuli svazani verze konfigurace s verzi aplikace ... jsou teda vysypany v gitu bokem, mimo adresar se zdrojaky, takze do nasazene aplikace se doplnuji az deployment skripty, ktere si git-repo checknou ..

moje prvni idea byla defakto zbuildit (dockerizovat) cistou app bez konfigurace, adresare s konfiguraci checknout tema deployment skriptama (defakto stavajici model) a zkompletovat pri pousteni .. tam bych ale musel checkovat repo z nejakeho konkretniho commitu (tzn asi si predavat commit hash pres tag u image, viz RUDOLF)

dalsi varianta byla zbuildit image s aplikaci a v ramci jeho FS nechat nekde bokem konfigurace pro vsechny prostredi (aka verze prvni, ale bez gitu, konfigurace se sveze s image), ale prijde mi, ze to porusuje to 'nedavejte konfiguraci do kontejneru :)

takze ted zvazuju, ze bych v ramci jednoho buildu vyrobil vic image (napriklad jeden jen s aplikaci + image pro kazde prostredi jen s konfiguraci, jejich kompletaci pak vyresi treba docker-compose) .. defakto bych potreboval obraceny multi-stage build, tusite o nejakem? ritim se do zahuby? :)

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