Incus systeemcontainers installeren op een VPS

Wat een Incus-systeemcontainer is

Incus-systeemcontainers op een VPS bieden u een volledige machine met een eigen init-systeem en eigen gebruikersaccounts, in plaats van slechts één proces met een gekoppeld bestandssysteem. De container start op, voert een init uit als PID 1 en reageert op systemctl. Omdat de container de kernel van de host deelt, is het geen virtuele machine. Alles boven de kernel gedraagt zich echter als een volwaardige machine.

Incus is de community-fork van LXD, onderhouden door het Linux Containers-project. Het client-commando is incus. Het kan ook echte virtuele machines draaien via QEMU wanneer u --vm meegeeft, maar de systeemcontainer is de reden waarom de meeste mensen het installeren, en dit is waar de rest van deze handleiding over gaat.

Waarom vergelijkingen met Docker misleidend zijn

Docker verpakt één proces. Incus verpakt één besturingssysteem. De documentatie van Incus verwoordt dit onderscheid direct: "Applicatiecontainers (zoals aangeboden door bijvoorbeeld Docker) verpakken een enkel proces of applicatie. Systeemcontainers daarentegen simuleren een volledig besturingssysteem, vergelijkbaar met wat u op een host of in een virtuele machine zou draaien."

Dat verschil verandert hoe u dagelijks met deze technologieën omgaat.

• Een Docker-image bevat geen init-systeem, waardoor systemctl binnenin niet werkt. Een Incus-container draait een init-systeem, waardoor services en timers werken zoals op een server.
• Een Docker-container is bedoeld om te worden vernietigd en opnieuw opgebouwd vanuit een Dockerfile. Een Incus-container is bedoeld om te worden behouden, gepatcht en voorzien van snapshots.
• Een Docker-image is een build-artefact dat u naar een registry pusht. Een Incus-instantie is een toestand op schijf in een storage pool, die u verplaatst met incus export.
• Docker isoleert een workload. Incus isoleert een machine, waardoor één container meerdere workloads en meerdere gebruikersaccounts kan bevatten.

U kunt Docker draaien binnen een Incus-systeemcontainer. U zult Incus niet draaien binnen een Docker-applicatiecontainer. Als u daadwerkelijk één proces per container met een image-buildstap wenst, is Podman en Docker op een VPS de vergelijking die u eerst moet lezen. Als u een aparte kernel per workload wilt in plaats van een gedeelde kernel, gaat Firecracker microVMs op een VPS de andere kant op.

Kan Incus draaien binnen een VPS?

Dit hangt af van het virtualisatietype en de kernel van uw VPS; controleer beide voordat u iets installeert. Vertrouw hiervoor niet op de marketingpagina van een provider. Voer deze vier commando's uit op de server.

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

systemd-detect-virt printen kvm of qemu betekent dat uw VPS een virtuele machine is met een eigen kernel. Dit is de eenvoudige situatie, omdat Incus zich dan gedraagt zoals op fysieke hardware. Het printen van lxc, lxc-libvirt of openvz betekent dat uw VPS zelf een container is die de kernel van de provider deelt. Incus-containers daarbinnen zijn geneste containers, en nesting werkt alleen als de provider dit heeft ingeschakeld voor uw container. U kunt dit niet zelf inschakelen vanuit de container, omdat de instelling op de host staat waar u geen controle over heeft.

stat -fc %T /sys/fs/cgroup hoort cgroup2fs te printen. Iets anders betekent dat de server een cgroup (control group) v1- of hybride-indeling gebruikt, wat door de huidige versie van Incus niet wordt ondersteund.

cat /sys/fs/cgroup/cgroup.controllers somt de control-group-controllers op die aan u zijn gedelegeerd. Incus documenteert blkio, cpuset, devices, freezer, memory en pids als vereisten. Op een geneste VPS is die lijst vaak korter dan op een KVM-VPS, omdat de provider bepaalt wat er wordt doorgegeven. Een controller die ontbreekt in dat bestand is een controller die Incus niet kan gebruiken; de instantielimiet die daarvan afhankelijk is, is dan niet voor u beschikbaar.

