Publikacje

Konteneryzacja aplikacji webowych: Docker, systemd-nspawn i jail we FreeBSD – izolacja, wydajność i bezpieczeństwo

Opublikowano: 14 maja 2026 · Autor: Marcin Szewczyk-Wilgan

Poniższe opracowanie porównuje trzy wiodące technologie konteneryzacji – Docker (OCI), systemd-nspawn i FreeBSD Jails – z perspektywy architektury jądra, mechanizmów pamięci masowej (overlay2 vs ZFS), sieci (NAT, macvlan, VNET/epair) oraz bezpieczeństwa (seccomp, AppArmor, Capsicum). Szczególną uwagę poświęcamy problemom wydajnościowym przy obciążeniach bazodanowych, w tym blokadzie io_uring w kontenerach Docker oraz natywnej integracji ZFS z FreeBSD Jails.

Wprowadzenie

Wdrażanie aplikacji webowych przeszło w ostatniej dekadzie fundamentalną transformację – od pełnej wirtualizacji sprzętowej (hypervisory) ku wirtualizacji na poziomie systemu operacyjnego. Zmiana ta przyniosła drastyczne zmniejszenie narzutu procesora i pamięci, umożliwiając uruchamianie setek wyizolowanych środowisk na pojedynczym serwerze fizycznym.

Rozwój ten nie przebiegał jednak jednorodnie. W ekosystemie Linux dominującym standardem stał się Docker, oparty na specyfikacji Open Container Initiative (OCI), który zrewolucjonizował dystrybucję oprogramowania poprzez koncepcję efemerycznych, zorientowanych na aplikację kontenerów. Alternatywą w tym samym ekosystemie jest systemd-nspawn – narzędzie zintegrowane z menedżerem systemu systemd, które traktuje kontenery nie jako pojedyncze procesy, lecz jako pełnoprawne wirtualne maszyny na poziomie systemu operacyjnego z własnym systemem inicjalizacji.

Z kolei w świecie systemów BSD mechanizm FreeBSD Jails oferuje natywne, głęboko zintegrowane z jądrem podejście do izolacji. Jego historia sięga 1999 roku, co czyni go technologią znacznie bardziej dojrzałą niż współczesne odpowiedniki linuxowe. W połączeniu z wirtualnym stosem sieciowym VNET oraz systemem plików ZFS, FreeBSD Jails tworzy środowisko o wyjątkowej spójności i bezpieczeństwie. Szczegóły konfiguracji ZFS pod bazy danych omawiamy w publikacji Zaawansowana optymalizacja ZFS dla baz danych PostgreSQL i MySQL.

Niniejsza analiza porównuje te trzy technologie z perspektywy architektury jądra, mechanizmów pamięci masowej, sieci i bezpieczeństwa – ze szczególnym uwzględnieniem obciążeń bazodanowych i aplikacji webowych.

Architektura izolacji: namespaces i cgroups v2 na Linuksie kontra Jails we FreeBSD

Kontener linuxowy – iluzja złożona z prymitywów jądra

W systemie Linux nie istnieje jeden spójny obiekt jądra o nazwie „kontener". Kontener linuxowy jest abstrakcją wynikającą z jednoczesnego zastosowania dwóch niezależnych podsystemów jądra: przestrzeni nazw (namespaces) oraz grup kontrolnych (cgroups). Docker i systemd-nspawn pełnią funkcję orkiestratorów, które konfigurują i łączą te podsystemy wokół określonego procesu.

Przestrzenie nazw zmieniają globalną widoczność zasobów dla określonego drzewa procesów:

• Mount (mnt) – izoluje topologię systemu plików. Nowe punkty montowania są widoczne wyłącznie wewnątrz danej przestrzeni.
• PID – procesy wewnątrz kontenera widzą niezależne drzewo procesów, rozpoczynające się od wirtualnego PID 1.
• Network (net) – wirtualizuje cały stos sieciowy: interfejsy, adresy IP, tabele routingu i reguły zapory (iptables/nftables).
• User – mapuje identyfikatory UID/GID wewnątrz kontenera na nieuprzywilejowane identyfikatory na hoście. Proces może mieć uprawnienia roota (UID 0) wewnątrz kontenera, będąc bezpiecznym użytkownikiem na hoście (architektura rootless containers).
• IPC – izoluje pamięć współdzieloną (System V IPC).
• UTS – izoluje nazwę hosta i domeny.

Grupy kontrolne (cgroups v2) odpowiadają za twarde limity wykorzystania zasobów: czas procesora (CPU quotas), pamięć RAM (zapobieganie OOM na poziomie hosta), przepustowość I/O (throttling) oraz liczbę procesów potomnych i deskryptorów plików. Cgroups v2 wprowadził ujednoliconą hierarchię (Unified Hierarchy), rozwiązując problemy z niespójnością obecne w starszej wersji v1.

