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.