VPS üzerinde Incus sistem konteyneri kurulumu

Incus sistem konteynerinin ne olduğu

VPS üzerindeki Incus sistem konteynerleri, size tek bir dosya sistemi eklenmiş süreç yerine, kendi init sistemine ve kullanıcı hesaplarına sahip tam bir makine sunar. Konteyner önyüklenir, PID 1 olarak bir init çalıştırır ve systemctl komutuna yanıt verir. Ana makinenin çekirdeğini paylaştığı için bir sanal makine değildir. Çekirdeğin üzerindeki her şey bir sanal makine gibi davranır.

Incus, Linux Containers projesi altında sürdürülen LXD'nin topluluk çatalıdır (fork). İstemci komutu incus şeklindedir. --vm bayrağını kullandığınızda QEMU aracılığıyla gerçek sanal makineleri de çalıştırabilir; ancak sistem konteyneri, çoğu kullanıcının bu yazılımı kurma nedenidir ve bu kılavuzun geri kalanı bu konuyu ele almaktadır.

Docker karşılaştırmaları insanları neden yanıltır

Docker tek bir süreci paketler. Incus ise tek bir işletim sistemini paketler. Incus belgeleri bu ayrımı doğrudan şu şekilde belirtir: "Uygulama konteynerleri (örneğin Docker tarafından sağlananlar) tek bir süreci veya uygulamayı paketler. Sistem konteynerleri ise bir ana makinede veya sanal makinede çalıştıracağınız sisteme benzer şekilde tam bir işletim sistemini simüle eder."

Bu fark, söz konusu araçla günlük olarak ne yapacağınızı değiştirir.

• Bir Docker imajında init sistemi yoktur, bu nedenle içinde systemctl çalıştırıldığında başarısız olur. Bir Incus konteyneri ise bir init sistemi çalıştırır; bu sayede servisler ve zamanlayıcılar bir sunucudaki gibi işler.
• Bir Docker konteyneri, yok edilmek ve bir Dockerfile üzerinden yeniden oluşturulmak üzere tasarlanmıştır. Bir Incus konteyneri ise korunmak, yamalanmak ve anlık görüntüleri (snapshot) alınmak üzere tasarlanmıştır.
• Bir Docker imajı, bir kayıt defterine (registry) gönderdiğiniz bir derleme çıktısıdır. Bir Incus örneği ise depolama havuzunda disk üzerinde bulunan bir durumdur ve onu incus export ile taşırsınız.
• Docker bir iş yükünü izole eder. Incus ise bir makineyi izole eder; bu sayede tek bir konteyner birden fazla iş yükünü ve birden fazla kullanıcı hesabını barındırabilir.

Bir Incus sistem konteyneri içinde Docker çalıştırabilirsiniz. Ancak bir Docker uygulama konteyneri içinde Incus çalıştırmazsınız. Eğer gerçekten istediğiniz şey, imaj derleme adımı içeren konteyner başına tek bir süreç ise, öncelikle okunması gereken karşılaştırma VPS üzerinde Podman ve Docker konusudur. Eğer paylaşımlı bir çekirdek yerine iş yükü başına ayrı bir çekirdek istiyorsanız, VPS üzerinde Firecracker microVM konusu diğer yöne giden seçenektir.

Incus bir VPS içinde çalışır mı?

Bu durum, VPS'nizin sanallaştırma türüne ve çekirdeğine bağlıdır; bu nedenle herhangi bir kurulum yapmadan önce her ikisini de kontrol edin. Sağlayıcının pazarlama sayfalarındaki ifadelere güvenmeyin. Sunucu üzerinde şu dört komutu çalıştırın.

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