Docker kontra systemd-nspawn – dwa podejścia na tym samym jądrze

Różnice między tymi narzędziami sprowadzają się do sposobu wykorzystania tych samych prymitywów:

Docker składa przestrzenie nazw wokół pojedynczego procesu aplikacji (np. serwera Nginx lub demona MariaDB). Kontenery Dockera są z założenia efemeryczne i bezstanowe.

systemd-nspawn ładuje pełny system inicjalizacji (systemd) jako PID 1 wewnątrz kontenera. Ogranicza dostęp do krytycznych interfejsów jądra, montując /sys, /proc/sys i /sys/fs/selinux w trybie tylko do odczytu. Nie pozwala na rebootowanie hosta ani ładowanie modułów jądra z wnętrza kontenera. Jest zintegrowany z mechanizmem machinectl, umożliwiając zarządzanie kontenerami jak usługami systemowymi.

FreeBSD Jails – monolityczny obiekt jądra

System FreeBSD implementuje izolację fundamentalnie inaczej. Mechanizm Jails nie składa się z niezależnych podsystemów – wywołanie systemowe jail_set(2) tworzy nierozerwalny obiekt jądra. Jądro zawsze wie, czy dany proces znajduje się w środowisku jail, ponieważ struktura danych procesu bezpośrednio wskazuje na strukturę więzienia.

Jail rozszerza klasyczne środowisko chroot o bezwzględną separację przestrzeni użytkowników, pamięci współdzielonej (System V IPC), podsystemu procesów oraz warstwy sieciowej. Jądro kategorycznie odmawia operacji na obiektach globalnych z wnętrza jaila, co tworzy znacznie węższą płaszczyznę ataku w porównaniu do Linuksa, gdzie abstrakcje przestrzeni nazw bywały wielokrotnie obchodzone z powodu błędów w weryfikacji kontekstów uprawnień.

Zarządzanie zasobami realizowane jest poprzez mechanizm RCTL (Resource Limits), który operuje hierarchicznie na użytkownikach, procesach i obiektach jail. Nowoczesne wdrożenia opierają się na modelu Jails v2 (hierarchiczne więzienia) oraz na w pełni zwirtualizowanym stosie sieciowym VNET (VIMAGE).

Pamięć masowa: System plików ZFS jako fundament infrastruktury

Warstwa przechowywania danych jest krytycznym aspektem decydującym o wydajności konteneryzowanych baz danych. Zrozumienie mechaniki I/O pod warstwą wirtualizacji pozwala uniknąć zjawisk amplifikacji zapisu i degradacji przepustowości.

Docker i sterowniki pamięci masowej

Kontenery Dockera budowane są na topologii warstwowej (image layers). Każda warstwa reprezentuje instrukcję w pliku Dockerfile i jest w trybie tylko do odczytu. Modyfikacje zapisywane są w efemerycznej warstwie zapisywalnej za pomocą mechanizmu Copy-on-Write.

Domyślnym sterownikiem jest overlay2, który operuje na poziomie całych plików (file-level CoW). Jeśli proces wewnątrz kontenera chce zmodyfikować 1 bajt w gigabajtowym pliku bazy danych z niższej warstwy, overlay2 musi skopiować cały plik do warstwy zapisu. Dla baz danych obsługujących ciągłe operacje UPDATE/INSERT generuje to katastrofalną degradację wydajności.

Rozwiązaniem jest stosowanie wolumenów Docker (Docker volumes) lub montowań powiązanych (bind mounts) dla katalogów danych (np. /var/lib/mysql). Mechanizmy te omijają warstwę CoW sterownika i pozwalają kontenerowi zapisywać dane bezpośrednio w systemie plików hosta z wydajnością zbliżoną do natywnej.

Alternatywą jest dedykowany sterownik ZFS (zfs storage driver), który działa na poziomie bloków (block-level CoW). Modyfikacja 1 bajtu skutkuje skopiowaniem tylko zmienionego bloku (np. 128 KB), co jest procesem niemal natychmiastowym. Sterownik ten zapewnia integralność danych z sumami kontrolnymi i przezroczystą kompresję (LZ4). Wadą jest ryzyko spowolnienia operacji administracyjnych ZFS przy dużej liczbie migawek tworzonych podczas pobierania obrazów.

systemd-nspawn i bezpośredni dostęp do ZFS

Narzędzie systemd-nspawn, ze swoją stanową naturą, doskonale integruje się z ZFS na poziomie datasetów. Każdy kontener może operować na własnym datasecie ZFS z indywidualnymi parametrami (recordsize, kompresja, quota). Migawki datasetów umożliwiają natychmiastowe tworzenie kopii zapasowych i rollback bez narzutu warstwy pośredniej.

