Praktyczny przewodnik po Dockerze i Kubernetes dla początkujących programistów i administratorów

Skąd się bierze Docker i Kubernetes i po co ich używać

Od „gołych” serwerów do kontenerów

Przez wiele lat standardem było wdrażanie aplikacji na „gołych” serwerach lub w maszynach wirtualnych. Administrator dostawał kod, instalował potrzebne pakiety, konfigurował serwer www, bazę danych, firewalla i ręcznie dogrywał kolejne zależności. Każda poprawka oznaczała potencjalny bałagan: różne wersje bibliotek, nadpisane konfiguracje, konflikty portów.

Wprowadzenie maszyn wirtualnych (VM) rozwiązało część problemów. Można było postawić kilka systemów na jednym fizycznym serwerze i izolować aplikacje. Nadal jednak każdy system gościnny miał własne jądro, pełny system operacyjny i cały zestaw usług. To kosztowało wydajność i zasoby, a zarządzanie dziesiątkami czy setkami VM-ek stawało się uciążliwe.

Konteneryzacja uprościła ten model. Zamiast kopiować całe systemy, kontener współdzieli jądro z hostem i pakuje tylko to, czego aplikacja naprawdę potrzebuje: binaria, biblioteki, konfiguracje. Dzięki temu uruchamianie i wyłączanie kontenerów jest szybkie, zużywają one mniej pamięci i są znacznie łatwiejsze do powielania między środowiskami.

Programista vs administrator: dwie perspektywy na Dockera

Dla programisty Docker to przede wszystkim narzędzie do powtarzalnego środowiska. Koniec z komunikatem „u mnie działa”. Aplikacja i wszystkie zależności są opisane w Dockerfile, z którego powstaje obraz. Tego samego obrazu można użyć lokalnie, na serwerze testowym i w produkcji.

Dla administratora czy inżyniera DevOps Docker to standaryzacja wdrożeń. Zamiast skomplikowanych instrukcji w stylu „zainstaluj pakiet X, potem uruchom skrypt Y”, admin dostaje gotowy obraz. Jego zadaniem jest zapewnienie infrastruktury pod uruchamianie kontenerów, a nie zaglądanie do wnętrza każdej aplikacji.

Dlaczego Kubernetes, skoro Docker już jest

Docker rozwiązuje problem uruchamiania kontenerów na pojedynczym hoście. Gdy pojawia się potrzeba skalowania – dziesiątki, setki instancji na wielu maszynach – ręczne zarządzanie kontenerami szybko wymyka się spod kontroli. I tu wchodzi Kubernetes, czyli system orkiestracji kontenerów.

Kubernetes rozkłada kontenery na wiele węzłów, monitoruje ich stan, restartuje, gdy coś się wysypie, zapewnia mechanizmy sieciowe, load balancing, konfigurację i zarządzanie sekretami. Z perspektywy programisty oznacza to możliwość opisania stanu docelowego (np. „chcę 3 repliki aplikacji webowej”), a resztą zajmuje się klaster. Administrator zyskuje centralne narzędzie do zarządzania całym stadem kontenerów.

Docker stał się standardem formatu obrazu i runtime’u, natomiast Kubernetes – standardem do orkiestracji w klastrach. Te narzędzia nie konkurują ze sobą, lecz się uzupełniają.

Jak oswoić lęk przed „za dużą ilością nowych pojęć”

Początkujący programiści i administratorzy często mają poczucie przytłoczenia: Docker, obrazy, rejestry, Pod, Deployment, Service, Ingress, Helm… Lista haseł wydaje się nieskończona. Dobrym sposobem jest podejście warstwowe: najpierw opanować Docker na pojedynczej maszynie, potem docker-compose, a dopiero potem stopniowo przechodzić do podstaw Kubernetesa.