systemd-detect-virt çıktısının kvm veya qemu olması, VPS'nizin kendi çekirdeğine sahip bir sanal makine olduğu anlamına gelir. Bu en kolay durumdur, çünkü Incus bu senaryoda fiziksel donanım üzerindeymiş gibi davranır. lxc, lxc-libvirt veya openvz çıktısı, VPS'nizin sağlayıcının çekirdeğini paylaşan bir container olduğu anlamına gelir. Bu durumda Incus container'ları iç içe geçmiş (nested) container'lar olur ve iç içe geçirme özelliği yalnızca sağlayıcı tarafından etkinleştirilmişse çalışır. Ayar, kontrolünüzde olmayan ana makinede (host) bulunduğu için bu özelliği içeriden etkinleştiremezsiniz.

stat -fc %T /sys/fs/cgroup komutu cgroup2fs çıktısını vermelidir. Bunun dışındaki herhangi bir çıktı, sunucunun cgroup (control group) v1 veya hibrit yapıda olduğunu gösterir ki güncel Incus sürümleri bunu desteklememektedir.

cat /sys/fs/cgroup/cgroup.controllers komutu, size devredilen control-group denetleyicilerini listeler. Incus; blkio, cpuset, devices, freezer, memory ve pids denetleyicilerinin gerekli olduğunu belirtir. İç içe geçmiş (nested) bir VPS'de bu liste, sağlayıcının yetkilendirdiği kısıtlı izinler nedeniyle genellikle KVM tabanlı bir sunucudan daha kısadır. Bu dosyada eksik olan bir denetleyici, Incus tarafından kullanılamaz; dolayısıyla o denetleyiciye bağlı olan kaynak sınırlamaları sizin için kullanılamaz hale gelir.

Çekirdek sürümü eskisinden daha fazla önem taşımaktadır. Ağustos 2026 itibarıyla Incus belgeleri, geliştirici ekibin sürdürdüğü iki farklı dal için iki ayrı minimum sürüm belirtmektedir. 6.0 LTS (uzun süreli destek) dalı için "Desteklenen minimum çekirdek sürümü 5.4'tür" ifadesi yer alırken, güncel kararlı dal için "Desteklenen minimum çekirdek sürümü 6.12'dir" denilmektedir. Ubuntu 24.04, 6.0 LTS serisini kendi deposunda paketler ve bunu 6.8 çekirdeği ile eşleştirir; bu desteklenen bir kombinasyondur. Güncel kararlı sürümü aynı 6.8 çekirdeği üzerine kurmak, sizi belgelenen minimum sürümün altına düşürür; bu nedenle bir depo seçmeden önce uname -r dosyasını okuyun.

Amacınız container'lar yerine tam sanal makineler çalıştırmaksa, kısıtlamalar farklı ve daha zorlayıcıdır. VPS'nizin /dev/kvm özelliğini sunup sunamayacağını öğrenmek için VPS üzerinde iç içe sanallaştırma bölümüne, donanımın sahibi olduğunuz durumlar için ise Kiralık VPS'e karşı Proxmox bölümüne bakın.

Ubuntu veya Debian üzerinde Incus kurulumu

Debian 13 ve Ubuntu 24.04 ve sonraki sürümler, Incus'u kendi depolarında sunar.

sudo apt update
sudo apt install -y incus

Debian üzerinde incus-base komutu, sanal makine bileşenleri olmadan konteyner desteğini kurar. Ubuntu üzerinde, --vm örneklerine de ihtiyaç duyuyorsanız qemu-system paketini ekleyin.

Dağıtımınızın sunduğundan daha yeni bir sürüm için, yukarı akış paketleri pkgs.zabbly.com adresinde bulunur. Bu komutlar, projenin kendi depo README dosyasından alınmıştır.

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

Ardından kullanıcı hesabınıza daemon soketine erişim yetkisi verin.

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

incus info komutunun sunucu yapılandırmasını yazdırması, soketin çalıştığı anlamına gelir. Bir izin hatası, grup değişikliğinin kabuğunuza henüz yansımadığını gösterir; bu durumu mevcut kabuk için newgrp incus-admin komutu, kalıcı olarak ise yeni bir oturum açma işlemi düzeltir. incus-admin grubuna üyeliği, ana makinede root yetkisine sahip olmakla eşdeğer tutun; çünkü bu sokete erişim, root olarak çalışan bir daemon üzerinde tam kontrol sağlar. Bazı dağıtımlar, kısıtlı kullanıcı erişimi için ayrıca bir incus grubu da oluşturur.

