INDIAN: tak minimalne se budou muset naucit balit a pushovat docker image... a k tomu uz si zapamatovat (nebo nascriptovat) docker-compose pull && docker-compose up -d snad zvladnou :)

DANIELSOFT: jj, nak tak balancuju mezi compose a swarm, zbytek mi pride jako kanon na vrabce, spis mi de ale taky o to, ze kluci maj nulovy zkusenosti a ochota se ucit neco navic je nekde u bodu mrazu.

doporucil byste mi nakej nenarocnej orchestrator k dockeru (zda-li to ma vubec cenu) pro radove 5-20 kontejneru pro pouze jednu fyzickou masinu? pro malej tym delajic interni webovy aplikace ...

NIXIMOR: Pomaham nekomu rozchodit projekty v dockeru na vyvoj. Zmena procesu aby to bezelo proti necemu jinemu nez localhostu by byla trochu nakladnejsi (nekolik projektu, scripty neco nastavi). Zmena configu v nekolika projektech, zmena build scriptu,... Tohle mi prislo casove lehci. Pak rozkopirovat docker-compose (vsechny projekty maji stejne technologie) a bylo by vyhrano. Aspon na to co by jim stacilo a pomohlo. Prvne kdy o necem takovem uvazuji...

MARTEN: localhost je localhost, druhy kontejner je jako druhy stroj, klidne muze bezet na uplne jine masine. Jaky ocekavas ze budes mit uzitek z toho ze se budes pripojovat na localhost?

Pouzivam docker-compose. Mam mysql container, ktery ma expose na 3306. Druhy container s aplikaci. Lze v druhem containeru pripojit mysql port tak, abych se mohl na nem pripojovat na localhost:3306 a ne na mysql:3306?

INDIAN: napadlo me skalovat to pomoci Jenkinse a pluginu pro openstack ale po podrobnejsim precteni mi to uz tak dobrej napad zas nepripada :/

MUXX: pres openstack api

INDIAN: Jak chces ty dalsi VM vytvaret/zapinat?

INDIAN: Rancher je dobry smer. Jeste se mi libilo ho pouzit v kombinaci s opennebula. Tahle kombinace by ti to mela zvladnout. Opennebula ti zvladne ze serveru/vps udelat jednoduchy cloud pro docker. Jedina pro mne nevyhoda rancheru je, ze nepodporuje docker version 3 a nelze do containeru dat config file, ale musi to jit pres environment. Ale je v planu update, jen nevim kdy ho budou mit.

INDIAN: zrovna koukam/prokousavam se dokumentaci Rancheru ...

Stojim ted pred koncepci jakyhosi buildovaciho clusteru, situace je kuriozne nasledovna:
(do jist miry OT, pac se velka cast tyka spis VM, ale bude treba resit hlavne jakejsi skalovaci container pool)

S nasema vyvojovejma oddelenima resime jak naskalovat spousteni jednotlivejch kontejneru a hlavne hostu na kterejch pobezi na zaklade poctu paralelnich buildu, ktery sou narocny jak na zdroje, tak casove. Idea je mit pri maly zatezi spustenou jednu VM na kterejch pobezi X kontejneru, nicmene pokud bude vyssi "poptavka", mely by se na zaklade zateze spoustet/vypinat dalsi VM hostujici opet kontejnery kde pobezej buildy ... Idea je proste neco treba jako flexibilita skalovani Openshift co se tyce ukladani images, avsak v nasem pripade by nebylo pasivnim ukazatelem zbejvajici misto na disku, ale dostupna pamet + vyuziti CPU.
O redistribuci buildu napric kontejnerama se bude starat icecream

Proc poustet/vypinat jednotlivy VM - cilem je usetrit za zdroje, pac cela infrastruktura bude u OVH, kde se dle vybranyho tarifu zohlednuje uptime vs. pocet spustenych VM... vzhledem k tomu ze pocet paralelne spustenych buildu je dost promenlivej (blizici se release, svatky, vikendy, atp), bylo by dost neefektivni nechat bezet vicero instanci ladem.

