Docker Compose – 10 błędów

W 2026 roku dla większości zastosowań domowych i produkcyjnych najlepszym wyborem jest uruchomienie Dockera w maszynie wirtualnej (VM) na Proxmox VE – to rozwiązanie oficjalnie wspierane przez Docker, w pełni izolowane i wolne od problemów z cgroups oraz jądrem systemu. LXC (zwłaszcza uprzywilejowany kontener) sprawdza się w homelabach, gdzie liczy się oszczędność RAM-u i błyskawiczny restart, ale wymaga świadomych kompromisów bezpieczeństwa i dodatkowej konfiguracji. Poniżej znajdziesz pełne uzasadnienie tej rekomendacji, benchmarki, instrukcje krok po kroku oraz odpowiedzi na najczęstsze pytania.

Artykuł zaktualizowany pod kątem Proxmox VE 9.2 (Debian 13 „Trixie”, jądro Linux 7.0, LXC 7.0) – stan na sierpień 2026.

Bezpłatne warsztaty: Zbuduj 5 Agentów AI

Sprawdź szczegóły:

https://asdevops.pl/warsztaty/

Spis treści

Dlaczego pytanie „VM czy LXC” w ogóle ma znaczenie
Czym różni się VM od LXC – podstawy techniczne
Docker w maszynie wirtualnej (VM) na Proxmox
Docker w kontenerze LXC na Proxmox
LXC uprzywilejowany vs nieuprzywilejowany dla Dockera
Tabela porównawcza: VM vs LXC dla Dockera
Wydajność: co pokazują testy
Bezpieczeństwo: ryzyka, o których trzeba wiedzieć
Co zmieniło się w Proxmox VE 9.x istotnego dla Dockera
Instrukcja: Docker w VM na Proxmox krok po kroku
Instrukcja: Docker w LXC na Proxmox krok po kroku
Co wybrać w zależności od scenariusza
Najczęstsze błędy i jak ich uniknąć
FAQ – najczęściej zadawane pytania
Podsumowanie

Dlaczego pytanie „VM czy LXC” w ogóle ma znaczenie

Proxmox VE to jedna z najpopularniejszych platform wirtualizacji open source do budowy homelabów i małych/średnich środowisk produkcyjnych. Oferuje dwie zupełnie różne technologie uruchamiania maszyn:

QEMU/KVM – pełna wirtualizacja sprzętowa (maszyny wirtualne, VM),
LXC (Linux Containers) – konteneryzacja na poziomie systemu operacyjnego, współdzieląca jądro hosta.

Docker sam w sobie jest technologią konteneryzacji aplikacji. Kiedy uruchamiasz Dockera wewnątrz LXC, tworzysz kontenery w kontenerze (nested containers), co technicznie działa, ale opiera się na współdzieleniu jednego jądra Linux między hostem Proxmox, kontenerem LXC i kontenerami Docker. To właśnie źródło większości problemów i pytań, które zadają administratorzy.

Wybór między VM a LXC dla Dockera to w praktyce wybór między maksymalnym bezpieczeństwem i zgodnością a maksymalną oszczędnością zasobów.

Czym różni się VM od LXC – podstawy techniczne

Maszyna wirtualna (VM)

VM w Proxmox (oparta na QEMU/KVM) emuluje pełny, niezależny komputer:

własne jądro Linux (lub Windows),
wirtualny sprzęt (CPU, RAM, dysk, karta sieciowa),
pełna izolacja od hosta na poziomie hypervisora,
Docker instalowany tak, jak na „prawdziwym” serwerze Linux (lub Windows).

Kontener LXC

LXC to lekka wirtualizacja na poziomie systemu operacyjnego:

współdzieli jądro hosta Proxmox – nie ma własnego jądra,
izolacja realizowana przez namespaces – izolacja Widoczności (Co proces widzi) i cgroups – (Control Groups): Izolacja Zasobów (Ile proces może zużyć) w jądrze Linux,
dużo mniejsze zużycie RAM i CPU niż VM,
start w ułamku sekundy zamiast kilkudziesięciu sekund.

To właśnie brak własnego jądra jest kluczem do zrozumienia wszystkich problemów z Dockerem w LXC — Docker sam w sobie chce zarządzać cgroups, przestrzeniami nazw i mostkami sieciowymi, a robiąc to wewnątrz kontenera, który sam już jest efektem takiej izolacji, tworzy się dodatkowa warstwa złożoności.

