hele, když jsem tady.. Už mi na produkci nějakej měsíc jede swarm mode. tak jen pár zkušeností a postřehů. Jedu na upravený Docker4aws z ofiko docker upstreamu. Je to znažší než kubernetes a snažší se to být jednouchý nástoj, bez zbytečné hloubky. Když jsem si zkoušel Kubernets přes yoyo, tak ten management klastru mi přišel hrozně tlustej. Swarm je tenčí.

a.) Bohužel je reálně potřeba mít 5 manager nodes and nikoliv jen 3. Na AWS v pár případech ty stroje ztratili quorum, když dělal nějakou aktualzici, kde se instance manageru museli nahradit. Je na to na githubu issue - myslím, že to může být specifkum clean up skriptů dodaných s docker4aws.

b.) Občas blbne ingress. Typicky, když jsem měl třeba 3+ replik, najednou v jednom kontejneru na konkrétním stroji nefungovalo service discovery, v jiné replikace na jiném stroji už zase jo. Je na to na githubu issue. U jiný appky jsem narazil, že appka nebyla dostupná na port z každého manager nodu. Tj. občas request na appku selhal.

c.) Docker4aws je dodanej s klascikým LB. Abych se přiznal, moc jsem nepochopil jak z toho klastru provozovat různý appky pod různými domain names. Je tam nějaká magice s propojován ARN domény a portem. Udělal jsem aplikační a network load balancer a target groupy pro každou službu. Důležitý bylo vypnout v cloudformation docker4aws healthchecky u toho defaultního LB, ideálně už při prvním vytvoření LB. Když jsem např. zcela legitimně undeploynul službu běžící na nějakém portu, ASG začal mít pocit, že node je rozbitej a začal zabíjet instance. Protože si mysell že ta služba na daným portu má fachat. V kombinaci s těma trablema, kdy člověk má jen 3 manager nodů, to skončilo ztrátou quora.

asi je toho víc, ale už bych měl jít spát.

oběcně, podobně jako s kubernetes, bych dal přednost managed solution - kde za život klastru má zodpovědnost třetí strana.

INDIAN: swam chceš pokud máš 3+n (n jsou workery) fyzickejch mašin a chceš aby ti swarm rešil životaběh kontejnerů . Jinak bych šel cestou docker-compose, imho lepší než jet one node swarm.

Nomad neznám.

INDIAN: hashicorp nomad jsem používal i pro složitější věci, ale je minimalistický a jednoduchý. me gusta

INDIAN: Pridavam se k docker-compose. Super jednoduche a neni skoro co se k tomu ucit. Pouzivam to jak k developmentu, tak i na nasazovani nekterych lehcich aplikaci. Na slozitejsi aplikace pak rancher.

INDIAN, NIXIMOR: presne pro tenhle ucel pouzivame docker-compose a bez problemu. Pro komplexnejsi prikazy a jejich retezeni je to vybavene jeste klasickym makefilem, takze

make cont-name.reboot

= down + up,

make cont-name.refresh

= down + pull + up atd.

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