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 -aZjisti, jestli container běží, restartuje se nebo hned skončil
docker logs NAMEPodívej se na stdout/stderr aplikace
docker inspect NAMEOvěř env, mounty, porty, IP adresy, health status
docker exec -it NAME shPodívej se dovnitř běžícího containeru
docker statsOvěř resource tlak a throttling
docker system dfZjisti, 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
USERNeběží aplikace zbytečně jako root?
base imageJe image malá, důvěryhodná a aktualizovaná?
secretsNejsou tajné údaje zapečené do image?
read-onlyMůže být root filesystem jen pro čtení?
capabilitiesNejsou přidělená zbytečná privilegia?
scanProbě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 upSpustit všechny služby
docker compose up -dNa pozadí (detached mode)
docker compose up --buildRebuild před spuštěním
docker compose up --force-recreateZnovu vytvořit kontejnery
docker compose up --no-deps webSpustit jen web, ne závislosti
docker compose up --scale web=3Spustit 3 instance webové služby
docker compose downZastavit 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-orphansSmazat osiřelé kontejnery
docker compose startSpustit zastavené kontejnery
docker compose stopZastavit bez smazání
docker compose stop -t 30Zastavit s 30s grace periodem
docker compose restartRestartovat všechny služby
docker compose pausePozastavit kontejnery (SIGSTOP)
docker compose unpauseObnovit pozastavené kontejnery
docker compose killUkončit SIGKILL
docker compose kill -s SIGTERMPoslat vlastní signál
Build a registry
docker compose buildSestavit všechny obrazy
docker compose build webSestavit jen danou službu
docker compose build --no-cacheBez použití cache
docker compose build --parallelParalelní build více služeb
docker compose build --pushBuild a okamžitý push do registru
docker compose pullStáhnout všechny obrazy z registru
docker compose pull --ignore-pull-failuresPokračovat při chybě pull
docker compose pushPush sestavených obrazů do registru
Monitoring a logy
docker compose psStav a porty kontejnerů
docker compose ps -aVčetně zastavených kontejnerů
docker compose ps --format jsonVýstup jako JSON
docker compose logsVýpis logů všech služeb
docker compose logs -f webSledovat logy služby web (follow)
docker compose logs --tail=100Posledních 100 řádků
docker compose logs --since=1hLogy za poslední hodinu
docker compose topProcesy běžící v kontejnerech
docker compose statsŽivé využití CPU/RAM
docker compose port web 80Zjistit mapovaný port na hostu
docker compose eventsLive stream Docker událostí
docker compose imagesPouž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 bashShell v běžícím kontejneru
docker compose exec -u root web shJako root
docker compose exec -e VAR=val web shS extra proměnnou
docker compose exec -w /tmp web shV daném pracovním adresáři
docker compose exec --index=2 web shKonkrétní instance (scale)
docker compose run web npm testNový kontejner + příkaz
docker compose run --rm web shSmazat kontejner po skončení
docker compose run --no-deps webBez spouštění závislostí
docker compose run -p 3001:3000 webS 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 configZobrazit vyhodnocenou konfiguraci
docker compose config --quietJen validace (exit code 0 = OK)
docker compose config --servicesVypsat seznam služeb
docker compose config --volumesVypsat seznam svazků
docker compose config --profilesVypsat dostupné profily
docker compose -f prod.yml upPoužít vlastní compose soubor
docker compose -f a.yml -f b.yml upSloučit více compose souborů
docker compose --profile debug upAktivovat pojmenovaný profil
docker compose -p myproject upNastavit název projektu
docker compose --env-file .env.prod upPoužít vlastní .env soubor
docker compose lsVypsat běžící Compose projekty
docker compose versionZobrazit verzi Docker Compose
docker compose rmSmazat zastavené kontejnery
docker compose alpha watchLive 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