Pomaga też przyjęcie założenia, że nie da się nauczyć tego wyłącznie z teorii. Najszybsza droga to małe, bezpieczne eksperymenty w lokalnym środowisku lub osobnym koncie w chmurze. Zamiast czytać o 30 obiektach Kubernetesa, lepiej przygotować prosty obraz, wrzucić go do lokalnego klastra i zobaczyć, jak reaguje na restart, awarię węzła czy zmianę konfiguracji.

Obawa „coś zepsuję” jest naturalna. Rozwiązaniem jest wydzielenie przestrzeni do eksperymentów, w której nie ma nic produkcyjnego ani ważnych danych. Wtedy można bez stresu usuwać, przeinstalowywać, psuć i naprawiać.

Kluczowe pojęcia – kontenery, obrazy, rejestry, klaster

Kontener a maszyna wirtualna – podobieństwa i różnice

Kontener i maszyna wirtualna na pierwszy rzut oka robią podobną rzecz: izolują środowisko aplikacji. Różni je jednak poziom, na którym to robią. VM uruchamia pełny system operacyjny z własnym jądrem, podczas gdy kontener współdzieli jądro hosta i izoluje jedynie przestrzeń użytkownika.

Gdy potrzebujesz uruchomić różne dystrybucje Linuxa lub Windows na jednej fizycznej maszynie – VM będzie naturalnym wyborem. Jeżeli celem jest szybkie, powtarzalne uruchamianie aplikacji w tej samej rodzinie systemu (np. Linux), kontener daje dużo większą elastyczność i wydajność.

Obraz kontenera – szablon systemu z aplikacją

Obraz kontenera to niezmienny szablon zawierający wszystko, czego potrzebuje aplikacja: system bazowy, biblioteki, pliki aplikacji, konfiguracje startowe. Z obrazu tworzony jest kontener – działająca instancja. Jeden obraz może posłużyć do utworzenia wielu kontenerów.

Każdy obraz składa się z warstw. Zmiana Dockerfile’a (np. dodanie kolejnego polecenia RUN) tworzy nową warstwę. Dzięki temu obrazy są efektywne – jeśli kilka obrazów korzysta z tej samej bazowej warstwy (np. oficjalny obraz Pythona), system przechowuje ją tylko raz.

Do identyfikowania obrazów używa się tagów. Najczęściej spotykany to „latest”, ale w praktyce lepiej używać wersji, np. 1.3.0 lub 1.3.0-alpine. Obraz bez jawnego taga ma domyślnie :latest, co bywa źródłem nieprzyjemnych niespodzianek, gdy w rejestrze pojawi się nowa wersja.

Rejestry obrazów – gdzie trzyma się kontenery

Rejestr obrazów to odpowiednik repozytorium git dla kodu. Tu przechowywane są obrazy, które potem można pobierać poleceniem docker pull lub uruchamiać bezpośrednio przez docker run. Najpopularniejsze rejestry to:

• Docker Hub – publiczny, z tysiącami oficjalnych obrazów.
• GitHub Container Registry – zintegrowany z GitHubem, wygodny dla projektów open source i prywatnych.
• Prywatne rejestry – np. w AWS (ECR), GCP (Artifact Registry), Azure (ACR) lub samodzielnie utrzymywane.

Typowy przepływ wygląda tak: programista buduje obraz lokalnie, taguje go nazwą rejestru (np. my-registry.com/app:1.0), wypycha do rejestru (docker push), a Kubernetes lub inny system CI/CD pobiera go stamtąd podczas wdrożeń.

Klaster i orkiestracja – czym zajmuje się Kubernetes

Klaster to zestaw maszyn (fizycznych lub wirtualnych), które współpracują, by uruchamiać aplikacje. Kubernetes zarządza takim klastrem, decydując, gdzie uruchomić poszczególne kontenery, monitorując ich stan i dbając o zgodność z zadeklarowaną konfiguracją.

Ten rozdział odpowiedzialności dobrze pasuje do nowoczesnych procesów CI/CD. Kod w repozytorium generuje obraz, obraz trafia do rejestru, a pipeline zajmuje się resztą. Taki sposób pracy świetnie łączy się z podejściem opisywanym na Złota Kielnia, gdzie duży nacisk kładzie się na automatyzację w informatyce i nowych technologiach.

