Praktyczny przewodnik po Dockerze: jak krok po kroku zbudować i wdrożyć aplikację w kontenerach

Po co w ogóle Docker? Krótki kontekst i sposób myślenia

Problem „u mnie działa” i chaos środowisk

Klasyczny scenariusz: aplikacja działa bezbłędnie na komputerze programisty, przechodzi część testów na serwerze testowym, a na produkcji wywraca się przy pierwszym żądaniu. Różne wersje bibliotek, inne pakiety systemowe, inne ustawienia sieci czy baz danych – to wszystko powoduje rozjazd między środowiskami developerskim, testowym i produkcyjnym.

Docker wprowadza spójny model: aplikacja wraz z zależnościami znajduje się w kontenerze. Ten sam obraz można uruchomić na laptopie, serwerze CI, a później na produkcji. Jeśli host ma zainstalowanego Dockera i zgodny kernel, kontener zachowa się tak samo. To nie rozwiązuje każdego problemu, ale usuwa całą klasę błędów związanych z różnicami w środowisku.

Efekt uboczny jest bardzo praktyczny: konfiguracja środowiska przestaje być ręcznym „klikiem” czy opisem w dokumentacji, a staje się deklaratywna – opisana w Dockerfile i plikach compose. Zmiana zależności czy ustawień to modyfikacja kodu, a nie pół dnia spędzone na serwerze z uprawnieniami roota.

Czym jest kontener w praktycznym sensie

Kontener to uruchomiona instancja obrazu – izolowany proces (lub grupa procesów) na hoście. W praktyce można o nim myśleć jako o lekkiej „mini-maszynie” z własnym systemem plików, procesami i siecią, ale współdzielącej kernel z hostem. Kontener nie jest wirtualną maszyną, nie ma pełnego systemu operacyjnego, ale ma wszystko, czego potrzebuje aplikacja: binaria, biblioteki, konfigurację.

Z punktu widzenia użytkownika kontener to:

• uruchamialna jednostka (polecenie docker run),
• zdefiniowane środowisko plików (system plików obrazu + wolumeny),
• oddzielna przestrzeń nazw procesów i sieci (własne PID-y, własne interfejsy).

Ważne jest to, że kontener jest ulotny. Po usunięciu kontenera znikają jego dane, jeśli nie zostały wyniesione do wolumenów lub na zewnątrz (bazy, S3, itp.). To wymusza inne podejście do przechowywania danych i konfiguracji, ale w zamian daje łatwe skalowanie i powtarzalność.

Kontenery a maszyny wirtualne – praktyczne różnice

Maszyny wirtualne (VM) uruchamiają pełny system operacyjny z własnym kernelem, nad którym siedzi hypervisor. Każda VM jest ciężka, zajmuje sporo RAM i CPU, długo się uruchamia. Kontener startuje w ułamku sekundy, bo jest tylko procesem na hoście, a nie pełnym systemem.

Stąd typowe nieporozumienia: ktoś próbuje traktować kontener jak pełną VM (z usługami typu systemd), albo odwrotnie – oczekuje od kontenera takiej samej izolacji bezpieczeństwa jak od VM. Docker rozwiązuje przede wszystkim problem spójnego środowiska aplikacji, a nie zastępuje każdą wirtualizację.

Gdzie Docker naprawdę błyszczy, a gdzie przeszkadza

Docker szczególnie pomaga, gdy:

• aplikacja składa się z wielu usług (np. web, API, baza, kolejka, cache),
• zespół potrzebuje powtarzalnego środowiska developerskiego,
• istnieje pipeline CI/CD i chcesz łatwo transportować artefakt z builda do produkcji,
• masz mikroserwisy, które chcesz skalować niezależnie.

Przykład: projekt webowy z backendem w Pythonie, frontendem w React, bazą PostgreSQL i Redisem. Zamiast dokumentu „jak to uruchomić”, powstaje docker-compose.yml; nowy developer wykonuje docker compose up i ma działające środowisko bez instalowania Pythona, Node, Postgresa czy Redisa lokalnie.

Docker bywa przerostem formy nad treścią przy małych, jednorazowych narzędziach: prosty skrypt do konwersji plików, jednorazowe odpalenie klienta bazy czy testu wydajności. Jeśli czas zbudowania obrazu i nauki Dockera przekracza korzyść – nie ma sensu na siłę „konteneryzować wszystkiego”. Podobnie na desktopie dla pojedynczych użytkowników, którzy odpalają kilka prostych aplikacji, docker może wprowadzić niepotrzebną złożoność.

Przygotowanie środowiska: instalacja i podstawowe narzędzia

Wybór platformy: Linux, macOS, Windows

Najbardziej naturalnym środowiskiem dla Dockera jest Linux. Kontenery korzystają z funkcji jądra Linuksa (namespaces, cgroups), więc na Linuksie Docker działa najbardziej bezpośrednio. Wystarczy zainstalować pakiety dockera, dodać użytkownika do odpowiedniej grupy i można pracować.

Na macOS i Windows Docker potrzebuje pośredniej warstwy – lekkiej maszyny wirtualnej z Linuksem. Docker Desktop dostarcza taką warstwę i integruje się z systemem, ale trzeba pamiętać o dodatkowym narzucie zasobów. Mimo to do typowej pracy developerskiej Docker Desktop jest wystarczający i wygodny.

