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 ]

mam problem s LXC na Debian Stretch, pri lxc-create mi na serveru vzdycky skonci kvuli GPG overeni image:

$ lxc-create -n testerka -t download
Setting up the GPG keyring
ERROR: Unable to fetch GPG key from keyserver.
lxc-create: lxccontainer.c: create_run_template: 1297 container creation template for testerka failed
lxc-create: tools/lxc_create.c: main: 318 Error creating container testerka

Pridam-li parametr --no-validate, vsechno probehne ok. Nez jsem zacal konfigurovat server, rozjel jsem si LXC doma ve virtualu taky na Debian Stretch ve VirtualBoxu, kde mi lxc-create chodi bez problemu. Cili pokud pristupuje na stejny key-server (predpokladam, ze ano), tak nekde bude problem, ale absoilutne nemam tucha kde a v cem. Virtual doma je za NATem od UPC a dalsim NATem myho routeru a dalsim NATem pro VirtualBox, server je primo v siti s pevnou IP.

Firewall je off, resp. je tam nejaky nastaveni pro lxc-net (asi dnsmasq):

# iptables -L -v -n
Chain INPUT (policy ACCEPT 15505 packets, 34M bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
    0     0 ACCEPT     udp  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      lxcbr0  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 10847 packets, 6737K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Popravde jsem fakt zmatenej, nic jinyho nez uvedeny --no-validate se mi vygooglit nepodarilo. Nenapada vas neco?

ADM: To je jednoduchej bind mount, abys moh pustit vedle svy aplikace nakej filebeat nebo podobne - Nomad jako takovej nejaky sofistikovany logovani neresi (umyslne).
Ale tusim ze to ted v poslednich verzich umi ty logy premigrovat, pokud treba drainujes ten node - nejsem si jistej :)

ADMIX: nj, ale jak pak nomad resi kdyz to bezi na ruznych nodech (za loadbalancerem)?

ADM: Uf, nemam ted kam se podivat, ale pokud se nepletu, tak nomad si pro kazdej taskgroup vytvori adresar na hostovi pod --data-dir, a ten pak bindem mountuje dovnitr tech rkt kontejneru jako rw volumes.

ADMIX: kdyz uz zminujes ten nomad, tak ty sdileny adresare jsou nejaky glusterfs, nebo jak tam maji tohle vyreseny? me cekaji ty logy vyresit na openshiftu (kubernetes), ale jeste jsem se tak daleko nedostal, zatim me nenapada jak to pak centralne sjenotit pokud repliky stejneho service loguji do stejnyho filename

opet me prekvapil docker, ze neni mozne z parent image zbavit se EXPOSE, ENTRYPOINT apod., ale porad nechapu odkud to z te vysledne image vycte, vzdyt to musi byt ulozeny nekde uvnitr prece

Zkousel nekdo neprivilegovany LXC kontejner a host networking? Nejsem si jistej jestli to vubec jde, pada mi to a dokumentace je skoupa, tak jen jestli nahodou nekdo netestoval

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 :)