W dużym uproszczeniu Kubernetes:

• przyjmuje deklaracje: „chcę X replik aplikacji A”,
• rozmieszcza kontenery na dostępnych węzłach,
• pilnuje, by zawsze działała wymagana liczba replik,
• dostarcza mechanizmy sieciowe, żeby usługi widziały się nawzajem i były dostępne z zewnątrz,
• ułatwia aktualizacje (rolling updates) i cofanie zmian.

Programista myśli raczej o obrazie i konfiguracji aplikacji. Administrator – o kondycji klastra, zasobach, bezpieczeństwie. Kubernetes jest miejscem, gdzie te dwie perspektywy się spotykają.

Przygotowanie środowiska pracy – co zainstalować i jak nie przesadzić

Podstawowe narzędzia dla programisty i administratora

Aby zacząć praktyczną pracę z Dockerem i Kubernetesem, wystarczy kilka narzędzi. Zbyt rozbudowany zestaw na start tylko zwiększa chaos, dlatego rozsądnie jest trzymać się minimalnego, ale kompletnego pakietu.

• Docker lub kompatybilny runtime – Docker Desktop (Windows/macOS) albo Docker Engine/Podman (Linux).
• kubectl – oficjalny klient do komunikacji z klastrem Kubernetesa.
• Lokalny klaster – najczęściej kind (Kubernetes in Docker), minikube albo k3d.
• Opcjonalnie: docker-compose lub wbudowane Compose w Docker Desktop do pracy z wieloma kontenerami lokalnie.

Dla początkującego programisty zwykle wystarczy Docker Desktop z włączonym Kubernetesem albo kombinacja Docker + kind/minikube. Administratorzy częściej dodatkowo instalują narzędzia do zarządzania chmurą (awscli, gcloud, az) i systemy do logowania oraz monitoringu.

Windows, macOS, Linux – najczęstsze pułapki instalacji

Na Linuxie Docker jest „u siebie” – działa natywnie i zwykle wystarczy instalacja z repozytoriów dystrybucji lub oficjalnego skryptu. Typowym problemem są uprawnienia: po instalacji użytkownik musi zostać dodany do grupy docker, inaczej każde polecenie wymaga sudo.

Na Windowsie najczęstsze wyzwanie to wybór między WSL2 a Hyper-V. Docker Desktop opiera się domyślnie na WSL2 i wymaga jego włączenia. Gdy WSL2 jest już uruchomione, większość pracy dzieje się w środku systemu linuksowego, a nie w „klasycznym” CMD/PowerShell. Dla początkującego jest to dodatkowa warstwa, ale po kilku dniach użytkownik zwykle docenia stabilność tego rozwiązania.

Na macOS Docker Desktop wykorzystuje maszynę wirtualną (nie ma natywnego jądra Linux), więc ważne jest przydzielenie rozsądnej ilości RAM-u i CPU. Zbyt mało zasobów spowolni kontenery, zbyt dużo – obciąży system i inne narzędzia developerskie.

Checklista instalacyjna – szybki test środowiska

Po instalacji Dockera warto przejść przez krótką listę kontrolną:

• docker version – sprawdza wersję klienta i serwera (daemon).
• docker run hello-world – uruchamia przykładowy obraz, testując możliwość pobierania z Docker Hub.
• docker ps – weryfikuje listę działających kontenerów.
• docker images – pokazuje pobrane obrazy.

Jeśli planowany jest Kubernetes, kolejne kroki to:

• kubectl version --client – test klienta kubectl,
• uruchomienie lokalnego klastra (np. kind create cluster),
• kubectl get nodes – wyświetlenie węzłów, co potwierdza komunikację z klastrem.

Gdy te proste polecenia działają, fundament jest gotowy. Reszta to już nauka i stopniowe dokładanie kolejnych elementów.

