Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: 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?
-
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.
-
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).
-
Pokud máte možnost volby, pak určitě Podman. Podman je Docker udělaný správně (nebo alespoň podstatně lépe).
-
A proč ne LXD? Docker má připravené image a podporu pro návaznosti v procesu vývoje, to je jasné, ale jinak?
-
... Podman je Docker udělaný správně (nebo alespoň podstatně lépe).
Mohl bys to rozvést?
-
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.
-
... 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.
-
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)
-
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í.
-
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 :).
-
...
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)
-
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.
-
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
-
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.).
-
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.
-
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?
-
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).
-
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.
-
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?
-
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.
-
... 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/).
-
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.
-
- 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)
-
- 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.