Základní struktura souboru
Compose V2: Klíč version je dnes volitelný — Compose V2 ho ignoruje. Pokud potřebuješ zpětnou kompatibilitu, použij version: "3.9". Soubor se může jmenovat compose.yml nebo docker-compose.yml.
Kompletní kostra
# Verze je volitelná v Compose V2
version: "3.9"
services: # definice kontejnerů (povinné)
web:
image: nginx:alpine
db:
image: postgres:16
networks: # volitelné – vlastní sítě
frontend:
backend:
volumes: # volitelné – pojmenované svazky
pgdata:
configs: # volitelné – konfigurační soubory
nginx_conf:
file: ./nginx.conf
secrets: # volitelné – tajné hodnoty
db_password:
file: ./secret.txt
Top-level klíče
services
Definice jednotlivých kontejnerů — hlavní a povinná sekce
networks
Vlastní sítě sdílené mezi službami
volumes
Pojmenované svazky pro perzistentní data
configs
Konfigurační soubory (Compose Spec / Swarm)
secrets
Tajné hodnoty — hesla, tokeny, certifikáty
include
Vložení jiných Compose souborů (Compose V2.20+)
include:
- ./infra/compose.yml
- ./services/compose.yml
Proměnné prostředí a .env
${VAR}
Nahrazeno z prostředí shellu nebo .env souboru
${VAR:-default}
Výchozí hodnota pokud VAR není nastavena
${VAR:?chyba}
Ukončí s chybou pokud VAR není nastavena
.env soubor
Automaticky načten ze stejného adresáře jako compose.yml
# .env
POSTGRES_DB=mydb
POSTGRES_USER=admin
NODE_ENV=production
env_file:
Explicitní seznam .env souborů pro danou službu
env_file:
- .env
- .env.production
x-rozšíření (YAML anchors)
Znovupoužitelné bloky pomocí YAML kotev
x-common: &common
restart: unless-stopped
env_file: [.env]
services:
web:
<<: *common
image: nginx
services — volby kontejneru
Obraz a identita
image:
Název Docker obrazu z registru nebo lokální
image: nginx:1.25-alpine
image: postgres:16
image: myregistry.io/myapp:latest
container_name:
Vlastní název kontejneru (musí být unikátní — neumožňuje scale)
container_name: my-nginx
hostname:
Hostname uvnitř kontejneru (výchozí = název služby)
domainname:
Doménové jméno kontejneru
pull_policy:
Kdy stáhnout obraz z registru
pull_policy: always # vždy
pull_policy: missing # jen pokud chybí (výchozí)
pull_policy: never # nikdy nestahovat
pull_policy: build # vždy buildovat
platform:
Cílová platforma obrazu
platform: linux/amd64
platform: linux/arm64
Porty
ports:
Mapování portů HOST:CONTAINER (zkrácená i dlouhá syntaxe)
ports:
- "8080:80" # host:container
- "443:443"
- "127.0.0.1:3000:3000" # vázat na IP
- "3000" # náhodný host port
- target: 80
published: "8080"
protocol: tcp
mode: host
expose:
Zpřístupní port pouze jiným službám, ne hostu
expose:
- "3000"
- "8080"
Sítě
networks:
Sítě ke kterým je služba připojena
# Zkrácená syntaxe
networks:
- frontend
- backend
# Rozšířená syntaxe
networks:
backend:
aliases:
- database
ipv4_address: 172.20.0.10
priority: 100
network_mode:
Síťový mód kontejneru (alternativa k networks:)
network_mode: host
network_mode: none
network_mode: "service:db"
network_mode: "container:my-nginx"
extra_hosts:
Přidat záznamy do /etc/hosts
extra_hosts:
- "myhost:192.168.1.10"
- "gateway:host-gateway"
dns: / dns_search:
Vlastní DNS servery a search domény
dns:
- 8.8.8.8
- 1.1.1.1
dns_search:
- example.com
Proměnné prostředí
environment:
Inline proměnné (seznam nebo mapa)
# Seznam
environment:
- NODE_ENV=production
- DB_HOST=db
- SECRET # převezme hodnotu z hostu
# Mapa
environment:
NODE_ENV: production
DB_PORT: 5432
env_file:
Načtení proměnných z .env souboru
env_file:
- .env
- .env.production
- path: ./default.env
required: false # Compose V2.24+
Svazky a souborový systém
volumes:
Bind mount nebo pojmenovaný svazek
volumes:
- ./data:/app/data # bind mount
- pgdata:/var/lib/pg # pojmenovaný
- /tmp # anonymní
# Dlouhá syntaxe
- type: bind
source: ./config.yml
target: /etc/app/config.yml
read_only: true
bind:
create_host_path: true
propagation: shared
tmpfs:
Dočasný souborový systém v RAM
tmpfs:
- /run
- /tmp:size=100m,mode=1777
working_dir:
Pracovní adresář uvnitř kontejneru
working_dir: /app
Příkazy a entrypoint
command:
Přepíše CMD z Dockerfile
command: python app.py --port 8080
command: ["npm", "run", "start"]
entrypoint:
Přepíše ENTRYPOINT z Dockerfile
entrypoint: /entrypoint.sh
entrypoint: ["/bin/sh", "-c"]
Restart a životní cyklus
restart:
Politika restartu kontejneru
restart: no # výchozí – nikdy
restart: always # vždy restartovat
restart: on-failure # jen při nenulové exit
restart: on-failure:3 # max 3 pokusy
restart: unless-stopped # kromě ručního stop
stop_signal:
Signál pro zastavení (výchozí SIGTERM)
stop_signal: SIGINT
stop_grace_period:
Čekací lhůta před SIGKILL
stop_grace_period: 30s
Závislosti
depends_on:
Spustit po jiných službách — s volitelnou podmínkou
depends_on:
db:
condition: service_healthy # čeká na healthcheck
redis:
condition: service_started # výchozí
migrate:
condition: service_completed_successfully
links:
zastaralé
Starý způsob propojení — dnes stačí sdílené sítě
Healthcheck
healthcheck:
Pravidelná kontrola zdraví kontejneru
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/health"]
# Alternativy:
# test: ["CMD-SHELL", "pg_isready -U postgres"]
# test: ["NONE"] # zakáže healthcheck
interval: 30s # jak často testovat
timeout: 10s # max čekání na výsledek
retries: 3 # po kolika selháních = unhealthy
start_period: 40s # grace period po startu
start_interval: 5s # interval v start_period (V2.23+)
Uživatel a bezpečnost
user:
Spustit kontejner jako daný uživatel
user: "1000:1000"
user: nobody
read_only:
Root filesystem jen pro čtení
read_only: true
privileged:
Plný přístup k hostu — používat opatrně!
privileged: true
cap_add: / cap_drop:
Přidat nebo odebrat Linux capabilities
cap_add:
- NET_ADMIN
- SYS_PTRACE
cap_drop:
- ALL
security_opt:
Bezpečnostní profily (seccomp, apparmor)
security_opt:
- no-new-privileges:true
- seccomp:./seccomp.json
- apparmor:docker-default
secrets:
Tajné hodnoty přípustné ve službě
secrets:
- db_password
- source: server_cert
target: /run/secrets/cert.pem
mode: 0440
Zdroje (standalone Compose V2)
deploy: resources:
CPU a paměťové limity — preferovaný způsob
deploy:
resources:
limits:
cpus: "0.50"
memory: 512M
pids: 100
reservations:
cpus: "0.25"
memory: 128M
mem_limit: / cpus:
V1 legacy
Starý způsob — funguje jen v Compose V1
mem_limit: 512m
cpus: "0.5"
TTY, stdin a terminál
stdin_open:
Otevřít stdin (ekvivalent docker run -i)
stdin_open: true
tty:
Alokovat pseudo-TTY (ekvivalent docker run -t)
tty: true
init:
Použít init jako PID 1 — správné přeposílání signálů
init: true
Ostatní volby
labels:
Metadata kontejneru jako Docker labely
labels:
app: myapp
version: "1.2"
traefik.enable: "true"
profiles:
Spustit službu jen při aktivaci profilu
profiles: ["debug", "tools"]
scale:
Počet replik (přepisuje deploy.replicas)
scale: 3
devices:
Mapování zařízení z hostu
devices:
- "/dev/ttyUSB0:/dev/ttyUSB0"
- "/dev/snd:/dev/snd"
shm_size:
Velikost sdílené paměti /dev/shm
shm_size: "256m"
ipc: / pid:
Sdílení IPC nebo PID namespace
ipc: host
pid: host
sysctls:
Nastavení kernel parametrů
sysctls:
net.core.somaxconn: 1024
net.ipv4.tcp_syncookies: 0
ulimits:
Limity procesů
ulimits:
nofile:
soft: 1024
hard: 4096
nproc: 65535
logging:
Konfigurace log ovladače
logging:
driver: json-file # json-file/syslog/none/fluentd
options:
max-size: "10m"
max-file: "3"
configs: (služba)
Připojit konfiguraci ze sekce configs
configs:
- source: nginx_conf
target: /etc/nginx/nginx.conf
mode: 0440
extends:
Zdědit konfiguraci z jiné služby nebo souboru
extends:
file: common.yml
service: webapp
networks — definice sítí
Typy a základní volby
driver:
Typ (driver) sítě
driver: bridge # výchozí – izolovaná bridge síť
driver: host # sdílí síťový stack hostu
driver: overlay # Swarm – multi-host komunikace
driver: none # bez sítě
driver: macvlan # vlastní MAC adresa
driver: ipvlan # sdílí MAC, vlastní IP
driver_opts:
Volby specifické pro daný driver
driver_opts:
com.docker.network.bridge.name: my_bridge
com.docker.network.driver.mtu: "1450"
external:
Použít existující síť — Compose ji nevytvoří
networks:
existing-net:
external: true
name:
Explicitní název sítě (bez prefixu projektu)
name: shared-network
internal:
Izolovaná síť bez přístupu k internetu
internal: true
attachable:
Umožní ruční připojení kontejnerů (overlay)
attachable: true
enable_ipv6:
Zapnout IPv6 na síti
enable_ipv6: true
IPAM — správa IP adres
ipam:
Konfigurace rozsahu IP adres
networks:
mynet:
ipam:
driver: default
config:
- subnet: 172.20.0.0/16
gateway: 172.20.0.1
ip_range: 172.20.1.0/24
aux_addresses:
reserved: 172.20.0.10
Připojení služby k síti
aliases:
Další hostname pro tuto službu v dané síti
networks:
backend:
aliases:
- database
- db-primary
ipv4_address: / ipv6_address:
Statická IP adresa v dané síti
networks:
mynet:
ipv4_address: 172.20.0.10
ipv6_address: 2001:db8::10
priority:
Priorita sítě — vyšší = výchozí síťové rozhraní
networks:
frontend:
priority: 100
backend:
priority: 10
volumes — definice svazků
Top-level definice svazku
driver:
Ovladač svazku
driver: local # výchozí
driver: nfs
driver: cifs
driver: azure-file
driver_opts:
Volby ovladače — např. NFS mount
volumes:
nfs_data:
driver: local
driver_opts:
type: nfs
o: addr=192.168.1.1,rw,nfsvers=4
device: ":/exports/data"
external:
Použít existující svazek (musí existovat před spuštěním)
volumes:
pgdata:
external: true
name:
Explicitní název svazku (bez prefixu projektu)
name: my-pgdata
labels:
Metadata svazku
labels:
backup: daily
project: myapp
Typy připojení v services.volumes
Pojmenovaný svazek
Docker spravuje umístění — data přežijí down
volumes:
- pgdata:/var/lib/postgresql/data
- redisdata:/data
Bind mount
Přímé mapování adresáře nebo souboru z hostu
volumes:
- ./app:/app # relativní cesta
- /etc/localtime:/etc/localtime:ro
- ~/config:/config
Anonymní svazek
Jen cílová cesta — Docker přiřadí náhodné ID
volumes:
- /var/cache/nginx
- /tmp/app
Dlouhá syntaxe (type)
Detailní konfigurace s explicitním typem
volumes:
- type: volume
source: pgdata
target: /var/lib/pg
read_only: false
volume:
nocopy: true # nekopírovat obsah kontejneru
- type: bind
source: ./config
target: /app/config
read_only: true
bind:
create_host_path: true
propagation: shared # shared/slave/private
- type: tmpfs
target: /tmp
tmpfs:
size: 104857600 # 100MB v bajtech
mode: 1777
build — sestavení obrazu
Základní build volby
context:
Build kontext — adresář nebo Git URL
build:
context: .
context: ./backend
context: https://github.com/user/repo.git
context: https://github.com/user/repo.git#branch
dockerfile:
Cesta k Dockerfile (výchozí: ./Dockerfile)
dockerfile: Dockerfile.prod
dockerfile: docker/Dockerfile
dockerfile_inline:
Inline obsah Dockerfile
dockerfile_inline: |
FROM alpine:3.19
RUN apk add --no-cache curl
COPY . /app
args:
Hodnoty pro ARG instrukce v Dockerfile
args:
- NODE_VERSION=20
- ENV=production
# nebo mapa:
NODE_VERSION: "20"
target:
Multi-stage build — cílová stage
target: production
target: builder
Pokročilé build volby (BuildKit)
cache_from: / cache_to:
Správa cache vrstev při buildu
cache_from:
- myapp:latest
- type=registry,ref=myregistry/myapp
- type=gha # GitHub Actions cache
cache_to:
- type=inline
- type=gha,mode=max
platforms:
Multi-arch build (vyžaduje BuildKit)
platforms:
- linux/amd64
- linux/arm64
- linux/arm/v7
secrets:
Tajné hodnoty dostupné jen při buildu (BuildKit)
secrets:
- server-certificate
- id: mysecret
src: ./mysecret.txt
ssh:
SSH agent socket — pro privátní git repozitáře
ssh:
- default
- mykey=~/.ssh/deploy_key
network:
Síťový mód během buildu
network: host
network: none
tags:
Přidat další tagy výslednému obrazu
tags:
- myapp:latest
- myapp:1.2.3
- myregistry.io/myapp:latest
labels:
OCI labely přidané do výsledného obrazu
labels:
org.opencontainers.image.version: "1.2.3"
org.opencontainers.image.source: https://...
shm_size:
Velikost /dev/shm během buildu
shm_size: "128m"
no_cache: / pull:
Zakázat cache / vždy stáhnout nový base image
no_cache: true
pull: true
additional_contexts:
Pojmenované build kontexty (Compose V2)
additional_contexts:
mylib: ../mylib
node-base: docker-image://node:20
Dockerfile — podrobný tahák
Dockerfile reference: Instrukce se vykonávají shora dolů. Soubor typicky začíná FROM; před ním mohou být jen parser directives, komentáře a globálně scoped ARG. Docker doporučuje psát instrukce velkými písmeny. Pro moderní build používej BuildKit a preferuj COPY před ADD, pokud nepotřebuješ jeho speciální chování.
Základní kostra
# syntax=docker/dockerfile:1
ARG NODE_VERSION=20
FROM node:${NODE_VERSION}-alpine AS base
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:${NODE_VERSION}-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY --from=base /app/dist ./dist
COPY --from=base /app/node_modules ./node_modules
EXPOSE 3000
USER node
CMD ["node", "dist/server.js"]
Parser directives a formát
# syntax=
Vybere frontend parseru Dockerfile a zpřístupní nové BuildKit funkce
# syntax=docker/dockerfile:1
# syntax=docker/dockerfile:1.10
# escape=
Mění escape znak; hodí se hlavně na Windows Dockerfiles
# escape=\
# escape=`
# check=
Parser/build checks v novějších verzích Dockerfile frontendu
# check=skip=JSONArgsRecommended
# check=error=true
Komentáře a pořadí
Instrukce běží postupně; parser directives musí být úplně nahoře před běžnými komentáři i instrukcemi
# syntax=docker/dockerfile:1
# comment
FROM alpine
Shell form vs exec form
Shell form spouští shell; exec form je JSON pole bez implicitního shellu
RUN apk add --no-cache curl
RUN ["apk", "add", "--no-cache", "curl"]
CMD node server.js
CMD ["node", "server.js"]
Základ image a stage
FROM
Určuje base image; Dockerfile musí začít touto instrukcí nebo globálním ARG
FROM alpine:3.20
FROM node:20-alpine AS build
FROM --platform=$TARGETPLATFORM nginx:alpine
ARG před FROM
Globální build argumenty lze použít při výběru base image
ARG NODE_VERSION=20
FROM node:${NODE_VERSION}-alpine
AS stage-name
Pojmenuje build stage pro pozdější COPY --from
FROM golang:1.24 AS builder
FROM scratch
COPY --from=builder /app/server /server
Multi-stage build
Odděl build závislosti od runtime image; výsledný image je menší a čistší
FROM python:3.12 AS build
RUN pip install --prefix=/install -r requirements.txt
FROM python:3.12-slim
COPY --from=build /install /usr/local
Soubory a build context
COPY
Kopíruje soubory z build contextu, stage, image nebo named contextu; pro běžné kopírování je to preferovaná volba
COPY package.json package-lock.json ./
COPY src/ ./src/
COPY --from=build /app/bin/myapp /usr/local/bin/myapp
COPY --chown=node:node --chmod=755 docker-entrypoint.sh /usr/local/bin/
ADD
Umí navíc remote URL a automatické rozbalení lokálních archivů; používej jen když tyto vlastnosti opravdu potřebuješ
ADD app.tar.gz /opt/app/
ADD https://example.com/archive.tgz /tmp/
.dockerignore
Omezuje build context; zásadní pro rychlost buildu a menší cache invalidace
node_modules
dist
.git
*.log
.env
VOLUME
Deklaruje mount point uvnitř image; nedefinuje host path
VOLUME ["/var/lib/postgresql/data"]
VOLUME /data
EXPOSE
Dokumentuje porty, které aplikace poslouchá; port sám nepublikuje
EXPOSE 80
EXPOSE 3000/tcp
EXPOSE 53/udp
Build-time instrukce
RUN
Provádí příkazy při buildu a vytváří novou vrstvu; časté změny v tomto kroku rozbíjí cache
RUN apk add --no-cache curl git
RUN <<EOF
apt-get update
apt-get install -y curl
EOF
RUN --mount
BuildKit mounty pro cache, secrets, bind nebo ssh bez zanechání dat ve výsledné image
RUN --mount=type=cache,target=/root/.npm npm ci
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci
RUN --mount=type=ssh git clone git@github.com:org/private-repo.git
RUN --network
Řídí síťový přístup konkrétního build kroku
RUN --network=none npm test
RUN --network=host apk add --no-cache curl
SHELL
Mění výchozí shell pro shell-form instrukce; užitečné na Windows nebo pro bash strict mode
SHELL ["/bin/bash", "-o", "pipefail", "-c"]
SHELL ["powershell", "-Command"]
Proměnné a metadata
ARG
Build-time proměnná; není automaticky dostupná v běžícím kontejneru a nemá se používat na tajné hodnoty
ARG NODE_VERSION=20
ARG TARGETPLATFORM
RUN echo $TARGETPLATFORM
ENV
Nastaví environment proměnné pro další build kroky i runtime; hodnota se persistuje do image
ENV NODE_ENV=production
ENV APP_HOME=/app
ENV PATH=/app/bin:$PATH
ARG + ENV dohromady
Běžný vzor pro build override s runtime defaultem
ARG APP_ENV=production
ENV APP_ENV=${APP_ENV}
LABEL
Metadata image, typicky OCI labels pro verzi, zdroj a dokumentaci
LABEL org.opencontainers.image.title="myapp"
LABEL org.opencontainers.image.source="https://github.com/acme/myapp"
MAINTAINER
deprecated
Historická instrukce; dnes používej raději LABEL
Runtime chování kontejneru
WORKDIR
Nastaví pracovní adresář pro následující RUN, COPY, ADD, CMD a ENTRYPOINT; pokud neexistuje, vytvoří se
WORKDIR /app
WORKDIR src # výsledkem je /app/src
USER
Určuje uživatele pro další build kroky i runtime; pro produkci je lepší neběžet jako root
USER node
USER 1000:1000
CMD
Výchozí příkaz nebo argumenty; použije se jen poslední CMD
CMD ["nginx", "-g", "daemon off;"]
CMD ["--port", "3000"]
ENTRYPOINT
Hlavní executable kontejneru; s CMD se často kombinuje jako default argumenty
ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]
CMD ["nginx", "-g", "daemon off;"]
HEALTHCHECK
Definuje kontrolu zdraví kontejneru; jen poslední instrukce se počítá
HEALTHCHECK --interval=30s --timeout=3s --retries=3 CMD curl -f http://localhost/health || exit 1
HEALTHCHECK NONE
STOPSIGNAL
Specifikuje signál použitý při ukončování kontejneru
STOPSIGNAL SIGTERM
STOPSIGNAL SIGQUIT
Rozšířené patterny a varování
ONBUILD
Odložená instrukce spuštěná až při použití image jako base image; užitečné jen pro specifické base image scénáře
ONBUILD COPY . /src
ONBUILD RUN npm ci
Cache layering
Nejstálejší kroky dávej nahoru. Typický pattern je nejdřív kopírovat lockfile, nainstalovat dependencies a až potom zbytek aplikace
COPY package*.json ./
RUN npm ci
COPY . .
Secrets
Citlivé údaje nedávej do ARG ani ENV; pro build použij BuildKit secrets a pro runtime orchestration nástroje
RUN --mount=type=secret,id=token,target=/run/secrets/token some-command
COPY vs ADD
Výchozí volba je COPY. ADD použij jen pro archive auto-extract nebo remote URL.
Poslední vyhrává
U CMD, ENTRYPOINT a HEALTHCHECK má efekt jen poslední definice
Docker image — vrstvy, immutable data, přenos a práce s image
Co je image: Docker image je read-only šablona pro spuštění kontejneru. Skládá se z vrstev, které reprezentují změny filesystemu. Vrstvy jsou immutable; při běhu kontejneru nad nimi vzniká tenká zapisovatelná container vrstva. Na novějších instalacích Docker Engine 29+ je lokální image store postavený na containerd snapshotters, zatímco overlay2 je hlavně historické a koncepční pozadí pro pochopení union/copy-on-write modelu.
Infografika — z čeho je image a container složený
docker run myapp:1.0
┌──────────────────────────────────────────────┐
│ Container writable layer │
│ dočasné zápisy, úpravy, delete masky │
│ read-write, zmizí při smazání containeru │
└──────────────────────────────────────────────┘
▲
┌──────────────────────────────────────────────┐
│ Layer 4 app code / build output │
│ COPY . . │
└──────────────────────────────────────────────┘
┌──────────────────────────────────────────────┐
│ Layer 3 dependencies │
│ RUN npm ci │
└──────────────────────────────────────────────┘
┌──────────────────────────────────────────────┐
│ Layer 2 runtime / packages │
│ RUN apk add nodejs │
└──────────────────────────────────────────────┘
┌──────────────────────────────────────────────┐
│ Layer 1 base image │
│ FROM alpine │
└──────────────────────────────────────────────┘
Image = stack read-only vrstev
Container = image + 1 writable vrstva nahoře
Každá image vrstva je diff oproti vrstvě pod ní
Union filesystem / overlay model je složí do jednoho pohledu
Základní pojmy
Image
Read-only balíček obsahující binárky, knihovny, konfiguraci, metadata a výchozí runtime nastavení pro kontejner
Layer
Sada změn filesystemu. Přidání, úprava i smazání souboru vytváří novou vrstvu nebo diff proti předchozí vrstvě
Immutable vrstva
Jakmile je vrstva vytvořená, neupravuje se. Nové změny vznikají jen jako další vrstva nad ní
Container layer
Dočasná zapisovatelná vrstva přidaná při docker run; odlišuje běžící container od image
Tag vs digest
tag je lidsky čitelný ukazatel, digest je neměnný obsahový identifikátor typu sha256:...
Jak fungují vrstvy
Každá vrstva je diff
Vrstva neobsahuje celý filesystem od nuly, ale jen změny proti předchozímu stavu. Finální image vznikne poskládáním těchto diffů
Read-only stack
Image layers jsou sdílené, deduplikované a znovupoužitelné mezi více image i containery
Metadata vrstvy
Některé Dockerfile instrukce mění jen metadata image a ve docker history se pak typicky objeví vrstva o velikosti 0B
Delete není “opravdu pryč”
Smazání souboru vytvoří další vrstvu, která soubor skryje. Data z nižších vrstev mohou stále přispívat k celkové velikosti image
Union filesystem a overlay model
UnionFS princip
Více adresářových vrstev se složí do jednoho logického filesystemu, který container vidí jako jeden strom
overlay2 / overlayfs
Klasický Docker storage driver pracující s lower layers a upper writable layer. Je dobrý mentální model pro pochopení image a container vrstev
copy-on-write
Když container zapisuje do souboru ze spodní read-only vrstvy, Docker vytvoří upravenou kopii do writable vrstvy místo přímé změny spodní vrstvy
whiteout / masking
Smazaný soubor je v horní vrstvě “zamaskovaný”, aby v union pohledu nebyl vidět, i když fyzicky existuje níž
Novější realita
Na fresh Docker Engine 29+ běží image store defaultně přes containerd snapshotters, ale chování z pohledu uživatele je pořád vrstvené a copy-on-write
Container vs image
Image je template
Nemění se při běhu. Můžeš z ní spustit libovolný počet containerů
Container je instance
Má procesy, síť, mounty a svoji vlastní writable vrstvu
Více containerů, jedna image
Všechny sdílí stejné read-only image vrstvy a každý má jen vlastní tenkou horní vrstvu
Persistovaná data
Pro databáze a write-heavy data nepoužívej container layer; použij volumes nebo bind mounts
Jak se s image pracuje
Vyhledání a stažení
Image typicky taháš z registru, nejčastěji Docker Hubu nebo privátního registry
docker search nginx
docker pull nginx:1.27-alpine
docker pull ghcr.io/org/app:1.2.0
Build a tag
Lokálně si image vytvoříš z Dockerfile a pak jí dáš jméno/tag
docker build -t myapp:1.0 .
docker tag myapp:1.0 registry.example.com/team/myapp:1.0
Spuštění
Image se použije jako read-only základ pro container
docker run --rm -p 8080:80 nginx:alpine
docker run -d --name app myapp:1.0
Inspekce
Vrsty, metadata, config, entrypoint, env, digest a velikost zkontroluješ přes CLI
docker image ls
docker image history myapp:1.0
docker image inspect myapp:1.0
docker system df
Naming, tagy a digesty
Formát jména
[registry/]namespace/repository[:tag]; bez registry je výchozí Docker Hub
nginx:alpine
library/ubuntu:24.04
ghcr.io/acme/api:1.4.2
registry.example.com/platform/web:prod
Tag
Pohyblivá reference. latest není “nejnovější build obecně”, jen konkrétní tag v repozitáři
Digest
Obsahově neměnná reference; ideální pro reproducibilní buildy a produkční pinning
docker pull nginx@sha256:...
Multi-platform image
Jedno jméno může ukazovat na image index obsahující varianty pro více architektur, třeba amd64 a arm64
Kde se images ukládají
Lokální image store
Docker daemon si image ukládá lokálně; na moderních instalacích přes containerd image store, historicky přes storage driver typu overlay2
Registry
Nejběžnější distribuční bod pro týmy a CI/CD
Docker Hub
GHCR
Harbor
ECR / GCR / ACR
privátní registry:2
Tar archiv
Pro offline přenos nebo backup můžeš image vyexportovat do souboru a nahrát jinde
Desktop / Engine nuance
Při přepnutí mezi různými backendy image store se staré image můžou dočasně “schovat”, i když data zůstávají na disku
Přenos image bez registru
docker save
Vyexportuje image do tar archivu včetně parent layers a tagů
docker image save myapp:1.0 > myapp.tar
docker image save -o myapp.tar myapp:1.0
docker image save myapp:1.0 | gzip > myapp.tar.gz
docker load
Na druhé straně archiv načteš zpět do lokálního image store; obnoví i tagy
docker image load < myapp.tar.gz
docker image load -i myapp.tar
Jak to přenést
Soubor pošli přes scp, rsync, sdílený disk, USB nebo artifact storage. Pro velké image můžeš archiv komprimovat nebo rozdělit na části
scp myapp.tar.gz user@server:/tmp/
split -b 500m myapp.tar.gz myapp.part.
Kdy se to hodí
Air-gapped prostředí, migrace mezi sítěmi, backup před změnou storage backendu, jednorázový offline deploy
Import, export a commit
save/load
Zachová image jako image včetně vrstev a tagů; to je standardní způsob přenosu bez registry
export/import
docker export a docker import pracují s filesystem snapshotem containeru, ne s plnohodnotnou image historií
docker export mycontainer > rootfs.tar
cat rootfs.tar | docker import - myimage:flat
container commit
Vytvoří image z aktuálního stavu containeru; dobré na experimenty a pochopení vrstev, ale ne jako hlavní produkční workflow
docker container commit mycontainer myimage:debug
Optimalizace a best practices
Stabilní kroky nahoru
Instrukce, které se mění málo, dávej dřív. Docker pak lépe reuse-ne cache a nebude zbytečně rebuildovat vše pod nimi
Malé base image
Používej rozumně malé a důvěryhodné base image; často alpine, slim nebo distroless varianty podle use case
Multi-stage build
Build nástroje nech v builder stage, do runtime stage kopíruj jen artefakty
.dockerignore
Do build contextu neposílej zbytečnosti jako .git, node_modules, logy nebo secrets
Prune a monitoring
Nechceš-li plný disk, průběžně sleduj usage a mazej nepoužívané image
docker system df
docker image prune
docker system prune
Docker container — runtime instance image
Co je container: Container je izolovaný proces spuštěný z image. Image zůstává read-only, container nad ní přidává vlastní zapisovatelnou vrstvu, síť, mounty a runtime konfiguraci. Jednu image můžeš použít pro mnoho containerů najednou.
Základní mentální model
Image → container
Image je šablona, container je její běžící nebo zastavená instance
Izolace
Container běží jako proces s vlastním filesystem pohledem, sítí a resource limity podle toho, jak je spuštěn
Writable layer
Změny za běhu se ukládají do horní zapisovatelné vrstvy; pro dlouhodobá data používej volumes nebo bind mounts
Životní cyklus
create
Vytvoří container bez spuštění procesu
docker container create --name web nginx:alpine
run
Zkratka pro create + start
docker run --name web -p 8080:80 nginx:alpine
docker run -d --name app myapp:1.0
start / stop / restart / rm
Spuštění, zastavení, restart a odstranění existujícího containeru
docker container start web
docker container stop web
docker container restart web
docker container rm web
Foreground a detached mode
Foreground
Container běží v popředí a logy tečou přímo do terminálu
docker run ubuntu echo hello
Detached
Container běží na pozadí; použij -d a logy sleduj zvlášť
docker run -d --name web nginx:alpine
docker logs -f web
Interaktivní shell
Pro TTY a stdin použij -it
docker run -it alpine sh
Každodenní práce
ps
Seznam běžících nebo všech containerů
docker ps
docker ps -a
exec
Spustí další proces v již běžícím containeru
docker exec -it web sh
docker exec app printenv
logs
Zobrazí log output containeru
docker logs web
docker logs -f --tail 100 web
inspect
Vrátí detailní JSON metadata včetně mountů, IP adres, env a stavu
docker inspect web
stats
Průběžné CPU, memory, network a block I/O statistiky
docker stats
docker stats web app db
Restart policy a ukončení
--restart
Určuje, jestli a kdy má Docker container znovu spustit
docker run --restart=no nginx
docker run --restart=always nginx
docker run --restart=unless-stopped nginx
docker run --restart=on-failure:3 myjob
stop timeout
Docker pošle stop signál a čeká definovaný čas, než proces násilně ukončí
docker run --stop-timeout=30 nginx
docker stop -t 30 web
stop signal
Lze změnit signál, který Docker použije pro ukončení procesu
docker run --stop-signal=SIGQUIT nginx
Healthcheck a stav
healthy / unhealthy / starting
Container může reportovat stav přes healthcheck definovaný v image nebo při run/Compose konfiguraci
Přepsání při run
Při spuštění lze healthcheck vypnout nebo parametry upravit
docker run --no-healthcheck nginx
docker run --health-cmd="curl -f http://localhost || exit 1" --health-interval=30s nginx
Kontrola stavu
Status uvidíš přes docker ps nebo detailněji v docker inspect
Storage — volumes, bind mounts a perzistence dat
Základní pravidlo: Data, která mají přežít smazání containeru, nepatří do container writable layer. Používej volumes, bind mounts nebo tmpfs podle typu dat a požadovaného chování.
Mentální model
Container layer
Zápisy do interní writable vrstvy containeru zaniknou při odstranění containeru
Volume
Docker-managed storage mimo lifecycle konkrétního containeru
Bind mount
Přímé mapování cesty z hosta do containeru
tmpfs
Dočasný filesystem v paměti hosta, vhodný pro ephemeral a citlivá data
Volume vs bind mount vs tmpfs
Named volume
Nejlepší default pro perzistentní aplikační data a databáze; Docker řeší umístění a správu
docker run -v pgdata:/var/lib/postgresql/data postgres
Bind mount
Hodí se pro development, sdílení zdrojáků nebo explicitní práci s konkrétní host cestou
docker run --mount type=bind,src=$PWD,target=/app nginx
tmpfs
Data se neukládají do vrstvy ani na disk mountu; po stop/smazání mizí
docker run --tmpfs /run nginx
Praktické mount syntaxe
--mount
Explicitnější a čitelnější syntaxe podporující více mount typů a voleb
docker run --mount source=pgdata,target=/data postgres
docker run --mount type=bind,src=$PWD,target=/app alpine
-v / --volume
Kratší syntaxe, pořád běžně používaná
docker run -v pgdata:/data postgres
docker run -v $PWD:/app alpine
read-only
Mount může být jen pro čtení
docker run --mount type=bind,src=/etc/config,target=/config,readonly app
Lifecycle dat
Volume data žijí dál
Po docker rm volume standardně zůstane, dokud ji explicitně nesmažeš
Anonymous volume
Docker vytvoří volume bez přiděleného jména; snadno se pak hůř dohledává a uklízí
Bind mount je navázaný na host path
Container je pak závislý na konkrétní struktuře host systému
Backup a obnova
Volume backup přes pomocný container
Docker docs ukazují přístup s dočasným containerem a tar archivem
docker run --rm --volumes-from dbstore -v $PWD:/backup ubuntu tar cvf /backup/backup.tar /dbdata
Restore
Archiv lze do volume vrátit zase přes dočasný container
docker run --rm --volumes-from dbstore -v $PWD:/backup ubuntu bash -c "cd /dbdata && tar xvf /backup/backup.tar --strip 1"
Časté chyby a limity
Obscured files
Když mountneš host cestu přes existující data v containeru, původní obsah se překryje
tmpfs není trvalé
Je ephemerální a ukládá data do host memory; není to náhrada volume
Bind mount přidává coupling
Konfigurace se může rozbít při přesunu mezi stroji, OS nebo CI prostředími
Networking — sítě, DNS a publikace portů
Základ: Containery komunikují přes Docker sítě. Interní komunikace container-container není totéž co publikace portu ven na hosta. EXPOSE port jen dokumentuje, zatímco -p nebo --publish ho mapuje ven.
Základní mentální model
Bridge default
Na standalone Dockeru je běžný default bridge networking
User-defined bridge
Doporučený pro aplikace, protože nabízí lepší izolaci a DNS jména mezi containery
Port publishing
Port se mapuje z hosta do containeru; bez publikace může být služba přístupná jen uvnitř Docker sítě
Network drivery
bridge
Výchozí izolovaná síť pro containery na jednom hostu
host
Container sdílí network namespace hosta; neprobíhá běžné port mapping chování
docker run --network host nginx
none
Container nemá žádné síťové rozhraní kromě loopbacku
docker run --network none alpine
overlay
Multi-host síť určená pro Swarm služby a propojení napříč daemon instancemi
Port publishing a EXPOSE
EXPOSE
Metadata v image, které říká, na jakém portu aplikace poslouchá
-p / --publish
Skutečně zveřejní port na hostovi
docker run -p 8080:80 nginx
docker run -p 127.0.0.1:8080:80 nginx
-P / --publish-all
Publikuje všechny exposed porty na náhodné host porty
docker run -P nginx
DNS a komunikace mezi containery
Jména na user-defined bridge
Containery ve stejné user-defined bridge síti se umí oslovit jménem nebo aliasem
network connect
Běžící container lze připojit do další sítě
docker network connect backend web
Container → host
Přístup na hosta je jiný problém než přístup mezi containery; nesahej po publish, pokud potřebuješ jen interní service-to-service komunikaci
Praktické flow
Vytvoření vlastní sítě
Dobrý základ pro více spolupracujících containerů
docker network create appnet
docker run -d --network appnet --name db postgres
docker run -d --network appnet --name app myapp
Debug
Když port není dostupný, ověř: běží proces, je published port, správná síť a správná bind adresa aplikace uvnitř containeru
BuildKit — build cache, mounts a rychlejší buildy
Co BuildKit přináší: modernější build engine, lepší paralelizaci, přesnější cache, build secrets, SSH mounty, cache mounty a pokročilé export/import cache workflow.
Základní pojmy
BuildKit
Moderní build backend Dockeru pro efektivnější a flexibilnější image build
Buildx
CLI plugin a rozhraní pro BuildKit funkce včetně multi-platform buildů a external cache
Cache reuse
Při shodném kroku a vstupu může Docker znovu použít dříve vytvořenou vrstvu místo nového buildu
Jak funguje cache
Instrukce po instrukci
Docker kontroluje každou Dockerfile instrukci a její vstupy; pokud se liší, cache pro ten krok a všechny následující typicky neplatí
COPY a build context
Změna kopírovaných souborů invaliduje příslušný krok a to, co je pod ním
Pořadí je zásadní
Nejstabilnější kroky dávej nahoru, nejčastěji se měnící níž
COPY package*.json ./
RUN npm ci
COPY . .
Co cache invaliduje
Změna instrukce
Jiný text příkazu nebo jiné flagy = jiný cache key
Změna vstupních souborů
Typicky u COPY a ADD
Build args a env použitá v kroku
Pokud mění výsledek kroku, může se cache invalidovat
Ruční vypnutí cache
Na buildu lze cache obejít
docker build --no-cache -t myapp .
BuildKit mounts
cache mount
Persistovaná build cache pro package manažery nebo kompilaci
RUN --mount=type=cache,target=/root/.npm npm ci
RUN --mount=type=cache,target=/var/cache/apt apt-get update
secret mount
Tajná data dostupná jen v konkrétním build kroku bez zapsání do finální image
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci
ssh mount
Použití SSH agenta nebo klíče během buildu, typicky pro privátní Git repozitáře
RUN --mount=type=ssh git clone git@github.com:org/private.git
External cache a CI/CD
cache backends
Build cache lze exportovat a znovu použít mimo lokální stroj
docker buildx build --cache-to type=inline --cache-from type=registry,ref=myorg/myapp .
Multi-stage build
Neřeší jen velikost image, ale pomáhá i oddělit build kroky a cache vrstvy
Multi-platform
Buildx umí buildovat varianty pro více architektur v jednom workflow
docker buildx build --platform linux/amd64,linux/arm64 -t myapp:latest .
Registry — tagování, push/pull a distribuce image
Registry workflow: Image typicky buildneš lokálně nebo v CI, označíš správnou referencí a pošleš do registry přes push. Na jiném stroji ji stáhneš přes pull nebo offline přes save/load.
Jak vypadá image reference
Formát
[registry/]namespace/repository[:tag]
nginx:alpine
ghcr.io/acme/api:1.4.2
registry.example.com/team/web:prod
Výchozí registry
Když registry neuvedeš, Docker typicky pracuje s Docker Hubem
Tag vs digest
Tag je pohyblivý ukazatel; digest je obsahově neměnná reference
Login, tag, push, pull
login
Uloží nebo vyžádá credentials pro registry
docker login
docker login ghcr.io
tag
Přidá image novou referenci bez kopírování obsahu
docker tag myapp:1.0 registry.example.com/team/myapp:1.0
push
Nahraje image layers a metadata do registry
docker push registry.example.com/team/myapp:1.0
pull
Stáhne image podle tagu nebo digestu
docker pull nginx:alpine
docker pull nginx@sha256:...
Tagy a release flow
latest není speciální magie
Je to jen běžný tag; jeho význam si musíš udržet procesně
Verzovací tagy
Pro release workflow dává smysl držet stabilní verze typu 1.4.2, případně paralelně i 1.4 nebo stable
Digest pinning
Do produkce je nejreprodukovatelnější odkaz přes digest
Registries a distribuce
Veřejné registry
Docker Hub nebo jiné cloud registry
Privátní registry
Self-hosted nebo managed řešení pro interní distribuci image
Offline distribuce
Když registry není k dispozici, použij docker image save a docker image load
docker image save -o myapp.tar myapp:1.0
docker image load -i myapp.tar
Troubleshooting — co zkontrolovat, když Docker nedělá co čekáš
První princip: Nehádej. Ověř stav přes docker ps, logy přes docker logs, metadata přes docker inspect a resource chování přes docker stats. Většina problémů se dá rychle zúžit na proces, síť, mount nebo build cache.
Rychlý debug flow
| docker ps -a | Zjisti, jestli container běží, restartuje se nebo hned skončil |
| docker logs NAME | Podívej se na stdout/stderr aplikace |
| docker inspect NAME | Ověř env, mounty, porty, IP adresy, health status |
| docker exec -it NAME sh | Podívej se dovnitř běžícího containeru |
| docker stats | Ověř resource tlak a throttling |
| docker system df | Zjisti, kdo zabírá místo |
Container hned skončí
Zkontroluj hlavní proces
Container žije tak dlouho, jak dlouho běží jeho PID 1 proces
Prohlédni logy
Chyby aplikace nebo shellu bývají nejrychlejší cesta k příčině
Ověř CMD / ENTRYPOINT
Špatný příkaz, chybějící binárka nebo špatné argumenty container ukončí okamžitě
Port není dostupný
Je port published?
Samotné EXPOSE nestačí; potřebuješ -p nebo Compose `ports`
Naslouchá proces správně?
Aplikace uvnitř containeru musí poslouchat na vhodné adrese a portu
Ověř mapping
Zkontroluj port bindings v docker inspect
Mounty a data neodpovídají očekávání
Bind mount překryl obsah
Host mount může skrýt soubory, které byly původně v image na stejném target path
Data zmizela po smazání containeru
Byla zřejmě zapsaná jen do writable container layer, ne do volume
Práva a ownership
Ověř UID/GID a read-only flagy mountu
Build a image problémy
Build je pomalý
Podívej se na pořadí instrukcí, `.dockerignore` a cache reuse
Image je moc velká
Zkontroluj `docker history`, base image, zbytečné build artefakty a multi-stage build
Cache se nechová divně
Ověř, které vstupy se mění a který krok invaliduje build cache
Příkazy první pomoci
docker ps -a
docker logs -f CONTAINER
docker inspect CONTAINER
docker exec -it CONTAINER sh
docker stats
docker image history IMAGE
docker system df
docker network ls
docker volume ls
Security — základní hardening pro image a containery
Praktický přístup: Sniž attack surface, omez privilegia, neukládej secrets do image a ověřuj image obsah. Cílem není “absolutně bezpečný container”, ale rozumné snížení rizika.
Základní principy
Minimal base image
Menší image obvykle znamená menší attack surface a méně balíků k patchování
Nepouštět vše jako root
Pokud to aplikace nepotřebuje, nastav neprivilegovaného uživatele
Least privilege
Přidávej jen capability a přístup, které aplikace skutečně potřebuje
Runtime hardening
USER
V Dockerfile nastav běh pod konkrétním ne-root uživatelem
USER 1000:1000
read-only rootfs
Kde to jde, mountuj root filesystem jen pro čtení a write potřeby řeš přes tmpfs/volume
docker run --read-only nginx
capabilities
Capability lze odebírat nebo přidávat podle potřeby
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx
no-new-privileges
Zabrání procesům získat další privilegia
docker run --security-opt no-new-privileges nginx
Rootless a omezení daemonu
Rootless mode
Docker Engine lze provozovat bez root práv daemonu i containerů
Praktický dopad
Rootless snižuje riziko spojené s privilegovaným daemonem, ale má i specifická omezení a provozní nuance
Secrets a image hygiene
Secrets ne do ARG/ENV
Build args a environment mohou skončit v historii image nebo inspect výstupech
Build secrets
Pro build-time tajné údaje používej BuildKit secrets
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci
Distroless / minimal
Kde to dává smysl, použij minimal nebo distroless runtime image a odděl build stage od runtime stage
Vulnerability scanning
Docker Scout
Docker nabízí image analýzu a CVE přehledy přes Docker Scout
docker scout cves myapp:1.0
Co hledat
Známé zranitelnosti v base image, neaktualizované balíky a outdated dependencies
Krátký checklist
| USER | Neběží aplikace zbytečně jako root? |
| base image | Je image malá, důvěryhodná a aktualizovaná? |
| secrets | Nejsou tajné údaje zapečené do image? |
| read-only | Může být root filesystem jen pro čtení? |
| capabilities | Nejsou přidělená zbytečná privilegia? |
| scan | Proběhla kontrola CVE a base image update? |
deploy — nasazení a škálování
Standalone Compose V2 respektuje resources a restart_policy. Ostatní volby (replicas, update_config, placement) vyžadují Docker Swarm nebo přepínač --compatibility.
Repliky a mód
replicas:
Počet instancí služby
deploy:
replicas: 3
mode:
Typ nasazení
mode: replicated # výchozí – N instancí
mode: global # 1 na každém Swarm uzlu
Rolling update
update_config:
Konfigurace postupné aktualizace
update_config:
parallelism: 2 # aktualizovat po 2
delay: 10s # pauza mezi dávkami
order: start-first # nebo stop-first
failure_action: rollback # nebo pause/continue
max_failure_ratio: 0.1
monitor: 60s # čas sledování po update
rollback_config:
Konfigurace automatického rollbacku
rollback_config:
parallelism: 1
delay: 5s
failure_action: pause
order: stop-first
Zdroje (CPU, paměť, GPU)
resources:
Limity a rezervace zdrojů
resources:
limits:
cpus: "0.50"
memory: 512M
pids: 100
reservations:
cpus: "0.25"
memory: 128M
devices: # GPU
- capabilities: [gpu]
count: 1
driver: nvidia
Restart policy a placement
restart_policy:
Detailní politika restartu (přesnější než restart:)
restart_policy:
condition: on-failure # any/none/on-failure
delay: 5s
max_attempts: 3
window: 120s
placement:
Kde spustit repliky (Swarm — omezení uzlů)
placement:
constraints:
- node.role == manager
- node.labels.region == eu-west
- engine.labels.os == linux
preferences:
- spread: node.labels.zone
max_replicas_per_node: 2
endpoint_mode: / labels:
Způsob publikace portů a Swarm service labely
endpoint_mode: vip # virtual IP (výchozí)
endpoint_mode: dnsrr # DNS round-robin
labels:
traefik.enable: "true"
CLI příkazy — docker compose
Spouštění a zastavování
| docker compose up | Spustit všechny služby |
| docker compose up -d | Na pozadí (detached mode) |
| docker compose up --build | Rebuild před spuštěním |
| docker compose up --force-recreate | Znovu vytvořit kontejnery |
| docker compose up --no-deps web | Spustit jen web, ne závislosti |
| docker compose up --scale web=3 | Spustit 3 instance webové služby |
| docker compose down | Zastavit a smazat kontejnery + sítě |
| docker compose down -v | + smazat pojmenované svazky |
| docker compose down --rmi all | + smazat všechny použité obrazy |
| docker compose down --remove-orphans | Smazat osiřelé kontejnery |
| docker compose start | Spustit zastavené kontejnery |
| docker compose stop | Zastavit bez smazání |
| docker compose stop -t 30 | Zastavit s 30s grace periodem |
| docker compose restart | Restartovat všechny služby |
| docker compose pause | Pozastavit kontejnery (SIGSTOP) |
| docker compose unpause | Obnovit pozastavené kontejnery |
| docker compose kill | Ukončit SIGKILL |
| docker compose kill -s SIGTERM | Poslat vlastní signál |
Build a registry
| docker compose build | Sestavit všechny obrazy |
| docker compose build web | Sestavit jen danou službu |
| docker compose build --no-cache | Bez použití cache |
| docker compose build --parallel | Paralelní build více služeb |
| docker compose build --push | Build a okamžitý push do registru |
| docker compose pull | Stáhnout všechny obrazy z registru |
| docker compose pull --ignore-pull-failures | Pokračovat při chybě pull |
| docker compose push | Push sestavených obrazů do registru |
Monitoring a logy
| docker compose ps | Stav a porty kontejnerů |
| docker compose ps -a | Včetně zastavených kontejnerů |
| docker compose ps --format json | Výstup jako JSON |
| docker compose logs | Výpis logů všech služeb |
| docker compose logs -f web | Sledovat logy služby web (follow) |
| docker compose logs --tail=100 | Posledních 100 řádků |
| docker compose logs --since=1h | Logy za poslední hodinu |
| docker compose top | Procesy běžící v kontejnerech |
| docker compose stats | Živé využití CPU/RAM |
| docker compose port web 80 | Zjistit mapovaný port na hostu |
| docker compose events | Live stream Docker událostí |
| docker compose images | Použité obrazy a jejich velikosti |
| docker compose wait web db | Čekat na ukončení služeb |
Spouštění příkazů v kontejnerech
| docker compose exec web bash | Shell v běžícím kontejneru |
| docker compose exec -u root web sh | Jako root |
| docker compose exec -e VAR=val web sh | S extra proměnnou |
| docker compose exec -w /tmp web sh | V daném pracovním adresáři |
| docker compose exec --index=2 web sh | Konkrétní instance (scale) |
| docker compose run web npm test | Nový kontejner + příkaz |
| docker compose run --rm web sh | Smazat kontejner po skončení |
| docker compose run --no-deps web | Bez spouštění závislostí |
| docker compose run -p 3001:3000 web | S mapováním portu |
| docker compose cp web:/app/log . | Kopírovat soubor z kontejneru |
| docker compose cp ./file web:/app/ | Kopírovat soubor do kontejneru |
Konfigurace, validace a projekty
| docker compose config | Zobrazit vyhodnocenou konfiguraci |
| docker compose config --quiet | Jen validace (exit code 0 = OK) |
| docker compose config --services | Vypsat seznam služeb |
| docker compose config --volumes | Vypsat seznam svazků |
| docker compose config --profiles | Vypsat dostupné profily |
| docker compose -f prod.yml up | Použít vlastní compose soubor |
| docker compose -f a.yml -f b.yml up | Sloučit více compose souborů |
| docker compose --profile debug up | Aktivovat pojmenovaný profil |
| docker compose -p myproject up | Nastavit název projektu |
| docker compose --env-file .env.prod up | Použít vlastní .env soubor |
| docker compose ls | Vypsat běžící Compose projekty |
| docker compose version | Zobrazit verzi Docker Compose |
| docker compose rm | Smazat zastavené kontejnery |
| docker compose alpha watch | Live reload při změně souborů |
Kompletní produkční příklad
Stack: Nginx jako reverse proxy → Node.js aplikace (2 repliky) → PostgreSQL s healthcheckem → Redis cache. Síť backend je interní (bez přístupu k internetu).
docker-compose.yml
services:
nginx:
image: nginx:1.25-alpine
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
- certs:/etc/ssl/certs:ro
networks:
- frontend
depends_on:
app:
condition: service_healthy
restart: unless-stopped
app:
build:
context: ./app
dockerfile: Dockerfile
target: production
args:
- NODE_VERSION=20
environment:
- NODE_ENV=production
- DB_HOST=db
- DB_PORT=5432
- DB_NAME=${POSTGRES_DB}
- REDIS_URL=redis://cache:6379
env_file:
- .env
networks:
- frontend
- backend
depends_on:
db:
condition: service_healthy
cache:
condition: service_started
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 30s
deploy:
replicas: 2
resources:
limits:
cpus: "1.0"
memory: 512M
restart_policy:
condition: on-failure
max_attempts: 3
restart: unless-stopped
init: true
read_only: true
tmpfs:
- /tmp
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
db:
image: postgres:16-alpine
environment:
POSTGRES_DB: ${POSTGRES_DB}
POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- pgdata:/var/lib/postgresql/data
- ./init.sql:/docker-entrypoint-initdb.d/init.sql:ro
networks:
- backend
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
cache:
image: redis:7-alpine
command: redis-server --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru
volumes:
- redisdata:/data
networks:
- backend
restart: unless-stopped
networks:
frontend:
driver: bridge
backend:
driver: bridge
internal: true # bez přístupu k internetu
volumes:
pgdata:
driver: local
labels:
backup: daily
redisdata:
certs:
external: true # musí existovat před spuštěním