Bezpieczna przestrzeń na eksperymenty

Aby uniknąć nerwowego „czy nie skasuję produkcji?”, dobrze jest wydzielić środowiska od razu na początku. Kilka prostych zasad bardzo poprawia komfort pracy:

• osobne konto w chmurze tylko do nauki,
• osobny kontekst w kubectl dla każdego klastra, z jasną nazwą (np. dev-kind-local, prod-cloud),
• domyślny kontekst ustawiony na środowisko testowe/lokalne, nie na produkcję.

Dzięki temu nawet omyłkowe kubectl delete wykonane w złym miejscu wyrządzi co najwyżej drobną szkodę w środowisku szkoleniowym. Taka separacja znacząco obniża psychologiczny próg wejścia – można śmielej testować, psuć i naprawiać.

Pierwsze kroki z Dockerem – od docker run do własnego kontenera

Najważniejsze polecenia Dockera z praktycznymi przykładami

Podstawy Dockera można opanować, ćwicząc dosłownie kilka komend. Każda kolejna to tylko wariant tych bazowych.

• docker run – uruchamia nowy kontener z danego obrazu.
• docker ps – pokazuje działające kontenery (z -a także zakończone).
• docker logs – wyświetla logi kontenera.

Uruchamianie pierwszego kontenera – praktyczne warianty docker run

Sama komenda docker run ma wiele przełączników, ale na start wystarczy kilka wzorców, które potem można modyfikować.

Najprostszy przykład, który po prostu coś wypisze i się zakończy:

docker run busybox echo "Hello z kontenera"

Docker pobierze obraz busybox, uruchomi go, wykona polecenie echo i zakończy kontener. Po tym kontener nie działa, ale można go zobaczyć w docker ps -a.

Aby uruchomić serwis, który ma działać dłużej (np. serwer HTTP), zwykle używa się opcji:

• -d – tryb „detached” (w tle),
• -p – mapowanie portów z kontenera na hosta,
• --name – przyjazna nazwa kontenera.

Przykład z Nginxem:

docker run -d --name moj-nginx -p 8080:80 nginx:latest

Po chwili serwer będzie dostępny pod http://localhost:8080. Kontener można zatrzymać poleceniem:

Jeśli interesują Cię konkrety i przykłady, rzuć okiem na: Jak sztuczna inteligencja zmienia rynek pracy: nowe zawody, kompetencje i wyzwania dla pracowników.

docker stop moj-nginx

a potem całkowicie usunąć:

docker rm moj-nginx

Przeglądanie logów i „wchodzenie” do kontenera

Gdy aplikacja w kontenerze nie działa jak trzeba, pierwszym odruchem jest zajrzenie do logów:

docker logs moj-nginx

Dodanie -f („follow”) powoduje śledzenie logów na żywo, podobnie jak tail -f:

docker logs -f moj-nginx

Druga typowa potrzeba to „wejść do środka” kontenera, by coś sprawdzić lub wykonać diagnostykę. Robi się to poleceniem docker exec:

docker exec -it moj-nginx /bin/bash

Jeżeli obraz nie ma bash, często dostępny jest lżejszy /bin/sh:

docker exec -it moj-nginx /bin/sh

Przełącznik -it zapewnia interaktywną sesję w terminalu. To bardzo przydatne przy pierwszych próbach, choć później, w środowiskach produkcyjnych, częstsze jest zbieranie logów i metryk niż ręczne „grzebanie” w kontenerach.

Usuwanie niepotrzebnych kontenerów i obrazów – sprzątanie bez stresu

Po kilku dniach nauki w środowisku lokalnym robi się bałagan: dziesiątki zakończonych kontenerów i nieużywanych obrazów. Można je bezpiecznie czyścić.

Usunięcie pojedynczego, zatrzymanego kontenera:

docker rm <id_lub_nazwa>

Usunięcie wielu na raz (np. wszystkich zakończonych):

docker container prune

Analogicznie dla nieużywanych obrazów:

