Menu
Szybki wybór
Hosting Domeny VPS SSL Kalkulator Porównania FAQ
Aktywne kody
Wszystkie kody rabatowe

LXC — kontenery systemowe Linux na VPS

Opublikowano: 9 kwietnia 2026 · Kategoria: VPS / Virtualization

Zanim Docker zdominował świat kontenerów, istniał LXC (Linux Containers) — pierwsza produkcyjna implementacja kontenerów w mainline kernelu. LXC nadal żyje i ma się dobrze, szczególnie tam gdzie Docker nie pasuje: jako lekki zamiennik maszyny wirtualnej. Jeden VPS z 4 GB RAM obsłuży 10-15 kontenerów LXC, każdy z własnym init, sshd i usługami.

LXC vs Docker vs VM — kiedy którego użyć

Feature LXC Docker KVM/VM
Typ System container App container Full virtualization
Kernel Współdzielony z hostem Współdzielony z hostem Własny
Init system Tak (systemd/init) Nie (1 proces) Tak
Overhead RAM 5-20 MB 2-10 MB 100-500 MB
Boot time 1-3 s < 1 s 10-30 s
Use case VPS-like, sshd, cron Stateless apps, CI/CD Inny OS, hard isolation

Instalacja LXC

Na Ubuntu/Debian pakiet lxc dostarcza wszystko: runtime, templates i narzędzia. Sprawdź najpierw, czy kernel ma włączone wymagane funkcje:

# Instalacja (Ubuntu 22.04+)
sudo apt update
sudo apt install -y lxc lxc-templates bridge-utils

# Sprawdź czy kernel wspiera LXC
sudo lxc-checkconfig
# Szukaj wszystkich "enabled" - jeśli są "missing", kontenery nie wystartują

# Status usługi
sudo systemctl status lxc-net
sudo systemctl enable --now lxc-net

# Bridge sieciowy lxcbr0 powinien być aktywny
ip addr show lxcbr0
# 10.0.3.1/24 - domyślna sieć LXC z NAT do świata

Tworzenie pierwszego kontenera

# Lista dostępnych templates
sudo lxc-create --template download --name temp -- --list
# Pokaże Debian, Ubuntu, Alpine, CentOS, Fedora, Rocky...

# Stwórz kontener Debian 12 (bookworm)
sudo lxc-create -n web1 -t download -- \
  --dist debian --release bookworm --arch amd64

# Kontener stworzony w /var/lib/lxc/web1/
# rootfs/ - system plików
# config  - konfiguracja (sieć, mounty, limity)

# Start w tle
sudo lxc-start -n web1

# Status
sudo lxc-ls --fancy
# NAME STATE   AUTOSTART GROUPS IPV4       IPV6
# web1 RUNNING 0         -      10.0.3.42  -

# Wejdź do kontenera (attach)
sudo lxc-attach -n web1

# Teraz jesteś rootem w kontenerze
apt update && apt install -y nginx
systemctl enable --now nginx
exit

# Sprawdź z zewnątrz
curl http://10.0.3.42/

Konfiguracja sieci — bridge vs NAT vs macvlan

LXC oferuje kilka trybów sieciowych, każdy z innym zastosowaniem. Wybierasz w pliku /var/lib/lxc/NAZWA/config:

# NAT przez lxcbr0 (domyślne, najprostsze)
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx

# Bridge z publicznym IP hosta (br0 musi być skonfigurowany na hoście)
lxc.net.0.type = veth
lxc.net.0.link = br0
lxc.net.0.flags = up
lxc.net.0.ipv4.address = 203.0.113.50/24
lxc.net.0.ipv4.gateway = 203.0.113.1

# Macvlan - kontener dostaje własny MAC i jest "widoczny" w LAN
lxc.net.0.type = macvlan
lxc.net.0.link = eth0
lxc.net.0.macvlan.mode = bridge
lxc.net.0.flags = up

# Brak sieci (isolated)
lxc.net.0.type = none

Żeby przekierować port z hosta do kontenera (np. 8080 -> 10.0.3.42:80), użyj iptables na hoście:

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 \
  -j DNAT --to-destination 10.0.3.42:80
sudo iptables -A FORWARD -p tcp -d 10.0.3.42 --dport 80 -j ACCEPT
sudo iptables-save | sudo tee /etc/iptables/rules.v4

Limity zasobów (cgroups v2)

Bez limitów kontener może zjeść cały RAM i zabić hosta. LXC korzysta z cgroups kernela — limity ustawiasz w pliku config i działają po restarcie kontenera:

# RAM max 512 MB
lxc.cgroup2.memory.max = 536870912

# Swap max 256 MB (total memory + swap)
lxc.cgroup2.memory.swap.max = 268435456

# CPU - 50% jednego rdzenia (50000 z 100000 quota)
lxc.cgroup2.cpu.max = 50000 100000

# Tylko CPU 0 i 1
lxc.cgroup2.cpuset.cpus = 0-1