Şimdi daemon'ı başlatın.

sudo incus admin init

incus admin init --minimal komutuna başvurmak yerine soruları yanıtlayın. En kısa yol dir depolama sürücüsünü seçer; bir sonraki bölüm bu seçimin neden önemli olduğunu açıklar.

Bir örnek başlatın ve çalıştığını doğrulayın.

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

incus list komutu, incusbr0 alt ağında bir IPv4 adresi ile RUNNING durumunda web çıktısını göstermelidir. Adres görünmüyorsa DHCP (dinamik ana bilgisayar yapılandırma protokolü) tamamlanmamış demektir; bu durum ağ bölümünde ele alınmıştır. Başlatılamayan bir konteyner, nedenini incus info web --show-log dosyasında yazdırır; daemon düzeyindeki hatalar ise sudo journalctl -u incus -n 50 dosyasında kayıt altına alınır. systemd-detect-virt komutunun lxc veya openvz döndürdüğü bir VPS üzerinde bu başlatma işlemi, iç içe sanallaştırmanın (nesting) kullanılabilir olup olmadığını test etmenin en güvenilir yoludur.

Varsayılan depolama arka ucunun önemi

Depolama arka ucu, bir anlık görüntünün (snapshot) anlık mı yoksa container diskinin tam bir kopyası mı olacağına karar verir. Kurulum sırasında yapılan ve daha sonra düşük maliyetle değiştirilmesi mümkün olmayan tek seçim budur.

Incus; dir, btrfs, lvm, zfs, Ceph ve çeşitli uzak sürücüleri destekler. Tek diskli bir VPS üzerinde gerçek seçim dir ile btrfs arasındadır.

dir sürücüsü, her container'ı /var/lib/incus altında sıradan dosyalar ve dizinler olarak tutar. Incus bunu "diğer tüm sürücülerden çok daha yavaş" olarak tanımlar; çünkü paylaşılan blokları referans almak yerine her imajı açmak ve gerçek kopyalar oluşturmak zorundadır. 4 GiB boyutundaki bir container'ın anlık görüntüsü 4 GiB veri yazar ve cp -a işleminin sürdüğü kadar zaman alır. Disk kotaları yalnızca dosya sistemi düzeyinde proje kotaları etkinleştirilmiş ext4 veya XFS üzerinde çalışır; bu özellik çoğu VPS imajında varsayılan olarak açık değildir, bu nedenle dir havuzundaki bir disk sınırının genellikle hiçbir etkisi olmaz.

btrfs ve zfs, copy-on-write (yazma sırasında kopyalama) özelliğine sahiptir, bu nedenle bir anlık görüntü yalnızca kendisinden sonra değişen blokları kaydeder. Incus, bu ikisini önerilen arka uçlar olarak belirtir. Anlık görüntüler neredeyse anlık hale gelir. Disk kotaları, dosya sisteminin kendi kota desteği aracılığıyla çalışır.

Çoğu VPS planı size yedek bölümü olmayan tek bir disk verir, bu yüzden havuzu bir loop dosyası üzerine kurun. Herhangi bir source= belirtmediğinizde Incus bunu sizin yerinize yapar.

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

size= olmadan, loop tabanlı bir havuz boş disk alanının %20'sini kaplar; alt sınır 5 GiB, üst sınır ise 30 GiB'dir. Bu değeri bilinçli olarak ayarlayın. Loop dosyası, kök dosya sisteminizdeki bir dosya olduğundan, havuz ve ana makine aynı boş alanı paylaşır; bu da havuzun dolmasının ana makinenin diskini de dolduracağı anlamına gelir.

