Docker — pytania rekrutacyjne: 15 pytań i odpowiedzi na rozmowę o pracę

Najczęstsze pytania rekrutacyjne z Dockera dotyczą różnicy między kontenerem a maszyną wirtualną, budowy obrazów i warstw, instrukcji Dockerfile (CMD vs ENTRYPOINT, COPY vs ADD), sieci i wolumenów, Docker Compose oraz bezpieczeństwa kontenerów. Na stanowiskach mid i senior dochodzą pytania o optymalizację obrazów, sekrety, diagnozowanie awarii i współpracę z Kubernetesem.

Poniżej 15 pytań, które realnie padają na rozmowach na stanowiska DevOps, backend i administratora, z odpowiedziami na takim poziomie, jakiego oczekuje rekruter techniczny — nie z definicją z Wikipedii, tylko z „dlaczego” i przykładem.

Podstawy: jak działa Docker

1. Czym jest Docker i czym kontener różni się od maszyny wirtualnej?

Docker to platforma do budowania, dystrybucji i uruchamiania aplikacji w kontenerach. Kontener to zwykły proces (lub grupa procesów) systemu Linux, odizolowany od reszty systemu mechanizmami jądra.

Maszyna wirtualna ma własne jądro i wirtualny sprzęt dostarczany przez hiperwizor. Kontener współdzieli jądro z gospodarzem, dlatego startuje w ułamku sekundy i zajmuje megabajty, a nie gigabajty. Ceną jest słabsza izolacja: błąd w jądrze dotyczy wszystkich kontenerów na hoście. Dobrą odpowiedź zakończ przykładem: „na Linuksie nie uruchomię natywnie kontenera z Windows, bo kontener nie przynosi własnego jądra”. Szczegółowo różnice opisuje artykuł maszyna wirtualna — co to jest i do czego służy.

2. Jakie mechanizmy jądra Linuksa wykorzystuje Docker?

Rekruter chce usłyszeć trzy rzeczy:

• namespaces — izolują to, co proces widzi: pid (własne drzewo procesów), net (własny stos sieciowy), mnt (system plików), uts (hostname), ipc, user i cgroup,
• cgroups (dziś zwykle cgroups v2) — ograniczają to, ile proces może zużyć: CPU, pamięć, I/O, liczbę procesów,
• system plików warstwowy (w Dockerze domyślnie sterownik overlay2) — składa obraz z warstw tylko do odczytu i dokłada na wierzch cienką warstwę zapisywalną kontenera.

Warto dodać, że Docker Engine deleguje uruchamianie kontenerów do containerd i runc, czyli implementacji standardu OCI.

3. Czym różni się obraz od kontenera?

Obraz to niezmienny szablon: zestaw warstw systemu plików i metadane (domyślna komenda, zmienne środowiskowe, porty). Kontener to uruchomiona instancja obrazu z dodatkową warstwą zapisywalną. Z jednego obrazu uruchomisz wiele kontenerów. Zmiany zapisane w kontenerze znikają po jego usunięciu, chyba że trafiły do wolumenu.

Dobre uzupełnienie: tag (nginx:1.27) jest ruchomą etykietą, a digest (nginx@sha256:…) jednoznacznie identyfikuje zawartość. W produkcji tag latest to proszenie się o kłopoty, bo nie wiadomo, co faktycznie zostało wdrożone.

Obrazy i Dockerfile

4. Jak działają warstwy i cache przy budowaniu obrazu?

Każda instrukcja zmieniająca system plików (RUN, COPY, ADD) tworzy nową warstwę. Przy kolejnym budowaniu Docker używa warstwy z cache, jeśli instrukcja i jej wejście się nie zmieniły. Gdy jedna warstwa się zmieni, wszystkie następne budowane są od nowa.

Stąd praktyczna zasada: najpierw kopiuj pliki zależności, potem instaluj zależności, a dopiero na końcu kopiuj kod aplikacji:

FROM node:22-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]

Zmiana w kodzie nie unieważnia wtedy warstwy z npm ci. Do tego plik .dockerignore, który wyklucza node_modules, .git i pliki lokalne z kontekstu budowania.

5. Czym różni się CMD od ENTRYPOINT?

ENTRYPOINT określa program, który zawsze zostanie uruchomiony. CMD to domyślne argumenty (albo domyślna komenda, gdy nie ma ENTRYPOINT), które użytkownik może nadpisać, podając je w docker run.

ENTRYPOINT ["curl"]
CMD ["--help"]

docker run obraz wykona curl --help, a docker run obraz -I https://example.com wykona curl -I https://example.com.

