Docker na VPS: instalace a první kontejner

Docker na VPS: instalace a první kontejner

V předchozí sérii jsme automatizovali samotný proces doručení kódu: push do větve, a během pár minut je změna na serveru bez účasti člověka. Ale schéma „push → SSH deploy → restart služby" léčí jen jeden symptom. Druhý, neméně bolestivý, zůstává na místě: závislosti na serveru se stále musí instalovat ručně a konfliktují mezi projekty, které žijí na stejném VPS.

Klasická situace: jeden projekt je napsaný pro Node.js 18 a závisí na konkrétní hlavní verzi balíčků, druhý je novější, už na Node.js 20. Oba se mají nasazovat na stejný server. Bez Dockeru je to buď dva systémové Node.js, které se perou přes nvm a proměnné PATH, nebo kompromis, kdy jeden z projektů běží na verzi, pro kterou nebyl testován. Totéž se opakuje u PHP, Pythonu, verzí knihoven, systémových balíčků — jakákoli sdílená závislost na hostu se dřív nebo později stane bodem konfliktu.

Docker to řeší na úrovni architektury, ne domluvy. Každá aplikace dostane vlastní izolované prostředí se svými závislostmi, a toto prostředí je popsané v kódu, ne v hlavě administrátora. Stejný image, který jste sestavili a otestovali lokálně, běží na serveru bitově identicky. A návrat k předchozí verzi není „vzpomenout si, které soubory přepsat", ale jeden řádek: docker run se starým tagem image.

2. Klíčové koncepty Dockeru

Než začnete cokoli instalovat na server, vyplatí se seznámit s pěti pojmy, bez kterých nebude mít smysl žádný příkaz Dockeru.

2.1 Image — neměnná šablona

Image je read-only šablona, ze které se spouští kontejner: souborový systém, nainstalované závislosti, proměnné prostředí, výchozí spouštěcí příkaz. Image se sám o sobě nikdy nemění — node:20-alpine, nginx:latest nebo vlastní my-app:1.0 zůstávají stejnými bajty, dokud explicitně nesestavíte nový image.

2.2 Container — spuštěná instance

Container je proces spuštěný z image, s vlastním souborovým systémem nad vrstvami image, vlastním síťovým prostorem a vlastním PID namespace. Z jednoho image lze spustit libovolné množství kontejnerů najednou, a každý bude izolovaný od ostatních, i když pocházejí ze stejného image.

2.3 Systém vrstev a cache sestavení

Každá instrukce v Dockerfile vytváří samostatnou vrstvu (layer) a vrstvy se cachují. Pokud se package.json nezměnil od minulého sestavení, vrstva s npm install se vezme z cache bez opětovného provedení — právě tato vlastnost dělá opakovaná sestavení v CI mnohonásobně rychlejší než první.

2.4 Registry image

Docker Hub je výchozí veřejný registr: docker pull nginx bez dalšího nastavení stáhne odtud oficiální image. Ale není to jediná varianta.

2.5 Docker Engine vs Docker Desktop

Docker Desktop je grafický obal pro lokální vývoj na Macu a Windows, s vlastním virtuálním strojem pod kapotou. Na VPS není potřeba a ani se neinstaluje: server dostane jen Docker Engine — daemon (dockerd) a CLI, bez jakékoli grafické vrstvy. Právě Engine instalujeme v další kapitole.

3. Instalace Dockeru na VPS

3.1 Proč ne apt install docker.io

Nejjednodušší cesta se ukazuje být pastí. Balíček docker.io ze standardního repozitáře Ubuntu nebo Debianu je verze zafixovaná k datu vydání distribuce, tedy obvykle 20.x v době, kdy aktuální řada je už 26.x a výš. Rozdíl není jen v čísle verze: ve starších sestaveních chybí bezpečnostní opravy a část moderních možností BuildKitu.

3.2 Oficiální způsob — repozitář Docker Inc.

Nejrychlejší spolehlivá varianta je oficiální instalační skript:

curl -fsSL https://get.docker.com | sh

Skript sám rozpozná distribuci, přidá oficiální repozitář Dockeru a nainstaluje aktuální Community Edition spolu s containerd a CLI pluginy (Compose, Buildx). Pro produkční servery, kde skript stažený z internetu není žádoucí varianta z bezpečnostních důvodů, lze stejný repozitář přidat ručně podle oficiální dokumentace pro konkrétní distribuci.

3.3 Spuštění bez sudo

Ve výchozím stavu má přístup k Docker daemonu jen root a každý příkaz vyžaduje sudo. Aby bylo možné pracovat jako běžný uživatel:

sudo usermod -aG docker $USER
newgrp docker

Místo newgrp docker se lze prostě znovu přihlásit — změna skupiny se projeví při novém přihlášení.

3.4 Automatické spuštění po restartu

Oficiální instalační skript už automatické spuštění zapíná, ale vyplatí se to ověřit explicitně:

sudo systemctl enable docker

3.5 Ověření instalace

docker --version
docker info
docker run hello-world

Poslední příkaz je nejlepší rychlý test: pokud Docker dokáže stáhnout drobný image a vypsat pozdrav, znamená to, že daemon funguje, práva jsou nastavená správně a síť pro pull požadavky je dostupná.

4. První příkazy: praxe s nginx

Teorie dává smysl až po pár příkazech v terminálu. Projdeme si životní cyklus kontejneru na příkladu nginx.