Debian ve Ubuntu üzerindeki ZFS, çekirdek içi bir modül yerine DKMS modülü olarak çalışır, bu nedenle her çekirdek yükseltmesinde yeniden derlenir ve yükseltme sonrasında derleme başarısız olabilir. Günlük olarak takip etmediğiniz bir sunucuda btrfs, bu ikisi arasında daha az bakım gerektiren seçenektir.

Üç ağ modu ve her birinin sunduğu erişim olanakları

incus admin init, incusbr0 adında yönetilen bir köprü oluşturur ve her yeni örneği bu köprüye dahil eder. Bu, bir container bağlamanın üç yolundan biridir; diğer ikisi ise ilk yöntemin container'larınızı NAT (ağ adresi çevirisi) arkasında gizlemesi nedeniyle mevcuttur.

Yönetilen köprü. incusbr0 özel bir alt ağ alır. Ana makine bu ağdaki ilk adresi tutar ve ağ geçidi görevi görür; Incus bu ağ üzerinde DHCP ve DNS (alan adı sistemi) çalıştırır ve giden trafik, kaynak NAT uygulanarak ana makinenin genel adresi üzerinden çıkar. Siz belirtmedikçe dışarıdan hiçbir şey container'a ulaşamaz. Bir proxy aygıtı ile port yönlendirmesi yapın.

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, ayrı bir kullanıcı alanı bağlantısı üzerinden proxy yapmak yerine netfilter kurallarıyla yönlendirme yapar; bu sayede istemcinin gerçek adresi container günlüklerine yansır. Incus bu modu yalnızca ana makine örneğin ağ geçidi olduğunda destekler; bu da tam olarak incusbr0 durumudur.

macvlan. Container, ana makinenin fiziksel ağında kendi MAC (ortam erişim denetimi) adresini alır. Çoğu VPS platformunda bu yöntem başarısız olur; çünkü sanal anahtar portu, VM'nizin MAC adresine bağlıdır ve başka bir adresten gelen çerçeveleri reddeder. Çalıştığı durumlarda bile kullanıcıları kısıtlayan ikinci bir engel daha vardır. Incus belgelerinde "macvlan aygıtları, kendi aralarında ve dış dünya ile iletişim kurabilseler de, bağlı oldukları ana aygıtla konuşamazlar" ifadesi yer alır. Bu, örneklerinizin ana makine ile iletişim kurması gereken durumlarda macvlan kullanamayacağınız anlamına gelir.

Routed. Bu mod, genellikle ek adreslere sahip bir VPS üzerinde çalışan yöntemdir. Incus, bu aygıtı "ana makineyi örneğe bağlamak için bir sanal aygıt çifti oluşturan ve örneğin belirlenen bir üst arayüzün ağına katılmasına izin vermek için statik rotalar ile proxy ARP/NDP girişleri ayarlayan" bir yapı olarak tanımlar. ARP, adres çözümleme protokolüdür. Container genel bir adres tutar. Ana makine onun yerine ARP yanıtı verir, bu sayede servis sağlayıcı yalnızca ana makinenin MAC adresini görmeye devam eder.

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

Üst arayüz adını ip route show default komutundan alın. Güncel imajlar genellikle enp1s0 veya ens3 gibi isimler kullanır, eth0 kullanımı nadirdir. Aygıtı eth0 olarak adlandırmak, default profilinin sağladığı ayarı geçersiz kılar; böylece container köprü yerine yönlendirilmiş (routed) arayüz üzerinde çalışır. Sonucu içeriden ip a ve ip route ile kontrol edin.

Bir container neden ana makinedeki bir servise erişebilir

incusbr0 üzerindeki bir container kendi ağ ad alanına (network namespace) sahiptir. Ana makineye karşı bir güvenlik duvarı sınırı bulunmaz. Ana makine, bu köprü üzerinde ağ geçidi (gateway) adresinde yer alır; bu nedenle container içinden bakıldığında ana makine doğrudan erişilebilir bir komşudur ve 0.0.0.0 adresine bağlı her ana makine servisi oradan yanıt verir.

