Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: oksoft 26. 01. 2020, 00:52:29

Název: LXD nebo Docker
Přispěvatel: oksoft 26. 01. 2020, 00:52:29
Zdravím,
plánuji udělat aplikaci s rozhraním v JS (budu používat zřejmě Node.JS) a některými backend komponentami jak v Pythonu tak v JS. Ale nechci si dělat při spouštění a následných (ručních) testech v systému nepořádek, tak jsem si řekl že to budu spouštět v kontejneru. Jestli by mělo smysl spouštět celé prostředí v LXD nebo vytvořit Docker kontejner. Budu tam instalovat asi node a python.

LXD nebo Docker?
Název: Re:LXD nebo Docker
Přispěvatel: miro simko 26. 01. 2020, 05:41:45
Odporúčam docker, je tu presne pre tento účel. Pre python aj node nájdete na docker hube predpripravené image, môžte si tam len doplniť svoju aplikáciu.

Ďalej, doporučovaná cesta je rozdeliť jednotlivé komponenty do samostatných kontajnerov a použiť napríklad docker-compose. Ale ako študijná úloha práce s dockerom kvôli jednoduchosti samozrejme možno dať všetko do jediného.
Název: Re:LXD nebo Docker
Přispěvatel: oksoft 26. 01. 2020, 11:23:46
A co podman? Co by bylo lepší, Docker nebo Podman?
Zdroj mě nějak nezajímá, budu používat Snap Store (Používám Ubuntu).
Název: Re:LXD nebo Docker
Přispěvatel: Filip Jirsák 26. 01. 2020, 12:15:48
Pokud máte možnost volby, pak určitě Podman. Podman je Docker udělaný správně (nebo alespoň podstatně lépe).
Název: Re:LXD nebo Docker
Přispěvatel: Ondrej Nemecek 26. 01. 2020, 13:37:55
A proč ne LXD? Docker má připravené image a podporu pro návaznosti v procesu vývoje, to je jasné, ale jinak?
Název: Re:LXD nebo Docker
Přispěvatel: hawran diskuse 26. 01. 2020, 14:36:20
... Podman je Docker udělaný správně (nebo alespoň podstatně lépe).

Mohl bys to rozvést?
Název: Re:LXD nebo Docker
Přispěvatel: 8B3CE273 26. 01. 2020, 15:16:55
A proč ne LXD? Docker má připravené image a podporu pro návaznosti v procesu vývoje, to je jasné, ale jinak?

LXD se víc hodí na kontejner s kompletním systémem, jako odledhčená virtualizace i když aplikační kontejnery podporuje taky. Docker je vhodný na provoz jedné konkrétní aplikace, ne na provoz celého stacku v kontejeru.
Název: Re:LXD nebo Docker
Přispěvatel: Filip Jirsák 26. 01. 2020, 16:05:50
... Podman je Docker udělaný správně (nebo alespoň podstatně lépe).

Mohl bys to rozvést?
Docker má vše v jednom (správu obrazů, procesů, kontejnerizaci); vše dělá přes démona; počítá se s tím, že vše dělá root a že kdokoli z kontejneru může získat roota na celém stroji – a když to chcete zabezpečit, musíte řešit, co vše nastavit, povypínat, zakázat atd. a stejně si nikdo není jistý, zda je výsledek bezpečný.

Docker ukázal cestu a za to mu patří místo v síni slávy, ale pořád je to spíš přerostlý prototyp nebo technologické demo. Už bylo více pokusů udělat to více unixovou cestou a lépe propojit kontejnery se zbytkem systému – např. rkt. Vzhledem k tomu, že za Podmanem stojí RedHat a udělal ho natolik kompatibilní s Dockerem, že doporučují udělat si v shellu alias docker=podman, věřím, že s Podmanem se to povede.
Název: Re:LXD nebo Docker
Přispěvatel: technik007cz 26. 01. 2020, 22:38:51
Pokud člověk neví co tam přesně v tom kontejneru potřebuje doporučil bych lxd.
Lxd nabízí plnohodnotný systém a člověk si vystačí s pár příkazy na to aby kontejner nainstaloval, spustil a do něj se nalogoval.
Návod viz https://ubuntu.com/blog/lxd-in-4-easy-steps (https://ubuntu.com/blog/lxd-in-4-easy-steps)
Název: Re:LXD nebo Docker
Přispěvatel: Filip Jirsák 27. 01. 2020, 08:12:37
Abych pravdu řekl, moc nechápu ty rady použít LXD. V Dockeru/Podmanu si budu spouštět jednotlivé aplikace v samostatných kontejnerech, když se rozhodnu vyzkoušet Node.js 13 místo 12 LTS, prostě spustím další kontejner, když budu chtít mít tři různé konfigurace Pythonu, prostě budu mít tři různé kontejnery. Když budu chtít spustit testy na CI, vezmu hotový image s aplikací používaný pro vývoj a spustím ho na CI serveru.

