MARTEN: tyjo vlastni projekty bych dal na cloud ve chvili kdy to vydelava penize a vzal bych na to nejakyho profika a udelal to s nim, strasne moc prace a na zacatku minimalni profit

MARTEN: za me aws a vlastni image postavenej na nejakem zakladu co ma vetsinu veci co potrebujes uz v sobe, lepe si pak muzes managovat upgrade na vyssi verze, zvednes jen to co uz je dele stable a opravdu vyuzijes ty nove features, je to nejaka rucni prace, ale zase mas plnou kontrolu vcetne detailu instalaci, napr. TZ apod.

Uplne nevim jestli to davat sem, ale kdyz uz je tu debata o cloudech a toolech.
Pro vsechny klientske projekty jsem vzdy mel moznost pouzit nejake self hosted cloud reseni (openshift,....). S AWS, GCP mam minimalni zkusenost. Ale ted mam vlastni projekt, ktery nechci hostovat na vlastnim serveru (i kdyz docker), ale rad bych to dal do cloudu. Hlavne kvuli SLA a protoze cekam vetsi navstevnost, tak skalovani muze byt taky dulezity faktor.
Otazka je kam to nejlepe dat. Technologicky php, nodejs, python, postgres, redis, rabbitmq, elk. Kdyz koukam ne nektere cloud reseni, tak vetsina ma postgres, ale treba ne rabbitmq a elk. Vzdy tam muzu mit vlastni image, ale urcite by bylo prijemne pouzit pripravene cele reseni a nemuset zbytecne nic nastavovat. Je neco co osobne preferujete? Koukam i na cenu, precejen to zatim budu dotovat ze sveho, nejlepe i datacentrum v CR nebo blizko. Zahranicni traffic bude minimalni.

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?