docker image prune

lub bardziej agresywnie (obrazy bez żadnych kontenerów, sieci bez użycia itd.):

docker system prune

Przed użyciem agresywnych opcji dobrze jest zerknąć, co dokładnie zostanie usunięte – Docker przed potwierdzeniem wyświetla podsumowanie.

Trwałe dane: wolumeny i mapowanie katalogów

Domyślnie dane zapisane w kontenerze znikają razem z nim. Dla bazy danych, narzędzia analitycznego czy nawet aplikacji web z danymi użytkowników to za mało. Rozwiązaniem są wolumeny (volumes) i bind mounty.

Najprostszy wariant – podpinanie katalogu hosta do kontenera:

docker run -d --name postgres 
  -e POSTGRES_PASSWORD=haslo 
  -v /home/uzytkownik/pg-data:/var/lib/postgresql/data 
  postgres:15

Dane z katalogu kontenera /var/lib/postgresql/data trafią na dysk hosta, w /home/uzytkownik/pg-data. Nawet po skasowaniu kontenera katalog zostanie.

Druga opcja to wolumeny zarządzane przez Dockera:

docker volume create pgdata
docker run -d --name postgres 
  -e POSTGRES_PASSWORD=haslo 
  -v pgdata:/var/lib/postgresql/data 
  postgres:15

Docker przechowuje taki wolumen w swojej przestrzeni, a nazwa pgdata staje się etykietą, którą można przenosić między kontenerami. To wygodne przy lokalnych testach i prostych środowiskach.

Proste sieci między kontenerami – mini‑klaster na laptopie

Kiedy pojawia się drugi kontener (np. aplikacja + baza), przydaje się własna sieć, żeby nie opierać się na portach hosta. Docker umożliwia tworzenie sieci typu bridge:

docker network create moja-siec

Następnie kontenery można podłączyć do tej sieci, a one zobaczą się po nazwach:

docker run -d --name postgres 
  --network moja-siec 
  -e POSTGRES_PASSWORD=haslo 
  postgres:15

docker run -d --name app 
  --network moja-siec 
  -e DB_HOST=postgres 
  moj-obraz-aplikacji:latest

Aplikacja może łączyć się z bazą używając hosta postgres i domyślnego portu 5432, bez wystawiania bazy na zewnątrz.

Budowa własnych obrazów – pisanie dobrego Dockerfile

Minimalny Dockerfile dla prostej aplikacji

Naturalnym kolejnym krokiem jest spakowanie własnego kodu do obrazu. Punktem wyjścia będzie minimalny Dockerfile. Przykład dla aplikacji w Node.js:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install --only=production

COPY . .

EXPOSE 3000
CMD ["npm", "start"]

Ten plik mówi Dockerowi:

• użyj gotowego obrazu node:20-alpine jako bazy,
• pracuj w katalogu /app,
• skopiuj pliki package*.json i zainstaluj zależności produkcyjne,
• skopiuj resztę projektu,
• nasłuchuj na porcie 3000,
• uruchom aplikację komendą npm start.

Obraz buduje się poleceniem:

docker build -t moja-apka:1.0 .

A następnie uruchamia:

docker run -d --name moja-apka -p 3000:3000 moja-apka:1.0

Porządek w warstwach – dlaczego kolejność instrukcji ma znaczenie

Każda instrukcja w Dockerfile tworzy nową warstwę. Kolejność wpływa na czas budowania i ponownego budowania obrazu. Rozsądny schemat:

1. rzadko zmieniające się rzeczy (system bazowy, narzędzia),
2. instalacja zależności (np. npm install, pip install),
3. kod aplikacji, który zmienia się najczęściej.

Dlatego osobno kopiuje się plik zależności i osobno resztę projektu. Jeśli zmienił się tylko kod, a nie package.json, warstwa z npm install zostanie użyta z cache, a budowa będzie dużo szybsza.

Unikanie typowych błędów w Dockerfile

