Slovník pojmů

Docker

Docker pomáhá spouštět stejnou aplikaci, runtime a závislosti v lokálním vývoji, CI i na serveru. Nenahrazuje ale návrh aplikace, správu dat ani bezpečný provoz.

Stručná definice

Aplikace zabalená jako image, spuštěná jako izolovaný proces.

Docker sestaví image, tedy neměnný balíček vrstev se soubory a instrukcí, jak proces spustit. Z jedné image pak vzniká jeden nebo více kontejnerů. Každý kontejner má vlastní zapisovatelnou runtime vrstvu, síťovou konfiguraci a proces, ale nesimuluje celý samostatný operační systém.

Kontejner není virtuální počítač. Více kontejnerů na stejném hostiteli sdílí jeho kernel, proto se liší jeho hranice izolace i kompatibilita. Praktický přínos je hlavně v opakovatelném sestavení PHP aplikace, frontendu, databáze nebo workeru bez ruční instalace rozdílných verzí na každém počítači.

Použití

Kde kontejnerizace řeší konkrétní provozní problém

Docker se hodí tam, kde aplikace potřebuje předvídatelné závislosti a oddělené běžící části.

lokální PHP aplikace se stejnou verzí runtime, Composeru a rozšíření jako v CI
oddělený webový server, PHP-FPM, worker, databáze a Redis v jednom vývojovém prostředí
opakovatelný image pro testy, statickou analýzu a sestavení artefaktu
izolace více projektů, které by si jinak kolidovaly portem nebo verzí závislosti
spuštění jednorázového importu, frontového workeru nebo plánované úlohy se stejným kódem jako aplikace

Praktický příklad

PHP e-shop s interní aplikací a veřejným vstupem

Lokální prostředí má čtyři služby: nginx přijímá požadavky pro prohlížeč, PHP aplikace obsluhuje kód, PostgreSQL drží relační data a Redis slouží cache či koordinaci. Jen nginx publikuje lokální port; aplikace a databáze se oslovují interními názvy služeb přes Docker síť.

CI sestaví image aplikace z Composer locku, uvnitř něj spustí testy a statickou analýzu a výsledný image označí konkrétní verzí. Produkční nasazení pak nepřebírá adresář z vývojářova počítače. Pořád ale musí samostatně řešit secrets, databázové migrace, monitoring a obnovu dat.

services:
  app:
    build: .
    expose:
      - '9000'

  nginx:
    image: nginx:alpine
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - app

Jak funguje

Od zdrojového kódu k běžícímu procesu

Image je popis připraveného prostředí. Kontejner je jeho konkrétní běh s konfigurací pro dané prostředí.

Dockerfile Popíše výchozí image, instalaci závislostí, kopírování aplikace a výchozí příkaz. Dává smysl stavět jej deterministicky z lock souboru.
Build a vrstvy Build vytváří obsahově adresované vrstvy. Dobré pořadí instrukcí dovolí znovu použít vrstvu závislostí, aniž by každá změna kódu stahovala vše znovu.
Image registry Hotový image lze uložit pod konkrétním tagem či digestem a použít stejný artefakt v CI, stagingu i produkci.
Kontejner Runtime spustí z image určený proces s proměnnými prostředí, limity, sítí a případně připojeným volume. Když hlavní proces skončí, skončí i kontejner.
Služby kolem Compose nebo jiný orchestrátor popíše více služeb, jejich sítě, volumes a závislosti. Aplikace se pak připojuje ke službě interním jménem, ne přes náhodný localhost port.

Hlavní části

Image, kontejner, volume, síť a Compose nejsou totéž

Rozlišení těchto pojmů brání častému omylu, že smazání či restart kontejneru automaticky chrání data.

Image a vrstvy

Image je šablona složená z neměnných vrstev změn souborového systému. Každý build krok může vytvořit další vrstvu; do image proto nepatří tajemství ani zbytečné build artefakty.

Kontejner a proces

Kontejner spouští obvykle jednu hlavní odpovědnost, například PHP-FPM nebo worker. Není to plnohodnotný server, do něhož se má ručně instalovat produkční oprava.

Volume a stav

Data databáze, uploady nebo jiné trvalé soubory potřebují jasně určené persistentní úložiště. Zapisovatelná vrstva kontejneru je pomíjivá a není zálohovací strategií.

Sítě a publikované porty

Služby na stejné Docker síti spolu komunikují interně. Publikování portu vytváří pravidlo z hostitele do kontejneru; ve výchozím nastavení může být dostupné na všech síťových rozhraních hostitele.

