RATTKIN: jj, v djangu to jde i hezky propojit, ze je videt transakce z klienta az do databaze, klidne pres nekolik service. Bez toho bych si casto prisel jak slepy

QUICK: Ahoj, do Stackdriveru (Google Cloud Logging) posílám klidně i všechny SQL queries v rámci debugu. Nejsou to milióny záznamů za sekundu, ale hodně jich je a na limit jsem zatím nenarazil. Můžeš zkusit mrknout na spojení Stackdriver + Django. Ohledně nginxu nevím, spíš loguju věci z aplikace než z webserveru

RUDOLF: moc děkuji za podněty.

Souběh běžích replik v různých verzích je s Djangem ok. Ale je samozřejmě potřeba myslet, když se nasazují nějaké destruktivní změny v db (odebrání sloupců nebo tabulek, přejmenování sloupců). U toho je potřeba trochu myslet :)

S tím monitoringem máš pravdu, to bych měl zlepšit. Teď používám jen Sentry a Better Uptime, ale jsou nástroje spíš pro hašení než prevenci. Teď koukám, že New Relic má i sympatický free plan. Na to kouknu.

Chtěl bych v budoucnu přejít na Digital Ocean, protože mají managed Kubernetes. Tohle je takový mezistav, abych si vyzkoušel všechny věci okolo.

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.

Tak jsem vše připravil na migraci na docker swarm (QUICK). Původně jsem měl jeden webový stroj na něm nginx, gunicorn (python django appka), memcached a varnish. Rozsekal jsem to do 4 docker service, docker swarm má jen 1 node (stejně výkoný jako aktuální produkce). Na build a uložení image jsem použil Google Cloud služby. Chtěl jsem si primárně vyzkoušet provoz na dokerizovaných aplikací a bezvýpadkové přenasazení. V budoucnu bych chtěl swarm rozšířit o další node, který bude v jiné geo (USA), tak aby obsluhoval traffic z USA.

Měl bych k tomu pár otázek:
- má z nějakého důvodu cenu spouštět na jednom nodu víc replik gunicorn služby?
- máte nějakou zkušenost s použitím Google Cloud Logging? Ngnix do stdout posílá access log, tak aby se docker kvůli tomu nějak nezakuckával...
- standardní nginx, varnish, memcached image spouští proces pod rootem. Je to ok? V různých best practices jsem četl, že je lepší aby běželo pod jiným uživatelem (gunicorn container mi tak běží)

Obecně je něco na co bych si při provozu v tomhle setupu měl dát pozor?

QUICK: jj je to tak.. neni to nic extra kompikovanyho, kdyz to clovek pochopi a naskriptuje si to kolem tak se to na to nemusi vubec myslet

ADMIX: máš pravdu, db host a db name jsou spíš konfigurace, tak asi do env nebo docker config. Na druhou stranu vadí něčemu, když to budu držet v secrets? Můžu to stejně držet v docker config, který má v podstatě stejnou logiku jako secrets, jen se hodnoty nešifrují.

HOUMLES: jo, jednodušší je mít hromadu souborů a nezavádět složitosti. Půjdu touhle cestou. Díky za upozornění na neměnost secrets, to jsem netušil. Ale teď jsem si s tím hrál a nevypadá, že změna by byla velká pruda. V docker-compose.yml:

secrets:
  my_test:
    external: true
    name: my_test-v1
services:
  nginx:
    image: nginx:1.18.0
    secrets:
      - my_test

V službě je to vždy dostupné pod /var/run/secrets/my_test. Při změně secret je nutný vytvořit nový secret v swarmu a inkrementovat my_test-v1 v konfigu. Pak už volat docker stack na přenasazení nebo samostatně přes docker service:

docker service update nginx_nginx --secret-rm my_test-v1 --secret-add source=my_test-v2,target=my_test

QUICK: ja bych na to sel takhle... co je jednodussi? spravovat hromadu souboru s heslama a loginama nebo spravovat min souboru, ale k tomu navic spravovat kod, kterej to bude parsovat?
ja to mam teda vsude rozdeleny zvlast, jeden file = jedna promena ..pak se s tim i lip pracuje (napr. staci cat na soubor a mas heslo).
ale jinak zalezi na prostredi, tohle vsecko lze delat i pres env nebo pres docker-compose.. u nas se treba pouzivaj secrets protoze mame komplet kod v gitlabu, kde probiha i build a je docker repository, ale do gitu maji pristup i lidi co by nemeli ty secrety znat, treba heslo do produkcni db.
takze pokud se k tomu secretu nemuze dostat nikdo jinej nejak jinak tak bych to zbytecne moc nekomplikoval...
a nevim jestli uz jsi na to narazil, ale priprav se na to, ze je s tim pekny srani.. musis zajistit verzovani tech secertu ve swarmu, protoze pokud neco uvnitr souboru zmenis a on se jmenuje porad stejne, tak ti ho docker nenacte jako novej.

QUICK: Nikdy nedavej jakykoliv credentials do connection strings; db host and db name nejsou credentials, ty patri do nakejch configu (ktery pak zalezi na tom jak planujes DR, failovers etc.), a jmena/hesla/privatni klice prave do nakyho vaultu (nemam zadnou zkusenost s docker secrets :D )

Ahoj, v návaznosti na QUICK jsem se rozhodl na projektu produkční deploy zmodernizovat. Rozhodl jsem se využívat pro provoz docker swarm. Na hesla plánuji použít docker secrets a řeším v jakém formátu údaje do docker secrets ukládat. Třeba pro DB se nabízí buď vytvořit čtyř secrets (database_host, database_user, database_password, database_dbname) nebo použít jedno secret a uložit vše ve DSN formátu jako postgres://login:heslo@hostname/dbname

Druhý mi přijde takový elegantní, ale před použitím je to potřeba rozparsovat (což v python aplikaci není problém, jinde by být mohl). Je na tohle nějaká best practice jak postupovat?

Obecně bych zvolený princip rád uplatnil na další credentials, například k přístupu na jednu službu mám jen jméno a heslo. Buď můžu uložit jako 2 secrets service_x_login, service_x_password nebo pouze jedno secret a uložit ve formátu login:heslo.

Jaký způsob byste zvolili vy?

RAGNAROK: proc restartujes kontas?

SH_PANDA: container mu jede a on v nem pomoci RUN pousti ruzny prikazy (treba bash)

RAGNAROK: aby jsi nemenil compode ale si jenom neco zkusil s kontajnerem a pak ho restartnul?

SH_PANDA:
na test