Okazjonalnie na Windowsie stosuje się natywny backend WSL2 z linuksową dystrybucją. Jeśli dużo pracujesz z Linuksem, taki układ bywa wygodniejszy, bo większość narzędzi działa jak na natywnym Linuksie.

Instalacja Dockera i pierwsze testy

Na współczesnych dystrybucjach Linuksa zwykle stosuje się oficjalne repozytoria Dockera lub pakiety dystrybucji. Przykładowy schemat (na bazie Debian/Ubuntu):

• dodanie klucza i repozytorium Dockera,
• instalacja pakietów: docker-ce, docker-ce-cli, containerd.io,
• dodanie użytkownika do grupy docker: sudo usermod -aG docker $USER,
• ponowne zalogowanie, sprawdzenie wersji: docker version.

Na macOS/Windows instalacja sprowadza się zwykle do pobrania Docker Desktop, akceptacji licencji i przejścia prostego kreatora. Po uruchomieniu Docker Desktop działa jako demon w tle, a z linii poleceń dostępna jest komenda docker.

Najprostszy test to:

docker run hello-world

Komenda pobierze z Docker Hub niewielki obraz hello-world, uruchomi go i wyświetli komunikat. Dodatkowe szybkie komendy do ogarnięcia sytuacji na hoście:

• docker ps – lista działających kontenerów,
• docker ps -a – wszystkie kontenery (także zatrzymane),
• docker images – lokalne obrazy.

Jeśli na starcie pojawiają się komunikaty o braku uprawnień (np. „permission denied” przy docker ps), oznacza to zwykle konieczność dodania użytkownika do grupy docker lub uruchamiania komend z sudo.

CLI kontra GUI: co naprawdę jest potrzebne na początku

Większość realnej pracy z Dockerem odbywa się w CLI. Komendy docker build, docker run, docker logs, docker exec to podstawa, którą warto opanować na pamięć. GUI (Docker Desktop, Portainer) bywa przydatne do podglądu stanu kontenerów i logów, ale bez CLI i tak się nie obejdzie.

Portainer jest ciekawą opcją na serwerach – uruchamiany jako kontener, daje webowe GUI do zarządzania kontenerami, obrazami i wolumenami. Dobrze się sprawdza na małych serwerach VPS, gdzie nie ma rozbudowanej orkiestracji typu Kubernetes.

Jednocześnie na etapie nauki docker dla początkujących zwykle lepiej skupić się na CLI. Dzięki temu lepiej zrozumiesz, co faktycznie się dzieje pod spodem, a ewentualne GUI stanie się tylko wygodnym dodatkiem, a nie „magiczna czarna skrzynka”. Wiele innych narzędzi DevOps (np. systemy CI) i tak operuje stricte na komendach CLI.

Struktura plików projektu z Dockerem

Najprostszy układ katalogu aplikacji konteneryzowanej to:

• katalog główny projektu (repozytorium),
• kod źródłowy (np. src/, app/),
• pliki zależności (np. requirements.txt, package.json),
• Dockerfile w katalogu głównym,
• opcjonalnie docker-compose.yml dla środowiska wielokontenerowego,
• plik .dockerignore, by ograniczyć niepotrzebne kopiowanie do obrazu.

Model mentalny Dockera: obrazy, kontenery, registry

Obraz, kontener, warstwa, tag, repozytorium

Obraz (image) to szablon – niezmienny system plików z metadanymi, z którego uruchamia się kontenery. Obraz składa się z warstw (layers), które są budowane krok po kroku na podstawie instrukcji w Dockerfile. Każda instrukcja (np. RUN, COPY) tworzy nową warstwę.

Kontener to uruchomiona instancja obrazu. Ma własny zapis zmian w systemie plików (warstwę zapisu), swój PID, IP w sieci dockerowej, własne zmienne środowiskowe. Jeden obraz może być podstawą dla wielu kontenerów – np. nginx:alpine jako trzy różne fronty dla trzech aplikacji.

Tag to etykieta wersji obrazu. Najczęściej spotykane są znaczniki typu :latest, :1.0, :1.0.3 czy :alpine. Tag nie gwarantuje treści – to tylko nazwa przypięta do konkretnego identyfikatora obrazu (digestu).

Repozytorium (repository) to logiczny zbiór obrazów o tej samej nazwie, ale różnych tagach – np. wszystkie warianty myapp. Registry (rejestr) – Docker Hub, GitHub Container Registry – przechowuje takie repozytoria.

Cykl życia: od Dockerfile do działającego kontenera

Najprostszy cykl pracy wygląda tak:

1. Tworzysz Dockerfile opisujący bazowy obraz i kroki budowania.
2. Budujesz obraz: docker build -t myapp:1.0 .
3. Sprawdzasz lokalne obrazy: docker images.
4. Uruchamiasz kontener: docker run -d --name myapp-container myapp:1.0
5. Podglądasz logi: docker logs -f myapp-container.
6. Zatrzymujesz: docker stop myapp-container, usuwasz: docker rm myapp-container.

Obraz jest niemutowalny: jeśli zmienisz Dockerfile, budujesz nowy obraz (najlepiej z nowym tagiem). Kontener natomiast można restartować, nadawać mu nazwy, podpinać wolumeny czy zmienne środowiskowe przy starcie. Dzięki temu build jest powtarzalny, a konfiguracja środowiska uruchomieniowego może być inna dla dev, test i produkcji.

Registry: Docker Hub i prywatne rejestry

