Incus na VPS: konfiguracja kontenerów systemowych

Czym jest kontener systemowy Incus

Kontenery systemowe Incus na serwerze VPS zapewniają pełne środowisko maszyny z własnym systemem init oraz kontami użytkowników, a nie tylko pojedynczy proces z dołączonym systemem plików. Kontener uruchamia się, wykonuje proces init jako PID 1 i odpowiada na systemctl. Współdzieli on jądro systemu z hostem, więc nie jest maszyną wirtualną. Wszystkie warstwy powyżej jądra zachowują się jednak jak w pełnym systemie.

Incus to społecznościowy fork LXD, utrzymywany w ramach projektu Linux Containers. Klientem wiersza poleceń jest incus. Incus pozwala również na uruchamianie pełnych maszyn wirtualnych przez QEMU po przekazaniu flagi --vm, jednak to kontenery systemowe są głównym powodem instalacji tego oprogramowania i to one stanowią przedmiot dalszej części tego przewodnika.

Dlaczego porównania z Docker wprowadzają w błąd

Docker pakuje jeden proces. Incus pakuje jeden system operacyjny. Dokumentacja Incus bezpośrednio wskazuje na ten podział: „Kontenery aplikacji (takie jak na przykład Docker) pakują pojedynczy proces lub aplikację. Kontenery systemowe natomiast symulują pełny system operacyjny, podobny do tego, który uruchamiany jest na hoście lub w maszynie wirtualnej”.

Ta różnica zmienia sposób codziennej pracy z danym rozwiązaniem.

• Obraz Docker nie posiada init, dlatego systemctl wewnątrz niego kończy się niepowodzeniem. Kontener Incus uruchamia system init, dzięki czemu usługi i timery działają tak samo, jak na serwerze.
• Kontener Docker jest przeznaczony do usuwania i ponownego budowania z pliku Dockerfile. Kontener Incus jest przeznaczony do utrzymywania, aktualizowania i tworzenia snapshotów.
• Obraz Docker to artefakt budowania, który wypycha się do rejestru. Instancja Incus to stan na dysku w puli pamięci, który przenosi się za pomocą incus export.
• Docker izoluje obciążenie. Incus izoluje maszynę, dzięki czemu jeden kontener może obsługiwać kilka obciążeń i kilka kont użytkowników.

Można uruchomić Docker wewnątrz kontenera systemowego Incus. Nie należy uruchamiać Incus wewnątrz kontenera aplikacji Docker. Jeśli faktycznie wymagany jest jeden proces na kontener z etapem budowania obrazu, Podman i Docker na VPS jest porównaniem, które należy przeczytać w pierwszej kolejności. Jeśli zamiast współdzielonego jądra wymagane jest oddzielne jądro dla każdego obciążenia, Firecracker microVM na VPS stanowi rozwiązanie w przeciwnym kierunku.

Czy Incus zadziała na VPS?

Zależy to od typu wirtualizacji VPS oraz używanego jądra systemu, dlatego należy sprawdzić oba te parametry przed rozpoczęciem instalacji. Nie należy polegać wyłącznie na informacjach marketingowych dostawcy. Należy wykonać poniższe cztery polecenia na serwerze.

systemd-detect-virt
uname -r
stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers

systemd-detect-virt zwracające kvm lub qemu oznacza, że VPS jest maszyną wirtualną z własnym jądrem. Jest to sytuacja optymalna, ponieważ Incus zachowuje się wtedy tak samo, jak na fizycznym sprzęcie. Wynik lxc, lxc-libvirt lub openvz oznacza, że VPS sam w sobie jest kontenerem współdzielącym jądro dostawcy. Kontenery Incus uruchomione wewnątrz będą kontenerami zagnieżdżonymi, a zagnieżdżanie działa tylko wtedy, gdy dostawca je włączył. Nie można go włączyć z poziomu wnętrza kontenera, ponieważ ustawienie to znajduje się na hoście, do którego użytkownik nie ma uprawnień.

stat -fc %T /sys/fs/cgroup powinno zwrócić cgroup2fs. Każdy inny wynik oznacza, że serwer korzysta z cgroup (control group) w wersji 1 lub układu hybrydowego, które nie są obsługiwane przez obecne wersje Incus.

