IGRACEK:
zkus http://prometheus.io/
a nebo https://sensuapp.org/

a na ovladani jenkins :)

IGRACEK: u tebe bych chtěl pracovat

navazu na nedavnou debatu..

co byste doporucili na monitoring nasledujiciho prostredi?
windows boxy [vetsinou .NET]
linux boxy [docker / aplikace hlavne v jave / radius / atd]

potrebujeme od toho idealne tohle vsechno:
- Synthetic monitoring
- Scalability [napr. self-tuning nam nastartuje dalsi node ci kontejner]
- Autodiscovery [co nejmin nastaveni, kde se ma co sledovat - napr. co dela New Relic]
- geo monitoring [sledovat jeden endpoint z vice regionu]
- integrace s jinymi tooly

Ja si zkusmo rozchodil chain New Relic > pagerduty > Slack a funguje to krasne.

Dalsi moznosti je napr. cAdvisor + dalsi exportery + Prometheus / PromDash - s tim jsem si zatim moc nehral.

BTW na ovladani zvazujeme Ansible Tower nebo Chef nebo Kubernetes, tak kdyby nekdo mel neco i k tem, rad uslysim jejich chvalu / kritiku. :]

P.S.: opensource je fajn, ale na penize ohled nebereme

SATAI: a jaka je vyhoda proti docker-machine okrem toho lajtu?

Pokud tu jsou nejaci ubozaci na Mac OS X (Yosemite a novejsi):

nlf/dlite · GitHub
https://github.com/nlf/dlite

DEII: co saltstack ?

ALMAD: Vyhovuje mi Ansible, ale nechci investovat do Ansible Tower. Proto jsem zkusil Ansible Playbooks spoustene z prostredi Rundeck. Chef a Puppet jsou alternativy, ale zbytecne robusni (nodu mame cca 30).

DEII: Tak to je imho spis na terraform/ansible/salt/puppet/chef/...

ALMAD: Predevsim mi jde o automatizaci deploymentu a verzovani konfigurace. V dalsi rade mi jde o to, mit prehled kde, co a zda to bezi. Monitorovani performance, pripadne infrastruktury v tuto chvili neni potreba.

DEII: Moc ted nerozumim, jestli ti jde o automatizaci toho procesu orchestrace, monitoring aplikace, nebo monitoring kontejneru...?

DEII: (kazda aplikace ma svou databazi)

Snad se sem hodi dotaz:
Zkousel jsem Rundeck. Cekal jsem, ze tam bude aspon zaklad nejakeho monitoringu - nody bezi. je na nich nainstalovana aplikace x ve verzi y a testy jsou ok. Nepochopil jsem neco, nebo mam zkusit jiny nastroj?
Mame cca 12 aplikaci, 10k testu a 6 typu nodu (dev, test, prod, ..). Potrebuji vzit sestavenou aplikaci z build serveru (Jenkins/Bamboo), nasadit a pripadne spustit testy v ruznych modech.

Hurá

aws/amazon-ecs-cli · GitHub
https://github.com/aws/amazon-ecs-cli

A na tohle se taky těšim

AWS re:Invent on Twitter: ".@werner announces the Amazon EC2 Container Registry #reInvent http://t.co/FqRsyqCli0"
https://twitter.com/AWSreInvent/status/652158844777336832

BTW starší, ale IMHO furt dobrý

Docker in real life, the tricky parts
http://blog.kaliop.com/en/blog/2015/05/27/docker-in-real-life-the-tricky-parts/

ALMAD: u nas pouziva docker QA oddeleni na cast testu nastroju na konfiguraci clusteru v datacentrech - tj. v pripadech kdy neni k dispozici fyzickej cluster, resp. kdyz test na virtualnim clusteru trva vecnost (pekelna kombinace vagrant+virtualbox) a neni tam treba simulovat existenci diskovyho pole....
ja sem na opacny strane barikady, docker pouzivam spis jen na vyslovny "prani" QA, kdyz je treba nasimulovat objevenej bug a dodat fix ...
kazdopadne sem zvedavej, book

SATAI: Jsou to celkem jemné crawlery, ale v pár případech skončí nějaký na blacklistu a chvilku trvá, než se s adminem domluvíme. No a když sklízíme z jednoho hostingu několik domén, je větší šance že crawler s jinou IP obsah sklidí.

RUDOLF: záleží na okolnostech. Ale ten základní požadavek na různé IP, proč to?

Jak je těžké virtualizovat JAVA aplikaci do 20 dockerů, aby každá měla vlastní veřejnou IP? Defakto bych to dělal jen proto, abych ušetřil RAM pro OS overhead při klasický instalaci do 20 virtuálů. Tak nevím jestli to stojí za to a jak se na to můžu spolehnout.