Przy pierwszych podejściach często pojawiają się te same pułapki:

• użycie latest zamiast konkretnej wersji obrazu bazowego,
• robienie wszystkiego w jednym RUN bez czyszczenia zbędnych plików (cache menedżera pakietów, build artefakty),
• praca i uruchamianie aplikacji jako root, choć nie ma takiej potrzeby,
• kopiowanie do obrazu dużych, niepotrzebnych katalogów (np. node_modules, katalogi buildów IDE).

Część problemów rozwiązuje rozsądny plik .dockerignore, zbliżony do .gitignore. Przykład dla Node.js:

node_modules
npm-debug.log
.git
.gitignore
Dockerfile
docker-compose.yml

Obrazy wieloetapowe – budowanie i uruchamianie w jednym pliku

Dla języków kompilowanych (Go, Java, .NET) przydaje się mechanizm multi-stage build. Dzięki niemu etap kompilacji odbywa się w jednym obrazie, a finalny, produkcyjny obraz jest mały i czysty.

Przykład dla aplikacji w Go:

# etap budowania
FROM golang:1.22-alpine AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o app

# etap runtime
FROM alpine:3.19
WORKDIR /app
COPY --from=builder /src/app ./app
EXPOSE 8080
CMD ["./app"]

Do środowiska produkcyjnego trafia tylko finalny binarny plik i minimalny system bazowy.

Na koniec warto zerknąć również na: Od zera do CI: pipeline dla aplikacji Node. — to dobre domknięcie tematu.

Bezpieczeństwo obrazów – kilka prostych nawyków

Nie trzeba od razu znać wszystkich dobrych praktyk bezpieczeństwa, ale kilka prostych kroków znacząco ogranicza ryzyko:

• wybór oficjalnych lub zaufanych obrazów bazowych,
• uruchamianie procesów na nieuprzywilejowanym użytkowniku (instrukcja USER),
• regularne przebudowywanie obrazów, aby zawierały aktualne poprawki systemowe,
• usuwanie plików tymczasowych po instalacji pakietów (w tej samej instrukcji RUN).

Duże organizacje używają dodatkowo skanerów obrazów (np. Trivy, Grype), ale nawet w małym projekcie można od czasu do czasu przeskanować obraz lokalnie i zobaczyć listę podatności.

Docker w zespole – workflow od developera do środowiska testowego

Standaryzacja środowiska – „u mnie działa” przestaje być problemem

Gdy każdy developer ma inne wersje bibliotek i serwerów lokalnie, problemy z reprodukcją błędów są normą. Kontenery dają szansę na wspólne środowisko:

• ten sam obraz aplikacji na laptopie, w CI i na serwerze testowym,
• te same wersje baz danych i brokerów komunikatów,
• powtarzalne komendy uruchomieniowe.

Prosty wzorzec w projekcie to katalog docker/ z plikami Dockerfile i przykładowymi konfiguracjami, oraz kilka skryptów make lub .sh/.ps1 ułatwiających codzienną pracę (np. make run-local, make test-in-docker).

Docker Compose jako narzędzie do lokalnego „mini‑środowiska”

Gdy aplikacja składa się z kilku usług, ręczne uruchamianie kontenerów staje się uciążliwe. Tutaj wchodzi docker compose. Konfiguracja całości trafia do pliku docker-compose.yml (lub compose.yaml).

Przykład prostego zestawu: aplikacja + baza PostgreSQL:

version: "3.9"
services:
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: haslo
      POSTGRES_DB: mojadb
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"

  app:
    build: ./
    environment:
      DB_HOST: db
      DB_NAME: mojadb
      DB_USER: postgres
      DB_PASSWORD: haslo
    ports:
      - "3000:3000"
    depends_on:
      - db

volumes:
  pgdata:

Całe środowisko startuje jednym poleceniem:

docker compose up

lub w tle:

docker compose up -d

Dzięki temu nowa osoba w zespole może w kilka minut uruchomić działające środowisko, zamiast konfigurować każdy komponent osobno.