4.1 Stažení image

docker pull nginx:alpine

Tag je uveden explicitně, ne latest — to je zásadní pro reprodukovatelnost: latest dnes a latest za měsíc mohou být různé image, a server po náhodném docker pull bez tagu jednoho dne dostane neočekávanou hlavní verzi.

4.2 Spuštění kontejneru

docker run -d -p 80:80 --name my-nginx nginx:alpine

4.3 Přehled běžících kontejnerů

docker ps
docker ps -a

docker ps zobrazí jen běžící kontejnery, -a přidá i zastavené — užitečné pro nalezení kontejneru, který skončil chybou hned po startu.

4.4 Logy

docker logs my-nginx
docker logs -f my-nginx

-f (follow) funguje stejně jako tail -f: pohodlné držet otevřené při diagnostice problému v reálném čase.

4.5 Shell uvnitř kontejneru

docker exec -it my-nginx sh

Otevře interaktivní shell uvnitř už běžícího kontejneru — prohlédnout konfiguraci, ověřit síť, podívat se na soubory, aniž byste zastavovali službu.

4.6 Zastavení a smazání

docker stop my-nginx
docker rm my-nginx

stop pošle signál k ukončení procesu uvnitř kontejneru, rm smaže samotný kontejner spolu s jeho souborovým systémem. Image, ze kterého byl vytvořen, přitom zůstává na disku.

4.7 Správa image na disku

docker images
docker image prune

docker images zobrazí seznam stažených image s velikostí, image prune odstraní dangling image — ty, které zůstaly bez tagu po přesestavení se stejným jménem.

5. První Dockerfile: vlastní image

5.1 .dockerignore — první soubor, ne Dockerfile

Než začnete psát Dockerfile, vyplatí se vytvořit .dockerignore: node_modules, .env, .git, *.log by se neměly dostat dovnitř image. Bez tohoto souboru se kontext sestavení (vše, co se posílá daemonu) nafoukne a secrets z .env mohou náhodou navždy skončit ve vrstvě image.

5.2 Struktura Dockerfile

Na pořadí instrukcí záleží — právě ono určuje, co se dostane do cache a co se bude přesestavovat pokaždé znovu:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
CMD ["node", "server.js"]

5.3 Proč se package*.json kopíruje samostatně

Pokud zkopírujete celý kód jedním COPY . . před instalací závislostí, jakákoli změna v kódu invaliduje cache vrstvy s npm ci a závislosti se přeinstalují znovu při každém sestavení. Rozdělením na dva kroky se vrstva npm ci bere z cache, dokud se nezmění samotný package.json nebo package-lock.json.

5.4 Alpine nebo plný image

5.5 CMD nebo ENTRYPOINT

5.6 Sestavení image

docker build -t my-app:1.0 .

Stejný image lze označit druhým tagem bez opětovného sestavení — například docker build -t my-app:latest . ve stejném kontextu vytvoří další tag na stejné vrstvy.

5.7 Spuštění vlastního image

docker run -d -p 3000:3000 --name my-app my-app:1.0

6. Volumes: data mimo kontejner

6.1 Proč data mizí

Souborový systém kontejneru je záměrně efemérní: docker rm smaže vše, co bylo zapsáno dovnitř během provozu. Pro stateless aplikaci to není problém, ale pro databázi nebo jakoukoli službu uchovávající stav to znamená ztrátu dat při každé aktualizaci kontejneru.

6.2 Bind mount

docker run -v /var/log/myapp:/app/logs my-app:1.0

Adresář z hostu se připojí přímo dovnitř kontejneru, změny jsou vidět z obou stran v reálném čase. Vhodné pro konfigurace, které je třeba upravovat zvenčí, a pro logy, které pak čte samostatný monitorovací systém na hostu.

6.3 Named volume

docker volume create pgdata
docker run -v pgdata:/var/lib/postgresql/data postgres:16-alpine

Named volume spravuje samotný Docker a fyzicky žije v /var/lib/docker/volumes/. Pro databáze je to obvykle lepší volba než bind mount: Docker sám řídí cesty a přístupová práva, a zálohu lze provést přes pomocný kontejner s --volumes-from, bez starostí o přesnou strukturu adresářů hostu.

6.4 Správa volumes

docker volume ls
docker volume inspect pgdata
docker volume prune

prune odstraní volumes, které nepoužívá žádný kontejner — užitečné, ale vyplatí se zkontrolovat seznam před spuštěním: takto smazaná data se už nevrátí.

7. Závěr

V tomto článku jsme prošli cestu od instalace Docker Engine na čistém VPS po vlastní sestavený image s daty, která přežijí restart kontejneru. To už stačí ke spuštění jedné aplikace izolovaně od zbytku systému a bez obav z konfliktu verzí Node.js nebo Pythonu se sousedním projektem.

Nepohodlí, které je znát hned po prvních pár kontejnerech: každá služba je samostatný dlouhý řádek docker run s porty, proměnnými prostředí a volumes, který se snadno splete nebo zapomene znovu vytvořit po aktualizaci serveru. Jakmile se aplikace neskládá z jednoho kontejneru, ale z několika — samotná aplikace, databáze, cache — spravovat tuto sadu jednotlivými příkazy se stává složité a náchylné k chybám.

Přesně tento problém řeší Docker Compose: celý stack se popíše jednou v souboru docker-compose.yml a spustí se jedním příkazem.

Časté dotazy