cat /sys/fs/cgroup/cgroup.controllers wyświetla listę kontrolerów control-group oddelegowanych do użytkownika. Incus wymaga obecności blkio, cpuset, devices, freezer, memory oraz pids. Na zagnieżdżonym VPS lista ta jest często krótsza niż w przypadku KVM, ponieważ dostawca decyduje, które zasoby udostępnić. Brak kontrolera w tym pliku oznacza, że Incus nie może z niego korzystać, przez co ograniczenia instancji zależne od tego kontrolera nie będą dostępne.

Wersja jądra ma obecnie większe znaczenie niż dawniej. Według stanu na sierpień 2026 dokumentacja Incus podaje dwa różne minima dla dwóch gałęzi utrzymywanych przez twórców. Gałąź 6.0 LTS (long term support) wymaga jądra w wersji co najmniej 5.4. Bieżąca stabilna gałąź wymaga jądra w wersji co najmniej 6.12. Ubuntu 24.04 dostarcza serię 6.0 LTS we własnym repozytorium i paruje ją z jądrem 6.8, co stanowi wspieraną kombinację. Instalacja bieżącej stabilnej wersji z repozytorium zewnętrznego na tym samym jądrze 6.8 oznacza zejście poniżej udokumentowanego minimum, dlatego przed wyborem repozytorium należy zapoznać się z uname -r.

Jeśli celem jest uruchamianie pełnych maszyn wirtualnych, a nie kontenerów, ograniczenia są inne i trudniejsze do spełnienia. Zobacz zagnieżdżona wirtualizacja na VPS, aby sprawdzić, czy VPS może w ogóle udostępnić /dev/kvm, oraz Proxmox na wynajętym VPS, jeśli posiadasz własny sprzęt.

Instalacja Incus na systemach Ubuntu lub Debian

Dystrybucje Debian 13 oraz Ubuntu 24.04 i nowsze dostarczają Incus we własnych repozytoriach.

sudo apt update
sudo apt install -y incus

W systemie Debian polecenie incus-base instaluje obsługę kontenerów bez komponentów maszyn wirtualnych. W systemie Ubuntu należy dodać qemu-system, jeśli wymagane są również instancje --vm.

W przypadku potrzeby użycia nowszego wydania niż to dostępne w dystrybucji, oficjalne pakiety znajdują się pod adresem pkgs.zabbly.com. Poniższe polecenia pochodzą z pliku README repozytorium projektu.

sudo apt update && sudo apt install -y curl
sudo mkdir -p /etc/apt/keyrings/
sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
sudo sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-stable.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc
EOF'
sudo apt-get update
sudo apt-get install -y incus

Następnie należy nadać użytkownikowi dostęp do gniazda (socket) demona.

sudo usermod -aG incus-admin "$USER"
newgrp incus-admin
incus info

incus info wyświetlające konfigurację serwera oznacza, że gniazdo działa poprawnie. Błąd uprawnień oznacza, że zmiana grupy nie została jeszcze uwzględniona w bieżącej powłoce, co naprawia newgrp incus-admin dla bieżącej sesji, a poprawne wylogowanie i ponowne zalogowanie rozwiązuje trwale. Członkostwo w grupie incus-admin należy traktować na równi z uprawnieniami root na hoście, ponieważ dostęp do tego gniazda zapewnia pełną kontrolę nad demonem działającym z uprawnieniami root. Niektóre dystrybucje tworzą również grupę incus dla użytkowników z ograniczonym dostępem.

Teraz należy zainicjować demona.

sudo incus admin init

Należy odpowiedzieć na pytania zamiast korzystać z incus admin init --minimal. Minimalna ścieżka wybiera sterownik pamięci dir, a kolejna sekcja wyjaśnia konsekwencje tego wyboru.

Uruchom dowolny obiekt i potwierdź jego działanie.

incus launch images:debian/13 web
incus list
incus exec web -- bash

incus list powinno wyświetlić web jako RUNNING z adresem IPv4 w podsieci incusbr0. Brak adresu oznacza, że protokół DHCP (dynamic host configuration protocol) nie zakończył działania, co opisano w sekcji dotyczącej sieci. Kontener, który nie uruchamia się, wypisuje przyczynę w incus info web --show-log, a błędy na poziomie demona trafiają do sudo journalctl -u incus -n 50. Na serwerze VPS, gdzie systemd-detect-virt zwróciło lxc lub openvz, to uruchomienie jest wiarygodnym testem dostępności zagnieżdżania (nesting).

Dlaczego domyślny backend pamięci masowej ma znaczenie

Backend pamięci masowej decyduje o tym, czy migawka jest natychmiastowa, czy stanowi pełną kopię dysku kontenera. Jest to jedyny wybór dokonywany podczas instalacji, którego nie można później tanio zmienić.

