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í.

Zdar! Opět docker swarm na aws, už se s tím docela zžívám ale na tomhle si furt lámu zuby.

Deployuju přes docker stack deploy compose3.4.yaml a potřeboval bych, abych consul propagoval veřejnou IP danýho node. Use case je, že consul servery a spoustu další havěti žije mimo AWS a consul propaguje ven interní IP. Takže nody na AWS se spojej, zbytek ne.

Možnosti jsou:
a.) Otvírát vnitřní IP se mi nezdá jako dobrý řešení (ani nevím, jestli by mi to AWS dovolilo).

b.) Asi by nejsprávnější cesta by byla, udělat si ve swarm vlastní consul DC a na jednom manager node udělat vlastní server, takže na jedné adresy si povídat s nody ve swarm a po druhé adrese s nody mimo swar -- ale to bych si nechal na jindy.

No a mě by stačilo:
Mám už pořešený, že nody v docker swarm propagují consul porty mimo ingress a sami za sebe. Jen bych jim potřeboval definovat veřejnou IP. Defakto jen advertise_addr=$(curl http://169.254.169.254/latest/meta-data/public-ipv4) per node. Ale nějak vůbec netuším jak na to. V v compose/service command to definovat nejde, nebo jsem nepochopil jak, na $(command) mi to vrátí že mám použít $$(command) - ale k expanzi na konečném nodu vůbec nedojde, mám pocit, že ta expanze navíc probíhá na mém hostu, z kterýho pouštím docker stack deploy.. Tj. nejsem schopen vytvořit service tak, abych použila tamní prostředí. Asi jsem něco přehlédl.

Pak jsme si všiml konstrukce přes config:
kde někdo používá: "advertise_addr" : {{ GetInterfaceIP "eth2" }}, -- ale to mi nějak neklaplo..

RUDOLF: tak moje idiocie - ofiko přístup:

$ ssh -i <path-to-ssh-key> -NL localhost:2374:/var/run/docker.sock docker@<ssh-host> &
$ docker -H localhost:2374 info

RUDOLF: No, koukam do jejich dokumentace a uprimne mi pripada divny, ze sekce "Deploy your app" neobsahuje jinej postup nez prave ssh do ty remote instance, bych cekal ze takovej deployment exposne nejaky API ... Sorry, nepomuzu :D

ADMIX: TLS -- Aspoň tipuju, Docker for AWS je Cloudformation template od Dockeru co používá vlastní distro. Ale není k tomu moc dokumentace a není mi jasný, jaký klíče ta manager instance použila. Ale nechci ji předkládat svoji - rád bych fungoval, aby to jelo default.

RUDOLF: Jak presne to mas zabezpeceny, resp. jakou authentication potrebujes? Tohle? https://docs.docker.com/engine/security/https/#secure-by-default

Co jsem zbezne kouknul do dokumentace SDK, tak tam zadnej login na socket samotnej neni, takze predpokladam ze to API je pak akorat o certifikatu?

RUDOLF: ale i to api běží vůči socket nebo https -- a mě furt neklape ta autentifikace..

ADMIX: ale jo, docker remote api je vončo

ADMIX: teď jsem na to zběžně juknul a jestli jsem to správně pochopil, tak swarm API k tomu primárně neslouží. Možná to jde, ale netváří se to jako standardní cesta. Ale na týhle úrovni si s tím hraju poprvé. Jinak ten docker-for-aws/swarm zatím působí příjemně, kdybych měl jenkinse na aws, tak by to asi šlapalo jak po drátkách.

RUDOLF: S dockerem jsem se tak daleko nedostal, ale nema to nahodou nejaky API do kteryho bys ten deployment poslal?

jedete někdo v docker for aws?

Potřeboval bych z jenkinsu co běží mimo cílový swarm, poslat deploy do swarmu.

Napadá mě:
a.) připojit docker co běží na tom jenkins serveru přes join-token do swarmu jako manager, tj. jenkins by mohlo posílat joby přímo do swarmu

b.) připojit docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=$HOST:2376 version (ta version se mi nezdá), nebo to vložit do env. prostě dělat docker service update --image -- ale nějak jsem zmatený, jaký klíče ten docker manager vlastně použil.. takže je neumím vytvořit: https://docs.docker.com/engine/security/https/

c.) nejšíleněnšjí mi přide ssh na daný management stroj a tam prostě docker service update --image pustit lokálně..

díky

MARASAN: vyreseno: [ MARASAN @ Network and host security - firewally, exploity, bugy, vulnerability, incidenty a vse o pocitacove bezpecnosti ]