Podstawy Docker #5: Wolumeny, sieci i dane

Kontener Docker jest tymczasowy — kiedy go usuniesz, wszystkie dane wewnątrz znikają. Wolumeny rozwiązują ten problem. A sieci pozwalają kontenerom komunikować się ze sobą. Te dwa tematy są kluczowe do sensownej pracy z Dockerem na serwerze.

Na tej stronie: pokaż

Problem: kontener ginie, dane giną

docker run -d --name test-db postgres:16
# ... wrzucasz dane do bazy ...
docker rm -f test-db
# dane zniknęły bezpowrotnie

Żeby dane przetrwały usunięcie czy aktualizację kontenera, musisz je trzymać poza kontenerem — w wolumenie.

Dwa sposoby na trwałe dane

1. Wolumeny Docker (named volumes)

Docker zarządza nimi sam — tworzy katalog na Twoim serwerze w /var/lib/docker/volumes/. Nie musisz wiedzieć gdzie dokładnie.

docker run -d --name db -v dane_postgres:/var/lib/postgresql/data postgres:16

Co się tu dzieje:

dane_postgres — nazwa wolumenu na Twoim serwerze
/var/lib/postgresql/data — ścieżka wewnątrz kontenera, gdzie PostgreSQL zapisuje dane
Docker „łączy” te dwa miejsca — dane zapisane przez kontener lądują w wolumenie na serwerze

W Docker Compose:

services:
  db:
    image: postgres:16
    volumes:
      - dane_postgres:/var/lib/postgresql/data
      #   ↑ serwer       ↑ wewnątrz kontenera

volumes:
  dane_postgres:    # deklaracja wolumenu — Docker go utworzy automatycznie

2. Bind mounts (montowanie katalogu z serwera)

Montujesz konkretny katalog z Twojego serwera do kontenera — Ty decydujesz gdzie na serwerze leżą pliki:

docker run -d --name web -v /home/roman/strona:/usr/share/caddy caddy

Co się tu dzieje:

/home/roman/strona — katalog na Twoim serwerze (musisz go sam utworzyć)
/usr/share/caddy — ścieżka wewnątrz kontenera
Zmieniasz plik na serwerze → kontener od razu to widzi (i odwrotnie)

W Docker Compose:

volumes:
  - ./html:/usr/share/caddy
  #  ↑ serwer (katalog html obok docker-compose.yml)
  #         ↑ wewnątrz kontenera

💡 Skąd wiadomo jakie ścieżki podać wewnątrz kontenera?

Każdy obraz ma dokumentację na Docker Hub, która mówi gdzie aplikacja trzyma dane. Np. PostgreSQL → /var/lib/postgresql/data, Caddy → /usr/share/caddy, n8n → /home/node/.n8n.

Porównanie

Cecha	Wolumen Docker	Bind mount
Kto zarządza?	Docker (sam tworzy i pilnuje)	Ty sam (tworzysz katalog na serwerze)
Gdzie na serwerze?	`/var/lib/docker/volumes/`	Dowolna ścieżka, którą wybierzesz
Backup	`docker cp` lub komendy `docker volume`	Zwykły `cp`/`tar`
Kiedy używać	Dane aplikacji (bazy danych, cache)	Pliki, które chcesz edytować (konfiguracje, HTML)
Składnia w Compose	`nazwa:/ścieżka`	`./katalog:/ścieżka`

💡 Która metoda kiedy?

Dane aplikacji (baza danych, pliki n8n) → wolumen Docker
Pliki, które chcesz edytować (konfiguracje, HTML) → bind mount

Zarządzanie wolumenami

docker volume ls                     # lista wolumenów
docker volume inspect dane_postgres  # szczegóły (ścieżka na dysku itp.)
docker volume rm dane_postgres       # usuń wolumen
docker volume prune                  # usuń WSZYSTKIE nieużywane wolumeny

⚠️ Uwaga przy docker compose down -v

docker compose down nie usuwa wolumenów — dane są bezpieczne. Ale docker compose down -v USUWA wolumeny razem z danymi! Upewnij się, że masz backup zanim użyjesz flagi -v.

Tryb tylko do odczytu

Jeśli kontener nie powinien modyfikować zamontowanych plików, dodaj :ro:

volumes:
  - ./Caddyfile:/etc/caddy/Caddyfile:ro

Backup danych z wolumenu

Metoda 1: kopia z działającego kontenera

docker cp db:/var/lib/postgresql/data ./backup-postgres
#          ↑ nazwa kontenera
#             ↑ ścieżka WEWNĄTRZ kontenera
#                                        ↑ katalog NA SERWERZE