FreeBSD Jails i natywna integracja z ZFS

W ekosystemie FreeBSD integracja ZFS z Jails jest jeszcze głębsza. Polecenie zfs jail pozwala na delegowanie całych datasetów do wnętrza jaila. Jail może zarządzać własnymi migawkami i parametrami ZFS bez dostępu do globalnego drzewa puli.

Konfiguracja wymaga odpowiednich flag bezpieczeństwa: enforce_statfs=1, allow.mount oraz allow.mount.zfs w definicji jaila, a także odpowiedniego zestawu reguł devfs (devfs_ruleset) eksponującego urządzenie /dev/zfs bez dostępu do fizycznych dysków hosta.

Architektura sieci kontenerowych

Linux: mosty wirtualne, NAT i macvlan

Domyślna konfiguracja sieciowa Dockera opiera się na wirtualnym moście (docker0) i translacji adresów NAT. Każdy kontener otrzymuje interfejs veth podłączony do mostu, a ruch wychodzący przechodzi przez reguły iptables/nftables na hoście.

Przy dużym obciążeniu (dziesiątki gigabitów na sekundę) narzut na operacje NAT – przepisywanie adresów MAC, sum kontrolnych IP i nawiązań TCP – drastycznie degraduje przepustowość.

Rozwiązaniem jest sterownik macvlan. Interfejs wirtualny otrzymuje indywidualny adres MAC i jest podpinany bezpośrednio do fizycznej karty sieciowej hosta. Kontener trafia do fizycznego przełącznika bez translacji NAT, osiągając przepustowość zbliżoną do fizycznego łącza. Macvlan jest dostępny zarówno w Dockerze, jak i w systemd-nspawn (parametr MACVLAN= w pliku profilu).

FreeBSD: VNET (VIMAGE) i pary epair

System VNET (VIMAGE) we FreeBSD powiela w pamięci operacyjnej kompletny stos sieciowy jądra dla każdego jaila: izolowane tabele ARP, unikalne interfejsy lo0, niezależne instancje protokołów transportowych, IPsec oraz osobne instancje zapory pakietowej.

Komunikacja oparta jest na parach interfejsów epair podpiętych pod wirtualny most bridge. Końcówka „a" (np. epair0a) pozostaje po stronie hosta jako członek mostu, a końcówka „b" (np. epair0b) trafia do wnętrza jaila, gdzie otrzymuje indywidualny adres IP.

Istotnym problemem w środowiskach z zagnieżdżoną wirtualizacją (np. FreeBSD w hypervisorze KVM) jest patologiczne zachowanie sprzętowego odciążania sum kontrolnych (Hardware Checksum Offloading). Wirtualne mosty VNET w połączeniu z NAT zniekształcają nagłówki TCP, powodując drastyczny spadek przepustowości. Rozwiązaniem jest dezaktywacja tego mechanizmu: parametry hw.vtnet.X.csum_disable=1 i hw.vtnet.lro_disable=1 w /boot/loader.conf oraz wyłączenie przepuszczania mostka przez zaporę pfil: net.link.bridge.pfil_member=0 i net.link.bridge.pfil_bridge=0.

Bezpieczeństwo: seccomp i AppArmor kontra Capsicum

Linux: wielowarstwowe bariery filtracyjne

Systemy Linux odpierają ataki typu container breakout wielowarstwową metodologią:

Seccomp-bpf (Secure Computing with Berkeley Packet Filter) filtruje wywołania systemowe za pomocą profili JSON zawierających białą i czarną listę dozwolonych operacji. Domyślne profile blokują m.in. CLONE_NEWUSER, clock_settime, key_ctl i operacje kryptograficzne na urządzeniach.

AppArmor (Mandatory Access Control) nakłada restrykcje na ścieżki dostępu do plików, niezależnie od uprawnień systemowych użytkownika. Profile AppArmor są przypisywane kontenerom automatycznie.

Połączenie seccomp + AppArmor tworzy wielopoziomową barierę: seccomp blokuje niebezpieczne wywołania systemowe, AppArmor ogranicza dostęp do ścieżek plików.

FreeBSD: Capsicum – bezpieczeństwo oparte na Capabilities

FreeBSD stosuje fundamentalnie inne podejście – model Capsicum, oparty na zdolnościach (Capabilities) zamiast list filtrów.

Aplikacja wywołuje funkcję cap_enter(), po czym zostaje uwięziona w trybie zdolności (capability mode). Od tego momentu program traci dostęp do globalnego systemu plików – nie może wywołać prostego open("/etc/passwd") za pomocą ścieżki tekstowej. Wszelkie odwołania do globalnych zasobów (procesów, pamięci, gniazd) są blokowane przez jądro.

