Django v Docker

[PavelZet]

1) Provozujete někdo ostrý projekt v Dockeru ?

2) Dá se říct že Docker plně nahradí Venv ?

3) Zkušenosti s Dockerem jsou kladné nebo lze očekávat záludnosti ?

4) Používáte Docker přímo v OS serveru nebo v nějakém virtuálním prostředí (Proxmox) ?

5) Řešili jste migraci Dockeru jinam ?

6) Používáte na produkci Kubernetes ke spokojenosti ?

7) Konfiguraci Dockeru je vhodnější zahrnout do gitu nebo přes puppet ?

8) Používáte Docker pod Linux či pod Windows ?

Díky za zkušenosti.

My používáme Docker pouze na vývoj pod Windows a pár problémů už sme měli

- starší stroje neumí Docker nativně

- na některých moderních strojích asi 100x pomalejší diskové operace

- Docker po vypnutí a zapnutí PC nereaguje a musí se manuálně restartovat

[Plovarna]

1) Provozujete někdo ostrý projekt v Dockeru ?

Ano

2) Dá se říct že Docker plně nahradí Venv ?

Ano

3) Zkušenosti s Dockerem jsou kladné nebo lze očekávat záludnosti ?

Kazda technologie ma nejake zaludnosti a zvlastnosti, Docker na tom neni jinak

4) Používáte Docker přímo v OS serveru nebo v nějakém virtuálním prostředí (Proxmox) ?

OS

5) Řešili jste migraci Dockeru jinam ?

Nerozumim jak to myslis. Zkus to prosim vic rozepsat.

6) Používáte na produkci Kubernetes ke spokojenosti ?

Ano, ale zatim prilis kratce aby se to dalo hodnotit. Zatim mi to pripada jako velky moloch, ktery se hodi spis na vetsi projekty. 

7) Konfiguraci Dockeru je vhodnější zahrnout do gitu nebo přes puppet ?

Upresni prosim dotaz (co myslis “konfiguraci Dockeru”?)

8) Používáte Docker pod Linux či pod Windows ?

Linux

Maj sa

Michal

[Petr Messner]

út 23. 10. 2018 v 16:58 odesílatel PavelZet <zeh...@gmail.com> napsal:

1) Provozujete někdo ostrý projekt v Dockeru ?

Ano.

A ty, které v Dockeru nejsou, migrujeme do Dockeru, jakmile je potřeba na ně nějak sáhnout.

 

2) Dá se říct že Docker plně nahradí Venv ?

Jsou to různé technologie určené k různým věcem (i když mají určitý překryv), takže takhle bych to neřekl.

Např. Docker používáme pouze na serverech a lokálně jedeme přes venv v každém projektu, je to jednodušší. A vím o lidech, kteří mají přesně naopak :)

Co se samotného Dockeru týče, spíš očekávám, že Docker sám bude nahrazen nějakou alternativou, která ale bude dělat v podstatě to samé :)

 

3) Zkušenosti s Dockerem jsou kladné nebo lze očekávat záludnosti ?

Stačí vědět, jak fungují linuxové procesy, síťování, iptables, cgroups. Pak žádné záludnosti nejsou :D

Spíš jsou záludnosti okolo snah o management a deployment Dockeru.

 

4) Používáte Docker přímo v OS serveru nebo v nějakém virtuálním prostředí (Proxmox) ?

No přímo v OS (Debian) ve virtuálním serveru :)

A jestli tu chce někdo namítat, že používáme "dvě virtualizace uvnitř sebe", tak ať se laskavě vrátí k mé odpovědi v bodu 3.

 

5) Řešili jste migraci Dockeru jinam ?

Taky nechápu otázku. Ale obecně je nesmysl cokoliv migrovat, když je jednodušší to vypnout/smazat/zrušit a vytvořit znovu.

 

6) Používáte na produkci Kubernetes ke spokojenosti ?

Nepoužíváme, ke své spokojenosti.

 

7) Konfiguraci Dockeru je vhodnější zahrnout do gitu nebo přes puppet ?

Ano.

Rozhodně vše do gitu. Jak jinak to chcete dělat? Psát si poznámky na papír, co jste si kde jak nakonfigurovali přes ssh a vim? SSH na servery zakázat (kromě emergency situací, a deadline není emergency).

Ansible, Salt, Puppet jsou ok. Nepotřebujete instalovat Kubernetes, pokud neděláte infrastrukturu jako službu pro firmu se 100+ IT lidmi. A to byste se tu takhle asi neptali :)

 

8) Používáte Docker pod Linux či pod Windows ?

