• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    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
    DOKIS
    DOKIS --- ---
    QUICK: Pokud nepotrebujes primo EC2, tak AWS LightSail ma 3TB transfer zahrnuty uz v $10/mesic planu. Ale tam je zase otazka, jestli ti staci jeden virtualni procesor, 2GB RAM a 60 GB SSD, ktere ten konkretni plan nabizi. Co jsem to kdysi pocital, tak LightSail vychazel podobne jako EC2, jen s vyrazne vetsim objemem dat v cene. Jen tam mas o hodne mensi moznosti konfigurace oproti "plnemu" EC2...
    QUOING
    QUOING --- ---
    QUICK: ja treba resim dynamicky routovani v nginxu (tedy s forkem openresty) + redis

    Zalozeno na:
    OpenResty - Dynamic Routing Based On Redis
    https://openresty.org/en/dynamic-routing-based-on-redis.html

    Pres redis-cli pak proste prepises klic v DB a routuje se tam kam potrebujes..
    KING
    KING --- ---
    QUICK: preklep, melo to byt git pull, pardon. Uz jsem v hlave premyslel nad tou druhou casti :)

    dynamicky udpdate resit nginx plus (komercni), ale v tomhle pripade bych se nebal ansiblem pregenerovat konfiigurak a dat reload, nginx to provede bezvypadkove a tak jako tak chces mit ten konfigurak spravovany ansiblem
    QUICK
    QUICK --- ---
    KING: mate mě, že píšeš, že to používáš bez dockeru a první příkaz máš docker pull. Můžeš to rozvést?

    Moc díky za doporučení. Ohledně toho přepnutí nginxu aby ukazoval na nový docker, jde to vyřešit nějak jednoduše, abych nemusel lézt do konfigurace nginxu, změnit tam adresu a restartovat ho?
    KING
    KING --- ---
    QUICK: Ja mam stejny setup (Django, Postgres a Elastic) a pouzivam to bez dockeru protoze mi to prislo jednodussi, jak to delam ja:
    * docker pull
    * pip install -r requirements.txt
    * migrate/collectstatic/...
    * restart gunicorn

    Postgres i Elastic (take jeden node, kdyz neni potreba vic, tak je za nej zbytecne platit, nikoho zabijet nebudu :) ) mam na cloudu protoze to nechci resit (RDS a Elastic Cloud). Celkovy naklady na provoz jsou hluboko pod $100 mesicne na AWS (t4g.micro, t2.micro RDS a 1 node na elastic cloudu, mame ale zatim maly traffic).

    Pokud uz to mas dockerizovany tak bych doporucil:
    * nahrat novou image s novou verzi aplikace
    * pustit docker
    * idealne pustit nejaky smoke test
    * prepnout nginx aby ukazoval na novy docker
    * zabit stary docker

    Budes to mit uplne bezvypadkove pokud ti to logika dovoli - nekde budes muset prizpusobit jak delas napriklad migrace aby sli delat tak, ze stara verze bude moct stale mluvit s novou DB.
    Kliknutím sem můžete změnit nastavení reklam