Bunu kendiniz kontrol edin. Ana makinede, dinlemede olanları listeleyin.

sudo ss -tlnp

Ardından, bir container içinden ip route komutunun bildirdiği ağ geçidini hedefleyin.

ip route show default
nc -zv 10.0.0.1 6379

Eğer ana makinedeki bir veritabanı, metrik uç noktası veya yönetim paneli 0.0.0.0 adresine bağlıysa, bu kontrol başarılı olur. Sağlayıcınızın ağ güvenlik duvarı paketi asla görmez, çünkü paket makineden dışarı çıkmaz. "Oraya nasıl erişti" şeklindeki çoğu sorunun arkasındaki sürpriz budur: container, NAT ile internetten izole edilmiştir ancak ana makineden hiçbir şekilde izole edilmemiştir.

Ana makine servislerini mümkün olan her yerde 127.0.0.1 adresine bağlayın. Ardından ana makinedeki köprüyü filtreleyin. ufw yüklü bir sistemde varsayılan reddetme (deny) politikası, container'dan ana makineye trafiği zaten engeller; bu durum Incus DNS ve DHCP servislerini bozar. Incus dokümantasyonunun sunduğu çözüm ise sudo ufw allow in on incusbr0 komutudur. Bu tek komut, tüm ana makine portlarını tüm container'lara yeniden açar. Bunun yerine, yalnızca container'ların gerçekten ihtiyaç duyduğu bağlantılara izin verin.

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

İki adet ufw route kuralı, instance trafiğinin ana makine üzerinden internete çıkmasını sağlayan kurallardır. Bunlar olmadan, ufw'nin yönlendirme (routed) politikası iletilen paketleri düşürür; bu nedenle container'lar bir adres alır ancak hiçbir yere ulaşamaz.

Anlık görüntüler ve profiller

Anlık görüntü (snapshot), instance'ın depolama havuzu içindeki belirli bir zamana ait kopyasıdır.

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

incus info web, instance'ın sahip olduğu anlık görüntüleri listeler. Bunları her instance için ayrı ayrı planlayabilirsiniz.

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

Bir anlık görüntü aynı havuzda, aynı diskte ve aynı sunucuda bulunur. Hatalı bir yükseltmeye karşı koruma sağlar. Bozuk bir disk veya silinen bir instance durumunda koruma sağlamaz. Yedekleme incus export ile yapılır ve dosyanın sunucudan dışarı aktarılması gerekir.

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

Profil, instance'lara uygulanan yapılandırma anahtarları ve cihazlardan oluşan isimlendirilmiş bir kümedir. Aksi belirtilmedikçe her instance default profilini alır; bu profil, instance'ın kök diskini ve ağ arayüzünü sağlar. default üzerinde yapılan değişiklikler, onu kullanan tüm instance'ları etkiler; bu özellik kullanışlıdır ve aynı zamanda yirmi container'ın ağ bağlantısını tek seferde kesmek için de kullanılır.

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

Profiller sırayla uygulanır, bu nedenle listedeki son profilde ayarlanan anahtar geçerli olur. Bir instance'ın nihai yapılandırmasını görmek için incus config show api --expanded kullanın.

Incus container içerisinde Docker çalıştırma

Incus sistem container'ı içerisinde Docker çalıştırmak için nesting özelliğinin etkinleştirilmesi gerekir; çünkü Docker, container'ların varsayılan olarak oluşturmasına izin verilmeyen kendi namespace ve mount yapılarını oluşturur.

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

