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: 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

fuck ted jsem 3 hodiny zjistoval proc se nemuzu z hostu dostat na container kdyz ho spoustim pomoci docker-compose run. Staci dat --service-ports.

docker-compose run --service-ports

RUDOLF: "outbound rveme mimo AWS" - chápu teda správně, že webový/aplikační servery máte mimo AWS? Můžeš to trochu rozepsat kde a jak to provozujete?

QUICK: serverless;-) ale to není trik, ale tuna práce;-)

Všechno co má outbound rveme mimo AWS;-) Ale CDN používáme globálně, hoříme hlavně na storage.

ADMIX: jsem teda škrt, ale přijde mi +-$250 jen za traffic jako dost. Pro porovnání teď ten web jede na třech 3 VPS na Vultr (web 4 vcpu/8gb, postgres 1 vcpu/2gb, elastic 1vcpu/2gb) a celý provoz vyjde i se zálohama na $70.

Chápu teda správně, že kromě Lightsailu, žádný kouzelný trik, který by výrazně snížil cenu na AWS není? Asi hold zůstanu u menších poskytovatelů typu Vultr/Digital ocean...

ADMIX: A jaký jsou teda postupy, jak to z AWS servírovat levněji? Logicky bych čekal, že bude levnější a rychlejší servírovat obrázky, CSS, JS z CDN, ale pokud si pamatuju správně, tak outbound traffic byl Cloudfront snad ještě dražší, než přímo z EC2 :D

DOKIS: jasny - lightsail je takova VPSka s trochou cukriku, daj se do toho naklikat ruzny ficury co te maj natahnout do kloudu - kontejnery, balancer, real EC2 instance apod.
ja bohuzel uz nemam vubec prehled co se cenove/komplexitou vyplati u tehle malejch deploymentu, ale obecne myslim plati ze hola EC2 je nejdrazsi, kdyz si nacpes assets do S3 tak je to levnejsi, kdyz S3 schovas za cloudfront tak zase o trochu levnejsi (plus vsechny vyhody CDN zejo), a pak jsou balancery (L4/L7) ktery stoji tusim jeste o neco min. Od CDN vejs (co se tyce komplexnosti) pak zalezi kudy ti ten provoz tece a kam, pac ruzny regiony stojej ruzne.

Souhlasim ze ansible nebo neco podobnyho je dobrej zacatek kdyz to ma 2-3 kontejnery, akorat 3TB mesicne outbound uz neni uplne trivialni kdyz to bude honit jen na holejch instancich - coz sam psal; zbezne koukam na cenik ze takovej provoz z EC2 je eazy 300 dolaru mesicne, takze tam bych uz radsi dal neco pred to.

KING: to zní dobře, s ansible nemám zkušenosti, okouknu to :)

DOKIS: Na lightsail jsem koukal, ale nedokázal jsem přijít na to proč pak upřednostnit AWS třeba před Digital Ocean, který mají ten pricing obecně přístupnější.

ADMIX: Ja to nejak podrobne neresil, muj traffic je minimalni. Jestli to AWS nejak cestou vyrazne ovlivnuje netusim. Z mojeho pohledu se to chova jako virtualni server primo dostupny pres verejnou IP adresu.