Domyślnym publicznym registry jest Docker Hub. Pullowanie nginx bez podawania registry oznacza w praktyce docker.io/library/nginx:latest. GitHub Container Registry czy GitLab Registry działają podobnie, integrując się z repozytoriami kodu.

W firmach często korzysta się z prywatnych registry, by obrazy (np. z kodem firmowym) nie były publiczne. Może to być np. Harbor, Artifactory, GitLab Registry czy ECR w AWS. Podstawowe operacje są identyczne:

• docker pull registry.example.com/projekt/aplikacja:1.0,
• docker push registry.example.com/projekt/aplikacja:1.0.

Przed push/pull do prywatnego registry zwykle trzeba się zalogować: docker login registry.example.com. Poświadczenia trafiają do lokalnego configu Dockera (najczęściej ~/.docker/config.json), dlatego trzeba rozsądnie chronić ten plik.

W praktyce sensowna strategia to trzymanie tylko „oficjalnych” buildów w registry (np. wytworzonych przez CI), a lokalne eksperymenty oznaczać jednoznacznymi tagami (np. feature-x-dev) i nie wypychać ich nigdzie poza maszynę deweloperską. Minimalizuje to ryzyko, że tymczasowy obraz trafi przypadkiem na serwer produkcyjny.

Przy pracy z wieloma registry przydaje się prosty porządek nazewnictwa. Dobrym schematem jest: registry.domena/projekt/aplikacja:środowisko-wersja, np. registry.example.com/crm/api:prod-1.4.2 albo registry.example.com/crm/api:staging-1.4.2. Taka konwencja od razu mówi, skąd obraz pochodzi i gdzie powinien być używany.

Obrazy w registry są identyfikowane nie tylko tagiem, lecz przede wszystkim digestem (np. @sha256:…). Jeśli środowisko produkcyjne ma być stabilne, można odwoływać się w manifestach orkiestracji (Kubernetes, Swarm) bezpośrednio do digestów. Tag wtedy służy ludziom, a maszyny trzymają się niezmiennego identyfikatora binarnej zawartości obrazu.

Jeśli chcesz pójść krok dalej, pomocny może być też wpis: Protokół TLS bez tajemnic: certyfikaty, szyfry i pułapki w przeglądarkach.

Przy rozproszonej pracy zespołowej rozsądne jest też regularne czyszczenie starych i nieużywanych tagów w registry. Z czasem każde buildowanie z osobnym tagiem prowadzi do śmietnika. Większość nowoczesnych rejestrów obsługuje polityki retencji – np. kasowanie obrazów nieużywanych od roku lub trzymanie tylko ostatnich kilku wersji danej gałęzi.

Docker wprowadza jasny podział: budowanie aplikacji kończy się obrazem, uruchamianie – kontenerem, a współdzielenie – push/pull do registry. Jeśli ten prosty model mentalny wejdzie w nawyk, pozostałe elementy ekosystemu (Dockerfile, wolumeny, sieci, CI/CD, orkiestracja) układają się w spójną, przewidywalną całość i przestają wyglądać jak zbiór losowych komend do zapamiętania.

Pierwsza aplikacja w kontenerze: prosty przykład krok po kroku

Minimalna aplikacja webowa jako cel ćwiczenia

Na start dobrze wybrać coś, co:

• jest proste do uruchomienia lokalnie,
• ma jeden proces (np. prosty serwer HTTP),
• pozwala łatwo sprawdzić, czy kontener działa – np. w przeglądarce.

Dobrym kandydatem będzie mały serwer HTTP w Pythonie czy Node.js. Załóżmy prostą aplikację w Pythonie, nasłuchującą na porcie 8000.

Przygotowanie prostego kodu aplikacji

Struktura katalogu roboczego:

• myapp/
  • app.py
  • requirements.txt
  • Dockerfile

Przykładowy app.py (Flask):

from flask import Flask

app = Flask(__name__)

@app.route("/")
def index():
    return "Hello from Dockerized app!"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000)

Plik requirements.txt:

flask==3.0.0

Ten kod w trybie „klasycznym” uruchomiłbyś poleceniem:

pip install -r requirements.txt
python app.py

Docker ma ten proces zamknąć w powtarzalnym kontenerze, bez ręcznego ustawiania zależności.

Pisanie pierwszego Dockerfile dla aplikacji

Przykładowy Dockerfile dla powyższej aplikacji:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 8000

CMD ["python", "app.py"]

Co się tu dzieje, po kolei:

1. FROM python:3.11-slim – wybór obrazu bazowego z zainstalowanym Pythonem.
2. WORKDIR /app – ustawienie katalogu roboczego wewnątrz obrazu.
3. COPY requirements.txt . – skopiowanie pliku zależności.
4. RUN pip install ... – instalacja bibliotek.
5. COPY app.py . – skopiowanie samej aplikacji.
6. EXPOSE 8000 – informacja dla ludzi i orkiestracji, na jakim porcie aplikacja nasłuchuje.
7. CMD ["python", "app.py"] – domyślna komenda uruchomieniowa kontenera.

Kluczowa rzecz: podczas builda Docker wykonuje kolejne instrukcje, zapisuje wynik w warstwach i potrafi je cache’ować. Prawidłowa kolejność COPY i RUN ma realny wpływ na czas buildów.

Budowa obrazu i pierwszy run

Będąc w katalogu myapp/ (tam, gdzie leży Dockerfile), wykonujesz:

docker build -t myapp:1.0 .