Samozřejmě ten Docker kontejner nebude jeden, ale bude jich více – pro každou aplikaci jeden, pro používané služby (třeba NoSQL databáze) další (opět pro každou jeden).

LXD mi vytvoří nový plnohodnotný systém, takže místo svého počítače bych si dělal nepořádek v tom LXD. Tím ale přece nic nezískám. Stejně budu muset řešit ten nepořádek, stejně při přenosu aplikace jinam budu mít problém v tom, že mám v tom LXD své specifické prostředí.
Název: Re:LXD nebo Docker
Přispěvatel: Jakub Daněk 27. 01. 2020, 14:58:22
Určitě Docker (nebo Podman). Potřebujete jen spustit izolované procesy, mezi nimi nasimulovat síť apod. Nechcete řešit "instalaci" celého virtuálního stroje (což je zjednodušeně to, co vám LXD nabízí).

LXD je prostě nástroj na úplně jiný use-case než který popisujete :).
Název: Re:LXD nebo Docker
Přispěvatel: hawran diskuse 27. 01. 2020, 22:48:31
Citace: hawran diskuse link=topic=22451.msg324218#msg324218
...
Mohl bys to rozvést?
Docker má vše ...
Aha, ok, ten podman jsem nějak zasklil.

Nicméně zatím tu pořád vidím jen školení docker...., žádný henten podman...
(jen konstantuji)

Název: Re:LXD nebo Docker
Přispěvatel: Filip Jirsák 28. 01. 2020, 08:20:57
Nicméně zatím tu pořád vidím jen školení docker...., žádný henten podman...
(jen konstantuji)
V tom asi bude nějakou dobu trochu zmatek, protože dnes Docker znamená jak obecnou technologii, tak její konkrétní implementaci – a druhá implementace je Podman. Předpokládám, že ta školení jsou tak nazvaná mimo jiné proto, že Docker jako název té technologie je známý, Podman daleko méně. Nejspíš většina věcí, kterou se na tom školení naučíte (možná i všechny) budete moci využít i s Podmanem. Klidně je i možné, že se to ve skutečnosti bude školit na Podmanu.
Název: Re:LXD nebo Docker
Přispěvatel: to_je_jedno 28. 01. 2020, 11:00:39
Určitě Docker (nebo Podman). Potřebujete jen spustit izolované procesy, mezi nimi nasimulovat síť apod. ...
LXD je prostě nástroj na úplně jiný use-case než který popisujete :).
a presne tady je pro lokalni vyvoj pripraveny docker-compose (jak uz tady nekdo zminoval). prakticky nikdy jsem nedaval docker run, proste nez tam mlatit ty miliony parametru tak zlaty .yml file
Název: Re:LXD nebo Docker
Přispěvatel: lazywriter 28. 01. 2020, 15:46:50
Na testy Docker (např. je podporovaný přímo gitlab-runnerem). Pro produkční běh LXD, např. z důvodu standardního nasazování bezpečnostních aktualizací (kvůli aktualizaci nemusím vždycky otáčet celou aplikaci, aktualizace v rámci distribucí bývají rychlejší než někdo aktualizuje zdrojový Docker image atd.).
Název: Re:LXD nebo Docker
Přispěvatel: Jakub Daněk 29. 01. 2020, 10:05:36
a presne tady je pro lokalni vyvoj pripraveny docker-compose (jak uz tady nekdo zminoval). prakticky nikdy jsem nedaval docker run, proste nez tam mlatit ty miliony parametru tak zlaty .yml file

Máte pravdu, já tak nějak historicky beru docker compose jako součást dockeru, což, uznávám, není pravda :)).