Incus obsługuje dir, btrfs, lvm, zfs, Ceph oraz kilka sterowników zdalnych. Na VPS z pojedynczym dyskiem rzeczywisty wybór ogranicza się do dir oraz btrfs.

Sterownik dir przechowuje każdy kontener jako zwykłe pliki i katalogi w /var/lib/incus. Incus dokumentuje go jako „znacznie wolniejszy od wszystkich pozostałych sterowników”, ponieważ musi on rozpakowywać każdy obraz i tworzyć rzeczywiste kopie zamiast odwoływać się do współdzielonych bloków. Migawka kontenera o rozmiarze 4 GiB zapisuje 4 GiB danych i trwa tyle, ile zajmuje operacja cp -a. Limity dyskowe działają tylko na ext4 lub XFS z włączonymi limitami projektowymi (project quotas) na poziomie systemu plików, co w większości obrazów VPS nie jest domyślnie aktywne, więc limit dysku w puli dir często nie przynosi żadnego efektu.

btrfs oraz zfs wykorzystują mechanizm copy-on-write, dzięki czemu migawka rejestruje tylko bloki, które uległy zmianie po jej utworzeniu. Incus wskazuje te dwa rozwiązania jako zalecane backendy. Migawki stają się niemal natychmiastowe. Limity dyskowe działają w oparciu o natywne wsparcie systemu plików dla kwot.

Większość planów VPS oferuje jeden dysk bez wolnej partycji, dlatego pulę należy umieścić w pliku typu loop. Incus wykonuje to automatycznie, jeśli nie zostanie podany parametr source=.

sudo apt install -y btrfs-progs
incus storage create fast btrfs size=30GiB
incus profile device set default root pool=fast
incus launch images:debian/13 web2 -s fast

Bez size=, pula oparta na pliku loop zajmuje 20% wolnego miejsca na dysku, przy czym wartość ta wynosi minimum 5 GiB i maksimum 30 GiB. Należy ustawić ją świadomie. Plik loop jest plikiem w głównym systemie plików, więc pula i host współdzielą tę samą wolną przestrzeń, co oznacza, że zapełnienie puli powoduje zapełnienie dysku hosta.

ZFS w systemach Debian i Ubuntu jest modułem DKMS, a nie częścią głównego drzewa kernela, dlatego jest przebudowywany przy każdej aktualizacji jądra i może nie zostać poprawnie skompilowany po takiej operacji. Na serwerze, który nie jest monitorowany codziennie, btrfs wymaga mniej czynności konserwacyjnych.

Trzy tryby sieciowe i zakres ich ekspozycji

incus admin init tworzy zarządzany most o nazwie incusbr0 i przypisuje do niego każdą nową instancję. Jest to jeden z trzech sposobów podłączania kontenera; pozostałe dwa istnieją, ponieważ pierwszy ukrywa kontenery za NAT (network address translation).

Zarządzany most (Managed bridge). incusbr0 otrzymuje prywatną podsieć. Host posiada w niej pierwszy adres i pełni rolę bramy, Incus uruchamia na niej DHCP oraz DNS (domain name system), a ruch wychodzący opuszcza sieć przez publiczny adres hosta z zastosowaniem source NAT. Nic z zewnątrz nie dociera do kontenera, dopóki nie zostanie to jawnie skonfigurowane. Przekierowanie portu realizuje się za pomocą urządzenia typu proxy.

incus config device add web http proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80 nat=true

nat=true przekazuje ruch przy użyciu reguł netfilter zamiast pośredniczyć przez oddzielne połączenie w przestrzeni użytkownika, dzięki czemu rzeczywisty adres klienta jest widoczny w logach kontenera. Incus wspiera ten tryb tylko wtedy, gdy host jest bramą dla instancji, co ma miejsce dokładnie w przypadku incusbr0.

macvlan. Kontener otrzymuje własny adres MAC (media access control) w fizycznej sieci hosta. Na większości platform VPS to rozwiązanie nie działa, ponieważ port wirtualnego przełącznika jest powiązany z adresem MAC maszyny wirtualnej i odrzuca ramki pochodzące z innych adresów. Istnieje drugie ograniczenie, które sprawia problemy nawet tam, gdzie rozwiązanie to działa. Incus wskazuje w dokumentacji, że „urządzenia macvlan, mimo że mogą komunikować się między sobą i ze światem zewnętrznym, nie mogą komunikować się z urządzeniem nadrzędnym. Oznacza to, że nie można użyć macvlan, jeśli instancje muszą komunikować się z samym hostem”.