Windows jsme zakázali.

V produkci náš software jede na Linuxu a věnovat byť jen minutu nějakému ohýbání, aby to jelo na něčí WIndows dev mašině, je absolutně zbytečná práce.

 

Díky za zkušenosti.

My používáme Docker pouze na vývoj pod Windows a pár problémů už sme měli

- starší stroje neumí Docker nativně

- na některých moderních strojích asi 100x pomalejší diskové operace

- Docker po vypnutí a zapnutí PC nereaguje a musí se manuálně restartovat

Proč proboha vyvíjíte na Windows? :)

"starší stroje neumí Docker nativně" - aha, ty asi myslíš, že starší stroje nemají CPU s nativní podporou virtualizace, takže vám pomalu běží ten Virtualbox, ve kterém je teprve ten Docker. To je ale problém Virtualboxu, resp. váš, že to děláte takhle, a ne Dockeru.

Navíc nativní podpora virtualizace je tu už 13 let.

"na některých moderních strojích asi 100x pomalejší diskové operace" - nejspíš to samé.

Zdar :)

PM

[Petr Messner]

PS. ještě doplňuji pár detailů :)

 

1) Provozujete někdo ostrý projekt v Dockeru ?

Ano.

A ty, které v Dockeru nejsou, migrujeme do Dockeru, jakmile je potřeba na ně nějak sáhnout.

V Dockeru akorát neprovozujeme databáze a některé postranní procesy (firewall, log management, monitoring).

 

 

5) Řešili jste migraci Dockeru jinam ?

Taky nechápu otázku. Ale obecně je nesmysl cokoliv migrovat, když je jednodušší to vypnout/smazat/zrušit a vytvořit znovu.

"migraci" tady chápu jakože typu ze serveru na server.

"vypnout/smazat/zrušit a vytvořit znovu" samozřejmě za předpokladu, že to "vytvořit znovu" máte zcela zautomatizované. A že architektura celé aplikace počítá s tím, že některé její části chvíli nepojedou nebo naopak pojedou víckrát vedle sebe. Tady už jsem ale od Dockeru hodně odbočil.

Podíval jsem se na ten Proxmox, na první pohled mi to přijde jako nějaká modernější obdoba takových těch control panelů, případně jako krabicová varianta Openshiftu. Možná by nakonec bylo lepší probrat, co vás páli při vývoji a co se snažíte řešit, než pitvat jeden konkrétní nástroj (Docker).

PM

[btx]

1) Provozujete někdo ostrý projekt v Dockeru ?

Ano.

2) Dá se říct že Docker plně nahradí Venv ?

Pro mne je snažší lokálně stále vyvíjet ve virtualenvu. Docker mám lokálně rozběhaný, kvůli ladění, testování, experimentování,... 

 

3) Zkušenosti s Dockerem jsou kladné nebo lze očekávat záludnosti ?

Kládné. Záludnosti jsou, ale všechno je to o zkušenostech a RTFM :)

 

4) Používáte Docker přímo v OS serveru nebo v nějakém virtuálním prostředí (Proxmox) ?

OS serveru.

 

5) Řešili jste migraci Dockeru jinam ?

Ne.

 

6) Používáte na produkci Kubernetes ke spokojenosti ?

Ano, velmi, velmi spokojen. Používáme Google Kubernetes Engine.

 

7) Konfiguraci Dockeru je vhodnější zahrnout do gitu nebo přes puppet ?

Konfiguraci jak docker images tak Kubernetes clusteru mám v gitu.

 

8) Používáte Docker pod Linux či pod Windows ?

Linux, MacOS

[starenka .]

Kdyz je to tady nakousli dovolim si OT dotaz :p

Mam appku pres docker compose, je tam par imagu (appka se supervisorem, nginx, redis, postgres). Sem asi tupejsi, ale zatim se mi moc nedari pri deploy dosahnout zero downtimu, na kterej byl clovek zvyklej s uwsgi/unicornem. (image zbuildim  a pak stopnu pustim vsechno, ale vubec nakopnuti tech kontajneru je v radech sekund, coz mi pride uplne absurdni)

A druhej dotaz, jak to resite s redisem? Mam v nem data o ktery nechci behem deploye prijit (fronta jobu), ale prichazim.

Dik

-----
'aknerats'[::-1]

--
--
E-mailová skupina djan...@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
---
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „django-cs“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete e-mail na adresu django-cs+...@googlegroups.com.

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/cbba535d-d636-41fe-906c-0227fac98cde%40googlegroups.com.

Další možnosti najdete na https://groups.google.com/d/optout.