Incus belgeleri security.nesting ayarını "instance içerisinde nesting işlemine izin verilip verilmeyeceği" olarak tanımlar ve bu ayar container'lar için varsayılan olarak false değerindedir. Incus FAQ kısmından gelen iki önemli nokta daha mevcuttur. Bir container kernel modüllerini yükleyemez; bu nedenle Docker'ın ihtiyaç duyduğu bir modülün host üzerinde yüklenmiş olması ve incus config set web linux.kernel_modules overlay,br_netfilter içerisinde listelenmesi gerekir. Ayrıca container içerisinde bir /.dockerenv dosyası oluşturmak, Docker'ın iç içe geçmiş (nested) ortamlarda başarısız olan bazı kontrolleri atlamasını sağlar.

Ubuntu 24.04 host sistemlerinde, AppArmor'un yetkisiz kullanıcı namespace kısıtlamaları, runc işleminin gerçekleştirdiği pivot_root çağrısını engelleyebilir. Container içerisindeki Docker şu hatayı verir:

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

ve host üzerindeki dmesg dosyası, apparmor="DENIED" operation="pivotroot" class="mount" ifadesini içeren bir satır gösterir. Kullanıcıların başvurduğu ayar kernel.apparmor_restrict_unprivileged_userns değeridir. Bu ayarı kapatmak güvenilir bir çözüm değildir: bu reddetme durumu için açılan upstream Incus hata raporu, ayarın 0 olarak değiştirilmesinin sorunu çözmediğini belirtmektedir. Bir güvenlik varsayımını değiştirmeden önce sorunun gerçekten AppArmor kaynaklı olup olmadığını anlamak için öncelikle dmesg dosyasını inceleyin.

Eğer container'ları doğrudan VPS üzerinde çalıştırmayı ve bir katmanı atlamayı tercih ederseniz, VPS üzerinde Docker çalıştırma rehberi bu kurulumu ayrıntılı olarak ele almaktadır.

Hata modları ve karşılaşacağınız dizeler

Docker'ı ana makineye kurduktan sonra instance'lar tüm ağ bağlantısını kaybeder. Incus belgeleri bunun nedenini şöyle açıklar: "Docker, global FORWARD politikasını drop olarak ayarlar; bu durum Incus'un trafiği yönlendirmesini engeller ve instance'ların ağ bağlantısının kesilmesine yol açar." Instance'lar IP adreslerini korur ancak hiçbir yere erişemez. /etc/docker/daemon.json dosyasında ip-forward-no-drop değerini true olarak ayarlayın, ardından yönlendirmeyi kalıcı hale getirin ve köprü trafiğinin Docker'ın kendi zinciri üzerinden geçmesine izin verin.

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

Bu iptables kuralları yeniden başlatma sonrasında kendiliğinden kalıcı olmaz. Bunları kalıcı hale getirin.

Container'lar bir cgroup hatası nedeniyle başlamayı durdurur. Incus FAQ bu durumu belgelemektedir. Failed to mount "/sys/fs/cgroup" ile ilgili bir mesaj, genellikle ana makinedeki bir VPN istemcisinin, Incus'un kullandığı cgroup v2 yerine net_cls cgroup v1 denetleyicisini bağladığı anlamına gelir. sudo umount /sys/fs/cgroup/net_cls bu durumu temizler.

Instance IPv4 adresi almıyor. incus list, instance'ın boş bir adres sütunuyla çalıştığını gösterir. Ana makineden gelen DHCP yanıtları, genellikle köprüden haberdar olmayan bir ana makine güvenlik duvarı tarafından düşürülmektedir. ufw üzerinde sudo ufw allow in on incusbr0 to any port 67 proto udp komutu bağlantıyı geri getirir. İsteklerin ulaşıp ulaşmadığını sudo tcpdump -ni incusbr0 port 67 ile izleyin.

Instance iç içe (nested) bir VPS üzerinde başlamayı reddediyor. Önce incus info <name> --show-log, ardından sudo journalctl -u incus -n 50 kısmını okuyun. Eğer systemd-detect-virt çıktısı lxc veya openvz diyorsa, eksik olan parça sağlayıcı tarafındadır ve VPS içindeki hiçbir ayar bunu değiştiremez.