Routed. Jest to tryb, który zazwyczaj działa na VPS z dodatkowymi adresami. Incus opisuje to urządzenie jako takie, które „tworzy parę urządzeń wirtualnych w celu połączenia hosta z instancją oraz konfiguruje statyczne trasy i wpisy proxy ARP/NDP, aby umożliwić instancji dołączenie do sieci wyznaczonego interfejsu nadrzędnego”. ARP to protokół rozstrzygania adresów (address resolution protocol). Kontener zachowuje publiczny adres. Host odpowiada na żądania ARP w jego imieniu, więc dostawca nadal widzi tylko adres MAC hosta.

incus config device add web eth0 nic nictype=routed parent=enp1s0 ipv4.address=203.0.113.20

Pobierz nazwę interfejsu nadrzędnego z ip route show default. Obecne obrazy używają nazw takich jak enp1s0 lub ens3, rzadziej eth0. Nazwanie urządzenia eth0 nadpisuje ustawienia dostarczane przez profil default, dzięki czemu kontener trafia do interfejsu routowanego zamiast do mostu. Sprawdź wynik z wnętrza kontenera za pomocą ip a oraz ip route.

Dlaczego kontener uzyskał dostęp do usługi na hoście

Kontener na incusbr0 posiada własną przestrzeń nazw sieciowych. Nie posiada on granicy firewalla oddzielającej go od hosta. Host znajduje się w tej samej sieci mostkowej pod adresem bramy, więc z wnętrza kontenera host jest bezpośrednio osiągalnym sąsiadem, a każda usługa hosta powiązana z 0.0.0.0 odpowiada na tym adresie.

Można to sprawdzić samodzielnie. Na hoście należy wyświetlić listę nasłuchujących usług.

sudo ss -tlnp

Następnie, z wnętrza kontenera, należy skierować zapytanie do bramy, którą wskazuje ip route.

ip route show default
nc -zv 10.0.0.1 6379

Jeśli baza danych, punkt końcowy metryk lub panel administracyjny na hoście są powiązane z 0.0.0.0, test zakończy się powodzeniem. Sieciowy firewall dostawcy nigdy nie widział tego pakietu, ponieważ pakiet nigdy nie opuścił maszyny. To jest zaskakujący aspekt większości pytań typu „jak to uzyskało dostęp”: kontener jest izolowany od Internetu przez NAT, ale od hosta nie izoluje go nic.

Usługi hosta należy wiązać z 127.0.0.1, gdzie tylko jest to możliwe. Następnie należy przefiltrować mostek na hoście. W systemach z ufw domyślna polityka deny blokuje ruch między kontenerem a hostem, co zakłóca działanie DNS i DHCP w Incus, a rozwiązanie podane w dokumentacji Incus to sudo ufw allow in on incusbr0. To pojedyncze polecenie otwiera każdy port hosta dla każdego kontenera. Zamiast tego należy zezwolić tylko na to, czego kontenery faktycznie potrzebują.

sudo ufw allow in on incusbr0 to any port 53 proto udp
sudo ufw allow in on incusbr0 to any port 53 proto tcp
sudo ufw allow in on incusbr0 to any port 67 proto udp
sudo ufw route allow in on incusbr0
sudo ufw route allow out on incusbr0

Dwie reguły ufw route pozwalają na przesyłanie ruchu instancji przez hosta do Internetu. Bez nich polityka routed w ufw odrzuca przekazywane pakiety, przez co kontenery otrzymują adres, ale nie mają łączności z niczym.

Migawki i profile

Migawka to kopia instancji wewnątrz puli pamięci masowej wykonana w określonym punkcie czasowym.

incus snapshot create web pre-upgrade
incus info web
incus snapshot restore web pre-upgrade
incus snapshot delete web pre-upgrade

incus info web wyświetla listę migawek posiadanych przez instancję. Harmonogramy migawek definiuje się dla każdej instancji z osobna.

incus config set web snapshots.schedule=@daily
incus config set web snapshots.expiry=4w

Migawka znajduje się w tej samej puli, na tym samym dysku i na tym samym serwerze. Chroni ona przed skutkami nieudanej aktualizacji. Nie zapewnia ochrony w przypadku awarii dysku lub usunięcia instancji. Kopia zapasowa to incus export, a plik musi zostać przeniesiony poza serwer.

incus export web /root/web-backup.tar.gz
incus import /root/web-backup.tar.gz