Ptam se kdyby nahodou nekdo neresil uz neco podobnyho nebo nezna neco co by resilo pribliznej use case abych nezacal znovu vynalejzat kolo... moje prvotni idea je napsat si jednoduchou sluzbu co analyzuje zatez na bezicich VMs a pres API (OVH pouziva OpenStack) pak spoustet/vypinat jednotlivy instance.
Snad je to srozumitelny.

ADM: tak castecne vyreseno, do docker daemon.json na buildovacim stroji dan limit max-concurrent-uploads na 1 (default je 5), tim se kompletne vyresily problemy s push a mohl se docker registry naskalovat na vic kopii.
problem byl ale nakonec v tom, ze byl prekrocen jakysi maximalni pocet podu na cpu core, ktery je podle dokumentace 10 - ten limit mi prijde spis jako doporuceny, pac neni pod jako pod a neni to samozrejme presny limit, ale v dokumentaci to nebude bezduvodne ze.
dost blbe se ta situace poznava, kdyz cpu se flaka, pameti je dostatek, ale jaksi container creating nikdy nedobehne. podobnou vec zpusobuje i docker registry, ktery od urciteho mnozstvi soucasnych docker pull dost casto vytimeoutuje (coz neni problem udelat, kdyz se necha odmigrovat treba 40 podu z celyho nodu).

pouzivate nekdo docker-registry nebo nejlepe rovnou openshift? konkretne teda musim pouzivat openshift/origin-docker-registry:v3.6.1. kdyztak popisu problem podrobneji, jedna se o skalovani, jako storage backend je mozny nfs nebo gluster (co se tyce read-write-many pristupu, tedy z vice instanci stejneho containeru), nebo jeste ceph rbd. problem je ze vic nez jedna instance ma problem s docker push (je to loadbalancovany na vic replik, problem je v glusterfs synchronizaci), ale zase s jedna instance nezvlada rekl bych odhadem vic nez 5 simultanich docker pull, potrebuji kapacitu alespon na 20. docker push/pull samozrejme jede nekolik chunk http spojeni, rozhazuje se to asi dost podivne protoze default loadbalance algorithm je leastconn, muzu to sice zmenit ale nechce se mi do toho openshift routeru zas prilis vrtat, tech potencialnich klientu je stejne zatim tak 9, z toho push jde prave z jednoho

RUDOLF: nakonec to bylo easy

for task in $(docker stack services -q web); do docker service update $task; done

DANIELSOFT: tak vyřešeno - ono to ty adresáře fakt vytváří, akorát já dal "ADD file /name/of/directory" a správně mělo být "add file /name/of/directory/file", v tom prvním špatném případě to vytvořilo soubor se jménem adresáře a proto ho program nenašel

Ahoj, lama otázka: když v Dockerfile zkouším ADDnout soubor do adresáře, který neexistuje, Docker adresář nevytvoří a tím pádem soubor vůbec nepřidá. Jediné co mě napadlo je dát před to RUN mkdir: přijde mi to ale neelegantní, je lepší způsob?

každopádně.. docker stack deploy má jednu vtipnou vlastnost, pokud jsem teda něco nepřehlédl: nezajistí, že deploynutá služba skutečně běží..

je nějaká možnost jak elegantně zkontrolovat, že daná služba běží? Procházel jsem API, ale nic mě netrklo.

Můžu například kontrolovat jesli neběží něco v replicas 0/1. Nebo inspected projít všechny služby ve stacku, jestli mají UpdateStatus.state na paused. Ale to se mi to zdá všecko takové čudné..

Když použiji docker service create/update, tak mi services vrátí exit code 1, když tasky v services nenaběhnou.. Žel stack deploy nemá žádný attach mode. Takže při deploymentu, pokud nezkontroluji že nějaký task nevysí, tak vím prd.. Ještě horší situace když nastavím rollback, tak ani pořádně nevím, že služba byla failed. Služba prostě běží v předchozí verzi.

RUDOLF: už jsem dávno pořešil, tak jen zpětně: řešení je v Launch configuration pro daný node připravil skript, který metadata zapíše do prostředí.