De kernelversie is belangrijker dan voorheen. Sinds augustus 2026 hanteert de Incus-documentatie twee verschillende minima voor de twee branches die upstream worden onderhouden. De 6.0 LTS-branch (long term support) stelt: "De minimaal ondersteunde kernelversie is 5.4." De huidige stabiele branch stelt: "De minimaal ondersteunde kernelversie is 6.12." Ubuntu 24.04 verpakt de 6.0 LTS-serie in zijn eigen repository en koppelt deze aan een 6.8-kernel, wat een ondersteunde combinatie is. Het installeren van de huidige stabiele build vanuit de upstream-repository op diezelfde 6.8-kernel brengt u onder het gedocumenteerde minimum, dus lees uname -r voordat u een repository kiest.

Als uw doel volledige virtuele machines zijn in plaats van containers, is de beperking anders en lastiger. Zie nested virtualisation on a VPS om te bepalen of uw VPS überhaupt /dev/kvm kan aanbieden, en Proxmox against a rented VPS voor het geval dat u de hardware in eigen beheer heeft.

Incus installeren op Ubuntu of Debian

Debian 13 en Ubuntu 24.04 en nieuwer leveren Incus in hun eigen repositories.

sudo apt update
sudo apt install -y incus

Op Debian installeert incus-base containerondersteuning zonder de onderdelen voor virtuele machines. Voeg op Ubuntu qemu-system toe als u ook --vm-instances wilt gebruiken.

Voor een nieuwere release dan uw distributie aanbiedt, bevinden de upstream-pakketten zich op pkgs.zabbly.com. Deze commando's zijn afkomstig uit de README van de repository van het project zelf.

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

Geef vervolgens uw gebruiker toegang tot de daemon-socket.

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

incus info die de configuratie van de server afdrukt, betekent dat de socket werkt. Een toegangs- of permissiefout betekent dat de groepswijziging uw shell nog niet heeft bereikt, wat newgrp incus-admin voor de huidige shell oplost en een nieuwe aanmelding definitief herstelt. Beschouw het lidmaatschap van incus-admin als gelijk aan root op de host, aangezien toegang tot die socket volledige controle geeft over een daemon die als root draait. Sommige distributies maken ook een standaard incus-groep aan voor beperkte gebruikerstoegang.

Initialiseer nu de daemon.

sudo incus admin init

Beantwoord de vragen in plaats van te grijpen naar incus admin init --minimal. Het minimale pad kiest de dir-storage driver, en de volgende sectie gaat over waarom die keuze u blijft achtervolgen.

Start iets op en bevestig dat het werkt.

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

incus list zou web moeten tonen als RUNNING met een IPv4-adres op het incusbr0-subnet. Geen adres betekent dat DHCP (dynamic host configuration protocol) niet is voltooid, wat in de netwerksectie wordt behandeld. Een container die niet start, print de reden in incus info web --show-log, en fouten op daemon-niveau komen terecht in sudo journalctl -u incus -n 50. Op een VPS waar systemd-detect-virt de waarde lxc of openvz teruggaf, is deze start de eerlijke test of nesting voor u beschikbaar is.

Waarom de standaard storage backend belangrijk is

De storage backend bepaalt of een snapshot direct wordt aangemaakt of dat het een volledige kopie van de schijf van de container betreft. Dit is de enige keuze tijdens de installatie die u achteraf niet eenvoudig kunt wijzigen.

Incus ondersteunt dir, btrfs, lvm, zfs, Ceph en diverse externe drivers. Op een VPS met één schijf is de feitelijke keuze tussen dir en btrfs.

De dir-driver bewaart elke container als gewone bestanden en mappen onder /var/lib/incus. Incus documenteert dit als "veel trager dan alle andere drivers", omdat het elke image moet uitpakken en daadwerkelijke kopieën moet maken in plaats van te verwijzen naar gedeelde blokken. Een snapshot van een container van 4 GiB schrijft 4 GiB weg en duurt net zo lang als cp -a. Schijfquota werken alleen op ext4 of XFS met projectquota ingeschakeld op bestandssysteemniveau; dit is op de meeste VPS-images niet standaard ingeschakeld, waardoor een schijflimiet op een dir-pool vaak geen effect heeft.

btrfs en zfs zijn copy-on-write, waardoor een snapshot alleen de blokken vastlegt die na het moment van de snapshot wijzigen. Incus beveelt deze twee aan als de aanbevolen backends. Snapshots zijn hierdoor vrijwel direct. Schijfquota werken via de eigen quota-ondersteuning van het bestandssysteem.