Profil to nazwany zestaw kluczy konfiguracyjnych i urządzeń stosowany do instancji. Każda instancja otrzymuje profil default, chyba że określono inaczej; to właśnie ten profil dostarcza dysk główny oraz interfejs sieciowy. Edycja default zmienia każdą instancję, która z niego korzysta, co jest przydatne i pozwala na przykład na jednoczesne odłączenie sieci od dwudziestu kontenerów.

incus profile create small
incus profile set small limits.memory=512MiB
incus profile set small limits.cpu=1
incus launch images:debian/13 api -p default -p small

Profile są stosowane w określonej kolejności, więc klucz ustawiony w ostatnim wymienionym profilu ma pierwszeństwo. Aby sprawdzić, jakie ustawienia ostatecznie otrzymała instancja, należy użyć incus config show api --expanded.

Uruchamianie Docker wewnątrz kontenera Incus

Uruchomienie Docker wewnątrz kontenera systemowego Incus wymaga włączenia funkcji nesting, ponieważ Docker tworzy własne przestrzenie nazw (namespaces) oraz punkty montowania, których kontener domyślnie nie może tworzyć.

incus config set web security.nesting=true
incus restart web

Dokumentacja Incus określa security.nesting jako „czy zezwolić na zagnieżdżanie wewnątrz instancji”, a domyślną wartością dla kontenerów jest false. Dwie dodatkowe kwestie wynikają bezpośrednio z FAQ Incus. Kontener nie może ładować modułów jądra, więc moduł wymagany przez Docker musi zostać załadowany na hoście i wymieniony w incus config set web linux.kernel_modules overlay,br_netfilter. Ponadto utworzenie pliku /.dockerenv wewnątrz kontenera sprawia, że Docker pomija niektóre testy, które kończą się niepowodzeniem w środowisku zagnieżdżonym.

Na hostach z systemem Ubuntu 24.04 ograniczenia AppArmor dotyczące nieuprzywilejowanych przestrzeni nazw użytkownika mogą blokować operację pivot_root, którą wykonuje runc. Docker wewnątrz kontenera wyświetla komunikat:

failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error jailing process inside rootfs: pivot_root .: permission denied

a plik dmesg na hoście zawiera linię z apparmor="DENIED" operation="pivotroot" class="mount". Ustawieniem, po które sięgają użytkownicy, jest kernel.apparmor_restrict_unprivileged_userns. Wyłączenie go nie jest niezawodnym rozwiązaniem: oficjalny raport o błędzie Incus dotyczący tej konkretnej odmowy wskazuje, że ustawienie wartości 0 nie rozwiązało problemu. Najpierw należy zapoznać się z dmesg dotyczącym odmowy, aby upewnić się, czy AppArmor rzeczywiście stanowi przyczynę problemu, zanim nastąpi zmiana domyślnych ustawień bezpieczeństwa.

Jeśli preferowane jest uruchamianie kontenerów bezpośrednio na VPS z pominięciem dodatkowej warstwy, sekcja uruchamianie Docker na VPS opisuje taką konfigurację.

Tryby awarii i towarzyszące im komunikaty

Instancje tracą łączność sieciową po zainstalowaniu Docker na hoście. Dokumentacja Incus wskazuje przyczynę: "Docker ustawia globalną politykę FORWARD na drop, co uniemożliwia Incus przekazywanie ruchu i powoduje utratę łączności sieciowej przez instancje". Instancje zachowują swoje adresy, ale nie mogą nawiązać połączenia z żadnym zasobem. Należy ustawić ip-forward-no-drop na true w pliku /etc/docker/daemon.json, a następnie zapewnić trwałość przekazywania pakietów i zezwolić na ruch przez łańcuch Docker.

echo "net.ipv4.conf.all.forwarding=1" | sudo tee /etc/sysctl.d/99-forwarding.conf
sudo systemctl restart systemd-sysctl
sudo iptables -I DOCKER-USER -i incusbr0 -j ACCEPT
sudo iptables -I DOCKER-USER -o incusbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Reguły iptables nie są automatycznie przywracane po restarcie systemu. Należy zapewnić ich trwałość.

Kontenery przestają się uruchamiać z błędem cgroup. Problem ten opisano w FAQ Incus. Komunikat dotyczący Failed to mount "/sys/fs/cgroup" zazwyczaj oznacza, że klient VPN na hoście zamontował kontroler cgroup v1 net_cls w miejsce cgroup v2, z którego korzysta Incus. Polecenie sudo umount /sys/fs/cgroup/net_cls rozwiązuje ten problem.