Parametry:

• -t myapp:1.0 – nazwa i tag obrazu,
• . – kontekst builda, czyli bieżący katalog.

Po zakończonym buildzie obraz powinien być widoczny w docker images. Środowisko uruchamiasz komendą:

docker run -d --name myapp-container -p 8000:8000 myapp:1.0

Co tu jest istotne:

• -d – tryb „detached” (w tle),
• --name myapp-container – czytelna nazwa kontenera,
• -p 8000:8000 – mapowanie portu hosta na port kontenera (host:container),
• myapp:1.0 – obraz, z którego ma powstać kontener.

Po chwili otwierasz http://localhost:8000 i powinieneś zobaczyć tekst zwrócony przez aplikację. Jeśli coś nie działa, standardowe ścieżki diagnostyczne to:

• docker ps – czy kontener w ogóle działa,
• docker logs myapp-container – czy nie ma wyjątków przy starcie,
• docker inspect myapp-container – szczegóły konfiguracji i sieci.

Modyfikacja aplikacji i ponowny build

Scenariusz codzienny: drobna zmiana w kodzie, np. nowy endpoint, i pytanie jak szybko to odświeżyć w kontenerze. Procedura jest zawsze podobna:

1. Zmiana w app.py.
2. Ponowny build: docker build -t myapp:1.1 .
3. Uruchomienie nowej wersji pod inną nazwą kontenera, np.:

   docker run -d --name myapp-v11 -p 8001:8000 myapp:1.1
   

4. Test na http://localhost:8001.

Podejście z nowym tagiem obrazu i osobnym kontenerem pozwala porównać stare i nowe zachowanie równolegle, co jest wygodne przy debugowaniu regresji.

Debugowanie aplikacji w uruchomionym kontenerze

Kiedy aplikacja działa inaczej w kontenerze niż lokalnie „na gołym systemie”, przydaje się wejście do środka. Najprostszy wzorzec:

docker exec -it myapp-container /bin/bash

Jeśli obraz jest „szczupły” i nie ma basza, można użyć:

docker exec -it myapp-container sh

W środku da się sprawdzić wersje pakietów, zmienne środowiskowe, zawartość katalogów, pliki logów. Jeśli zależności różnią się względem oczekiwań, powodem bywa najczęściej:

• nieprzebudowany obraz po zmianie requirements.txt,
• nieprawidłowy kontekst builda (Dockerfile kopiuje inne pliki niż myślisz),
• mylenie tagów – uruchomiony jest stary obraz o tej samej nazwie, ale innej wersji.

Dockerfile w praktyce: instrukcje, warstwy i dobre nawyki

Najczęściej używane instrukcje i ich rola

Podstawowy zestaw instrukcji Dockerfile, z którym spędza się najwięcej czasu:

• FROM – wybór obrazu bazowego,
• WORKDIR – katalog roboczy,
• COPY / ADD – kopiowanie plików do obrazu,
• RUN – komendy wykonywane przy buildzie,
• ENV – zmienne środowiskowe ustawiane w obrazie,
• EXPOSE – deklaracja portu, na którym nasłuchuje proces w kontenerze,
• CMD i ENTRYPOINT – definicja komendy startowej.

ADD kusi tym, że potrafi m.in. rozpakować archiwum tar, ale w większości aplikacji bezpieczniej i czytelniej trzymać się COPY. ADD zostaje raczej do specyficznych zastosowań.

Kolejność instrukcji a cache warstw

Docker agresywnie korzysta z cache warstw podczas builda. Jeśli instrukcje i ich wejście (pliki, zmienne) się nie zmieniły, warstwa jest brana z cache, bez ponownego wykonania. Kolejność instrukcji decyduje więc o tym, jak często będziesz czekać na instalację zależności.

Typowy wzorzec dla aplikacji w Pythonie/Node:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "app.py"]

Logika:

• Najpierw kopiujesz requirements.txt i instalujesz zależności.
• Dopiero potem kopiujesz resztę kodu (COPY . .).

Dzięki temu drobna zmiana w kodzie nie unieważnia warstwy z instalacją bibliotek. Gdyby COPY . . było na początku, każda zmiana w pliku źródłowym zmuszałaby Dockera do ponownego pip install.

Obrazy „pełne” vs „slim” vs „alpine”

Wybór obrazu bazowego ma wpływ na:

• rozmiar końcowego obrazu,
• czas pobierania na serwerach,
• dostępność narzędzi systemowych (debugowanie, kompilacja),
• potencjalną powierzchnię ataku (im mniej pakietów, tym lepiej).

Przykłady dla Pythona:

Taki układ ułatwia integrację z systemami CI/CD (wskazujesz po prostu katalog repozytorium jako kontekst builda) oraz z innymi narzędziami typowymi dla świata devops, które podpowiadają chociażby praktyczne wskazówki: informatyka w podobnym stylu pracy z kodem i infrastrukturą.

• python:3.11 – pełna dystrybucja, wygodna do eksperymentów i buildów,
• python:3.11-slim – mniejszy rozmiar, zwykle rozsądny wybór na produkcję,
• python:3.11-alpine – bardzo mały, ale potrafi sprawiać problemy przy kompilacji niektórych bibliotek (inne glibc/musl, inne pakiety).

Częsty kompromis to użycie „cięższego” obrazu w etapie build (np. multi-stage) i „szczupłego” w finalnym obrazie. Przykładowy szkic:

FROM node:22 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