Docker w maszynie wirtualnej (VM) na Proxmox

Zalety

Pełne wsparcie oficjalne – Docker Inc. testuje i wspiera swój silnik na standardowych dystrybucjach Linux uruchomionych jako VM lub bare metal, nie na kontenerach LXC.
Pełna izolacja jądra — awaria, wyciek pamięci czy błąd w jądrze wewnątrz VM nie wpływa na hosta Proxmox ani inne maszyny.
Zgodność 100% – wszystkie funkcje Dockera (Docker-in-Docker, --privileged, niestandardowe sieci overlay, sterowniki devicemapper/overlay2, moduły jądra jak WireGuard, ZFS w kontenerze) działają bez modyfikacji.
Łatwiejsza migracja – obraz VM można bez problemu przenieść między hostami Proxmox, do chmury (AWS, Hetzner, OVH) lub na inny hypervisor.
Snapshoty i backup działają przewidywalnie, bez pułapek związanych z warstwami overlay współdzielonymi z hostem.
Bezpieczeństwo produkcyjne -brak ryzyka „ucieczki” procesu z kontenera do jądra hosta (kernel escape), co jest realnym zagrożeniem przy niepoprawnie skonfigurowanym LXC.

Wady

Większe zużycie zasobów – własne jądro, własny system plików, narzut wirtualizacji (zwykle 512 MB-1 GB RAM samo na system operacyjny, zanim jeszcze uruchomisz jakikolwiek kontener Docker).
Wolniejszy start – 15–40 sekund do pełnego bootu w porównaniu do <1 sekundy dla LXC.
Więcej administracji – aktualizacje jądra, systemu operacyjnego wewnątrz VM, osobne zarządzanie dyskiem.
Mniejsza gęstość – na tym samym sprzęcie zmieścisz mniej instancji VM niż kontenerów LXC.

Docker w kontenerze LXC na Proxmox

Zalety

Minimalne zużycie RAM – kontener LXC z Dockerem potrafi działać przy 128–256 MB RAM w spoczynku, kontra 1 GB+ dla VM.
Błyskawiczny start – restart usługi w ciągu sekundy.
Bardzo dobra gęstość – na słabszym sprzęcie (np. Raspberry Pi, mini PC, N100) możesz uruchomić więcej izolowanych środowisk.
Bezpośredni dostęp do plików hosta przez bind mounty bez warstwy wirtualnego dysku – szybszy I/O (zapis/odczyt).
Niższe zużycie CPU (procesora) – brak narzutu emulacji sprzętu.

Wady

Brak oficjalnego wsparcia Dockera dla uruchamiania wewnątrz LXC – cała konfiguracja opiera się na „obejściach” społeczności (nesting, keyctl, cgroups v2 w trybie unified).
Konieczność ustawień specjalnych na poziomie hosta Proxmox (features: nesting=1,keyctl=1), co samo w sobie zwiększa powierzchnię ataku.
Problemy z niektórymi funkcjami Dockera – sieci bridge bywają kapryśne, AppArmor/SELinux w zagnieżdżonych kontenerach potrafi blokować część operacji, a --privileged w kontenerach Docker uruchomionych w LXC bywa zawodny.
Ryzyko bezpieczeństwa przy trybie uprzywilejowanym LXC – proces w kontenerze może teoretycznie uzyskać wyższe uprawnienia na hoście (kernel/container escape).
Wspólne jądro – aktualizacja jądra hosta Proxmox wpływa na wszystkie kontenery LXC jednocześnie; nie da się uruchomić w LXC dystrybucji wymagającej innej wersji jądra niż hosta.
Backup i migracja bywają mniej przewidywalne przy większych wolumenach danych Dockera (warstwy overlay2 na overlay2 hosta).

LXC uprzywilejowany vs nieuprzywilejowany dla Dockera

To kluczowy wybór, jeśli mimo wszystko decydujesz się na LXC.

Kontener uprzywilejowany (privileged)

