KING: bohuzel, do provoznich veci nevidim. Muzu zkusit zjistit vic...

KING: ...tak právě skript co se zeptá na pár otázek a nastaví přes API? :)

ALMAD: tak to je v podstate to demo co jsem linkoval (jen pres docker compose, transpozice na ECS by mela byt easy). Problem je konfigurace - coz je 99% toho vseho a co se musi delat per-nasazeni. Do budoucna (logstash 2.0) by melo byt lepsi reseni kdy LS bude taky cluster a bude mit API na konfiguraci misto prosteho spolehani se na conf soubory. Pak to bude o hodne snazsi.

NIXIMOR: zajimave, mas trochu vic informaci proc a jak to pada?

SATAI: jen ta cena je jina ;)

KING: FWIW, nemate na ELK stack nekde "pust tenhle shellscript pro vybudovani beziciho clusteru na ECS"?

KING: etcd, Dobrý vědět, asi to zkusime.

I když teda furt čekám, že přijde microservice as a service co prostě tyhlecty discovery a secret věci implementuje za mě, ale to ještě hádám bude trvat...

Ad Docker, já vim...akorát pak jsem došel k tomu že buď naberu zookeeper department, nebo si chvíli počkám. Vim že je to složitý protože to řeší složitej problém, ale stejně ;)

NIXIMOR: to zni uplne presne jako Splunk ;)

KING: ano, logstash mame, na nem napojenou kibanu. Funguje to, ale ma to tendence obcas padat, a podle murphyho zakonu schvalnosti logstash stavkuje presne v momente, kdy nutne potrebujes resit nejaky provozni problem ke kteremu potrebujes logy - zbytek casu funguje 100% spolehlive :D
Takze jsme radi ze se dostanem i k cistym logfile nez je neco prechrousta, tam se nastesti uz nema co po** :)

NIXIMOR: Logstash idealne - agregovat vsechny logy na jedno misto. Idealne do Elasticsearch aby se s tim neco dalo delat. Tam uz je to vyreseny problem co se da delat, kolik to bude stat atp. Pripadne z logstashe treba do loggly nebo tak (== elasticsearch co provozuje nekdo jiny).

Existuje uz spousta vice ci mene oficialnich napojeni docker->ls

Disclaimer: Elasticsearch me zivi :)

ALMAD: syslog historicky neumime, logujeme do souboru... takze logy ukladame do volume.

ALMAD: jestli chces production ready, tak zookeeper je skutecne super neprustrelny, ale vyzaduje HODNE pevne nervy na to ho rozbehat dobre a hodne se toho naucit, to bych radsi risknul to etcd, znam dost firem co to spokojene bezi na produkci.

SATAI: Aha :(

SATAI: ...jo, rádi vás tu uvidíme ;)

NIXIMOR: my všechno řešíme přes syslog stream ven, děje se vám to i tak? Nebo logy ukládáte na volume v kontejnerech?

NIXIMOR: My zatim máme dědictví heroku, takže hacky okolo env proměnných...o etcd jsem slyšel dobré věci, ale někdo (myslim že šéfka devops v parsu) mi říkala, že to ještě neni production ready, ale už si nepamatuju proč.

Docker Prague (Prague)- Meetup
http://www.meetup.com/Docker-Prague-Czech-Republic/

ALMAD: My v nem (nebo ve vagrantu) mivame jenom zabalene lokalni vyvojove zalezitosti, aby si kazdy nemusel resit trebas hadoopy. Na produkci to chteli kluci z ops postupne protlacit, ale pak to nedopadlo AFAIK ciste z toho duvodu, ze se Jakub Veverka vydal za zelenejsimi pastvinami.

A jeste by me zajimal evergreen, jak resite logovani. docker logs je hodne omezeny, neumi moc dobre tail a ma tendenci bobtnat kdyz aplikace bezi dlouho. My nakonec skoncili tak, ze mountujeme externi volume do kontejneru kam se ukladaji perzistentne logy, abychom k nim meli pristup nezavisle na zivotnosti kontejneru i hodne zpetne (obcas je potreba neco dohledat i par mesicu pote co udalost nastala).

Mame docker v produkci, na nekterych dilcich vecech jak webovku tak backend, postupne se snazime pridavat dalsi veci, ale casto to znamena dost zmen. Pomoci Mesos + Marathon + Chronos. Problemy s DNS nevim, nejsem admin.

Me by zajimalo, jak resite konfiguraci. U nas mame striktne oddelene provozni a vyvojove prostredi, vyvoj nema pristup do provozu a admini zas nevrtaji do devackych veci. Tim padem v devu nemame pristup k provozni konfiguraci, takze ji ani nepridavame do image. Zkousime si tedy ted hrat s etcd, pomoci ktereho generujeme konfiguraci pro aplikaci podle toho, na ktery etcd cluster se aplikace pripoji (coz ji pri startu predame pres env promenne). Vyhoda je rychly deploy, kdy admini nemusi prebalovat dalsi layer nad nasim image ve kterem by byla jejich konfigurace.

KING: My bychom potřebovali

*.domain.tld

, protože některý testy generují subdomény pro boundary testing.

Ale už jsem v tý fázi, že tomu holt v případě dockeru podstrčim statickej seed :-|

ALMAD: to resim tak ze compose reknu co ma do hosts pridat, ma na to parametr: https://docs.docker.com/compose/yml/#extra-hosts

KING: Náš problém je, že starší appka používá dost subdomén, které se používají i v testech a zjistili jsme, že nastavit kontejner, aby se mysubdomain.whatever.tld resolvnulo na 127.0.0.1 neni jednoduchý (compose přepisuje hosts).

Ja pouzivam Docker na testy, automaticke i manualni - kdyz potrebuju otestovat neco na vetsim clusteru s urcitou konfiguraci pouziju docker-compose.

Mam vlastni sadu imagu pro nase produkty (logstash, elasticsearch, kibana, packetbeat) (https://github.com/zumo64/ELK_POC je kopie) a pak pouzivam std image na infrastrukturni veci (redis, ...)

ALMAD: DNS jsem neresil, na lokale pouzivam links a bohate mi to staci, na produkci bych se rozhodne podival na http://consul.io/

Docela by mně zajímalo, kdo používá docker pro web a kdo pro balení lokálních aplikací / skriptů.

A pak jestli je tu někdo, kdo už jede produkční nasazení.

...a pak jestli někdo rozumně vyřešil DNS s dockerem, nebo jsme fakt exoti ;)