W pierwszym etapie powstaje build frontendu, w drugim – minimalny serwer HTTP serwujący gotowe pliki.

CMD vs ENTRYPOINT: kiedy którego użyć

CMD definiuje domyślną komendę, którą można łatwo nadpisać przy docker run. ENTRYPOINT traktowane jest jako „główna komenda”, a CMD staje się domyślnymi argumentami.

Przykład 1 – prosty serwer, gdzie wystarczy CMD:

CMD ["python", "app.py"]

Możesz uruchomić kontener z inną komendą, np.:

docker run -it myapp:1.0 bash

Przykład 2 – narzędzie CLI, które ma zawsze wywoływać konkretny program, a argumenty przekazujesz przy starcie:

ENTRYPOINT ["backup-tool"]
CMD ["--help"]

Wtedy:

docker run mybackup

wykona backup-tool --help, a

docker run mybackup --full --target=/data

wykona backup-tool --full --target=/data. Taki wzorzec jest wygodny przy budowaniu narzędzi uruchamianych z CI lub przez administratorów.

.dockerignore – ochrona przed tłustym kontekstem builda

Podczas docker build Docker wysyła do demona cały kontekst builda, czyli katalog, który podałeś (np. .) wraz z zawartością. Bez pliku .dockerignore w obrazie mogą lądować zbędne rzeczy: .git/, artefakty buildów, duże pliki tymczasowe.

Przykładowy .dockerignore dla repozytorium aplikacji:

.git
.gitignore
node_modules
__pycache__
*.pyc
dist
build
.env
Dockerfile*
docker-compose.yml

Efekt:

• szybsze buildy (mniej danych do spakowania i wysłania do demona),
• mniejsze ryzyko przypadkowego wycieku wrażliwych plików (np. .env) do obrazu.

Praca z danymi: wolumeny, bind mounty, konfiguracja

Dlaczego dane trzymamy poza kontenerem

Kontener jest traktowany jako jednorazowy: można go w każdej chwili usunąć i odtworzyć z obrazu. Jeśli dane aplikacji (baza, uploady, logi) byłyby wyłącznie w warstwie zapisu kontenera, znikną wraz z jego skasowaniem.

Stąd zasada: wszystko, co ma przetrwać restart czy rekreację kontenera, powinno być trzymane na zewnątrz – w wolumenach lub na hostowym systemie plików (bind mount). Kontener staje się wtedy wymienialną „powłoką” wokół trwałych danych.

Wolumeny zarządzane przez Dockera

Wolumen (volume) to kawałek przestrzeni dyskowej zarządzany przez Dockera. Może być lokalny (na tym samym hoście) lub dostarczony przez wtyczkę (np. EBS w AWS, NFS).

Podstawowe operacje:

docker volume create mydata
docker volume ls
docker volume inspect mydata
docker volume rm mydata

Wolumen podpinasz przy uruchamianiu kontenera:

docker run -d 
  --name myapp 
  -v mydata:/var/lib/myapp 
  myapp:1.0

Kontener może być dowolnie usuwany i tworzony na nowo, a katalog /var/lib/myapp zachowa zawartość, bo fizycznie znajduje się w wolumenie. Dla usług typu PostgreSQL czy Redis taki wzorzec jest praktycznie obowiązkowy.

Wolumeny dobrze sprawdzają się też w środowiskach serwerowych, gdzie nie chcesz wiązać się z konkretną ścieżką na hoście. Docker dba o lokalizację i uprawnienia, a Ty operujesz jedynie nazwą wolumenu. W połączeniu z wtyczkami (np. do EBS czy Ceph) ten sam kontenerowy stack można przenosić między hostami, nie zmieniając definicji usługi.

Bind mounty: mapowanie katalogów z hosta

Bind mount to bezpośrednie podpięcie katalogu z hosta do środka kontenera. Używa się go najczęściej przy developmentcie, logach albo przy integracji z istniejącą strukturą danych na serwerze.

Przykład dla środowiska developerskiego, gdzie chcemy „na żywo” widzieć zmiany w kodzie:

docker run -d 
  --name myapp-dev 
  -v $(pwd):/app 
  -p 8000:8000 
  myapp:dev

Kod jest na hoście, kontener tylko go widzi pod /app. Edytor, testy, narzędzia linterskie działają tak jak wcześniej, a proces w kontenerze korzysta z aktualnej wersji plików. W środowisku produkcyjnym bind mounty częściej służą do logów (np. /var/log/myapp) albo do współdzielenia danych z innymi systemami na tym samym serwerze.

Trzeba mieć świadomość, że bind mount zdejmuje z Dockera kontrolę nad zawartością katalogu. Jeśli ktoś na hoście usunie lub zmieni uprawnienia plików, kontener od razu to „poczuje”. Przy aplikacjach krytycznych bezpieczniej zwykle oprzeć się na wolumenach, a bind mounty zostawić dla scenariuszy administracyjnych i deweloperskich.

Strategie przechowywania konfiguracji

Obrazu nie powinno się przebudowywać tylko po to, żeby zmienić URL do bazy czy poziom logowania. Konfiguracja powinna wychodzić na zewnątrz: zmienne środowiskowe, pliki konfiguracyjne w wolumenach lub bind mountach, ewentualnie sekrety z zewnętrznego systemu (Vault, SSM, Secrets Manager).

Najprostszy wariant to zmienne środowiskowe:

