• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    QUICK
    QUICK --- ---
    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?
    MARTEN
    MARTEN --- ---
    WOODMAKER: pozor, run spusti novy container. Pokud chces spustit neco v jiz bezicim, tak od toho je exec
    RAGNAROK
    RAGNAROK --- ---
    WOODMAKER:
    to jen kdyz zmenim neco v docker-compose jinak to neni potreba.
    WOODMAKER
    WOODMAKER --- ---
    RAGNAROK: proc restartujes kontas?
    WOODMAKER
    WOODMAKER --- ---
    SH_PANDA: container mu jede a on v nem pomoci RUN pousti ruzny prikazy (treba bash)
    RAGNAROK
    RAGNAROK --- ---
    SH_PANDA:
    1. Je to pohodlnejsi nez vypisovat vsechny nastaveni v commandline za pouziti docker run

    2. Ostatni containery bezi ale potrebuju otestovat nejakou zmenu v kodu v jednom kontasu.

    Pomoci dockefile mam vybuldeny prostredi a kod leze do konteineru krz volume, takze nemusim buildit image po kazdy zmene kodu. Zmenim kod a restartnu kontas.

    Dobry to je pro golang, python, bash kod.

    treba:
    docker-compose run contname bash
    a pak si jde hrat v containeru.

    samozrejme to jde i jinak
    SH_PANDA
    SH_PANDA --- ---
    RAGNAROK: aby jsi nemenil compode ale si jenom neco zkusil s kontajnerem a pak ho restartnul?
    RAGNAROK
    RAGNAROK --- ---
    SH_PANDA:
    na test
    SH_PANDA
    SH_PANDA --- ---
    RAGNAROK: a proc poustis docker-compse run? (jsem lama, chci znat odpoved)
    RAGNAROK
    RAGNAROK --- ---
    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
    RUDOLF --- ---
    QUICK: Děláme streaming kamer včetně broadcastingu. Takže máme edge servery všude kde jsou dobré linky za dobré peníze. Aplikační servery s daty máme v AWS, caching standardně přes Cloudfront a segmenty s nahrávkáma tahá zákazník z S3. Live view segmenty and broadcasting míjejí AWS kompletně, zákazník dostává segmenty přímo z edge serveru připojenýho ke kameře.

    Caching děláme hlavně kvůli latenci, máme jedno django pro zákoše ve dvou ec2 a další django ve swarmu jako marketing web. Všechno jede přes ALB, krom videa.

    Každopádně kdybych designoval něco nového, šel bych do spot instancí, lambdy a asi zůstal u ALB a Clloudfront. Abych řekl pravdu, náš hlavní cost v AWS je S3, computing při nahrávání a až pak dole networking. Tak největší optimalizace jsou na S3 a rust appkách v computing. K tomu se váže přesun do EKS kvůli servisám, který běží za ALB a nechceme je řešit jako instance.
    QUICK
    QUICK --- ---
    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?
    RUDOLF
    RUDOLF --- ---
    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.
    QUICK
    QUICK --- ---
    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
    ADMIX --- ---
    QUICK: Tos me dostal :D tohle je hrozne blbe pocita bez znalosti konkretniho usecase, a u balanceru/CDN hrajou roli regiony, tps apod.
    ale strelim od oka, rikal jsi 3TB traffic, EC2 outbound je ~290USD + tax; kdyz se podivam na ALB, dam jeden balancer, nejakejch 30 tps a 6TB processed bytes (pro pripad ze je to proste full duplex), tak ten vychazi cca 70USD + tax. Nahata S3 co posle 3TB do non-AWS internetu vychazi jen o chlup levnejc nez EC2, ale u S3 jsou ruzny triky (typu - traffic do AWS regions je tak tretina ceny, traffic do cloudfront je zadarmo, in-region EC2 traffic je taky zadarmo etc.). No a cloudfront na 3TB vychazi cca 250USD + tax, bez lambda@edge a jinejch ficur.

    premejslim kdy jsem napsal vic useless prispevek :D CDN treba urcite neni silver bullet na distribuci static assets, hrozne zalezi co to serviruje.
    QUICK
    QUICK --- ---
    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
    ADMIX
    ADMIX --- ---
    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.
    QUICK
    QUICK --- ---
    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ší.
    DOKIS
    DOKIS --- ---
    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.
    ADMIX
    ADMIX --- ---
    DOKIS: ono lightsail v tom bude nejspis mit nejakej balancer, kterej vyrazne srazi cenu outbound trafficu, ne? zaklad cloudu je mit cisla o svym deploymentu, a pak se kouknout kde chci veci behat, jak kriticky jsou a tak - treba co se tyce trafficu, tak servirovat outbound do internetu z EC2 je pravdepodobne nejdrazsi cesta jak to delat :D
    Kliknutím sem můžete změnit nastavení reklam