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.