docker run -d 
  -e DATABASE_URL=postgres://user:pass@db:5432/app 
  -e LOG_LEVEL=info 
  myapp:1.0

Dla bardziej złożonej konfiguracji wygodny bywa jeden plik YAML/JSON trzymany na hoście lub w wolumenie:

docker run -d 
  -v /etc/myapp/config.yml:/app/config.yml:ro 
  myapp:1.0

Aplikacja czyta wtedy ustawienia z pliku, a Ty możesz je wersjonować osobno, spinać z Ansible/Terraformem i aktualizować bez modyfikacji obrazu. Flaga :ro (read-only) ogranicza ryzyko, że przypadkowa zmiana w kontenerze nadpisze konfigurację.

Co dalej: sieci i łączenie usług

Mając opanowane obrazy, kontenery oraz sposób obchodzenia się z danymi, sensownie jest pójść krok dalej i uporządkować komunikację między usługami. Sieci Dockera i ich proste wzorce (bridge, overlay, sieci prywatne per projekt) pozwalają rozdzielić ruch, zdefiniować stabilne nazwy hostów między kontenerami i ograniczyć ekspozycję na świat zewnętrzny, bez wprowadzania od razu pełnego klastra orkiestracji.

Sieci w Dockerze: modele, praktyka i typowe wzorce

Podstawowe typy sieci: bridge, host, none

Docker udostępnia kilka wbudowanych driverów sieciowych. Najczęściej trafia się na trzy z nich:

• bridge – domyślna sieć dla kontenerów uruchamianych bez dodatkowych opcji,
• host – współdzielenie sieci z hostem, bez izolacji na poziomie IP/portów,
• none – brak połączenia sieciowego, poza loopbackiem.

Tryb bridge tworzy wirtualny switch na hoście. Kontenery dostają własne IP (np. 172.18.0.2), mogą gadać między sobą w obrębie tej sieci, a na świat wychodzą przez NAT. W praktyce jest to najbezpieczniejszy i najbardziej elastyczny wariant dla większości usług aplikacyjnych.

Tryb host przydaje się tam, gdzie liczy się prostota integracji z istniejącą infrastrukturą sieciową albo każdy dodatkowy „hop” sieciowy jest niepożądany (np. monitoring, narzędzia sieciowe). Kontener używa wtedy interfejsu sieciowego hosta, a aplikacja nasłuchuje na tych samych portach, co inne procesy systemowe. Konsekwencja: brak izolacji portów między kontenerami i większe ryzyko kolizji.

Trybu none używa się, gdy kontener w ogóle nie ma komunikować się z siecią – np. zadanie wsadowe przetwarzające dane z podpiętego wolumenu. Dostępny jest tylko lo, więc nawet przypadkowy kod sieciowy nie wycieknie na zewnątrz.

Domyślna sieć bridge vs sieci użytkownika

Docker tworzy przy starcie sieć bridge o nazwie bridge. Jeśli uruchomisz kontener bez podawania sieci, trafi właśnie tam. To wygodne na początku, ale ma ograniczenia:

• brak wbudowanego DNS po nazwach kontenerów (komunikacja raczej po IP),
• brak wyraźnego odseparowania aplikacji – wszystko ląduje w jednym „worku”.

Dla realnych projektów dużo lepszy jest własny bridge per aplikacja lub per środowisko:

docker network create 
  --driver bridge 
  myapp-net

Uruchamianie kontenerów z przypisaną siecią:

docker run -d 
  --name db 
  --network myapp-net 
  -e POSTGRES_PASSWORD=secret 
  postgres:16

docker run -d 
  --name api 
  --network myapp-net 
  -e DATABASE_HOST=db 
  myapp-api:1.0

Kontener api widzi bazę po nazwie db, bo w sieciach użytkownika działa wewnętrzny DNS Dockera. Nie ma potrzeby szukania IP ani ręcznego wpisywania ich w konfigurację. Dodatkowo inne projekty na tym samym hoście nie są automatycznie podłączane do tej sieci, więc trudniej przypadkiem „przestrzelić się” z połączeniem do nie tej bazy.

Dobrym uzupełnieniem będzie też materiał: Jak zbudować cichy i wydajny komputer do grania krok po kroku — warto go przejrzeć w kontekście powyższych wskazówek.

Mapowanie portów: -p, EXPOSE i konsekwencje

Wewnętrzne porty kontenera są niewidoczne na zewnątrz, dopóki ich nie wystawisz. Służy do tego mapowanie portów przy docker run:

docker run -d 
  --name web 
  -p 8080:80 
  myapp-web:1.0

Znaczenie zapisu -p 8080:80 jest proste: port 8080 na hoście przekieruj na port 80 w kontenerze. Kontener może nasłuchiwać np. na 0.0.0.0:80, a użytkownik wchodzi przez http://host:8080. Jeśli aplikacja ma być dostępna tylko lokalnie, można związać port z adresem 127.0.0.1:

docker run -d 
  --name web-local 
  -p 127.0.0.1:8080:80 
  myapp-web:1.0

Instrukcja EXPOSE w Dockerfile nie otwiera portu na świat – to tylko informacja dokumentacyjna (i sygnał dla niektórych narzędzi orkiestrujących). Rzeczywista ekspozycja dzieje się przy -p lub w definicji usługi w narzędziach typu Compose czy Swarm.