Jedynym sposobem dostępu do zasobów są deskryptory plików (file descriptors) przydzielone przed wejściem w tryb capability. Program operuje wyłącznie na deskryptorach przekazanych mu z zewnątrz, korzystając z ograniczonych wersji wywołań systemowych (np. openat(2) zamiast open(2)).

Podejście to – określane jako oblivious sandboxing – uodparnia program na ataki typu RCE (Remote Code Execution) znacznie skuteczniej niż filtrowanie wywołań systemowych w seccomp, ponieważ nawet wykorzystanie luki w jądrze nie daje atakującemu dostępu do globalnych zasobów systemu.

Restrykcje bezpieczeństwa a wydajność: problem io_uring w Dockerze

Interfejs io_uring, wprowadzony w jądrze Linux 5.1, rewolucjonizuje wydajność I/O dzięki kolejkom pierścieniowym (Submission Queue i Completion Queue) odwzorowanym w pamięci współdzielonej między przestrzenią użytkownika a jądrem. Eliminuje to narzut ciągłego przełączania kontekstu, pozwalając na pełne wykorzystanie przepustowości dysków NVMe.

Problem polega na tym, że domyślny profil seccomp w Dockerze blokuje wszystkie wywołania z rodziny io_uring. Wynika to z faktu, że asynchroniczna natura io_uring i dzielona struktura pamięci tworzą dużą płaszczyznę ataku – moduł ten generował wielokrotne luki w zabezpieczeniach, co skłoniło Google (gVisor) i Android do jego całkowitego zablokowania.

Skutkiem tej polityki jest cicha degradacja wydajności baz danych wewnątrz kontenerów Docker – silniki automatycznie wracają do powolnych interfejsów synchronicznych bez ostrzeżenia. Problematykę tę omawialiśmy również w kontekście MariaDB w publikacji Optymalizacja ZFS dla baz danych.

Rozwiązania dostępne dla administratorów:

• Wyłączenie seccomp dla kontenera bazy danych flagą --security-opt seccomp=unconfined – wymaga świadomej akceptacji podwyższonego ryzyka.
• Załadowanie spersonalizowanego profilu JSON, który selektywnie dopuszcza wywołania io_uring.
• Zwiększenie limitu blokowanej pamięci (memlock) w Docker Compose lub konfiguracji systemd (LimitMEMLOCK), ponieważ io_uring wymaga blokowania stron pamięci.

We FreeBSD problem ten nie występuje – jails nie stosują mechanizmu seccomp, a natywna architektura Capsicum nie blokuje operacji I/O na poziomie wywołań systemowych.

Zakończenie i rekomendacje

Każda z trzech technologii – Docker, systemd-nspawn i FreeBSD Jails – realizuje izolację w fundamentalnie odmienny sposób i sprawdza się w innych scenariuszach.

Docker jest optymalnym wyborem dla środowisk wymagających szybkiego deploymentu, horyzontalnego skalowania i integracji z ekosystemem Kubernetes. Efemeryczność kontenerów i rozbudowana infrastruktura rejestrów obrazów czynią go standardem w architekturach mikroserwisowych. Wymaga jednak świadomości ograniczeń: narzut sterownika overlay2 na bazach danych, blokowanie io_uring przez seccomp i konieczność stosowania wolumenów dla danych trwałych.

systemd-nspawn sprawdza się tam, gdzie potrzebna jest stanowa, wielousługowa maszyna z pełnym systemem inicjalizacji – np. środowiska deweloperskie, staging, izolacja legacy aplikacji. Doskonale integruje się z ZFS i machinectl, ale nie dysponuje ekosystemem obrazów porównywalnym z Docker Hub.

FreeBSD Jails z VNET i ZFS oferują najgłębszą integrację z jądrem, najwęższą płaszczyznę ataku (monolityczny obiekt jądra + Capsicum) i natywną delegację datasetów ZFS bez warstwy pośredniej. Są idealnym rozwiązaniem dla wymagających obciążeń bazodanowych i środowisk, w których priorytetem jest bezpieczeństwo i stabilność I/O. Wymagają jednak większej ekspertyzy w konfiguracji (VNET, epair, devfs_ruleset, RCTL) i mniejszej społeczności niż ekosystem Docker.

Niezależnie od wybranej technologii, kluczowe jest zrozumienie zachowań jądra hosta – limitów memlock, restrykcji seccomp, charakterystyki Copy-on-Write w systemie plików oraz mechanizmów sprzętowego odciążania sieci. To właśnie te detale, a nie sam wybór narzędzia konteneryzacji, decydują o ostatecznej wydajności i bezpieczeństwie produkcyjnej infrastruktury.

Najczęstsze pytania

FAQ – Konteneryzacja