Budowanie obrazów w CI – z kodu do rejestru

Kolejny krok to automatyczne budowanie obrazów przy każdym commicie lub mergu do głównej gałęzi. Typowy pipeline CI robi kilka rzeczy:

1. pobiera kod z repozytorium,
2. uruchamia testy jednostkowe,
3. buduje obraz Dockera,
4. taguje go (np. numerem wersji, SHA commita),
5. publikuje do rejestru (Docker Hub, GHCR, ECR itd.).

Przykładowy, uproszczony fragment konfiguracji GitHub Actions może wyglądać tak:

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Logowanie do GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Budowa i push obrazu
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ghcr.io/<org>/moja-apka:${{ github.sha }}

Rezultat: każdy commit w głównej gałęzi ma własny obraz, który można wdrożyć na środowisku testowym.

Promowanie wersji między środowiskami – ten sam obraz, inna konfiguracja

Najczęściej zadawane pytania (FAQ)

Czym różni się Docker od Kubernetesa?

Docker służy głównie do pakowania i uruchamiania pojedynczych aplikacji w kontenerach na jednym hoście. Pomaga programiście zbudować obraz z kodem i zależnościami, a administratorowi – uruchomić go w powtarzalny sposób.

Kubernetes wchodzi do gry, gdy tych kontenerów jest dużo i działają na wielu maszynach. Zarządza klastrem, rozkłada kontenery po węzłach, pilnuje ich stanu, skaluje, aktualizuje i udostępnia je w sieci. Krócej: Docker rozwiązuje „jak uruchomić kontener”, Kubernetes – „jak zarządzać setkami kontenerów w środowisku produkcyjnym”.

Czy początkujący programista powinien najpierw uczyć się Dockera czy Kubernetesa?

Na start zdecydowanie łatwiej jest ogarnąć Dockera. Najpierw zrozum, czym jest obraz, kontener, Dockerfile i jak uruchomić prostą aplikację (np. API w Pythonie czy Node.js) w kontenerze na swojej maszynie. To już usuwa sporą część chaosu związanego z różnicami między środowiskami.

Dopiero potem sensownie jest dołożyć docker-compose (kilka kontenerów razem, np. aplikacja + baza), a na końcu podstawy Kubernetesa: Pod, Deployment, Service. Takie warstwowe podejście zmniejsza poczucie przytłoczenia i pozwala spokojnie oswoić nowe pojęcia.

Czy kontenery zastąpią całkowicie maszyny wirtualne?

Nie, te technologie się uzupełniają. Kontener współdzieli jądro z systemem hosta, więc świetnie nadaje się do lekkiego, szybkiego uruchamiania aplikacji z tej samej „rodziny” systemów (np. różne mikroserwisy w Linuxie). Maszyna wirtualna ma własne jądro i pełny system operacyjny, więc lepiej sprawdza się, gdy potrzebujesz różnych systemów (np. Linux i Windows) albo silnej izolacji na poziomie całego OS.

W praktyce często spotyka się połączenie: na fizycznym serwerze działają VM-ki, a w nich – klaster Kubernetesa z kontenerami Dockera. VM zapewnia izolację środowiska, kontenery – elastyczność i szybkość dla aplikacji.

Czym jest obraz Dockera i dlaczego tag „latest” bywa problematyczny?

Obraz Dockera to szablon zawierający system bazowy, biblioteki, pliki aplikacji i konfigurację startową. Z jednego obrazu można uruchomić wiele kontenerów, więc idealnie nadaje się do powtarzalnych wdrożeń: ten sam obraz lokalnie, na testach i na produkcji.

Tag „latest” oznacza po prostu „domyślną” wersję obrazu w rejestrze, niekoniecznie „najlepszą” czy „stabilną”. Jeśli nie podasz taga, Docker przyjmie latest, co może prowadzić do niespodzianek, gdy obraz w rejestrze zostanie podmieniony. Bezpieczniej jest stosować tagowanie wersjami, np. 1.3.0 lub 1.3.0-alpine, żeby mieć kontrolę nad tym, co dokładnie uruchamiasz.