# IO weight (priorytet dyskowy, 100 = default)
lxc.cgroup2.io.weight = 200

# Po zmianach
sudo lxc-stop -n web1
sudo lxc-start -n web1

# Weryfikacja limitu RAM z kontenera
sudo lxc-attach -n web1 -- cat /sys/fs/cgroup/memory.max

Snapshoty i klonowanie

LXC obsługuje snapshoty — przydatne przed ryzykownym update albo do szybkiego klonowania szablonu. Na backendzie dir snapshoty są kopiami katalogów, na btrfs/zfs używają copy-on-write.

# Snapshot przed update
sudo lxc-snapshot -n web1 -c "przed-upgrade-nginx"

# Lista snapshotów
sudo lxc-snapshot -n web1 -L
# snap0 (przed-upgrade-nginx) 2026-04-09 10:23:45

# Restore gdyby coś poszło nie tak
sudo lxc-stop -n web1
sudo lxc-snapshot -n web1 -r snap0

# Klonowanie (overlayfs = kopia w sekundę)
sudo lxc-copy -n web1 -N web2 -B overlayfs --snapshot
sudo lxc-start -n web2

# Autostart przy boot hosta
# W config:
lxc.start.auto = 1
lxc.start.delay = 5
lxc.start.order = 10

Best practices

  • Unprivileged containers dla multi-tenant — jeśli dajesz komuś roota, używaj user namespace mapping. Root w kontenerze = UID 100000 na hoście.
  • Backup rootfs + configtar lub rsync na /var/lib/lxc/NAZWA. Snapshoty to nie backup — żyją na tym samym dysku.
  • Monitorowanie przez host — zainstaluj Prometheus node_exporter na hoście, nie w każdym kontenerze. Metryki cgroups są widoczne z hosta.
  • Nie instaluj Dockera w LXC (unless nested) — Docker w kontenerze LXC wymaga privileged mode i otwiera podatności. Użyj Podmana albo osobnego VPS.
  • Rozważ LXD zamiast czystego LXC — LXD (teraz Incus) to bardziej user-friendly wrapper nad LXC: API, REST, live migration, storage pools, projekty.

Uwaga: Canonical przeniosło LXD pod licencję CLA w 2023. Upstream społeczność stworzyła fork Incus (Linux Containers). Nowe projekty warto rozpoczynać od Incus — jest w Debian/Ubuntu oficjalnych repo od 2024.

Najczęstsze pytania

Czym różnią się LXC od Dockera? +
LXC to kontener "system" — uruchamia pełny system operacyjny (init, systemd, cron, sshd), działa jak lekki VPS. Docker to kontener "aplikacji" — jeden proces, jedno zadanie, immutable image. LXC pasuje do sytuacji gdzie potrzebujesz maszyny podobnej do VPS (instalujesz pakiety, konfigurujesz usługi, SSH). Docker pasuje do aplikacji 12-factor (deploy przez image, stateless, CI/CD). Na tym samym kernelu mogą działać jednocześnie — LXC dla długo żyjących usług, Docker dla deploymentu apek.
Czy mogę uruchomić LXC na VPS? +
Zależy od wirtualizacji. Na KVM tak — masz pełny kernel i możesz uruchamiać kontenery. Na OpenVZ/Virtuozzo zazwyczaj nie (są już zagnieżdżone i host blokuje cgroups). Contabo, Hetzner, OVH, DigitalOcean używają KVM — LXC działa. Mikrus (OpenVZ 7) — teoretycznie działa nested, ale z ograniczeniami. Najlepiej sprawdzić przez sudo lxc-checkconfig i komendę lsmod | grep kvm przed zakupem.
Jak ograniczyć RAM i CPU dla kontenera LXC? +
LXC używa cgroups Linuxa. W pliku /var/lib/lxc/NAZWA/config dodaj: lxc.cgroup2.memory.max = 512M (max 512 MB RAM), lxc.cgroup2.cpu.max = 50000 100000 (50% jednego rdzenia), lxc.cgroup2.cpuset.cpus = 0-1 (tylko CPU 0 i 1). Po restarcie kontenera limity są aktywne. Oversubscription (więcej RAM przydzielonego niż fizycznego) działa — LXC używa swap jeśli host ma.
Czy LXC jest bezpieczny dla untrusted workloads? +
Domyślne LXC (privileged containers) NIE są bezpieczne dla nieufnych użytkowników — root w kontenerze = root na hoście przy błędzie kernela. Dla multi-tenant używaj unprivileged containers (UID mapping — root w kontenerze to unprivileged user na hoście) + AppArmor/SELinux + seccomp. Alternatywa: LXD z ISO-mode albo Firecracker/Kata Containers (microVM). Jeśli nie musisz dawać roota użytkownikom — zostań przy Dockerze z userns-remap.

Sprawdź oferty pasujące do tego scenariusza

Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.