De meeste VPS-abonnementen bieden één schijf zonder vrije partitie, dus plaats de pool in een loop-bestand. Incus doet dit automatisch voor u wanneer u geen source= opgeeft.

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

Zonder size= neemt een loop-backed pool 20% van de vrije schijfruimte in beslag, met een ondergrens van 5 GiB en een bovengrens van 30 GiB. Stel dit bewust in. Het loop-bestand is een bestand op uw root-bestandssysteem, waardoor de pool en de host dezelfde vrije ruimte delen. Dit betekent dat het vullen van de pool ook de schijf van de host vult.

ZFS op Debian en Ubuntu is een DKMS-module in plaats van een in-tree module. Hierdoor wordt deze bij elke kernel-upgrade opnieuw gebouwd en kan het bouwen na een upgrade mislukken. Op een server die u niet dagelijks controleert, is btrfs de optie met het minste onderhoud van de twee.

De drie netwerkmodi en wat ze elk blootstellen

incus admin init maakt een beheerde bridge genaamd incusbr0 aan en plaatst elke nieuwe instantie hierop. Dit is een van de drie manieren om een container te koppelen; de andere twee bestaan omdat de eerste methode uw containers verbergt achter NAT (network address translation).

Managed bridge. incusbr0 krijgt een privaat subnet. De host bezit het eerste adres hiervan en fungeert als gateway; Incus draait hierop DHCP en DNS (domain name system), en uitgaand verkeer verlaat het netwerk via het publieke adres van de host met source NAT toegepast. Niets van buitenaf bereikt de container tenzij u dit instelt. Forward een poort met een proxy-device.

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 forwardt met netfilter-regels in plaats van via een aparte userspace-verbinding te proxien, waardoor het werkelijke adres van de client behouden blijft in de logs van de container. Incus ondersteunt deze modus alleen wanneer de host de gateway van de instantie is, wat precies het geval is bij incusbr0.

macvlan. De container krijgt zijn eigen MAC (media access control)-adres op het fysieke netwerk van de host. Op de meeste VPS-platformen mislukt dit, omdat de poort van de virtuele switch is gebonden aan het MAC-adres van uw VM en frames van andere adressen blokkeert. Er is een tweede beperking die gebruikers treft, zelfs waar het wel werkt. Incus documenteert dat "macvlan-devices, hoewel ze onderling en met de buitenwereld kunnen communiceren, niet kunnen praten met hun parent-device. Dit betekent dat u macvlan niet kunt gebruiken als uw instanties ooit met de host zelf moeten communiceren."

Routed. Dit is de modus die meestal werkt op een VPS met extra adressen. Incus documenteert dit device als een type dat "een virtueel device-paar aanmaakt om de host met de instantie te verbinden en statische routes en proxy ARP/NDP-entries instelt om de instantie toe te staan deel uit te maken van het netwerk van een aangewezen parent-interface". ARP is het address resolution protocol. De container behoudt een publiek adres. De host beantwoordt ARP-verzoeken hiervoor, zodat de provider nog steeds alleen het MAC-adres van de host ziet.

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

Haal de naam van de parent-interface uit ip route show default. Huidige images gebruiken namen zoals enp1s0 of ens3, zelden eth0. Door het device eth0 te noemen, overschrijft u de instelling die het default-profiel levert, waardoor de container op de routed-interface terechtkomt in plaats van op de bridge. Controleer het resultaat van binnenuit met ip a en ip route.

Waarom een container een service op de host bereikte

Een container op incusbr0 heeft een eigen netwerk-namespace. Deze heeft geen firewall-grens ten opzichte van de host. De host bevindt zich op die bridge op het gateway-adres; vanuit de container gezien is de host dus een direct bereikbare buur. Elke host-service die gebonden is aan 0.0.0.0 reageert daarop.

Controleer dit zelf. Bekijk op de host wat er luistert.

sudo ss -tlnp

Richt u vervolgens vanuit een container op de gateway die ip route rapporteert.

ip route show default
nc -zv 10.0.0.1 6379

Als een database, een metrics-endpoint of een admin-paneel op de host gebonden is aan 0.0.0.0, dan slaagt die controle. De netwerkfirewall van uw provider heeft het pakket nooit gezien, omdat het pakket de machine nooit heeft verlaten. Dit is de verrassing achter de meeste vragen over "hoe heeft het dat bereikt": de container is door NAT geïsoleerd van het internet, maar is op geen enkele wijze geïsoleerd van de host.