Root w kontenerze = root na hoście (mapowanie UID 1:1).
Docker działa „od ręki” po włączeniu nesting i keyctl.
Najprostszy w konfiguracji, ale najmniej bezpieczny – udana ucieczka z kontenera daje pełne uprawnienia roota na hoście Proxmox.
Rekomendowany wyłącznie dla zaufanych, izolowanych sieciowo homelabów.

Kontener nieuprzywilejowany (unprivileged)

Root w kontenerze jest mapowany na zwykłego, nieuprzywilejowanego użytkownika na hoście (UID/GID shifting).
Znacznie bezpieczniejszy domyślnie.
Wymaga dodatkowej konfiguracji, aby Docker w ogóle wystartował (m.in. odpowiednie mapowania idmap, czasem dodanie lxc.apparmor.profile: unconfined i poprawek w /etc/subuid / /etc/subgid).
Niektóre funkcje Dockera (np. niektóre sterowniki storage, overlay2 na pewnych systemach plików hosta) mogą wymagać dalszego dostrajania lub w ogóle nie zadziałać poprawnie.

Rekomendacja: jeśli i tak decydujesz się na LXC, zawsze zaczynaj od próby konfiguracji nieuprzywilejowanej. Tryb uprzywilejowany traktuj jako ostateczność dla środowisk testowych.

Tabela porównawcza: VM vs LXC dla Dockera

Kryterium	VM (QEMU/KVM)	LXC (nested Docker)
Oficjalne wsparcie Docker Inc.	✅ Tak	❌ Nie (konfiguracja nieoficjalna)
Izolacja jądra	✅ Pełna, własne jądro	⚠️ Współdzielone jądro hosta
Zużycie RAM w spoczynku	~512 MB–1 GB+	~128–256 MB
Czas uruchomienia	15–40 s	<1 s
Zgodność ze wszystkimi funkcjami Dockera	✅ 100%	⚠️ Częściowa, wymaga obejść
Bezpieczeństwo (izolacja od hosta)	✅ Wysokie	⚠️ Niższe, zależne od konfiguracji
Łatwość migracji między hostami/chmurą	✅ Bardzo łatwa	⚠️ Trudniejsza
Gęstość na tym samym sprzęcie	⚠️ Niższa	✅ Wyższa
Prostota backupu snapshotów	✅ Przewidywalna	⚠️ Może komplikować się przy dużych wolumenach
Zalecane dla produkcji	✅ Tak	⚠️ Ostrożnie, z uprzywilejowanym trybem — nie
Zalecane dla homelabu na słabym sprzęcie	⚠️ Możliwe, ale kosztowne zasobowo	✅ Tak

Wydajność: co pokazują testy

W testach obciążeniowych typowych kontenerów Docker (np. Nginx, PostgreSQL, aplikacje Node.js) uruchomionych wewnątrz VM na Proxmox VE 9.x kontra wewnątrz kontenera LXC z włączonym nestingiem, różnice w czystej wydajności obliczeniowej i sieciowej są zaskakująco niewielkie – zwykle w granicach 3–8% na korzyść LXC, głównie dzięki brakowi narzutu wirtualizacji sprzętu i wirtualnej karty sieciowej.

Prawdziwa różnica ujawnia się w:

zużyciu pamięci w spoczynku – tu LXC wygrywa zdecydowanie (nawet 4–6-krotnie mniej RAM-u bez uruchomionych aplikacji),
operacjach dyskowych I/O (zapis/odczyt) – LXC z bind mountami bywa szybszy, bo pomija warstwę wirtualnego dysku VM (virtio mimo optymalizacji nadal dodaje narzut),
czasie reakcji na restart usługi – kluczowe przy częstych redeployach (ponownych wdrożeniach) w środowiskach CI/CD.

Wniosek praktyczny: jeśli Twój serwer ma dużo wolnego RAM-u i CPU, różnica wydajności praktycznie nie ma znaczenia – wtedy decyzję powinno determinować bezpieczeństwo i zgodność (czyli VM). Jeśli działasz na ograniczonym sprzęcie (Raspberry Pi, mini PC, N100, stary laptop jako homelab), oszczędność zasobów LXC może być decydująca.

Bezpieczeństwo: ryzyka, o których trzeba wiedzieć

To najczęściej pomijany aspekt w dyskusjach „VM czy LXC”, a jednocześnie najważniejszy dla środowisk wystawionych do internetu.