Po co mi rejestr obrazów, skoro mogę budować obraz lokalnie?

Lokalne budowanie wystarcza na etapie nauki i prostych eksperymentów. Gdy w grę wchodzi praca zespołowa lub środowiska testowe/produkcyjne, potrzebne jest wspólne, dostępne miejsce na obrazy. Tym właśnie jest rejestr – odpowiednik zdalnego repozytorium Git dla kontenerów.

Typowy przepływ wygląda tak: budujesz obraz, tagujesz go adresem rejestru, wysyłasz poleceniem docker push, a następnie system CI/CD lub Kubernetes pobiera go z rejestru i uruchamia. Bez rejestru każdy serwer musiałby samodzielnie budować obrazy, co szybko staje się nie do utrzymania.

Czy Kubernetes jest „za trudny” dla początkujących administratorów?

Na początku może sprawiać wrażenie przytłaczającego – dużo nowych nazw (Pod, Deployment, Service, Ingress, ConfigMap, Secret…) i sporo YAML-a. To normalne, że rodzi się obawa „na pewno coś zepsuję”. Da się jednak to oswoić, jeśli podejdziesz do tematu małymi krokami.

Dobrym sposobem jest założenie osobnego środowiska do eksperymentów (np. minikube, kind, k3s albo osobne konto w chmurze) i świadome „psucie”: usuwanie Podów, zmiana konfiguracji, symulowanie awarii. W bezpiecznym środowisku nie ma ryzyka utraty danych produkcyjnych, więc możesz sprawdzić, jak Kubernetes reaguje na błędy i co faktycznie robi „sam z siebie”.

Jak w praktyce łączy się Docker, rejestr i Kubernetes w procesie CI/CD?

W prostym scenariuszu wygląda to tak: commitujesz zmiany w kodzie, pipeline CI buduje na tej podstawie nowy obraz Dockera, taguje go (np. numerem wersji lub hashem commita) i wysyła do rejestru obrazów. Ten krok zastępuje ręczne budowanie i kopiowanie plików na serwer.

Następnie część CD (Continuous Delivery/Deployment) aktualizuje manifesty Kubernetesa lub wykres Helm tak, żeby wskazywały nowy tag obrazu, i wykonuje wdrożenie. Kubernetes pobiera obraz z rejestru, uruchamia nowe kontenery, dokonuje rolling update’u i w razie problemów pozwala szybko wrócić do poprzedniej wersji. Dzięki temu zarówno programista, jak i administrator mają jasny, zautomatyzowany proces zamiast ręcznych, podatnych na błędy działań.

Źródła informacji

• Docker Overview. Docker Inc. – Oficjalne wprowadzenie do Dockera, obrazy, kontenery, rejestry
• Dockerfile reference. Docker Inc. – Składnia Dockerfile, warstwy obrazów, dobre praktyki wersjonowania
• Kubernetes Documentation – Concepts. Cloud Native Computing Foundation – Podstawowe pojęcia: Pod, Deployment, Service, klaster, orkiestracja
• The Docker Book: Containerization is the New Virtualization. James Turnbull (2014) – Różnice kontenery vs VM, obrazy, rejestry, zastosowania Dockera
• Kubernetes: Up and Running. O’Reilly Media (2022) – Praktyczne wprowadzenie do klastra, obiektów i orkiestracji kontenerów
• Docker Deep Dive. Leanpub (2020) – Szczegółowe omówienie architektury Dockera, obrazów i runtime
• NIST Special Publication 800-190: Application Container Security Guide. National Institute of Standards and Technology (2017) – Zalecenia bezpieczeństwa dla kontenerów i ich orkiestracji
• Microsoft Docs – Containers and virtualization overview. Microsoft – Porównanie kontenerów i maszyn wirtualnych, scenariusze użycia