RATTKIN: A do te doby co? Nedostupnost sluzby? Trochu pitomy, ne?

KOJA: když node selže, tak ti to hlásí monitoring a jdeš node opravit?

HVJ3R: Predem se omlouvam, mozna zmotam terminy.

Necht mam jediny node a na nem bezi service ve trech replikach. Pripravim a do swarmu pridam druhy node. Otazka zni zda se necha nejak zaridit aby se nejaka z tech trech replik automaticky "prestehovala" na ten druhy node aby byl cluster robustnejsi proti selhani jednoho z nodu.

Duvod proc jsem to resil byla predstava, ze pokud se tohle nedeje automaticky, tak kazde "zaskobrtnuti" hw/os/sw nodu mi efektivne vyradi node z clusteru a cely cluster se tak pomalu sestehovava na jediny node. Nebo je to blbost?

Mam skoro pocit, ze jsem nekde videl, ze tohle docker-swarm zatim neumi ale pamet uz nerika kde. Na druhou stranu mi to ale prijde celkem dulezite a tusim, ze docker-swarm uz asi dost lidi pouziva v produkci, tak jsem z toho muflon.

Predem diky za osvetu.

Neresili jste nekdo problem s volumes definovanych pres docker-compose ve Windows 10 (Hyper-v) ? prosel jsem github, stackoverflow a nikde nic nepomohlo :(

Pocitam ze ma na mysli bezici instance.

KOJA: Replik ceho?

ALMAD: My to zatim nemame, ale chceme, jsme v rany fazi testovani a vyzkumu (the R part in R&D :D )

ADMIX: Je něco na consulu a vaultu co jste našli a nelíbí se vám? Oba bychom taky rádi.

ADMIX: Mozna uplne mimo ale nedavno jsem narazil na toto: https://vmware.github.io/photon-controller/

Existuje neco peknyho na jednoduchou orchestraci kontejneru pro small-scale systemy? Hlavni vyhoda kontejneru v soucasny dobe je deployment stategy, ale muze se stat, ze system skonci se dvema fyzickejma strojema (a mozna par VM na nich), malokdy se instalace dostavaj do vyssich desitek stroju. Vetsinou on-premise, bez internetu. Vsichni si chvali kubernetes, ale to je jako atomovkou na komara :)

hadam ze init kvuli tomuto
Docker and the PID 1 zombie reaping problem
https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

jak resite spusteni nejakyho daemona po startu kontejneru v dockeru?
mam jednu aplikaci co na beznym systemu startuje pomoci supervisiord a na dockeru se mi vubec nedari ji presvedcit aby nastartovala hned jak nabehne kontejner...
Zkousel jsem psi kusy s dumb-initem ale proste ne a ne to tam natlacit...
Ted jsem zkousel vzit ty relevantni casti s init scriptu a zkusit je primo natlacit tomu dumb-initu pres cmd ale taky nic a uz se v tom zacinam zamotavat...

ENTRYPOINT ["dumb-init", "--"]

CMD ["dumb-init", "opt/imm/.virtualenvs/imm_server/bin/activate"]

CMD ["dumb-init", "/opt/imm/.virtualenvs/imm_server/bin/supervisord", "-c", "/opt/imm/imm_server/supervisord.cfg", "-u", "imm"]

Muzete mi prosim nekdo poradit jak bud spravne zavolat ten init script kterej jinak bezi normalne z init.d, nebo jak tyhle startovaci commandy nacpat tomu dumb-initu?

diky!

NIXIMOR: Moc díky!

UETOYO: V podstate si to predstavujes spravne, akorat pozor na databazi a perzistentni storage... resp. v tvem pripade asi idealne neperzistentni. Co jsou treba predpripravene image pro MySQL, tak maji data defaultne ve volume, takze zustavaji i mezi restarty kontejneru, coz v tvem pripade je nezadouci.

Mám úplně začátečnickou otázku, která s tím asi souvisí. Chtěl bych vývoj založit jen na Dockeru. Představuji si to tak, že mám např. běhové prostředí (JVM, CLR) v jednom imagi a databázi v druhém. Tím se odstíním od jakýchkoliv závislostí na mém stroji. Image s databází používám tedy jen na integrační testy (ať už lokálně nebo na build serveru). Pokud potřebuji k vývoji více částí, použiji docker-compose. Představuji si to reálně? Můžu tím nahradit zcela Vagrant apod.