Współdzielone jądro = współdzielona powierzchnia ataku. Luka w jądrze Linux (np. w podsystemie cgroups lub namespace) może teoretycznie pozwolić na eskalację uprawnień z kontenera LXC do hosta Proxmox – a stamtąd do wszystkich innych maszyn na tym hoście. W VM taki scenariusz wymaga znacznie poważniejszej luki w samym hypervisorze KVM, co jest rzadsze i szybciej łatane.
Docker + LXC uprzywilejowany to podwójna warstwa ryzyka. Sam Docker domyślnie działa jako root i ma dostęp do demona z pełnymi uprawnieniami – to już samo w sobie wymaga ostrożności (np. rootless mode Dockera). Uruchomienie go dodatkowo w uprzywilejowanym LXC kumuluje oba ryzyka.
AppArmor/SELinux w zagnieżdżonych kontenerach bywa wyłączany lub rozluźniany (unconfined), żeby Docker w ogóle zadziałał w LXC – co same w sobie obniża domyślny poziom ochrony.
VM izoluje na poziomie sprzętowym (rozszerzenia wirtualizacji CPU: Intel VT-x/AMD-V), co jest fundamentalnie silniejszą barierą niż izolacja programowa oparta na namespace’ach jądra.

Rekomendacja bezpieczeństwa: dla usług wystawionych publicznie do internetu (reverse proxy, panele administracyjne, bazy danych z danymi wrażliwymi) zdecydowanie wybieraj Dockera w VM. Dla wewnętrznych usług homelabowych, niedostępnych z internetu, LXC (najlepiej nieuprzywilejowany) jest akceptowalnym kompromisem.

Co zmieniło się w Proxmox VE 9.x istotnego dla Dockera

Proxmox VE 9.2 (najnowsza stabilna wersja na sierpień 2026) bazuje na Debianie 13 „Trixie” z jądrem Linux 7.0 oraz LXC w wersji 7.0. To ma bezpośrednie znaczenie dla decyzji VM vs LXC:

Nowsze jądro 7.0 oznacza lepsze wsparcie dla cgroups v2 i nowszych mechanizmów izolacji, co poprawia stabilność Dockera uruchamianego w LXC względem starszych gałęzi Proxmox VE 7.x/8.x, ale nie eliminuje fundamentalnych ograniczeń zagnieżdżonej konteneryzacji.
Proxmox VE 8.4 (poprzednia gałąź LTS) kończy standardowe wsparcie bezpieczeństwa wraz z końcem wsparcia Debiana 12 „Bookworm” – administratorzy wciąż działający na PVE 8.x powinni zaplanować migrację do gałęzi 9.x, co jest dobrą okazją, aby przy okazji zweryfikować, czy dane obciążenie Dockera nie powinno zostać przeniesione z LXC do VM (lub odwrotnie).
Proxmox VE 9.x wprowadził też dynamiczny load balancer klastra oraz rozszerzone SDN – istotne przy planowaniu większych wdrożeń z wieloma VM hostującymi Dockera w klastrze wysokiej dostępności (HA).

Ogólna zasada pozostaje niezmienna niezależnie od wersji Proxmoksa: LXC nigdy nie stanie się „oficjalnie wspieranym” środowiskiem dla Dockera, ponieważ problem leży w architekturze (współdzielone jądro), a nie w konkretnej wersji oprogramowania.

Instrukcja: Docker w VM na Proxmox krok po kroku

Utwórz nową VM w Proxmox: co najmniej 2 vCPU, 2–4 GB RAM (więcej w zależności od obciążenia), dysk 20+ GB, kontroler virtio-scsi dla wydajności dysku.
Zainstaluj lekką dystrybucję Linux – dobrym wyborem są Debian 13, Ubuntu Server 24.04/26.04 LTS lub Alpine Linux dla minimalnego zużycia zasobów.
Zaktualizuj system: apt update && apt full-upgrade -y.
Zainstaluj Dockera z oficjalnego repozytorium, korzystając ze skryptu instalacyjnego lub repozytorium APT dostępnego w dokumentacji Docker Engine dla wybranej dystrybucji.
Dodaj swojego użytkownika do grupy docker, aby uniknąć konieczności używania sudo przy każdym poleceniu.
Zainstaluj Docker Compose (obecnie jako plugin docker compose, dostępny razem z Docker Engine).
Skonfiguruj automatyczny start VM wraz z hostem Proxmox (opcja „Start at boot” w ustawieniach VM) oraz kolejność startu, jeśli VM zależy od innych maszyn (np. serwera NFS z danymi).
Ustaw regularne backupy przez wbudowany mechanizm Proxmox Backup Server lub vzdump.
Rozważ agenta gościa (qemu-guest-agent) dla lepszej integracji z Proxmox (poprawne zamykanie, statystyki).

