ADM: s dockerem jsem resil logovani jen pres bud filebeat a nebo pres ten jejich docker logging driver pres logstash do ES v Gelf formatu (je mozny samozrejme psat i na disk z logstashe)

Kdyz jsem to resil pres filebeat tak, na zadost klienta, jsme vse napred presunuli na centralni server opet pres docker logging driver a syslog - https://docs.docker.com/config/containers/logging/syslog/ - na centralnim serveru pak staci mit syslog server

INDIAN: ja do ES nic posilat nechci, ja si vystacim pokud mozno se starym dobrym syslog serverem. v openshiftu je jako hotovy logovaci reseni EFK vicemene dany (a je to teda pekny shit), na nejaky vlastni bastleni to neni

ADM: proc ne filebeat teda? kdyz to posilas do ES ...

RUDLF: s dockerem na centosu mam taky dobrou zkusenost, je tam dobre out-of-the-box oselinuxovany a nakonfigurovany, nicmene pouziji debian, kvuli aktualni verzi dockeru (a compose). zatim mi v dockeru v porovnani s openshift/kubernetes chybi par veci, nektery mrzi hodne, az to budu mit hotovy tak to shrnu a podelim se.

jeste bych se zeptal, jestli nemate nekdo vyreseny logovani, idealne bych vystupy containeru rad dostal na syslog server. v openshiftu je docker logging do journald, jako daemonset je na kazdym nodu fluentd, ktery logy collectuje z journald a posila do elasticsearch. predstavoval bych si to podobne ale s posilam na remote syslog server

Rozjíždím teď kubernetes a mám dotaz na Helm versus kubectl apply -f.

Do jednohu YAMLu pro kubectl je možný definovat všechny K8s objekty (deployment, loadbalncer apod), takže deployment mi nepřijde nijak komplikovanej. YAML si templatuju už s ansible, takže s Jenkins CD si deployuji služby do různých prostředí. Co jsem si všiml, že nějaký POD byl restartovaný i když imho to nebylo třeba.

Tj. jediný potencionální benefit Helm by mohl být jemnější aktualizace prostředí. Ale nic konkrétního jsem neviděl. Ale co jsem četl, o Helm se mluví jako o packager manageru. Když jsem jukal na přípravu Helm Chartů, je to prostě templatování. Jasná výhoda je, pokud člověk používá 3rd party charty pro zavedený kontejnery, tak je to možná jednodušší. Ale u nás je to tak akorát consul a pak monitorovací/logovací stack.

MARTEN: ten repozitar samozrejme mam ale docker-compose tam neni, ale nainstaloval jsem ho teda pres pip

ADM: na debian muzes pouzit docker repository, ktere vetzi 3 podporuje. bezim na tom bez problemu. jen neni v oficialnim debian repo. koukni na webu dockeru na sekci instalace na debian.

zdravim vespolek, dostal jsem za ukol prozkoumat migraci z openshiftu na ciste docker ekosystem (rikal jsem jim uz pred rokem, ze je to blbost, ale nedali si rict), takze sem pravdepodobne budu sem tam hazet nejaky dotaz.
Pro zacatek by me zajimalo, jakou distribuci pro docker swarm. V openshiftu neni co resit , proste redhat/centos. Bral bych debian ale nema docker-compose s podporou verze 3. Je nejaka vhodnejsi distribuce ktera by stala za doporuceni? Co ten clear linux, provozuje to nekdo?

OMNISLASH: Tak asi nejjednodussi najit ktery adresar je tak nejvetsi. Muzou to byt stazene image, vytvorene volume, nebo cokoliv dalsiho.

MUXX: to je on. nezustala, i tu jsem vypakoval

OMNISLASH: to je ten co bezi pres VirtualBox? nezustala ti tam nekde nejaka VM?

ta uz je pryc

OMNISLASH: Nezbyla po nem slozka C:\User\*username*\.docker?

nejake zkusenosti s dockerem pro windows, respektive s docker toolboxem? jak ze systemu odstranim vsechan jeho chapadla? po odinstalaci a nasladnem smazani vsech oddenku, co si kde nechal, mi stale schazi misto, ktere zmizelo za jeho cinnosti. nikde jsem nenasel zadnou rozumnou dokumentaci, ze ktere by bylo patrne, co si kde pri jake prilezitosti odklada

Dneska Troubleshooting Docker na Packtpubu
Free Learning - Free Programming eBooks | PACKT Books
https://www.packtpub.com/packt/offers/free-learning

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.