Bind host-services waar mogelijk aan 127.0.0.1. Filter vervolgens de bridge op de host. Op een systeem met ufw blokkeert het standaard 'deny'-beleid al het verkeer van container naar host. Dit verstoort Incus DNS en DHCP, en de oplossing die de Incus-documentatie biedt is sudo ufw allow in on incusbr0. Dat ene commando stelt elke host-poort weer open voor elke container. Sta in plaats daarvan alleen toe wat containers daadwerkelijk nodig hebben.

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

De twee ufw route-regels zorgen ervoor dat verkeer van instances via de host naar het internet kan gaan. Zonder deze regels laat het 'routed'-beleid van ufw doorgestuurde pakketten vallen, waardoor containers wel een adres krijgen, maar niets kunnen bereiken.

Snapshots en profielen

Een snapshot is een kopie van de instance op een specifiek tijdstip binnen de storage pool.

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

incus info web toont de snapshots die de instance bevat. Plan deze per instance in.

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

Een snapshot bevindt zich in dezelfde pool, op dezelfde schijf en op dezelfde server. Het beschermt u tegen een mislukte upgrade. Het biedt geen bescherming tegen een defecte schijf of een verwijderde instance. De back-up is incus export en het bestand moet de server verlaten.

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

Een profiel is een benoemde set configuratiesleutels en apparaten die op instances worden toegepast. Elke instance krijgt het default-profiel, tenzij u anders aangeeft; dit profiel levert de root-schijf en de netwerkinterface. Het bewerken van default wijzigt elke instance die dit profiel gebruikt. Dit is nuttig en is tevens de manier waarop men het netwerk van twintig containers tegelijk loskoppelt.

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

Profielen worden in volgorde toegepast, waardoor een sleutel die in het laatst vermelde profiel is ingesteld, voorrang krijgt. Lees met incus config show api --expanded wat de uiteindelijke configuratie van een instance is geworden.

Docker draaien binnen een Incus-container

Docker binnen een Incus-systeemcontainer vereist dat nesting is ingeschakeld. Docker maakt namelijk eigen namespaces en mounts aan die een container standaard niet mag aanmaken.

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

Incus documenteert security.nesting als "Of nesting binnen de instantie is toegestaan", en dit staat standaard op false voor containers. Twee extra punten komen rechtstreeks uit de Incus FAQ. Een container kan geen kernelmodules laden, dus een module die Docker nodig heeft, moet op de host worden geladen en worden vermeld bij incus config set web linux.kernel_modules overlay,br_netfilter. Daarnaast zorgt het aanmaken van een /.dockerenv-bestand in de container ervoor dat Docker enkele controles overslaat die in een geneste omgeving falen.

Op Ubuntu 24.04-hosts kunnen de beperkingen van AppArmor voor niet-geprivilegieerde gebruikers-namespaces de pivot_root blokkeren die runc uitvoert. Docker in de container geeft de volgende melding:

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

en de dmesg van de host toont een regel met apparmor="DENIED" operation="pivotroot" class="mount". De instelling waar vaak naar wordt gegrepen is kernel.apparmor_restrict_unprivileged_userns. Deze uitschakelen is geen betrouwbare oplossing: het upstream Incus-bugrapport voor deze specifieke weigering vermeldt dat het instellen op 0 het probleem niet verhielp. Lees eerst dmesg voor de weigering, zodat u weet of AppArmor daadwerkelijk het probleem is voordat u een beveiligingsinstelling wijzigt.

Als u liever containers rechtstreeks op de VPS draait en een laag overslaat, behandelt Docker draaien op een VPS die configuratie afzonderlijk.

Foutmodi en bijbehorende meldingen

Instances verliezen alle netwerkverbinding na installatie van Docker op de host. De Incus-documentatie benoemt de oorzaak: "Docker stelt het globale FORWARD-beleid in op drop, wat voorkomt dat Incus verkeer doorstuurt, waardoor de instances hun netwerkverbinding verliezen." Instances behouden hun adressen, maar bereiken niets. Stel ip-forward-no-drop in op true in /etc/docker/daemon.json, maak het doorsturen persistent en laat het verkeer door de eigen chain van Docker toe.

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

Deze iptables-regels blijven na een herstart niet uit zichzelf behouden. Maak ze persistent.