Punkt bonusowy: forma exec (["prog", "arg"]) kontra forma shell (prog arg). W formie shell procesem PID 1 jest /bin/sh, który nie przekazuje sygnałów — aplikacja nie dostanie SIGTERM przy docker stop i zostanie zabita po 10 sekundach.

6. COPY czy ADD?

Oba kopiują pliki do obrazu, ale ADD dodatkowo rozpakowuje lokalne archiwa tar i potrafi pobierać pliki z URL. Ta „magia” bywa źródłem niespodzianek, dlatego zalecenie z dokumentacji Dockera jest proste: domyślnie COPY, a ADD tylko wtedy, gdy świadomie potrzebujesz rozpakowania archiwum.

7. Co to jest multi-stage build i po co go stosować?

To Dockerfile z kilkoma instrukcjami FROM. W pierwszym etapie masz pełne środowisko do kompilacji, a do obrazu końcowego kopiujesz tylko gotowy artefakt:

FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

FROM gcr.io/distroless/static-debian12
COPY --from=build /app /app
USER nonroot
ENTRYPOINT ["/app"]

Obraz wynikowy nie zawiera kompilatora, kodu źródłowego ani powłoki. Jest mniejszy, szybciej się pobiera i ma znacznie mniejszą powierzchnię ataku.

Sieci, wolumeny i Docker Compose

8. Jakie są tryby sieci w Dockerze?

• bridge — domyślny; kontenery dostają adresy w prywatnej sieci wirtualnej, a na zewnątrz wychodzą przez NAT hosta,
• host — kontener używa stosu sieciowego hosta bez izolacji (brak mapowania portów, najlepsza wydajność),
• none — brak sieci,
• overlay — sieć rozciągnięta na wiele hostów (Swarm),
• macvlan / ipvlan — kontener dostaje adres w fizycznej sieci LAN.

Często pada doprecyzowanie: w sieci utworzonej przez użytkownika (docker network create) kontenery rozwiązują się nawzajem po nazwie dzięki wbudowanemu DNS, a w domyślnej sieci bridge — nie.

9. EXPOSE a -p — czym się różnią?

EXPOSE 8080 w Dockerfile to tylko dokumentacja: informacja, na jakim porcie słucha aplikacja. Port publikuje dopiero -p 8080:8080 (host:kontener) przy docker run albo ports: w Compose. Warto wspomnieć, że -p 8080:8080 domyślnie nasłuchuje na wszystkich interfejsach hosta, a Docker dopisuje własne reguły iptables, które potrafią ominąć reguły UFW. Bezpieczniej jest -p 127.0.0.1:8080:8080, gdy usługa ma być dostępna tylko lokalnie.

10. Wolumen, bind mount czy tmpfs?

Wolumeny są przenośne i niezależne od struktury katalogów hosta; bind mount daje pełną kontrolę, ale wiąże kontener z konkretną maszyną i bywa źródłem problemów z uprawnieniami (UID w kontenerze vs UID na hoście).

11. Do czego służy Docker Compose i jak zapewnić kolejność startu usług?

Compose opisuje w jednym pliku YAML aplikację złożoną z wielu kontenerów: usługi, sieci, wolumeny, zmienne. Uruchamiasz ją jednym poleceniem docker compose up -d. Obecnie używa się Compose v2 (docker compose ze spacją); stary docker-compose w Pythonie nie jest już wspierany, a klucz version: w pliku jest zbędny.

Pułapka rekrutacyjna: samo depends_on czeka tylko na start kontenera, nie na gotowość usługi. Poprawnie łączy się je z healthcheckiem:

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets: [db_password]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 10
  app:
    build: .
    depends_on:
      db:
        condition: service_healthy
secrets:
  db_password:
    file: ./db_password.txt

Bezpieczeństwo i produkcja

12. Jak przechowywać hasła i klucze w kontenerach?

Czego nie robić: wpisywać sekretów w ENV lub ARG w Dockerfile ani kopiować plików .env do obrazu — każdy, kto pobierze obraz, odczyta je przez docker history lub docker inspect.

Co robić:

• w czasie budowania: sekrety BuildKit (RUN --mount=type=secret,id=npmrc …), które nie trafiają do warstw,
• w czasie działania: sekrety Swarm lub Compose montowane jako pliki w /run/secrets/, sekrety Kubernetesa albo zewnętrzny menedżer (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault),
• zmienne środowiskowe tylko jako ostateczność — są widoczne w docker inspect i w /proc procesu.

13. Jak zabezpieczyć kontener?

Odpowiedź, która robi wrażenie, to konkretna lista:

