Ten mindset shift je s kontejnerama znacnej a do jisty miry je to o akceptovani 'pet vs. cattle' principu. Ne jenom co se tyka provozu aplikace, ale environmentu celkove. V posledni dobe vidim trend kdy zakaznici i k samotnejm kontejnerovejm clusterum (Kubernetes, OpenShift,...) pristupujou jako ke cattle. Neco se podela pri upgradu? Smazat cluster, spustit playbook a za chvili je vsechno vyreseny. Velky aktivni dev prostredi? Kazdej vikend smazat, spustit playbook a za chvili uz engineering deployuje z gitu do cistyho clusteru.

GIOMIKY: mozna si nejdriv over fakta nez neco podobnyho napises ;)
Docker Desktop WSL 2 backend | Docker Documentation
https://docs.docker.com/docker-for-windows/wsl/
(moji widloidni kolegove docker ve WSL normalne pouzivaj)

GIOMIKY: Na kazdem VPS jedu docker, nic jineho uz neinstaluju a je to lepsi a lehci nez instalovat balicky.
A k prenaseni, muzes pak rozchodit swarm, k8s apod. a klidne mit rovnou ty data replikovany a nic nemuset resit.
Jinak docker ma i image na zalohovani, staci pak spustit `docker run backup-image....` a jen poslat ktery image a ktera data.

GIOMIKY: ja bych to spis videl, ze bys mel dospet ty a upustit od tvych zajetych koleji :)

GIOMIKY: no, ona zaloha dockeru se dela uplne jinak a je mnohem snazsi.
Strasne zjednodusene, pokud budu chapat dobre presne co potrebujes.
Vytvoris si docker-compose.yml, coz je config sluzby kterou chces bezet. Vynecham jak bude vypadat. Ale je tam jaky image chces pouzit, pripadne nastaveni (treba jaky se ma vytvorit defaultne user v mysql, jake ma mit virtualni site,....). V tom bude i adresar ktery chces mit persistentni, to je jedine co te zajima na zalohu. V docker-compose to bude treba /var/lib/mysql:/volumes/mysql.
Docker-compose.yml das do gitu, nebo kamkoliv, at se ti to hezky prenasi i k tobe, jestli je treba (nebo v gitu daneho projektu).
Pokud to chces prenest k sobe, pouze zazalohujes /volumes/* a preneses k sobe. Spustis `docker-compose up` a to je vsechno. Uz se ani nestaras o to ze u sebe nemas mysql, nebo cokoliv jineho. Udela to sam podle toho co bylo na serveru. Nezalohujes nic dalsiho.
Je to zjednodusene. Do /var/docker je zbytecne chodit, tam jsou proste interni veci.

GIOMIKY: HOUMLES: to je prostě úplně jinej mindset. Lidi jedou podle osvědčených vzorců, dokud se nestřelí do nohy. Do kolegy pravidelně hučím, ať ten postup vždy přepíše do ansible - a odpovědi typu - to budeme dělat jen jednou a tak:-) Jakoby nikdy neproovozoval žádnej systén. No a samo, včera přišel produkťák, že po něm chtěl aby deploynul dalších sedm strojů:-) Oba si uvědomili, že ta investince do ansible asi není blbá a neděláme to abychom si honili naše engineering péra.

Jinej mindset je třeba vnímat ty OS jako efemerální zdroj, v kterým jen alokuješ to co je skutečně perzistentní a to máš někde pravidelně zálohovaný. Všechno ostatní deployuješ kam potřebuješ a jen obnovíš perzistentní data ze zálohy.

A nebo migruješ VM, ale pak si ji jednou za mnoho let rozesereš a už ji nedáš dohromady:-)

GIOMIKY: Vyhoda dockeru proti VM je rychlost - predevsim spusteni, protovozovani uz je skoro stejne. A hlavne i to zabere o dost min mista nez VM, jak na disku, tak v pameti a vlastne i na cpu.
/var/docker te nemusi zajimat, to je jeho interni cache a persistentni data. Hromada jineho sw taky ma cache kterou nechces prochazet.
.net tam spustis, mssql apod taky. Ale docker neni delan na spusteni celych windows, nebo ani linuxu. To neni vubec jeho cil a nema na to byt pouzit. Docker ani nema nahradit VM, proste jeho ucel je neco jineho.

GIOMIKY: Docker je o konzistentním nasazení kódu do produkce. Můžeš si upéct packerem VM, ale Docker má pár dalších užitečných features díky orchestraci, že tě VM sami o sobě přestanou zajímat. Kdyby byl Docker jen na vývoj a testování, tak nikoho nezajímá. Přínos je v běhu na produkci a orchestraci. O tý struktuře souborů dockeru si můžeš přečíst v dokumentaci. Ale chápu, že běžný IT je spovykaný z každý novinky, kterou neví jak vstřebat.