[Plovarna]

Mam appku pres docker compose, je tam par imagu (appka se supervisorem, nginx, redis, postgres). Sem asi tupejsi, ale zatim se mi moc nedari pri deploy dosahnout zero downtimu, na kterej byl clovek zvyklej s uwsgi/unicornem. (image zbuildim  a pak stopnu pustim vsechno, ale vubec nakopnuti tech kontajneru je v radech sekund, coz mi pride uplne absurdni)

Kontejner s appkou bezi v nekolika kopiich za load balancerem, pri deployi pak Rancher ci Kubernetess postupne zabiji stare kontejnery a startuje nove. Tj. resi to dalsi vrstva. Docker compose pouzivam jenom na lokale (jako jo, jednou jsem ho mel i venku na mensim soukromem projektu, a tam to probihalo podobne jak u tebe, tj. zastavit a zas pustit, var vterin downtime)

A druhej dotaz, jak to resite s redisem? Mam v nem data o ktery nechci behem deploye prijit (fronta jobu), ale prichazim.

Vsecko dulezite s persistenci je mimo Docker: DB, Redis jako sluzby na dane platforme nebo samostatne v nejake managovane instanci. Primo v OS, bez zadnych mezivrstvev. Docker kontiky jsou jepice, zabit, pustit, zabit, pustit, … 

Maj sa

M.

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CA%2B7MNVqTk9ssRQjnANH5TRcCUFf9qKq55cTwk4_mjoKDNYNPjQ%40mail.gmail.com.

[Petr Messner]

pá 26. 10. 2018 v 8:35 odesílatel starenka . <star...@gmail.com> napsal:

Mam appku pres docker compose, je tam par imagu (appka se supervisorem, nginx, redis, postgres). Sem asi tupejsi, ale zatim se mi moc nedari pri deploy dosahnout zero downtimu, na kterej byl clovek zvyklej s uwsgi/unicornem. (image zbuildim  a pak stopnu pustim vsechno, ale vubec nakopnuti tech kontajneru je v radech sekund, coz mi pride uplne absurdni)

Docker compose považuju za dev tool, na produkci mi nejpřijde úplně vhodný - z důvodu, který píšeš, taky nechává za sebou pěkný bordel v kontejnerech, minimálně jednou se mi dostal do nějakého rozbitého stavu apod.  Ale je to jen můj spíš subjektivní názor, možná ho neumím nakonfigurovat. Funkcionalitu compose mi dělá Salt/Ansible.

Zero downtime řeším buď více běžícími kontejnery vedle sebe za nginxem, případně Python skriptem, který zorchestruje blue-green deployment. Je fajn mít assets (img, css, js) od toho úplně oddělené a uploadnout je do CDN dřív, než dojde k přepínání.

 

A druhej dotaz, jak to resite s redisem? Mam v nem data o ktery nechci behem deploye prijit (fronta jobu), ale prichazim.

Databáze a podobné věci mám mimo kontejner. Co kontejnerizace přinese za výhody? Kontejner je super jako způsob "zmražení" a deploymentu tebou implementované konponenty, nebo nějaké 3rd party věci. Ale databáze už bývají dost pěkně zabalíčkované v distribuci, takže tam ani není ten problém, který bych jinak řešil Dockerem.

Ale znám lidi, kteří provozují v Kubernetes i databáze. Opět, jde o případ, kdy nějaké "devops support" oddělení připraví infrastrukturu pro ostatní týmy, a když už to dělají, tak je jednodušší do toho zahrnout i databáze a řešit vše uniformně, než řešit databáze jinak. Je to spíš o takovém tom stylu, jak se vám líbí dělat věci.

 

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CA%2B7MNVqTk9ssRQjnANH5TRcCUFf9qKq55cTwk4_mjoKDNYNPjQ%40mail.gmail.com.

[Jan Bednařík]

pá 26. 10. 2018 v 8:35 odesílatel starenka . <star...@gmail.com> napsal:

Kdyz je to tady nakousli dovolim si OT dotaz :p

Mam appku pres docker compose, je tam par imagu (appka se supervisorem, nginx, redis, postgres). Sem asi tupejsi, ale zatim se mi moc nedari pri deploy dosahnout zero downtimu, na kterej byl clovek zvyklej s uwsgi/unicornem. (image zbuildim  a pak stopnu pustim vsechno, ale vubec nakopnuti tech kontajneru je v radech sekund, coz mi pride uplne absurdni)