1. Uruchamiaj aplikację jako zwykły użytkownik (USER w Dockerfile), a jeśli to możliwe — Dockera w trybie rootless.
2. Nie używaj --privileged i nie montuj /var/run/docker.sock do kontenerów — dostęp do gniazda Dockera to praktycznie root na hoście.
3. Odbieraj zbędne uprawnienia: --cap-drop ALL i dodawaj tylko potrzebne, --read-only dla systemu plików, --security-opt no-new-privileges.
4. Używaj minimalnych obrazów bazowych (distroless, Alpine, slim) z zaufanych źródeł i przypinaj wersje.
5. Skanuj obrazy pod kątem podatności (Docker Scout, Trivy, Grype) w pipeline CI.
6. Ustawiaj limity zasobów (--memory, --cpus, --pids-limit), żeby jeden kontener nie położył hosta.

14. Docker, Docker Swarm i Kubernetes — jaka jest relacja?

Docker buduje obrazy i uruchamia kontenery na jednym hoście. Orkiestrator zarządza kontenerami na wielu hostach: planuje je na węzłach, skaluje, restartuje po awarii i wykonuje aktualizacje kroczące. Swarm to wbudowany w Dockera, prosty orkiestrator; Kubernetes to standard branżowy o znacznie większych możliwościach i złożoności.

Pytanie kontrolne: „czy Kubernetes używa Dockera?”. Od wersji 1.24 (2022) Kubernetes usunął dockershim i uruchamia kontenery przez containerd lub CRI-O. Obrazy budowane Dockerem działają dalej, bo są zgodne ze standardem OCI. Więcej w artykule Kubernetes vs Docker.

Debugowanie: pytanie praktyczne na koniec

15. Kontener ciągle się restartuje. Jak to zdiagnozujesz?

To pytanie sprawdza doświadczenie, więc opisz kolejne kroki:

docker ps -a                                   # status i kod wyjścia
docker logs --tail 100 nazwa_kontenera         # co aplikacja wypisała przed śmiercią
docker inspect nazwa_kontenera --format '{{.State.ExitCode}} {{.State.OOMKilled}}'
docker stats --no-stream                       # zużycie CPU i pamięci
docker events --since 10m                      # zdarzenia: die, oom, restart
docker run -it --entrypoint sh obraz           # uruchomienie obrazu z powłoką zamiast aplikacji

Interpretacja kodów wyjścia jest ulubionym „dopytaniem”: 137 = 128 + 9 (SIGKILL, najczęściej OOM killer lub przekroczony czas na zamknięcie), 143 = 128 + 15 (SIGTERM, łagodne zatrzymanie), 126 — polecenie nie jest wykonywalne, 127 — polecenia nie znaleziono (np. zła ścieżka w CMD albo brak powłoki w obrazie distroless). Kod 1 oznacza błąd samej aplikacji — wtedy odpowiedź jest w logach.

Dopowiedz też, jak zapobiec pętli restartów w przyszłości: healthcheck, sensowna polityka --restart (on-failure zamiast always), limity pamięci dobrane do realnego zużycia i logowanie na standardowe wyjście, a nie do pliku w kontenerze.

Jak przygotować się do rozmowy z Dockera

Rozmowy techniczne rzadko kończą się na definicjach. Rekruter zwykle poprosi o opisanie własnego projektu, więc przygotuj konkretną historię: co konteneryzowałeś, jak wyglądał Dockerfile, jaki był problem i jak go rozwiązałeś. Plan na kilka wieczorów:

1. Zbuduj aplikację z bazą danych w Docker Compose, z healthcheckiem, wolumenem na dane i sekretem z pliku.
2. Przepisz Dockerfile na multi-stage build i porównaj rozmiar obrazu (docker images).
3. Uruchom aplikację jako użytkownik bez roota i z --read-only, popraw to, co przestanie działać.
4. Zepsuj coś celowo (zły port, brak zmiennej, limit pamięci 50 MB) i przećwicz diagnozę z pytania 15.
5. Powtórz podstawy Linuksa — procesy, sygnały, uprawnienia, sieć. Pomoże zestawienie 20 poleceń w Linuksie, które musisz znać oraz poradnik o systemctl, bo Docker na serwerze to też usługa systemd.

Na stanowiska DevOps przygotuj się również na pytania o CI/CD: gdzie w pipeline budujesz i skanujesz obraz, jak go tagujesz (np. hashem commita) i czym różni się wdrożenie od wydania — to temat artykułu Deploy a release — różnice. Jeśli potrzebujesz szerszego wprowadzenia do samej technologii, zajrzyj do poradnika Dockera na hostingowy.top, a pełną dokumentację znajdziesz na docs.docker.com.