Instrukcja: Docker w LXC na Proxmox krok po kroku

Utwórz kontener LXC z szablonu Debian 13 lub Ubuntu (unikaj Alpine – problemy ze zgodnością libc dla niektórych obrazów Docker).
Zdecyduj: uprzywilejowany czy nie. Dla nauki/testów – uprzywilejowany jest prostszy. Dla czegokolwiek bliższego produkcji — dąż do nieuprzywilejowanego.
Włącz nesting w opcjach kontenera na hoście Proxmox: w pliku konfiguracyjnym /etc/pve/lxc/<ID>.conf dodaj: features: nesting=1,keyctl=1
Zrestartuj kontener, aby zmiany weszły w życie.
Zainstaluj Dockera wewnątrz kontenera tak samo jak na zwykłym systemie Linux (oficjalne repozytorium APT Docker Engine).
Sprawdź działanie cgroups: uruchom docker run hello-world i zweryfikuj, czy kontener startuje bez błędów związanych z cgroups v2.
W razie problemów z siecią bridge rozważ użycie trybu sieciowego host dla kontenerów Docker wewnątrz LXC lub dostosuj MTU na moście sieciowym Proxmox.
Monitoruj logi (journalctl -u docker) – większość problemów z Dockerem w LXC objawia się właśnie tam jako błędy uprawnień lub brakujących modułów jądra.
Regularnie testuj backup i przywracanie – zagnieżdżone warstwy Docker overlay2 wewnątrz backupu LXC bywają większe i wolniejsze do przywrócenia niż się wydaje.

Co wybrać w zależności od scenariusza

Serwis produkcyjny wystawiony do internetu (e-commerce, API, baza danych klientów): VM. Bez dyskusji, izolacja jądra i oficjalne wsparcie Dockera są tu priorytetem.
Homelab na Raspberry Pi / mini PC z 4-8 GB RAM, dużo drobnych usług (Home Assistant, arr stack, Pi-hole): LXC (nieuprzywilejowany, jeśli to możliwe) – oszczędność RAM-u pozwoli zmieścić więcej usług.
Środowisko testowe/CI, gdzie kontenery są tworzone i niszczone dziesiątki razy dziennie: LXC – szybkość startu realnie skraca czas iteracji.
Klaster Proxmox z HA i migracją na żywo: VM – łatwiejsza, przewidywalna migracja między nodami, brak zależności od identycznej wersji jądra hosta.
Nauka Dockera i eksperymentowanie „na sucho”: LXC uprzywilejowany – najszybszy sposób na start, akceptowalne ryzyko przy izolowanej sieci.
Firma z wymogami zgodności/audytu bezpieczeństwa (RODO, ISO 27001): VM – łatwiej uzasadnić i udokumentować izolację wobec audytorów.

Najczęstsze błędy i jak ich uniknąć

Uruchamianie Dockera w domyślnym, nieuprzywilejowanym LXC bez włączonego nestingu – kontener po prostu nie wystartuje demona Dockera lub będzie zgłaszał błędy cgroups.
Ignorowanie aktualizacji jądra hosta przy współdzielonym LXC – aktualizacja jądra Proxmox wpływa na wszystkie kontenery naraz; brak testów przed aktualizacją bywa bolesny.
Mieszanie środowisk produkcyjnych i testowych w jednym uprzywilejowanym LXC – brak izolacji między nimi zwiększa skutki potencjalnego incydentu.
Zbyt małe zasoby VM – Docker Engine i kontenery wymagają więcej RAM-u niż się wydaje przy większej liczbie uruchomionych obrazów; zaplanuj margines.
Brak regularnych backupów wolumenów Dockera niezależnie od wybranej metody – snapshoty Proxmox nie zastępują backupu danych aplikacji (np. baz danych) na poziomie logicznym.
Używanie --privileged w kontenerach Docker działających wewnątrz LXC – to kumulacja dwóch warstw podwyższonych uprawnień; unikaj, jeśli to możliwe.

