VPS üzerinde Incus sistem konteyneri kurulumu

Incus sistem konteynerinin ne olduğu

Bir VPS üzerindeki Incus sistem konteynerleri, size dosya sistemi eklenmiş tek bir süreç değil, 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 servis yöneticisine yanıt verir. Bu, Debian ve Ubuntu gibi systemd imajlarında systemctl, OpenRC kullanan Alpine üzerinde ise rc-service'tür. Konteyner, 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 çatallanmasıdır (fork). İstemci komutu incus'tür. --vm parametresi verildiğinde QEMU aracılığıyla gerçek sanal makineler 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 kapsamaktadı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 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 (nested) container'lar olur ve iç içe çalıştırma özelliği yalnızca sağlayıcı tarafından etkinleştirilmişse çalışır. Bu ayar sizin kontrolünüzde olmayan ana makinede bulunduğu için içeriden etkinleştirmeniz mümkün değildir.

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

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 yapılandırılmış bir VPS'de bu liste, sağlayıcının size sunduğu yetkilere bağlı olarak 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. Ekim 2026 itibarıyla upstream, mevcut özellik sürümlerinin yanı sıra 6.0 ve 7.0 olmak üzere iki LTS (uzun süreli destek) serisini sürdürmektedir ve bunların ortak bir minimum sürüm gereksinimi yoktur. 6.0 LTS belgeleri "Desteklenen minimum çekirdek sürümü 5.4'tür" ifadesini içerir. Güncel belgeler ise "Desteklenen minimum çekirdek sürümü 6.12'dir" demektedir ve Mayıs 2026 tarihli 7.0 LTS duyurusu, minimum gereksinimler arasında Linux 6.12'yi listeler. Aynı duyuru, 6.0 LTS'yi yalnızca güvenlik güncellemelerinin sağlandığı aşamaya taşımıştır. Ubuntu 24.04, 6.0 LTS serisini kendi deposunda paketler ve bunu desteklenen bir kombinasyon olan 6.8 çekirdeği ile eşleştirir. Aynı 6.8 çekirdeği üzerine upstream deposundan kararlı sürümü veya 7.0 LTS sürümünü kurmak, sizi belgelenen minimum sürümün altına düşürür; bu nedenle bir depo seçmeden önce uname -r kısmı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 bir VPS üzerinde Proxmox bölümüne bakın.

Ubuntu veya Debian üzerinde Incus kurulumu

Debian 13 ve Ubuntu 24.04 ve sonraki sürümleri, Incus paketini 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 türünde instance'lar da istiyorsanız qemu-system paketini ekleyin.

Dağıtımınızın sunduğundan daha yeni bir sürüm için, güncel paketler pkgs.zabbly.com adresinde bulunur. Bu depo lts-6.0, lts-7.0 ve stable kanallarını sunar; projenin kendi deposundaki README dosyasından alınan aşağıdaki komutlar stable kanalını kullanır. Çekirdeğiniz bir LTS serisi gerektiriyorsa, dosya adındaki kanal ismini ve URIs: satırını buna göre değiştirin.

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 komutu ile sunucu yapılandırmasının yazdırılması, soketin çalıştığı anlamına gelir. Bir izin hatası, grup değişikliğinin mevcut shell oturumunuza yansımadığını gösterir; bu durumu mevcut oturum için newgrp incus-admin komutu, kalıcı olarak ise yeni bir giriş işlemi düzeltir. incus-admin grubuna üyeliği, ana makine üzerinde 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 incus grubunu da oluşturur.

Şimdi daemon'ı başlatın.

sudo incus admin init

incus admin init --minimal kullanmak yerine soruları yanıtlayın. Minimal yol dir depolama sürücüsünü seçer; sonraki bölüm bu seçimin neden önemli olduğu hakkındadır.

Bir instance 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, web durumunu RUNNING olarak ve incusbr0 alt ağında bir IPv4 adresi ile 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 içerisinde yazdırır; daemon seviyesindeki hatalar ise sudo journalctl -u incus -n 50 içerisine düşer. systemd-detect-virt komutunun lxc veya openvz döndürdüğü bir VPS üzerinde bu başlatma işlemi, nesting (iç içe sanallaştırma) özelliğinin kullanılabilir olup olmadığının gerçek testidir.

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. Bu, kurulum aşamasında yapılan ve daha sonra düşük maliyetle değiştirilmesi mümkün olmayan tek seçimdir.

