• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    Docker aneb přístupný provoz kontejnerizovaných aplikací
    Docker(Hub), Compose, Swarm, boot2docker, DevOps, LXC, ECS, TumTum a jiné buzzwordy
    Bezpečnost v prostředí kontejnerů
    Related: automatizace [ Centralizovaná správa stanic a ostatních prvků v síti konfigurace/inventarizace/instalace/aktualizace/zalohovani ]
    rozbalit záhlaví
    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.
    QUICK
    QUICK --- ---
    KING: FALLENANGEL: Rád bych to rozebral konkrétněji. Provozuju střední web, historicky to běží na třech VPS instancích - jedna pro web (Django), jedna pro Postgres, třetí Elasticsearch (KINGu ty mě asi nakope za provoz elasticu na jednom nodu, ale pro ty objemy vyhledávání co mám je to zatím v poho)

    Všechno teď mám nainstalované přímo v systému bez dockeru. Nasazení nové verze jsou v zásadě tři příkazy:
    - git pull
    - případná aktualizace db přes python manage.py migrate
    - restart gunicornu

    Což je pro mě docela jednoduchý na nasazení nové verze aplikace, a když se všechno povede, tak návštěvníci výpadek nezaznamenají. Ale uvědomuji si, že to není správný řešení. Nedá se spolehnout, že na devu a produkci se používají stejné verze všech balíků a knihoven. Updatu systému (apt get) / restart mašiny není bezvýpadkový a je potřeba se předtím pokřižovat, aby se nic nevysypalo. atp.

    Lokální vývojové prostředí už do mám dockerizované, ale pořád se odhodlávám, jak to úspěšně převést na produkci. CI, Kubernetes a většina devops věci jde tak nějak mimo mě. Dokázali byste mě navést jaký zvolit postup?

    Hlavně bych chtěl aby výsledný řešení bylo tak akorát robustní, nasazení bylo rychlý, předcházelo se výpadkům při nasazení a případný rollback, šel udělat rychle. V úplně nejdivočejších snech bych v budoucnu chtěl ještě spustit jeden extra cluster v Americe (django, postgres jako slave), aby dokázal pokrýt read-only requesty z Ameriky.

    A AWS/Google cloud jsem nikdy nepoužíval, ale asi při mém trafficu (2-3 TB měsíční outbound) by to asi lezlo do peněz.
    KING
    KING --- ---
    FALLENANGEL: Ja bych to asi resil jednoduchym ansible playbookem, prijde mi to o rad jednodussi nez nejake platformy. Ty bych mel v zaloze az by moje aplikace prerostla stav "v nekolika kontejnerech."
    FALLENANGEL
    FALLENANGEL --- ---
    QUICK: Dobra otazka. Predpokladam, ze existuji i jine orchestracni platformy nez Kubernetes, ale vsechno co me ted napada jsou vlastne platformy postaveny prave na Kubernetesu (Rancher, Tanzu, GKE).

    KING: Myslel jsem to tak, ze jedna aplikace ma vice komponent, kazdou v jinym kontejneru. Takze spis jde o to spustit kontejnery s novou verzi, presmerovat na ne ingress a smazat stare kontejner.
    KING
    KING --- ---
    QUICK: samozrejme, stejne jako slo resit zero downtime deployment bez kontejneru. Typicky proste staci neshodit vsechny kontejnery najednou, ale jeden po druhym a nahradit je novym. Pokud je tam zabudovana redundance, tak to staci. Konkretni provedeni zalezi na zpusobu orchestrace
    Kliknutím sem můžete změnit nastavení reklam