QUICK:
- mi máme Django ve dvou EC2 replikách, udělal bych to stejně i ve swarmu, vlastně to tak mám asi pro wagtail. Při aktualizace service nahradí swarm ty repliky postupně myslím. Otázka jestli to nemá nějaký side-effect, když běží pár vteřin ty repliky souběžně, tj. že něco zapisuje appka se starým db modelem a něco appka s novým db model. Vůbec netuším jestli to má Django nějak ošetřený, ale děláme to tak na produkci:-)
- GCP neznám, jen je rozumný tím kontejnerům nastavit limit v MB na logy a počet souborů. Obzvlášť pokud má host malý úložiště. Logy stejně posíláme do centrální služby a ta má zpravidla vlastní retenční politiku.
- obecně je dobrý nechat ty appky běžet pod non-roootem.Tj. když tam není nějaký app-specific voser, tak se to vyplatí.
Na co si dát pozor - monitoring hosta a kontejnerů, kdyby bylo nějaký issue, abys to viděl. Tj. je užitečný sledovat paměť, CPU a udělat si alerting. Samosebou, je dobrý monitoring SQL queries při debugování. Ale na to jsme používali New Relic, který má hezký insight do appky. Tj. app monitoring je vždycky dobrý:--)
No a určitě je dobrý mít sepsaný postup, jak ten swarm budeš upgradovat:-) Pro mě upgrade clusteru hlavní důvod proč přejít do managed orchestraci:-) Dělám to pomocí nějakýho AWS CF od dockeru a jen se modlím ať to tvůrce udělal co nejsprávněji -> většinou je to jen nahrazení EC2 instancí novějšíma verzema dockeru. TTaky se hodí si vyzkoušet, jestli umíš obnovit stav swarmu, když ztratí raft konsenzus:-) Mě se to nikdy nepovedlo nahodit na testovacím prostředí a vždy jsem ty stacky znova deploynul. A na produkci se mi to nikdy nestalo.