Taky nevím, kdy jsem naposledy spouštěl kontejner přes *docker run*.
Stejně jako nevím, kdy jsem naposledy použil compose jinde než na lokálu.
Název: Re:LXD nebo Docker
Přispěvatel: to_je_jedno 29. 01. 2020, 11:26:17
Stejně jako nevím, kdy jsem naposledy použil compose jinde než na lokálu.
A co jinyho pouzit na mensi projekty kde je Kubernetes proste kanon na vrabce?
Název: Re:LXD nebo Docker
Přispěvatel: Jakub Daněk 29. 01. 2020, 13:45:10
A co jinyho pouzit na mensi projekty kde je Kubernetes proste kanon na vrabce?

Pak je compose výborný nástroj. Ale my jsme ho na produkci nikdy nevyužili.

Dokud jsme neměli Openshift cluster, docker jsme na produkci vůbec nepoužívali - měli jsme nějakou sadu deploy skriptů, AWS a jenkins. Od té doby co máme Openshift zas není potřeba i malé projekty spouštět někde jinde než v tom clusteru.

Mimochodem, provozovat docker produkčně (stabilně) není žádná legrace a člověku, který ho chce využívat hlavně proto, aby mohl programovat a neřešit nasazování bych to nedoporučoval. To je pak imho lepší využít providera který Docker runtime poskytuje (a je vcelku jedno jestli to bude AWS, Azure, Openshift nebo něco jinýho).
Název: Re:LXD nebo Docker
Přispěvatel: Mirek Prýmek 29. 01. 2020, 20:21:16
Stejně jako nevím, kdy jsem naposledy použil compose jinde než na lokálu.
A co jinyho pouzit na mensi projekty kde je Kubernetes proste kanon na vrabce?
Docker Swarm. Je s Docker Compose téměř 100%ně kompatibilní. Stačí vzít docker-compose.yaml, jenom velmi mírně poupravit a může se to šupnout do Swarmu.
Název: Re:LXD nebo Docker
Přispěvatel: Jakub Daněk 31. 01. 2020, 11:45:51
Docker Swarm. Je s Docker Compose téměř 100%ně kompatibilní. Stačí vzít docker-compose.yaml, jenom velmi mírně poupravit a může se to šupnout do Swarmu.

Máte s tím zkušenosti? Jak těžké je Swarm nasadit a provozovat?
Název: Re:LXD nebo Docker
Přispěvatel: Mirek Prýmek 31. 01. 2020, 15:37:52
Máte s tím zkušenosti? Jak těžké je Swarm nasadit a provozovat?
Ano. Jednoduché, přímočaré. Ani si nepamatuju, že bysme měli jakékoliv problémy se stabilitou.
Název: Re:LXD nebo Docker
Přispěvatel: Filip Jirsák 04. 02. 2020, 17:43:01
... Podman je Docker udělaný správně (nebo alespoň podstatně lépe).

