Kontenery Docker

Obrazy, kontenery, sieci oraz Docker Compose — od mechanizmu systemu operacyjnego do kompletnego środowiska aplikacji.

Inna wersja środowiska, brak zależności, odmienna konfiguracja i ręczne kroki tworzą niepowtarzalne wdrożenia.

Pakujemy proces razem z jego środowiskiem

Kontenery nie pojawiły się nagle

Płacimy także za niewykorzystane zasoby

Koszt to nie tylko zakup serwera: energia, chłodzenie, miejsce, licencje, utrzymanie i czas administratorów.

VM kontra kontener

Kontener to izolowany proces

• ma własny widok procesów, sieci i systemu plików,
• korzysta z jądra systemu gospodarza,
• nie jest domyślnie granicą bezpieczeństwa równą VM,
• po zatrzymaniu procesu głównego kontener kończy pracę.

Definicja staje się procesem

Dlaczego głównie Linux?

Docker wykorzystuje mechanizmy jądra Linuksa. Jądro tworzy izolację i limity — Docker dostarcza model obrazów, API i narzędzia.

Namespaces zmieniają widok świata

• PID — procesy,
• NET — interfejsy, routing i porty,
• MNT — punkty montowania,
• UTS — nazwa hosta,
• USER — mapowanie użytkowników.

Cgroups mierzą i ograniczają

Są także kontenery Windows

Obraz musi pasować do rodziny jądra hosta. Docker Desktop pozwala przełączać tryb Linux/Windows containers.

Czym jest WSL?

Środowiskiem umożliwiającym uruchamianie dystrybucji i narzędzi Linuksa na Windows. WSL 2 używa prawdziwego jądra Linuksa.

wsl --install
wsl --status
wsl --list --verbose

Od terminala do kontenera

Kod przechowywany w systemie plików WSL zwykle działa wydajniej niż kod montowany z dysku Windows.

Jak czytać nazwę obrazu?

postgres:17 · eclipse-temurin:21-jre · ghcr.io/acme/api:1.4.2

Kolejność instrukcji ma znaczenie

Rzadko zmieniające się zależności umieszczamy przed często zmienianym kodem.

COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package

Skąd pobieramy obrazy?

registry/repository:tag · tag może się zmienić, digest wskazuje konkretną treść.

Przepis na obraz

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY target/app.jar app.jar
EXPOSE 8080
USER 10001
ENTRYPOINT ["java", "-jar", "app.jar"]

Obraz bazowy: eclipse-temurin — Docker Official Image. Docker pobierze go z rejestru, jeśli nie ma go lokalnie.

Narzędzia budujące nie muszą trafić do wyniku

FROM maven:3-eclipse-temurin-21 AS build
WORKDIR /src
COPY . .
RUN mvn -q -DskipTests package

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=build /src/target/*.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

Źródła obrazów: maven — etap budowania · eclipse-temurin — mały obraz uruchomieniowy.

Docker widzi tylko przekazany katalog

# .dockerignore
target
.git
.idea
.env

Nie wysyłaj do silnika sekretów, repozytorium ani zbędnych artefaktów.

Zbuduj, oznacz, sprawdź

docker build -t space-api:1.0 .
docker image ls
docker image inspect space-api:1.0
docker history space-api:1.0

Instancja obrazu w ruchu

Kontener ma własną konfigurację, sieć i warstwę zapisu. Usunięcie kontenera usuwa tę warstwę — dane trwałe wymagają wolumenu.

docker run łączy kilka operacji

docker run -d --name space-api \
  -p 8080:8080 \
  -e SPRING_PROFILES_ACTIVE=docker \
  space-api:1.0

-d tło · --name nazwa · -p port · -e zmienna

Port hosta ≠ port kontenera

EXPOSE dokumentuje port. Dopiero -p udostępnia go hostowi.

W jednej sieci używamy nazw

docker network create mission-net
docker run --network mission-net --name db mysql:8
docker run --network mission-net --name api space-api

API łączy się z db:3306, nie z localhost:3306.

Named volume żyje niezależnie od kontenera

docker volume create mysql-data

docker run --name db \
  -v mysql-data:/var/lib/mysql \
  mysql:8

Named volume wybieramy dla danych aplikacji. Bind mount jest wygodniejszy, gdy człowiek ma edytować pliki z hosta, np. kod źródłowy.

Kontener można wymienić bez utraty bazy

docker rm -f db                 # dane zostają
docker volume ls               # volume nadal istnieje
docker run --name db-new \
  -v mysql-data:/var/lib/mysql mysql:8

docker volume rm mysql-data    # jawnie usuwa dane

Najczęściej używane polecenia

docker ps -a
docker logs -f NAME
docker exec -it NAME sh
docker inspect NAME

docker stop NAME
docker rm NAME
docker image ls
docker volume ls

Obserwuj, zanim zmienisz

1. docker ps -a — czy proces nadal działa?
2. docker logs — co zgłosiła aplikacja?
3. docker inspect — jaka jest konfiguracja?
4. docker exec — co widać od środka?

Opis całego środowiska jako kod

Jeden plik deklaruje usługi, obrazy, sposób budowania, sieci, wolumeny, porty, zmienne i warunki gotowości.

Anatomia compose.yaml

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_DB: missions
      POSTGRES_PASSWORD: DB_PASSWORD_FROM_ENV
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Trzy usługi, jedna sieć projektu

Nie wszystko powinno być w obrazie

• ustawienia przekazujemy przy uruchomieniu,
• sekretów nie commitujemy do repozytorium,
• sieć domyślna daje DNS po nazwie usługi,
• wolumen oddziela cykl życia danych od kontenera.

Uruchomiony proces nie zawsze jest gotowy

healthcheck:
  test: ["CMD-SHELL", "pg_isready -U app"]
  interval: 5s
  timeout: 3s
  retries: 10

depends_on:
  db:
    condition: service_healthy

Cykl życia środowiska

docker compose config
docker compose up --build -d
docker compose ps
docker compose logs -f api
docker compose down
docker compose down -v   # usuwa też dane!

Najczęstsze zagrożenia

Buduj mniejszą powierzchnię ataku

• używaj minimalnych, oficjalnych obrazów i przypinaj wersje,
• uruchamiaj proces jako użytkownik bez uprawnień root,
• nie zapisuj sekretów w Dockerfile ani repozytorium,
• skanuj obrazy i regularnie je przebudowuj,
• publikuj tylko potrzebne porty.

Obraz opisuje. Kontener wykonuje. Compose łączy.