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.

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

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

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.

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.

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.

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

FALLENANGEL: pokud mám "appku v pár kontejnerech", jde řešit zero downtime deployment bez Kubernetes?

JON: :P 'jako jo, no...'

REFLEX: Jako jo, Kubernetes zvlada orchestrovat opravdu velky prostredi, takze pokud mas jednu malou appku v par kontejnerech, je to trochu overkill. Na druhou stranu kdyz tomu venujes cas a naucis se to, tak s nim muzes delat opravdu zajimavy veci. Nemluve o tom, o kolik stoupne tvoje cena na trhu prace ;)

Jenom si ted nejsem jistej, jestli porad podporujou Docker jako container runtime.

REFLEX: jako jo, a ne - kdyz chces jen pustit par apek v kontejnerech je to nesmysl.
Ale jakmile nad tim chces nejake blue-green, canary deploymenty, nebo rolling update / zero downtime, pripadne testy celeho deploymentu usetri to fakt hrozne moc prcani.
Proste to tam uz je vymysleny a udelany, a kdyz to budes chtit zorchestrovat nejak jinak, tak to budes muset napsat nejak sam.