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

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ší.