Containers starten niet meer door een cgroup-fout. De Incus FAQ documenteert dit probleem. Een melding over Failed to mount "/sys/fs/cgroup" betekent meestal dat een VPN-client op de host de net_cls cgroup v1-controller heeft gemount over cgroup v2, die Incus gebruikt. sudo umount /sys/fs/cgroup/net_cls lost dit op.

Instance krijgt geen IPv4-adres. incus list toont de instance als actief met een lege adreskolom. DHCP-antwoorden van de host worden tegengehouden, meestal door een host-firewall die de bridge niet herkent. Bij ufw herstelt sudo ufw allow in on incusbr0 to any port 67 proto udp dit. Monitor de inkomende verzoeken met sudo tcpdump -ni incusbr0 port 67.

Instance weigert te starten op een geneste VPS. Lees eerst incus info <name> --show-log en daarna sudo journalctl -u incus -n 50. Als systemd-detect-virt de melding lxc of openvz gaf, ligt het ontbrekende onderdeel bij de provider en kan geen enkele instelling binnen uw VPS dit wijzigen.

Snapshots zijn traag en de schijf raakt vol. U gebruikt een dir-pool. incus storage list toont de driver voor elke pool. Overstappen naar een copy-on-write-pool betekent dat u de nieuwe pool aanmaakt, de instances ernaartoe kopieert met incus copy web web-new -s fast en vervolgens de originelen verwijdert zodra u heeft gecontroleerd of de kopieën opstarten.

FAQ

Is een Incus container hetzelfde als een Docker container?

Nee. Docker verpakt één enkel proces of applicatie. Een Incus systeemcontainer simuleert een volledig besturingssysteem, met een eigen init, eigen gebruikers, eigen services en een eigen pakketbeheerder. U onderhoudt en patcht een Incus container zoals een server. Een Docker container vervangt u door deze weg te gooien en opnieuw op te bouwen vanuit een image. U kunt Docker binnen een Incus container draaien door security.nesting=true op de container in te stellen. Het omgekeerde is niet mogelijk.

Kan ik Incus op een VPS draaien?

Op een KVM VPS wel. systemd-detect-virt geeft kvm of qemu weer, u beschikt over een eigen kernel en Incus gedraagt zich zoals op fysieke hardware. Als het lxc, lxc-libvirt of openvz weergeeft, is uw VPS zelf een container. Incus containers daarbinnen zijn dan genest en werken alleen als de provider nesting op uw container heeft ingeschakeld. Controleer ook uname -r, aangezien de huidige stabiele Incus-branch per augustus 2026 een minimale kernel van 6.12 vereist, terwijl de 6.0 LTS-branch 5.4 documenteert.

Welke storage backend moet ik kiezen voor Incus op een VPS?

btrfs op een loop-bestand, tenzij u een extra block device beschikbaar heeft. De dir-driver is gedocumenteerd als aanzienlijk trager dan de andere, omdat deze bestanden kopieert in plaats van copy-on-write te gebruiken; hierdoor wordt bij elke snapshot de volledige container opnieuw weggeschreven. incus admin init --minimal selecteert dir, daarom is het beantwoorden van de interactieve vragen de twee minuten waard. Maak de pool aan met incus storage create fast btrfs size=30GiB.

Waarom kan mijn Incus container een service op de host bereiken?

Omdat de standaard incusbr0-bridge de host in hetzelfde subnet plaatst als de container, op het gateway-adres, en er geen filtering tussen beide plaatsvindt. Elke host-service die gebonden is aan 0.0.0.0 reageert daar, en de firewall van uw provider ziet deze pakketten nooit omdat ze de machine niet verlaten. Bind host-services aan 127.0.0.1, en sta op een ufw-host alleen DNS en DHCP toe op incusbr0 in plaats van de algemene sudo ufw allow in on incusbr0.

Hoe maak ik een back-up van een Incus container?

incus export web /root/web-backup.tar.gz schrijft de instantie en de bijbehorende snapshots naar één bestand, en incus import herstelt dit op dezelfde of een andere server. Snapshots gemaakt met incus snapshot create zijn geen back-ups: ze bevinden zich in dezelfde storage pool op dezelfde schijf. Ze overleven dus wel een mislukte upgrade, maar geen defecte server. Plan ze in met incus config set web snapshots.schedule=@daily en kopieer de exports naar een externe locatie.