Docker vs LXC w Proxmox VE:
różnice i kiedy którego użyć

Kontener aplikacyjny vs systemowy

LXC i Docker stoją na tym samym fundamencie Linuksa: namespaces (PID, mount, net, UTS, IPC, user) i cgroups. Żadne z nich nie bootuje własnego jądra — to nie jest KVM. Rozjeżdżają się tam, gdzie zaczyna się cykl życia.

LXC to kontener systemowy. W środku masz pełny userspace: systemd jako PID 1, pakiety, użytkowników, cron, kilka usług naraz. W Proxmox VE jest to natywny typ gościa — tworzysz CT z panelu albo przez pct, nadajesz IP na mostku, robisz backup PBS. Szczegóły bezpieczeństwa i bind mounts są w artykule Kontenery LXC w Proxmox.

Docker to kontener aplikacyjny. Typowy obraz OCI uruchamia jeden główny proces (albo mały zestaw procesów) i jest budowany warstwami z Dockerfile. Obrazy ściągasz z rejestru, składasz stosy Compose albo orkiestrujesz w Kubernetes. Proxmox nie ma typu gościa „Docker” — engine instalujesz w VM, w LXC z nestingiem albo — czego nie polecamy — bezpośrednio na hoście.

Tabela różnic na Proxmox VE

Żadne z dwojga nie zastąpi VM tam, gdzie potrzebujesz własnego jądra albo Windows. Narzut RAM pustego LXC jest minimalny — czysty Debian 13 w CT to ok. 16 MB wobec ok. 213 MB w VM; liczby i kontekst są w VM vs kontener: zużycie RAM. Docker dokłada jeszcze demona i warstwy obrazów — gęstość zależy od liczby kontenerów w jednym engine, nie od samego „kontener vs VM”.

Trzy sposoby na Docker w klastrze

Proxmox nie zabrania Dockera. Wybierasz, gdzie stoi engine — i ten wybór decyduje o izolacji, backupie i HA.

• Docker w VM (zalecane na produkcję): pełna izolacja jądra gościa, migracja na żywo samej VM, backup PBS całej maszyny, spokojne privileged / overlay2 w środku. Narzut to koszt VM, nie Dockera.
• Docker w LXC (nesting): w Features włączasz nesting=1; często też FUSE, gdy overlayfs w nieuprzywilejowanym CT jest niedostępny i engine schodzi na fuse-overlayfs. Gęściej niż VM, ale więcej tarć: AppArmor, device cgroup, keyctl. HA to restart CT, nie live migration.
• Docker na hoście Proxmox: pakiety i moduły na hypervisorze, konflikt z aktualizacjami PVE, ucieczka z kontenera bliżej jądra klastra. Da się zainstalować — nie warto tego robić na węźle produkcyjnym.

Sieć, dane, backup i HA

LXC dostaje adres na vmbr, tag VLAN albo SDN — z sieci wygląda jak mała VM. Docker domyślnie siedzi za mostkiem docker0 i publikuje porty; overlay i macvlan to już osobna warstwa, której Proxmox nie widzi jako gościa.

Backup LXC idzie przez PBS albo vzdump (rootfs; bind mounts osobno, jak w artykule o LXC). Backup Dockera to obrazy w rejestrze plus volumes — PBS zrzuci je tylko wtedy, gdy engine stoi w VM albo CT, której rootfs obejmuje te dane. Sama definicja Compose nie zastępuje kopii wolumenów.

HA klastra obejmuje CT i VM. Działającego LXC nie zmigrujesz na żywo — Proxmox robi migrację z restartem. Kontener Docker też nie wędruje na żywo: odtwarzasz go na innym węźle (Compose, Swarm, Kubernetes). Różnica: przy LXC failover jest w ha-managerze Proxmoxa; przy Dockerze w VM failover dotyczy całej maszyny z enginem.

Kiedy Docker, kiedy LXC, kiedy VM

• LXC: długożyjące usługi linuksowe, które traktujesz jak małe serwery — reverse-proxy, DNS, monitoring, wewnętrzne aplikacje, jump host. Jeden panel, PBS, firewall, limity zasobów.
• Docker: obrazy dostawcy, CI, mikrousługi, niezmienne wdrożenia, Compose, przygotowanie pod Kubernetes. Engine trzymaj w VM, gdy izolacja i live migration mają znaczenie.
• VM bez kontenerów: Windows, własne jądro albo moduły, niezaufani najemcy, compliance wymagający separacji na hypervisorze.

W jednym klastrze Proxmox te trzy warstwy współistnieją: LXC na gęste usługi, Docker w VM na stosy aplikacyjne, pełne KVM tam, gdzie jądro albo Windows są nienegocjowalne. Nie wybierasz „platformy kontenerów zamiast Proxmox” — dobierasz narzędzie per obciążenie.