Deploy aplikace v nette v dockeru pres Mesos/Marathon
- dada-amater
- Bronze Partner | 52
Ahoj, potreboval bych pomoct od nekoho, kdo je dobrej. A to jste tady vsichni, takze jsem bez obav, ze se tohle rychle vyresi :-).
O co jde:
Spustili jsme web na nette: Amateri.com. Cela aplikace je v docker kontejneru a bezi to naprosto bez problemu v nekolika instancich. Problem mam s deployem nove verze. Ty jsou nekolikrat denne.
Idealni stav:
Push do masteru → jenkins build (testy, tvorba docker image, nahrani image do
repository) → marathon rolling update (postupne nahrazovani kontejneru a
rekonfigurace proxy) = teoreticky bezvypadkovy deploy.
Problem:
Vypadek jako prase (cca 1–2 min). Zub jako prase, z prumernych 100ms za
vygenerovani stranky to hodi desitky vterin.
Pouzivam:
sablony v souborech, cache sablon v memcache
cache obecne memcache
journal Kdyby/Redis
Puvodne jsem si myslel, ze se triska nejaka cache se zavislosti Cache::FILE. Tudiz si to paralelne pustene verze prepisuji. Ale ja to tohle nepouzivam.
Pouzivam New Relic, je do kodu dost videt, ale v cem je prapuvod problemu jsme nenasel. Muze byt v nette, muze byt v mem kodu, muze to byt docker.
Resim to prubezne par tydnu a nepovedlo se mi to opravit. Za tyden letim na dovolenou na ctvrt roku, rad bych to mel v cajku ;-). Kdo mi pomuze, rad ho dobre zaplatim. Hrat ho muze predevsim pocit, ze ceske porno nebude zobrazovat ani jeden 502 error a honici budou jeste vic honit ;-).
Edit: Nette je v2.0.18. Vim, upgrade je v planu.
Editoval dada-amater (25. 11. 2015 15:58)
- studna
- Člen | 181
Chtelo by to vice informaci o konfiguraci a nejake runtime logy z kontejneru. Takhle je fakt tezko rict, kde hledat problem.
Ja ten deploy na serveru resim velmi podobne (Git → CI/CD → deploy → run). Jen s tim rozdilem, ze ty stare kontejnery nahrazuji novymi az v okamzik, kdy jsou plne nastartovane (vetsinou mi tam bezi jeste nejake init skripty, ktere vytvari cache apd.).
- skrivy
- Člen | 51
Popravde neznam marathon, takze odpoved bude spis obecna.
Pokud je balancer http, tak bych do logu pridal backend server, ktery pozadavek zpracoval a cas jak dlouho ho zpracovaval. Logy bych pak porovnal s tim deployment toolem a zkusil zjistit, jestli je nacasovani zmen balanceru opravdu spravne a neposila traffic na backend, ktery je uz down nebo jeste neni up.
Koukni do logu a kdyz tam uvidis, ze se pozadavky zpracovavaji moc dlouho, tak bych zkusil zjistit proc – to myslim pujde jednoduse nasimulovat i mimo produkci – jednoduchy ab by k tomu mel stacit.
Jaky je tam balancer? A co vsechno bezi v tech docker kontejnerech? Redis a memcached bezi taky v nich nebo maji svuj kontejner?
Na balanceru se pak daji take nastavit health checky, ktere mohou pomoci predejit tomu, ze je na backend zasilan provoz ikdyz backend jeste nebezi uplne ready.
Editoval skrivy (25. 11. 2015 21:34)
- dada-amater
- Bronze Partner | 52
studna napsal(a):
Chtelo by to vice informaci o konfiguraci a nejake runtime logy z kontejneru. Takhle je fakt tezko rict, kde hledat problem.
Ja ten deploy na serveru resim velmi podobne (Git → CI/CD → deploy → run). Jen s tim rozdilem, ze ty stare kontejnery nahrazuji novymi az v okamzik, kdy jsou plne nastartovane (vetsinou mi tam bezi jeste nejake init skripty, ktere vytvari cache apd.).
Co pouzivas na deploy? Ja prave pouzivam marathon. On ten kontejner spusti a pres zaregistrovany event o nem da vedet (o vsech zmenach). Ja spustim script, ktery nacte pres REST api novou konfiguraci z marathonu, vygeneruje nastaveni pro haproxy a reloadne ji. Marathon kontroluje i stav (healthcheck), umi i http check (ktery by mohl cache vygenerovat). Ale mozna spusti traffic na conteiner, ktery jeste neni zeleny.
- studna
- Člen | 181
Deploy a spousteni kontejneru jsem si musel napsat sam, mame to dost specificky resene.
Zkus tady dat nejake logy z kontejneru, co mu tak dlouho trva, nez se nastartuje. Nicmene jak psal skrivy, proxy by ti nikdy nemela smerovat traffic na kontejner, ktery jeste neni ready. Zvlast pokud jich startujes hned nekolik.
- dada-amater
- Bronze Partner | 52
Se Skrivym jsme to dali dohromady, timto mu patri velky dik. Kazdy z vas mel kus pravdy. Problemu bylo vicero:
- prilis rychly nekolikanasobny reload haproxy zapricinil, ze tam pak visely stare instance haproxy, ktere smerovaly na mrtve kontejnery → 502.
- v kontejnerech se spustil nginx rychleji nez php-fpm stihalo obsluhovat prvni pozadavky → 502.
Mam fakt radost, je to posledni velky stripek, co me trapil. Jeste jednou DIKY.
- studna
- Člen | 181
Prakticky nad danym kontejnerem sleduji jeho stav. Pokud je vse ready, tak aktualizuji proxy pomoci Docker Gen a starsi kontejner jednoduse odpojim/vypinam. :-)