Przy kilku usługach webowych czy API dobrym zwyczajem jest zrezygnowanie z wielu losowych portów na hoście i schowanie wszystkiego za jednym reverse proxy (np. Traefik, Nginx). Kontenery aplikacji widzą wtedy siebie w prywatnej sieci, a na świat wychodzi wyłącznie proxy z sensowną konfiguracją TLS, logów i limitów.

Izolowanie środowisk: sieci prywatne i „warstwy” dostępu

Gdy na jednym hoście ląduje kilka środowisk (np. staging, demo, małe production), ich logiczny podział można zrealizować prostym schematem sieciowym:

• osobne sieci bridge dla każdego środowiska (myapp-staging-net, myapp-prod-net),
• wspólna sieć „edge” na potrzeby reverse proxy lub load balancera.

Reverse proxy podłącza się wtedy do dwóch sieci: jednej „zewnętrznej” (z mapowaniem portów na hosta), drugiej „wewnętrznej” z aplikacją:

docker network create edge-net
docker network create myapp-prod-net

docker run -d 
  --name reverse-proxy 
  --network edge-net 
  -p 80:80 -p 443:443 
  nginx:alpine

docker network connect myapp-prod-net reverse-proxy

Kolejne usługi aplikacyjne (API, frontend, baza) podłącza się wyłącznie do myapp-prod-net. Świat zewnętrzny zna tylko reverse proxy. Gdy potrzebne jest odseparowanie backendu od bazy, często stosuje się jeszcze trzecią sieć tylko dla komponentów danych, a API pełni rolę „bramy” dla zapytań.

Łączenie kontenerów między hostami: overlay i zewnętrzne rozwiązania

Sam Docker Engine w trybie pojedynczego hosta nie buduje sieci rozproszonej między maszynami. Do tego służą:

• sieci overlay w ramach Docker Swarm,
• rozwiązania zewnętrzne (np. CNI w Kubernetesie, Calico, flannel),
• lub klasyczne podejście: L2/L3 w infrastrukturze (VLAN, VPC) i statyczna konfiguracja adresów.

W mniejszych środowiskach często wystarcza prosty wariant: każdy host ma prywatne IP w sieci VPC/VLAN, a kontenery komunikują się po adresie hosta i zmapowanym porcie lub przez lokalny reverse proxy. Dla środowisk produkcyjnych, gdzie ważna jest mobilność kontenerów między węzłami, częściej stosuje się pełnoprawną orkiestrację, która zarządza siecią klastrową.

Debugowanie problemów sieciowych w kontenerach

Przy problemach z połączeniem dobrze sprawdza się prosty kontener narzędziowy z zainstalowanymi curl, dig i podobnymi narzędziami. Można go podłączyć do tej samej sieci, co aplikacja:

docker run -it --rm 
  --network myapp-net 
  alpine:latest sh

# wewnątrz kontenera:
apk add --no-cache curl bind-tools
curl http://api:8080/health
dig db

Podejście jest szybkie i nie wymaga „brudzenia” właściwego obrazu aplikacji dodatkowymi pakietami diagnostycznymi. Jeśli brak połączenia wynika z kolizji portów na hoście, przydaje się też proste sprawdzenie:

docker ps
ss -tulpen | grep ':8080'

Połączenie tych narzędzi zwykle wystarcza, żeby w kilka minut ustalić, czy winna jest konfiguracja sieci Dockera, mapowanie portów, czy raczej firewall lub routing poza hostem.

Najczęściej zadawane pytania (FAQ)

Po co używać Dockera, skoro aplikacja działa na moim komputerze?

Docker rozwiązuje klasyczny problem „u mnie działa”. Aplikacja zainstalowana ręcznie na laptopie może korzystać z innych wersji bibliotek, pakietów systemowych czy ustawień sieci niż na serwerze testowym lub produkcyjnym. To prowadzi do błędów, których trudno szukać, bo wynikają z różnic w środowisku, a nie z samego kodu.

W Dock erze aplikacja wraz z zależnościami jest zamknięta w obrazie. Ten sam obraz uruchamiasz na swoim laptopie, w CI i na produkcji, dzięki czemu zachowuje się identycznie. Konfiguracja środowiska jest opisana w Dockerfile i plikach compose, więc staje się częścią kodu zamiast być „magicznie” ustawiona ręcznie na serwerze.

Czym dokładnie różni się kontener Dockera od maszyny wirtualnej?

Maszyna wirtualna uruchamia pełny system operacyjny z własnym kernelem, a nad wszystkim czuwa hypervisor. Jest cięższa, dłużej się uruchamia i zajmuje więcej CPU i RAM. Kontener to po prostu proces (lub grupa procesów) na hoście, który współdzieli kernel z systemem gospodarza, ale ma odseparowany system plików, przestrzeń procesów i sieć.

W praktyce kontener startuje w ułamku sekundy, jest lżejszy i idealnie nadaje się do uruchamiania aplikacji i mikroserwisów. VM lepiej sprawdza się do izolowania całych systemów operacyjnych, legacy aplikacji lub scenariuszy typu „wirtualny desktop”. Jeśli oczekujesz od kontenera pełnej izolacji bezpieczeństwa jak od VM, to będzie rozczarowanie – jego główny cel to spójne środowisko aplikacji.

Kiedy Docker ma sens, a kiedy lepiej go nie używać?

Docker najbardziej pomaga, gdy projekt składa się z kilku usług (np. backend, frontend, baza, cache), zespół potrzebuje identycznego środowiska developerskiego i istnieje pipeline CI/CD. Wtedy jeden plik docker-compose.yml potrafi zastąpić długą instrukcję „jak to uruchomić”, a nowy developer startuje projektem po jednym docker compose up.

