LXD nebo Docker

wabi

Re:LXD nebo Docker
« Odpověď #15 kdy: 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.


Re:LXD nebo Docker
« Odpověď #16 kdy: 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?
Děkuji za možnost editace příspěvku.

wabi

Re:LXD nebo Docker
« Odpověď #17 kdy: 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).

Re:LXD nebo Docker
« Odpověď #18 kdy: 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.

wabi

Re:LXD nebo Docker
« Odpověď #19 kdy: 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?


Re:LXD nebo Docker
« Odpověď #20 kdy: 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.

Re:LXD nebo Docker
« Odpověď #21 kdy: 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
.

Re:LXD nebo Docker
« Odpověď #22 kdy: 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.

Re:LXD nebo Docker
« Odpověď #23 kdy: 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)
Děkuji za možnost editace příspěvku.

Re:LXD nebo Docker
« Odpověď #24 kdy: 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.