FAQ – najczęściej zadawane pytania

Czy Docker w LXC na Proxmox jest oficjalnie wspierany?

Nie. Docker Inc. nie testuje ani nie wspiera oficjalnie uruchamiania swojego silnika wewnątrz kontenerów LXC. Działa to dzięki pracy społeczności Proxmox i odpowiedniej konfiguracji nestingu, ale pozostaje rozwiązaniem nieoficjalnym.

Czy Docker w LXC jest bezpieczny?

Może być akceptowalnie bezpieczny w środowiskach zaufanych i odizolowanych sieciowo, szczególnie w konfiguracji nieuprzywilejowanej. Dla usług wystawionych publicznie do internetu zalecana jest jednak VM ze względu na silniejszą izolację jądra.

Czy istnieje oficjalny szablon LXC dla Dockera w Proxmox?

Proxmox nie dostarcza dedykowanego, oficjalnego szablonu „Docker LXC”. Społeczność (m.in. popularne skrypty pomocnicze do Proxmox) udostępnia gotowe skrypty ułatwiające instalację, ale nie zastępują one oficjalnego wsparcia.

Ile RAM-u realnie oszczędza LXC względem VM?

W typowym scenariuszu kontener LXC z Dockerem w spoczynku zużywa od kilku do kilkunastu razy mniej pamięci RAM niż porównywalna VM z pełnym systemem operacyjnym – różnica maleje wraz ze wzrostem liczby i wielkości uruchomionych kontenerów Docker.

Czy da się migrować z LXC na VM (lub odwrotnie) bez utraty danych?

Tak, jeśli dane aplikacji trzymane są w wolumenach Docker lub katalogach bind mount poza samym kontenerem/VM. Wystarczy przenieść te dane i ponownie uruchomić docker compose up w nowym środowisku.

Czy Portainer lub inne narzędzia GUI zmieniają tę decyzję?

Nie. Portainer, Dockge czy podobne narzędzia zarządzają Dockerem niezależnie od tego, czy działa on w VM czy LXC – same w sobie nie rozwiązują żadnych ograniczeń architektonicznych LXC.

Czy Proxmox VE 9.2 rozwiązał problemy z Dockerem w LXC?

Nowsze jądro (Linux 7.0) i LXC 7.0 poprawiają ogólną stabilność i zgodność z cgroups v2, ale nie eliminują fundamentalnego faktu, że Docker w LXC pozostaje rozwiązaniem nieoficjalnym opierającym się na współdzielonym jądrze hosta.

Co jest lepsze dla początkującego użytkownika Proxmox?

VM – mniej niespodzianek, pełna zgodność z tutorialami i dokumentacją Dockera pisaną z myślą o standardowych systemach Linux, mniejsze ryzyko trudnych do zdiagnozowania błędów cgroups.

Podsumowanie

Wybór między VM a LXC dla Dockera na Proxmox w 2026 roku sprowadza się do jednego pytania: co jest dla Ciebie ważniejsze – zgodność i bezpieczeństwo, czy oszczędność zasobów i szybkość?

Wybierz VM, jeśli zależy Ci na pełnej zgodności z Dockerem, silniejszej izolacji bezpieczeństwa, łatwej migracji i pracujesz na sprzęcie z wystarczającą ilością RAM-u.
Wybierz LXC, jeśli działasz na ograniczonym sprzęcie, budujesz homelab z wieloma drobnymi usługami, akceptujesz dodatkową konfigurację (nesting, keyctl) i rozumiesz związane z tym kompromisy bezpieczeństwa.

Proxmox VE 9.2 i nowsze jądro Linux 7.0 nieco poprawiają stabilność obu rozwiązań, ale nie zmieniają fundamentalnej zasady: Docker został zaprojektowany, aby działać na pełnym jądrze Linux – VM daje mu to natywnie, LXC symuluje to za pomocą dodatkowych warstw. W razie wątpliwości, zwłaszcza przy usługach produkcyjnych, wybór VM pozostaje bezpieczniejszą, bardziej przewidywalną drogą.

Bezpłatne warsztaty: Zbuduj 5 Agentów AI