Mam kontejner, kam jsem si dal nginx, uwsgi a python, plus supervisor, kterej mi spusti uwsgi a nginx. Ze tam mam dva procesy mi srdce netrha, nicmene spravne by teda mel byt uwsgi, python a aplikace v jednom kontejneru a do druheho dat jen a pouze samotny nginx a konfiguraci k nemu? Vyznam toho vysunuti nginxu ven vidim jen v pripade, ze by serviroval vic ruznejch aplikaci, ktery pobezi v ruznych kontejnerech.

Navic ted se muze uwsgi a nginx napojit pres socket, takhle by to muselo byt pres http.

KOJA: Jo, deployment dobre separovanejch kontejneru je zuzo labuzo, mam ted jedno PoC ktery jede komplet na coreos a orchestruju rkt Nomadem z jednoho cloudfrontu :)

ADMIX: Jsem pouze zvedavy amater, izolaci tech procesu povazuju za vyhodu ale dal uz nevidim. Je tam snazsi sprava zavislosti (treba security update knihovny) kdyz ma clovek vice mensich imagu nebo je to zajimavy z jineho duvodu?

DWICH: Ja to treba delam kvuli tomu, ze backend je perl, je tam extra kontejner na perl a par dalsich dependencies, zatimco nginxu staci base OS kvuli par knihovnam.

DWICH:u malych aplikaci to neni tak zjevny, ale v tom nginxu si to muzes treba rozhazovat mezi nekolik upstreamu (vic kontejneru) kvuli loadbalancingu, nebo AB testovani, nebo cast appky ti bezi v php a cast treba v ruby, nebo abys nasral uzivatele nebo admina apod. Duvod se dycky najde.

ADM: V tomhle se mi kubernetes libi vic, pac v kombinaci s flanneld neresi porty, ale proste namapuje rovnou IP adresu pro tu danou instanci.

no a pak by to podle zadani melo behat pod openshift(kubernetes), na to jsem taky zvedavej, takze predpokladam ze tahle vrstva se kompletne postara o dns-services-routing-portmapping a ten container bude hovorit pouze http na jakoukoli host hlavicku zvenku, jinak si nedovedu predstavit jak by se to uridilo, takze jina moznost nez nginx+php-fpm v kazdym containeru asi neni mozna

resim ted microservices jako nginx+php container a musim si povzdechnout ze ofiko reseni jako CMD nebo ENTRYPOINT ve forme script wrapperu na startovani obou sluzeb me teda elegantni vubec neprijde (a uz vubec ne ta dalsi moznost hazet do containeru python kvuli supervisord, jak se pise v dokumentaci https://docs.docker.com/engine/admin/multi-service_container/). tohle mi prijde jako dost velke omezeni jinak velice vychytaneho dockeru

ADMIX: Diky!

KOJA: Ja ti vubec nerozumim a stejne ti nedokazu poradit. Tohle neni use case, ktery bych resil. My v podstate mame desitky dockeru postaveny tak, aby nam kopirovaly produkcni prostredi (akorat misto jednoho kazdyho fyzickyho serveru v produkci, na kterym bezi pet sluzeb, mame pet dockeru).

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.