Metoda 2: backup specyficzny dla aplikacji

Dla baz danych lepiej użyć natywnego narzędzia:

docker exec db pg_dumpall -U postgres > backup.sql           # PostgreSQL
docker exec db mysqldump -u root -p --all-databases > backup.sql  # MySQL

💡 Scenariusz: aktualizacja bazy danych

# 1. Backup przed aktualizacją
docker exec db pg_dumpall -U postgres > backup-przed-update.sql

# 2. Zatrzymaj i podmień obraz
docker compose pull
docker compose up -d

# 3. Sprawdź czy działa
docker compose logs db

# 4. Jeśli coś nie tak — przywróć backup
docker exec -i db psql -U postgres < backup-przed-update.sql

Sieci Docker

Kontenery muszą ze sobą rozmawiać — WordPress musi połączyć się z MySQL, n8n z bazą Postgres. Docker ma wbudowany system sieci, który to umożliwia.

Domyślna sieć bridge

Kiedy uruchamiasz kontener przez docker run, trafia do domyślnej sieci bridge. Kontenery w tej sieci mogą łączyć się z internetem, ale nie widzą się nawzajem po nazwie.

docker network ls                    # lista sieci

Docker Compose — automatyczna sieć

Docker Compose automatycznie tworzy sieć dla każdego projektu. Serwisy w tej sieci widzą się po nazwie serwisu:

services:
  app:
    image: n8nio/n8n
    environment:
      - DB_POSTGRESDB_HOST=db        # łączy się po nazwie "db"
  db:
    image: postgres:16

Nie musisz nic konfigurować — Compose tworzy sieć automatycznie i dodaje do niej oba serwisy.

💡 Komunikacja po nazwie

W Docker Compose serwis db jest dostępny pod adresem db (nie localhost, nie 127.0.0.1). Jeśli aplikacja pyta o host bazy danych — wpisz nazwę serwisu.

Mapowanie portów a sieci

Porty mapujesz żeby serwis był dostępny z zewnątrz:

ports:
  - "8080:80"          # host:kontener

Bez mapowania portów serwis jest dostępny tylko dla innych kontenerów w tej samej sieci. Dlatego bazy danych zwykle nie potrzebują ports — to bezpieczniejsze.

Własne sieci

Jeśli masz kilka projektów na jednym serwerze i chcesz, żeby serwisy z różnych projektów się widziały (np. wspólny reverse proxy):

services:
  app:
    image: n8nio/n8n
    networks:
      - frontend
      - backend
  db:
    image: postgres:16
    networks:
      - backend

networks:
  frontend:
    external: true       # sieć utworzona ręcznie, poza tym plikiem Compose
  backend:

Tworzenie sieci zewnętrznej:

docker network create frontend

Kiedy tworzyć własne sieci?

Jeden projekt — nie musisz, Compose zrobi to za Ciebie
Reverse proxy współdzielony między projektami — sieć frontend external
Izolacja — baza danych tylko w sieci backend, nie w frontend

Tryby sieci

Driver	Opis	Kiedy
`bridge`	Izolowana sieć (domyślna)	Prawie zawsze
`host`	Kontener używa sieci hosta bezpośrednio	Rzadko potrzebne
`none`	Brak sieci	Pełna izolacja

💡 Podpowiedź

W 99% przypadków wystarczy domyślna sieć bridge (tworzona automatycznie przez Compose). Nie komplikuj, dopóki nie potrzebujesz.

Komendy sieciowe

docker network ls                            # lista sieci
docker network inspect bridge                # szczegóły sieci
docker network create moja-siec              # utwórz sieć
docker network rm moja-siec                  # usuń sieć
docker network connect moja-siec kontener    # podłącz kontener do sieci
docker network disconnect moja-siec kontener # odłącz

Podsumowanie

Wolumeny

Komenda	Co robi
`docker volume ls`	Lista wolumenów
`docker volume inspect nazwa`	Szczegóły wolumenu
`docker volume rm nazwa`	Usuń wolumen
`docker cp kontener:/ścieżka ./cel`	Kopiuj pliki z kontenera
`docker compose down`	Zatrzymaj (dane zostają)
`docker compose down -v`	Zatrzymaj + USUŃ dane

Sieci

Komenda	Co robi
`docker network ls`	Lista sieci
`docker network create nazwa`	Utwórz sieć
`docker network inspect nazwa`	Szczegóły sieci
`docker network rm nazwa`	Usuń sieć