Rozděl to na samostatné docker compose, kde zadáš stejný network, aby na sebe kontejnery viděly. Kvůli updatu appky nepotřebuješ restartovat ostatní věci. A když bys chtěl fakt zero downtime, pusť appku dvakrát a restartuj/updatuj její kontejnery nezávisle.

Není to tak sofistikované jako Kubernetes apod., ale na jednoduché věci good enough.

 

A druhej dotaz, jak to resite s redisem? Mam v nem data o ktery nechci behem deploye prijit (fronta jobu), ale prichazim.

Viz výše, nechej ho běžet :-)

 

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CA%2B7MNVqTk9ssRQjnANH5TRcCUFf9qKq55cTwk4_mjoKDNYNPjQ%40mail.gmail.com.

[starenka .]

Appka sama o sobe nemuze bezet dvakrat z duvodu, ktery tady nechci rozebirat (ve zkratce taha to data, ktery sou stream a nemuzu se tam pripojit vickrat a zaroven je blby kdyz kus dat ztratim. Ty data se pak zpracovavaji zpusobem dost narocnym na zdroje pres rq, takze i tim musim setrit, aby to na ty masine vubec jelo +- realtime). 

Za napad s vic sitema a oddelenim dik, to me nenapadlo...

-----
'aknerats'[::-1]

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAMmgUkPaN_6LDAU9DmeO1LwG%3DXNTXFM-%3DF41gPSSCqBvkHt2_Q%40mail.gmail.com.

[Petr Messner]

pá 26. 10. 2018 v 23:23 odesílatel starenka . <star...@gmail.com> napsal:

Appka sama o sobe nemuze bezet dvakrat z duvodu, ktery tady nechci rozebirat (ve zkratce taha to data, ktery sou stream a nemuzu se tam pripojit vickrat a zaroven je blby kdyz kus dat ztratim. Ty data se pak zpracovavaji zpusobem dost narocnym na zdroje pres rq, takze i tim musim setrit, aby to na ty masine vubec jelo +- realtime). 

Nevím, o co přesně jde, můžeme se o tom pobavit na Pyvu :) Ale obecně se v těhle případech snažím ten “síťový” problém oddělit do samostatné, co nejminimalističtější komponenty (procesu), a na to pak navázat už nějak normálně, aby to odpovídalo “standardům mojí infrastruktury”.

Příklad: mám aplikaci, která hodně používá websockets. A já chci, aby ta spojení byla co nejstabilnější, např. aby se neresetovala, když nasadím novou verzi aplikace. Samozřejmě bych toho klienta měl mít udělaného tak, aby zkoušel reconnect, ale i to chci pokud možno minimalizovat. Tak jak to teda udělám, abych mohl nasadit novou verzi aplikace a ty websockety to nejen neshodilo, ale aby se dokonce “přesunuly” na tu novou verzi? Tak, že tu aplikaci rozdělím na “vstupní část”, která skoro nic nedělá, jen udržuje ta spojení a poskytuje nějaké úplně low-level API pro tu “aplikační část”, která teprve obsahuje nějakou business logiku. A cílem je při nasazování nové verze nasazovat jen tu aplikační část, a naopak minimalizovat hýbání s tou síťovou částí. U klasických webových aplikací tuto roli hraje v podstatě load balancer, a ten vlastně taky obvykle bývá “mimo” (hlavně v cloudu).

Python je na tohle použití super, mj. díky asyncio. Ale dá se to napsat i v C/C++ za použití libuv, zmq apod. a na to pak navázat v Pythonu. 

No a tu aplikační část bych dal klidně do kontejneru, ale tu “low-level síťovou část” bych spíš nechal mimo (klidně i na jiném VM/hardware).

Tohle se vůbec nemusí týkat Stařenky, jen píšu svůj pohled na věc :)

PM

[Honza Král]

Take to takhle delim na vstupni vs "aplikacni" cast, ja takhle hlavne resim vstupy typu UDP kde je prvni super tenka vrstva ktera jen cte a preposila do solidnejsiho uloziste (typicka kafka).

Vubec bych se ale nebal tohle vsechno bezet v dockeru, nemam rad michani raw OS veci a dockeru a ani k tomu neni duvod, i databaze provozujeme v dockeru, jen je potreba samozrejme ohlidat napojeni volumes aby to melo primy pristup k disku a ne tu docker storage hybrid nad tim.

PM

--
--
E-mailová skupina djan...@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
---
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „django-cs“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete e-mail na adresu django-cs+...@googlegroups.com.

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAK9Q5BQE1x0-uGDS5E5H1JSUYh7dhMeOaJD%2Bwr%3DNTpJWpEwRxg%40mail.gmail.com.