Instancja nie otrzymuje adresu IPv4. Polecenie incus list wskazuje, że instancja działa, ale kolumna adresu jest pusta. Odpowiedzi DHCP z hosta są odrzucane, najczęściej przez zaporę sieciową hosta, która nie rozpoznaje mostka. W przypadku ufw, polecenie sudo ufw allow in on incusbr0 to any port 67 proto udp przywraca łączność. Należy monitorować napływające żądania za pomocą sudo tcpdump -ni incusbr0 port 67.

Instancja odmawia uruchomienia na zagnieżdżonym VPS. Należy najpierw zapoznać się z incus info <name> --show-log, a następnie z sudo journalctl -u incus -n 50. Jeśli systemd-detect-virt zwróciło lxc lub openvz, brakujący element znajduje się po stronie dostawcy i żadne ustawienie wewnątrz VPS nie zmieni tej sytuacji.

Migawki działają wolno, a dysk zapełnia się. Używany jest zasób dir. Polecenie incus storage list wyświetla sterownik dla każdego zasobu. Przejście na zasób typu copy-on-write wymaga utworzenia nowego zasobu, skopiowania instancji za pomocą incus copy web web-new -s fast, a następnie usunięcia oryginałów po zweryfikowaniu, że kopie uruchamiają się poprawnie.

FAQ

Czy kontener Incus to to samo co kontener Docker?

Nie. Docker pakuje pojedynczy proces lub aplikację. Kontener systemowy Incus symuluje pełny system operacyjny z własnym procesem init, użytkownikami, usługami i menedżerem pakietów. Kontener Incus utrzymuje się i aktualizuje jak serwer. Kontener Docker usuwa się i buduje ponownie z obrazu. Można uruchomić Docker wewnątrz kontenera Incus, ustawiając security.nesting=true dla danego kontenera. Odwrotna konfiguracja nie działa.

Czy mogę uruchomić Incus na VPS?

Na VPS typu KVM – tak. Jeśli systemd-detect-virt zwraca kvm lub qemu, posiadasz własne jądro, a Incus zachowuje się tak samo jak na sprzęcie fizycznym. Jeśli zwraca lxc, lxc-libvirt lub openvz, Twój VPS sam jest kontenerem, więc kontenery Incus wewnątrz niego są zagnieżdżone i działają tylko wtedy, gdy dostawca włączył obsługę zagnieżdżania. Sprawdź również uname -r, ponieważ w sierpniu 2026 roku stabilna gałąź Incus wymaga jądra w wersji co najmniej 6.12, podczas gdy gałąź 6.0 LTS wymaga 5.4.

Który backend pamięci masowej wybrać dla Incus na VPS?

btrfs na pliku pętli (loop file), chyba że masz do dyspozycji wolne urządzenie blokowe. Sterownik dir jest znacznie wolniejszy od pozostałych, ponieważ kopiuje pliki zamiast korzystać z mechanizmu copy-on-write, co powoduje, że każdy snapshot zapisuje cały kontener od nowa. incus admin init --minimal wybiera dir, dlatego warto poświęcić dwie minuty na odpowiedzenie na pytania w trybie interaktywnym. Utwórz pulę za pomocą incus storage create fast btrfs size=30GiB.

Dlaczego mój kontener Incus ma dostęp do usługi działającej na hoście?

Ponieważ domyślny most incusbr0 umieszcza hosta w tej samej podsieci co kontener, pod adresem bramy, a ruch między nimi nie jest filtrowany. Każda usługa hosta powiązana z 0.0.0.0 odpowiada na żądania, a firewall dostawcy nigdy nie widzi tych pakietów, ponieważ nie opuszczają one maszyny. Powiąż usługi hosta z 127.0.0.1, a na hoście z ufw zezwól tylko na DNS i DHCP na incusbr0 zamiast stosować ogólne sudo ufw allow in on incusbr0.

Jak wykonać kopię zapasową kontenera Incus?

incus export web /root/web-backup.tar.gz zapisuje instancję wraz ze snapshotami do jednego pliku, a incus import przywraca ją na tym samym lub innym serwerze. Snapshoty wykonane za pomocą incus snapshot create nie są kopiami zapasowymi: znajdują się w tej samej puli pamięci na tym samym dysku, więc chronią przed nieudaną aktualizacją, ale nie przed awarią serwera. Zaplanuj je za pomocą incus config set web snapshots.schedule=@daily i kopiuj wyeksportowane pliki poza maszynę.