Docker Compose

Soubor compose.yaml drží popis lokálního více-službového prostředí ve verzovaném kódu. Pomáhá vývoji, ale sám neřeší produkční orchestrace, rollout ani monitoring.

Vztah k ostatním nástrojům

Kontejner je provozní obálka, ne náhrada architektury.

Docker se skládá s webovým serverem, databází a CI, ale každá část zachovává svou vlastní odpovědnost.

nginx: Často přijímá veřejný HTTP provoz a předává jej aplikaci v interní Docker síti. Není nutné zveřejňovat port každého PHP procesu.
CI/CD: Pipeline může sestavit image, spustit testy a publikovat ověřený artefakt. Kontejner ale nezaručuje, že migrace, secrets a rollback jsou bezpečné.
PostgreSQL a Redis: Databáze a cache mohou běžet v kontejnerech, jejich data, zálohy, limity a obnova však vyžadují vlastní provozní plán.
Symfony nebo Laravel: Framework běží uvnitř image stejně jako jiný PHP proces. Docker nenahrazuje správnou konfiguraci aplikace, fronty ani rozdělení odpovědností.

Výhody a omezení

Opakovatelnost je přínos, ne automatická bezpečnost.

Přínosy

stejné verze runtime a rozšíření pro vývojáře, CI i server
oddělené služby a menší riziko konfliktu závislostí
verzovaný způsob sestavení image místo ruční konfigurace stroje
snazší lokální spuštění databáze, cache, workeru a webového serveru

Na co pozor

image se zastaralou základní vrstvou přenáší známé bezpečnostní a provozní problémy
tajemství v Dockerfile, image nebo logu zůstávají dostupná v historii a registrech
zveřejněný port databáze může být přístupný mimo zamýšlené prostředí
kontejner bez volume, zálohy a postupu obnovy nechrání důležitá data
příliš mnoho služeb v malém projektu může vývoj spíše komplikovat

Hranice použití

Použít tam, kde opakovatelný běh převáží cenu provozní vrstvy.

Docker dává smysl pro PHP aplikaci s více závislostmi, pro tým, CI a dlouhodobý provoz, kde je důležité znovu sestavit stejné prostředí. Umožní například oddělit veřejný nginx, aplikaci, worker a databázi, aniž by se jejich závislosti instalovaly přímo do hostitelského systému.

Jednoduchý jednorázový skript nemusí potřebovat složitý compose soubor ani vlastní registry workflow. Kontejnerizace nemá zakrývat chybějící dokumentaci, nejasné proměnné prostředí nebo nevhodně navržené rozdělení na mikroslužby.

Na co myslet

Build i runtime mají být popsané, omezené a dohledatelné.

Dobré kontejnerové prostředí minimalizuje ruční kroky a zároveň dává jasně najevo, kde leží data, porty a tajemství.

stavět image z lock souboru a jednoznačně určit používaný artefakt
oddělit build závislosti od výsledného runtime image, pokud tím skutečně klesne jeho rozsah
neukládat hesla, tokeny ani privátní klíče do image či Dockerfile
publikovat jen porty, které musí být dostupné mimo interní síť
držet persistentní data, zálohy a obnovu mimo životní cyklus jednoho kontejneru
spouštět stejný image v CI a následných prostředích, ale ověřit jejich konfiguraci zvlášť

Časté otázky

Co Docker řeší a co ne

Je Docker virtuální počítač?

Ne. Kontejner je izolovaný proces sdílející kernel hostitele. Virtuální počítač obsahuje vlastní operační systém a kernel, proto má jiné vlastnosti i režii.

Je image totéž co kontejner?

Ne. Image je neměnná šablona; kontejner je její konkrétní spuštěná instance s runtime zapisovatelnou vrstvou a konfigurací.

Stačí kontejner databáze pro zálohu dat?

Nestačí. Data mají být v určeném persistentním úložišti se zálohou, ověřenou obnovou a provozním plánem.

Publikuje EXPOSE port do internetu?

Ne. EXPOSE pouze deklaruje zamýšlený port image. Skutečné zpřístupnění z hostitele vyžaduje publish pravidlo, například přes ports nebo docker run -p.

Jak navrhuji technické zázemí aplikace

Vývojové a provozní prostředí držím co nejblíž skutečnému běhu aplikace.

U PHP projektů řeším spolupráci aplikace, databáze, cache, workerů a integračních služeb tak, aby šel jejich stav dohledat a bezpečně změnit.

Jak přemýšlím o architektuře aplikací Nezávazně probrat projekt