Mohl bys to rozvést?
Evidentně nejsem sám, kdo si to myslí – pokud vás to zajímá, na konci února bude v Praze meetup na téma
Podman - Docker done right (https://www.meetup.com/Prague-Containers-Meetup/events/268292962/).
Název: Re:LXD nebo Docker
Přispěvatel: geekyfreak 04. 02. 2020, 22:34:46
Me se zda, ze tady trochu narazime na problem mezi developmentem a deploymentem. Kdyz to budete mit na lokale tak si proste namapujete nejakej adresar /projekty/moje/nodejs a /projekty/moje/python primo z hosta na do dockeru. Kdyz si pak budete chtit pripojit debuger tak uz si zacnete nejako pracovat na Dockerfile, ktery kdyz ho napisete rozume bude kompatibilni jak s podmanem, tak ve finale klidne i s Kubernetes, kde si jenom trochu priohnete ten deployment popr. si to ohnete do docker-swarm. Budete mit teda treba nejaky takovy tri kontejnery jeden s nodejs, druhej s pythonem a treti treba s databazi (nekomu staci na vyvoj sqlite, zalezi). Pokud to budete chtit mit vsechno v jednom a zkouset si na tom "rucni testy" asi bych sahnul spis po LXD a choval se k tomu jako k VM. Az si vyresite dependencies a balicky co to bude chtit, rozbit to do dockerfile, buildnete si svuj image, nekam ho musite hodit atd. uz je relativne primocara cesta. Je na vas jestli chcete vyvijet aplikaci nebo resit deployment proces (ve finale asi budete resit oboji). Jak budete delat treba debug/breakpointy, jak chcete resit assety/cdn, kdyz to mate v dockeru? Jasne, muzete to delat na "remote", pak mate zase dva "dockerfile/envy". Kdyz si pak budete otacet ty kontejnery furt dokola musite pak ty mrtvy mazat atd, nakonec si zabordelite ten svuj docker image, bude se vam to buildovat mozna dyl nez byste chtel a misto developmentu budete cekat na buildy.

Rad bych se zeptal mistnich jestli to vidi jinak nebo jestli mi neco unika. Prijde mi proste delat jednodussi delat devel na lokale "po staru" a pak to proste nekam pushnout a tam at se to buildne a testne o tom zadna, ale rad se neco priucim a vyslechnu si jiny nazor.
Název: Re:LXD nebo Docker
Přispěvatel: to_je_jedno 05. 02. 2020, 17:22:51
- lokalne kazdopadne docker + docker-compose(protoze vsichni maji mit stejnou verzi prostredi, kazdy muze mit na jine projekty potrebu dalsich prostredi a treba nginx + php-fpm nechces konfigurovat na kazdy projekt... mam firemni image treba PHP (napr php-base). do nej mounted volume se zdrojakama (xdebug apod funguje s phpstormem v pohode). pouzivame .env ktery NENI v gitu (je tam neco jako .env.default) protoze treba porty neumi docker-compose nacist z jineho souboru (a porty chci menit protoze mam jeden projekt na kompu vickrat, nekdo muze mit nejaky port pouzity na jiny projekt apod)
- na dev serveru zbuildim image (from php-base) a jmenuje se neco jako php-produkt, ten pak pomoci docker-compose nasadim ve spravne verzi (mam tam neco jako .env.dev), verzovani pomoci .gitlab-ci a jeho promennych neco jako CI_COMMIT_NAME a envsubst
- pro staging a produkci je to podobny jako dev, ale nemusim url adresy apod urcovat dynamicky v .gitlab-ci.yml, je tam je pouzitych volumes skrz data, nejaky cron, zalohovani atd

(na nekterych projektech jede staging a produkce pres kubernetes)
Název: Re:LXD nebo Docker
Přispěvatel: geekyfreaky 07. 02. 2020, 21:35:53
- lokalne kazdopadne docker + docker-compose(protoze vsichni maji mit stejnou verzi prostredi, kazdy muze mit na jine projekty potrebu dalsich prostredi a treba nginx + php-fpm nechces konfigurovat na kazdy projekt... mam firemni image treba PHP (napr php-base). do nej mounted volume se zdrojakama (xdebug apod funguje s phpstormem v pohode). pouzivame .env ktery NENI v gitu (je tam neco jako .env.default) protoze treba porty neumi docker-compose nacist z jineho souboru (a porty chci menit protoze mam jeden projekt na kompu vickrat, nekdo muze mit nejaky port pouzity na jiny projekt apod)
- na dev serveru zbuildim image (from php-base) a jmenuje se neco jako php-produkt, ten pak pomoci docker-compose nasadim ve spravne verzi (mam tam neco jako .env.dev), verzovani pomoci .gitlab-ci a jeho promennych neco jako CI_COMMIT_NAME a envsubst
- pro staging a produkci je to podobny jako dev, ale nemusim url adresy apod urcovat dynamicky v .gitlab-ci.yml, je tam je pouzitych volumes skrz data, nejaky cron, zalohovani atd

(na nekterych projektech jede staging a produkce pres kubernetes)

Az se kluci na PHPku prestanou placat po zadech, ze se naucili pouzivat xdebug misto var_dump dobry a prestanou adminum kecat do toho jestli ti dovolime cron nebo neco jinyho tak bude lip. V mezicase si zkus ochocit ten php composer at ti nemusim instalovat bokem npm protoze chces pouzivat javascript. V jinejch jazycich jsou treba virtualni prostredi per projekt, viz treba python a pipenv v nodejs maj taky aspon nejakej prod a dev.

Autor prispevku se ptal na nodejs a python. Tvuj workflow na tom fungovat apriory nebude, protoze je language specific. Ti co tady pisou, at si do dockeru narve vic demonu jsou mimo, protoze to je proti celymu kontejnerovymu paradigmatu. Ono totiz pustit plnohodnotne PHP v dockeru uplne nejde, jelikoz to je uplne proti tomu co kontejner predstavuje, teda pokud bys to nechtel poustet na mod_php. Az ti ten wordpress pojede na ciste na php-fpm a nauci se to pouzivat neco jinyho nez mysql tak se muzem bavit.