Snapshot'lar yavaş ve disk sürekli doluyor. Bir dir havuzu kullanıyorsunuz. incus storage list her havuz için sürücüyü yazdırır. Copy-on-write bir havuza geçmek; yeni havuzu oluşturmak, incus copy web web-new -s fast ile instance'ları bu havuza kopyalamak ve kopyaların çalıştığını doğruladıktan sonra orijinalleri silmek anlamına gelir.

FAQ

Bir Incus container ile Docker container aynı şey midir?

Hayır. Docker, tek bir süreci veya uygulamayı paketler. Bir Incus sistem container'ı, kendi init süreci, kullanıcıları, servisleri ve paket yöneticisi ile tam bir işletim sistemini simüle eder. Bir Incus container'ını bir sunucu gibi tutar ve yamalarsınız. Bir Docker container'ını ise atar ve imajdan yeniden oluşturursunuz. Container üzerinde security.nesting=true ayarını yaparak bir Incus container'ı içerisinde Docker çalıştırabilirsiniz. Bunun tersi mümkün değildir.

Bir VPS üzerinde Incus çalıştırabilir miyim?

KVM tabanlı bir VPS üzerinde evet. systemd-detect-virt komutu kvm veya qemu çıktısını veriyorsa kendi çekirdeğinize sahipsiniz demektir ve Incus donanım üzerindeymiş gibi davranır. Eğer lxc, lxc-libvirt veya openvz çıktısını veriyorsa, VPS'niz halihazırda bir container'dır; bu durumda içindeki Incus container'ları iç içe (nested) çalışır ve yalnızca sağlayıcınız container'ınızda iç içe çalıştırma özelliğini etkinleştirdiyse işlevsel olur. Ayrıca uname -r değerini de kontrol edin; çünkü Ağustos 2026 itibarıyla mevcut Incus kararlı sürümü minimum 6.12 çekirdek sürümünü şart koşarken, 6.0 LTS sürümü 5.4 çekirdek sürümünü desteklemektedir.

Bir VPS üzerinde Incus için hangi depolama arka ucunu seçmeliyim?

Elinizde ayırabileceğiniz bir blok cihazı yoksa, bir loop dosyası üzerinde btrfs kullanın. dir sürücüsünün diğerlerinden çok daha yavaş olduğu belgelenmiştir; çünkü copy-on-write yerine dosyaları kopyalar, bu nedenle her snapshot tüm container'ı yeniden yazar. incus admin init --minimal seçimi dir değerini belirler, bu yüzden etkileşimli soruları yanıtlamak için harcayacağınız iki dakikaya değer. Depolama havuzunu incus storage create fast btrfs size=30GiB ile oluşturun.

Incus container'ım neden host üzerinde çalışan bir servise erişebiliyor?

Varsayılan incusbr0 köprüsü, host'u container ile aynı alt ağa, ağ geçidi adresine yerleştirir ve aralarında herhangi bir filtreleme yoktur. 0.0.0.0 adresine bağlı herhangi bir host servisi oradan yanıt verir ve paketler makineyi asla terk etmediği için sağlayıcınızın güvenlik duvarı bu paketleri görmez. Host servislerini 127.0.0.1 adresine bağlayın ve ufw kullanan bir host üzerinde, genel sudo ufw allow in on incusbr0 yerine incusbr0 üzerinden yalnızca DNS ve DHCP trafiğine izin verin.

Bir Incus container'ını nasıl yedeklerim?

incus export web /root/web-backup.tar.gz, instance'ı ve snapshot'larını tek bir dosyaya yazar; incus import ise bunu aynı veya başka bir sunucuda geri yükler. incus snapshot create ile alınan snapshot'lar yedek değildir: aynı diskteki aynı depolama havuzunda bulunurlar, bu nedenle hatalı bir güncellemeden kurtarabilirler ancak çöken bir sunucuda işe yaramazlar. Bunları incus config set web snapshots.schedule=@daily ile zamanlayın ve dışa aktarılan dosyaları makinenin dışına kopyalayın.