Dla prostych, jednorazowych narzędzi – np. pojedynczy skrypt do konwersji plików – konteneryzacja często jest przerostem formy nad treścią. Jeśli czas nauki Dockera i tworzenia Dockerfile jest większy niż potencjalny zysk, rozsądniej pozostać przy klasycznym uruchamianiu z systemu.

Jak zainstalować Dockera na Linux, Windows i macOS i sprawdzić, czy działa?

Na Linuksie zwykle korzysta się z oficjalnych repozytoriów Dockera lub pakietów dystrybucji. Typowe kroki na Debian/Ubuntu to: dodanie klucza i repozytorium Dockera, instalacja pakietów docker-ce, docker-ce-cli, containerd.io, dodanie użytkownika do grupy docker i ponowne zalogowanie. Stan instalacji sprawdzisz komendą docker version.

Na Windows i macOS instaluje się Docker Desktop przez klasyczny instalator. Docker Desktop uruchamia w tle lekką maszynę z Linuksem i udostępnia CLI docker w terminalu lub PowerShellu. Najprostszy test to docker run hello-world – jeśli widzisz komunikat powitalny, Docker jest poprawnie zainstalowany. Błędy typu „permission denied” zwykle oznaczają brak dodania użytkownika do grupy docker lub konieczność użycia sudo.

Czy do pracy z Dockerem potrzebne jest GUI, czy wystarczy terminal?

Podstawą pracy z Dockerem jest CLI: docker build, docker run, docker ps, docker logs, docker exec. Te komendy są używane także przez narzędzia CI/CD, więc i tak trzeba je poznać. Opanowanie ich daje pełną kontrolę nad tym, co dzieje się z kontenerami i obrazami.

GUI, takie jak Docker Desktop czy Portainer, ułatwia podgląd stanu kontenerów, logów i wolumenów, ale jest dodatkiem. Na serwerach często uruchamia się Portainera jako kontener z webowym interfejsem. W fazie nauki najlepiej skupić się na CLI, a z GUI korzystać wtedy, gdy rzeczywiście przyspiesza pracę (np. szybkie podejrzenie logów na zdalnym VPS-ie).

Jak powinna wyglądać podstawowa struktura projektu korzystającego z Dockera?

Najprostszy, praktyczny układ to katalog główny projektu (repozytorium), w nim kod aplikacji (np. src/ lub app/), pliki zależności (requirements.txt, package.json), plik Dockerfile oraz – jeśli projekt składa się z kilku usług – docker-compose.yml. Dobrą praktyką jest także .dockerignore, żeby nie kopiować do obrazu np. node_modules, buildów czy katalogów IDE.

Taki układ sprawia, że konfiguracja budowania i uruchamiania aplikacji jest przejrzyście opisana na tym samym poziomie co kod. Dzięki temu nowa osoba w projekcie nie szuka konfiguracji po serwerach, tylko widzi od razu, jak wygląda obraz i jakie usługi wchodzą w skład środowiska.

Co dzieje się z danymi po usunięciu kontenera Dockera?

Kontener jest z założenia ulotny: po jego usunięciu dane zapisane wewnątrz systemu plików kontenera znikają. Dotyczy to np. logów lub plików zapisanych w /tmp czy w katalogach aplikacji, jeśli nie są podpięte jako wolumen.

Trwałe dane trzyma się poza kontenerem – w wolumenach Dockera, na zewnętrznych usługach (bazy danych, S3) albo w osobnych kontenerach-bazach z podpiętymi wolumenami. Dzięki temu kontener możesz łatwo wymienić lub zreplikować, a dane zachowują ciągłość niezależnie od cyklu życia pojedynczej instancji.

Najważniejsze punkty

• Docker rozwiązuje problem „u mnie działa” dzięki zamknięciu aplikacji i jej zależności w powtarzalnym kontenerze, który zachowuje się tak samo na laptopie, CI i produkcji.
• Konfiguracja środowiska przestaje być ręcznym ustawianiem serwerów – staje się kodem w Dockerfile i docker-compose, co ułatwia zmiany, wersjonowanie i automatyzację.
• Kontener to lekki, izolowany proces z własnym systemem plików i siecią, ale współdzielący kernel z hostem; nie jest pełną maszyną wirtualną ani substytutem całego systemu operacyjnego.
• Dane wewnątrz kontenera są ulotne, więc trzeba świadomie wynosić je do wolumenów lub zewnętrznych usług (baza, S3); w zamian zyskuje się łatwe skalowanie i szybką wymianę instancji.
• W porównaniu z maszynami wirtualnymi kontenery startują znacznie szybciej, zużywają mniej zasobów, ale oferują słabszą izolację systemową – nadają się głównie do aplikacji i mikroserwisów, nie do emulowania całych systemów.
• Docker najbardziej pomaga w złożonych projektach (wiele usług, mikroserwisy, CI/CD, zespoły developerskie), natomiast bywa nadmiarem przy prostych, jednorazowych narzędziach uruchamianych lokalnie.
• Najbardziej naturalnym środowiskiem dla Dockera jest Linux; na macOS i Windows potrzebna jest dodatkowa warstwa (Docker Desktop lub WSL2), co dodaje narzut, ale nadal dobrze się sprawdza w pracy developerskiej.