Konteneryzacja stała się standardem w nowoczesnym DevOps i administracji systemami. Dzięki niej możemy izolować aplikacje, upraszczać deployment i osiągać powtarzalność środowisk. Ale wybór narzędzia nie jest już tak oczywisty jak kiedyś.
Czy dalej używać Dockera? Czy warto przejść na Podmana? A może sięgnąć po inne rozwiązania?
Czym jest konteneryzacja (i kiedy ma sens)
Kontenery pozwalają uruchamiać aplikacje w izolowanych środowiskach, współdzieląc kernel systemu hosta. To kompromis między:
- wydajnością (lepszą niż VM)
- izolacją (gorszą niż VM, ale wystarczającą w większości przypadków)
Ma sens gdy:
- budujesz mikroserwisy
- deployujesz aplikacje na wielu hostach
- chcesz mieć reproducible environments
- pracujesz z CI/CD lub Kubernetes
Docker – to de facto standard w konteneryzacji
Docker to najpopularniejsza platforma kontenerowa.
Architektura
- daemon (
dockerd) - klient CLI (
docker) - centralne API
Info: problem: daemon działa jako root
Podstawowe komendy
docker build -t app .
docker run -d -p 8080:80 app
docker ps
docker exec -it container bash
Zalety
- ogromny ekosystem
- integracja z CI/CD
- wsparcie dla Kubernetes
Wady
- daemon jako root (security concern)
- większy narzut
- vendor lock-in (Docker Hub, tooling)
Podman – bez daemon, bardziej „linuxowy”
Podman to alternatywa kompatybilna z Docker CLI.
Kluczowa różnica
Cecha: brak demona
- każdy kontener = proces użytkownika
- pełne wsparcie dla rootless
Komendy (identyczne jak Docker!)
podman build -t app .
podman run -d -p 8080:80 app
podman ps
podman exec -it container bash
Dodatkowe możliwości
Rootless containers
podman run --userns=keep-id -it ubuntu bash
Generowanie systemd
podman generate systemd --name container > container.service
Cecha: ogromny plus dla adminów Linuxa
Zalety
- brak demona
- lepsze bezpieczeństwo
- natywna integracja z systemd
- rootless by default
Wady
- mniej popularny ekosystem
- edge-case incompatibilities
Docker vs Podman – kluczowe różnice
| Cecha | Docker | Podman |
|---|---|---|
| Architektura | daemon | daemonless |
| Rootless | ograniczone | natywne |
| systemd | słabe | bardzo dobre |
| CLI | standard | kompatybilne |
| Security | średnie | lepsze |
Inne alternatywy
containerd
containerd
- low-level runtime
- używany przez Kubernetes
- brak wygodnego CLI
ctr images pull docker.io/library/nginx:latest
CRI-O
CRI-O
- runtime pod Kubernetes
- minimalny, bez „feature creep”
LXC / LXD
LXC
- bliżej VM niż Docker
- pełne systemy operacyjne w kontenerze
lxc launch ubuntu:22.04 mycontainer
Kontenery a Kubernetes
W kontekście Kubernetes:
- Docker już NIE jest runtime (dockershim usunięty)
- standard:
- containerd
- CRI-O
Info: Podman lepiej wpisuje się w nowoczesny stack
Kiedy co wybrać?
Docker
- szybki start
- CI/CD
- kompatybilność
Podman
- bezpieczeństwo
- rootless
- systemd + Linux-native
containerd / CRI-O
- Kubernetes
- produkcja
LXC
- „lekka VM”
- system-level isolation
Praktyczne wzkazówki (dla zaawansowanych)
- Podman + systemd = świetny replacement dla docker-compose
- rootless = brak potrzeby sudo → lepszy security model
- cgroups v2 → lepsze zarządzanie zasobami
- overlayfs → podobna wydajność w obu rozwiązaniach
