Klidne bych zacal s dockerem pro lokalni vyvoj. Mam takhle vsechny projekty a ne vsechny pak v produkci opravdu bezi v dockeru, ale na vyvoj je to taky super. Kdyz tohle uvidis ze ti to funguje jak potrebujes, tak pak uz je to jen o tom, ze musis automatizovat vytvareni novych imagu pro nove verze. Ale minimalne v te dobe neco o dockeru uz budes vedet.

ASACHI: jak bylo psany, je toho shitload k pochopeni/nastaveni. Spoustu lidi uz prislo o data, kdyz si je nacpali do kontejneru misto do externiho volume a podobne pribehy.
Poustel bych se do toho asi leda v pripade, ze bych to pak treba vyuzil v praci nebo chtel dat do dockerovyho cloudu a neplatit za VPS.

Pokud bys chtel zacit s necim mensim, tak se da nechat DB samostatne a do dockeru dat treba jenom ten prestashop/wordpress. Usnadni to treba instalaci novejsi verze. Pullnes novejsi image, restartujes a hotovo.
Prestashop docker https://hub.docker.com/r/prestashop/prestashop/ zrovna ani zadny volume nepotrebuje, takze to bude jenom jednoradkovej skript k nastartovani aplikace. Wordpress taky.
Ovsem jak se budes chtit vrtat v nastaveni php, tak uz to bude chtit bud externi volume nebo vlastni docker image a nejspis te to prestane bavit.

Pokud to budes drzet v gitu tak si dej bacha, at nemas .git adresar verejnej - https://lynt.cz/blog/globalni-scan-otevrenych-git-repozitaru

ASACHI: Moznosti je vic. Hodne zalezi jak chces resit deployment apod. Ta moznost se trema containerama kterou pises je spis o tom, ze nahradit instalaci z package managementu instalaci docker imagu. Coz neni uplne docker way (ale je to tool a pouzit se da nekolika zpusoby). Spravnejsi by bylo mit docker image pro eshop apache, eshop php, eshop mysql, to same pro ty ostatni, takze treba 9 imagu. Coz ale ma vliv na potrebny vykon VPS. Duvod pro tohle je ze kazdou cast deployuje zvlast a kazda je verzovana jinak.
Pokud nemas primo duvod pouzit docker, tak bych si tam proste nainstalovat to co potrebujes a provozoval jako multihosting. Pokud budes prechazet na jine VPS, to prekopirovani bude uplne stejne, protoze napr. DB data nejsou soucasti containeru a pri prechodu si je stejne musis zazalohovat, prenest a restornout.
A pro nastaveni a balicky mi takhle prijde lepsi pouzit Ansible, kor jestli nemas zkusenost s dockerem a jak nastavit jednotlive sluzby. DOcker by mel vyhodu, pokud provozujes treba PHP a pro kazdy web by si potreboval jinou verzi, i kdyz i to by pres fpm bylo mozna lehci.

ASACHI: Uf, takhle kdyz to vidim pohromade, tak me napada jen okridlene "docker neni silver bullet na problemy" :)

Asi bych zacal tim, odpovedet si sam sobe, co si od ty migrace slibujes. Webhostingy existujou, protoze lidi se nechtej starat o tyhle webovy sracky, a malokdo to umi delat dobre, to samy s databazema (managed typu RDS vs. vlastni postgres nekde na lokalu)

Kdybyste nekdo potreboval resit i licence: https://lwn.net/Articles/752982/

Neni to uplne vesele cteni :)

URPUTNIK: základ image můžeš vyrobit pomocí debootstrap, a pak případně ručně doinstalovat v chrootu co potřebuješ a pomocí tar udělat image?
není to moc hezké, ale automatizovatelné to je.

Create a base image | Docker Documentation
https://docs.docker.com/develop/develop-images/baseimages/

MARTEN: vi, ne vim.

URPUTNIK: Ano. Ale obecne neni dobre se pripojit a z toho udelat image. Pokud pak budes chtit pouzit novou verzi alpine/debian/.... tak je to vpodstate nereplikovatelna vec. Takze pekne vsechno do Dockerfile a ty muzes retezit. Jeden layer je jeden prikaz, proto casto uvidis

RUN apt-get update && apt-get install vim && apt-get clean

apod. Protoze tohle udela jediny layer a ne tri. Ale opatrne s tim kdyz tam budes mit balicek kde te zajima verze. Pokud priste buildnes s novou verzi, tak prijde o layery vseho co na tom bylo postaveno.
Docela se divim, ze vim je hned v zakladu. Alpine se snazi byt co nejmensi, bezne v tech zakladnich neni ani less ani ping. Jinak si muzes udelat i vlastni uplne ten zakladni image, takze nemusis vychazet z existujiciho, ale je to trochu opruz :)