Incus; dir, btrfs, lvm, zfs, Ceph ve çeşitli uzak sürücüleri destekler. Tek diskli bir VPS üzerinde asıl 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 bloklara referans vermek yerine her imajı açmak ve gerçek kopyalar oluşturmak zorundadır. Incus özellik karşılaştırmasında optimize edilmiş anlık görüntü oluşturma desteği olmayan tek sürücüdür; bu nedenle dir havuzunda 4 GiB boyutundaki bir container'ın anlık görüntüsü tam bir kopyadır: 4 GiB veri yazar ve bu kadar verinin kopyalanması kadar sürer. btrfs, lvm veya zfs üzerinde aynı anlık görüntü optimize edilir ve tüm diski kopyalamaz. 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 yüzden dir havuzundaki bir disk sınırının genellikle hiçbir etkisi olmaz.

btrfs ve zfs "copy-on-write" (yazma anı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. 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 kullanır; alt sınır 5 GiB, üst sınır ise 30 GiB'dir. Bu değeri bilinçli olarak ayarlayın. Havuz kendi boyutunda durur, bu nedenle ana makinede boş alan olsa bile havuz dolabilir; loop tabanlı bir havuzun tükenme şekli genellikle budur. Loop dosyasının kendisi ana makinenin dosya sistemindeki bir dosyadır, bu yüzden havuzu her boş gigabaytı ona vermek yerine ana makinenin kendi ihtiyaçlarını göz önünde bulundurarak boyutlandırın.

Debian ve Ubuntu üzerindeki ZFS, çekirdek içine gömülü (in-tree) değil bir DKMS modülüdür; bu nedenle her çekirdek yükseltmesinde yeniden derlenir ve yükseltme sonrası derleme başarısız olabilir. Günlük olarak takip etmediğiniz bir sunucuda btrfs, ikisi arasında daha az bakım gerektiren seçenektir.

Üç ağ modu ve her birinin sundukları

Önerilen yanıtı kabul ettiğinizde, incus admin init, incusbr0 adında yönetilen bir köprü (bridge) oluşturur ve bunu default profiline ekler; böylece bu profili kullanan her yeni örnek bu köprüye dahil olur. Bunun yerine mevcut bir köprüye veya arayüze de yönlendirme yapabilirsiniz. Yönetilen köprü, 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ü (Managed bridge). 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 üzerinde DHCP ve DNS (alan adı sistemi) çalıştırır ve giden trafik, kaynak NAT uygulanarak ana makinenin genel adresi üzerinden çıkar. Siz izin vermedikçe dışarıdan hiçbir şey container'a ulaşamaz. Bir proxy cihazı 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; böylece istemcinin gerçek adresi container günlüklerinde korunur. 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 sizin VM'nizin MAC adresine bağlıdır ve diğer adreslerden gelen çerçeveleri reddeder. Çalıştığı durumlarda bile kullanıcıları kısıtlayan ikinci bir sınır daha vardır. Incus, "macvlan cihazlarının kendi aralarında ve dışarıyla iletişim kurabilmelerine rağmen, üst cihazlarıyla konuşamadıklarını" belirtir. Bu, örneklerinizin ana makinenin kendisiyle konuşması gerektiğinde macvlan kullanamayacağınız anlamına gelir.

Yönlendirilmiş (Routed). Bu, ek adreslere sahip bir VPS üzerinde genellikle çalışan moddur. Incus, bu cihazı "ana makineyi örneğe bağlamak için sanal bir cihaz ç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şlerini 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, böylece servis sağlayıcı yalnızca ana makinenin MAC adresini görür.

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

Üst arayüz adını ana makinedeki ip route show default üzerinden alın. Bu ad, VPS'nizin kendi çekirdeğinden ve imajından gelir; eth0 yerine enp1s0 veya ens3 gibi tahmin edilebilir bir ad olabilir, bu yüzden tahmin etmek yerine okuyun. Container içinde durum farklıdır: Incus belgeleri, default profilindeki ağ arayüzünün "örnek içinde eth0 haline geldiğini" belirtir. Cihazı eth0 olarak adlandırmak, default profilinin sağladığı ismi geçersiz kılar; böylece container köprü yerine yönlendirilmiş arayüz üzerinde çalışır. Sonucu içeriden ip a ve ip route ile kontrol edin.

Bir container sunucudaki servise nasıl erişti?

incusbr0 üzerindeki bir container kendi ağ ad alanına (network namespace) sahiptir. Bu, sunucuya karşı bir güvenlik duvarı sınırı değildir. Incus köprüsünün eklediği güvenlik duvarı kuralları, dokümantasyonda belirtildiği üzere "tam işlevselliği sağlamak" içindir; sunucuyu dışarıdan yalıtmak için değildir. Sunucu, ağ geçidi adresinde bu köprü üzerinde yer alır; bu nedenle container içinden bakıldığında sunucu doğrudan erişilebilir bir komşudur ve 0.0.0.0 adresine bağlı her sunucu servisi, bir güvenlik duvarı kuralı paketleri düşürmediği sürece yanıt verir.

Bunu kendiniz kontrol edin. Sunucuda, dinleme yapan servisleri 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

Sunucudaki bir veritabanı, metrik uç noktası veya yönetim paneli 0.0.0.0 adresine bağlıysa ve hiçbir sunucu güvenlik duvarı kuralı köprüyü engellemiyorsa, 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" sorularının çoğunun arkasındaki sürpriz budur: container internetten NAT ile yalıtılmıştır, ancak sunucudan yalnızca sizin uyguladığınız güvenlik duvarı kuralları ile yalıtılmıştır.

Sunucu servislerini mümkün olan her yerde 127.0.0.1 adresine bağlayın. Ardından sunucudaki köprüyü filtreleyin. ufw yüklü bir sistemde varsayılan reddetme (deny) politikası, container'dan sunucuya giden 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 sunucu portlarını tüm container'lara yeniden açar. Bunun yerine, yalnızca container'ların gerçekten ihtiyaç duyduğu erişimlere 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 sunucu üzerinden internete geçmesini 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 erişemez.

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

Incus container ile Docker container aynı şey midir?

Hayır. Docker, tek bir süreci veya uygulamayı paketler. Incus sistem container'ı ise 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.

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 üzerindeki gibi davranır. Eğer lxc, lxc-libvirt veya openvz çıktısını alıyorsanız, VPS'niz halihazırda bir container'dır; bu durumda içerideki Incus container'ları iç içe (nested) çalışır ve yalnızca sağlayıcınız container'ınızda iç içe çalışmaya izin verdiyse işlevsel olur. Ayrıca uname -r değerini de kontrol edin; çünkü Ekim 2026 itibarıyla güncel Incus sürümleri ve 7.0 LTS serisi 6.12 veya daha yeni bir çekirdek gerektirirken, 6.0 LTS serisi için 5.4 sürümü belirtilmektedir.

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ğerlerine göre ç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 atar, bu yüzden etkileşimli soruları yanıtlamak için harcayacağınız iki dakikaya değer. Havuzu incus storage create fast btrfs size=30GiB ile oluşturun.

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

Çünkü varsayılan incusbr0 köprüsü, host'u container ile aynı alt ağda, ağ geçidi adresinde konumlandırır ve Incus'un bu köprüye eklediği güvenlik duvarı kuralları ağ trafiğini çalıştırmak içindir, host'u engellemek için değil. 0.0.0.0 adresine bağlı herhangi bir host servisi, bir host güvenlik duvarı kuralı paketleri düşürmediği sürece oradan yanıt verir ve paketler makineden hiç çıkmadığı için sağlayıcınızın güvenlik duvarı bunları asla 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 yalnızca DNS ve DHCP trafiğine incusbr0 üzerinden 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 ölü bir sunucudan kurtaramazlar. Bunları incus config set web snapshots.schedule=@daily ile zamanlayın ve dışa aktarılan dosyaları sunucunun dışına kopyalayın.