Proxmox'ta LXC Konteyner Oluşturma

Bir Proxmox sunucusunda tek bir küçük servis çalıştırmak için tam bir sanal makine ayırmak çoğu zaman israftır. Bir DNS önbelleği, bir reverse proxy, bir izleme ajanı ya da küçük bir web uygulaması için 2 GB RAM'i çekirdek ve önyükleyici çalıştırmaya harcamanın anlamı yok. İşte Proxmox LXC konteyner tam olarak bu boşluğu doldurur: kendi çekirdeğini çalıştırmayan, ana makinenin çekirdeğini paylaşan, saniyeler içinde açılan ve 60-80 MB RAM ile idare edebilen izole bir Linux ortamı.

Bu rehberde Proxmox üzerinde LXC konteynerin nasıl oluşturulduğunu hem web arayüzünden hem de pct komut satırı aracıyla adım adım göstereceğim. Şablon (template) indirmeden başlayıp, unprivileged ve privileged konteyner farkına, disk ve ağ ayarlarına, kaynak limitlerine ve konteyner içinde Docker çalıştırmak istediğinizde karşınıza çıkacak nesting ayarına kadar gideceğiz. Sonda da yıllardır aynı şekilde tekrarlanan hataları ve bunların çözümünü toplayacağım; asıl zaman kazandıran kısım orası.

LXC Konteyner Nedir, Proxmox Onu Nasıl Çalıştırır#

LXC (Linux Containers), işletim sistemi seviyesinde sanallaştırma yapar. Bir KVM sanal makinesi kendi BIOS'unu, kendi çekirdeğini ve kendi sanal donanımını çalıştırırken, LXC konteyner doğrudan Proxmox ana makinesinin çekirdeği üzerinde çalışan izole bir süreç grubudur. İzolasyonu sağlayan iki çekirdek özelliği vardır: namespace'ler (süreç, ağ, mount, kullanıcı gibi kaynakların ayrı görünmesi) ve cgroup'lar (CPU, bellek, disk G/Ç limitleri). Yani konteynerin içinde ps aux çalıştırdığınızda yalnızca kendi süreçlerini görürsünüz, ama o süreçler aslında ana makinenin süreç listesinde de vardır.

Bu tasarımın iki doğrudan sonucu var. Birincisi, konteyner inanılmaz hafiftir; boş bir Debian konteyneri yaklaşık 40-70 MB RAM tüketir ve iki saniyede açılır. İkincisi, konteyner ana makineyle aynı çekirdeği kullandığı için içinde farklı bir çekirdek sürümü, farklı bir çekirdek modülü ya da Linux olmayan bir işletim sistemi çalıştıramazsınız. Windows bir LXC konteyner içinde çalışmaz, özel bir kernel modülü gerektiren VPN yazılımı da genellikle çalışmaz. Bu ayrımı ve hangi iş yükünün hangisine uygun olduğunu daha derin karşılaştırmak isterseniz LXC mi KVM mi yazısı tam bu konuya ayrılmıştır.

Proxmox tarafında konteyner yönetiminin tamamı pct (Proxmox Container Toolkit) aracıyla yapılır ve her konteynerin yapılandırması /etc/pve/lxc/ altında düz metin bir dosyada tutulur. Web arayüzünde tıkladığınız her seçenek, sonunda bu dosyaya bir satır yazar. Dosyayı okumayı öğrenmek, panelde kaybolmaktan çok daha hızlı sonuç verir.

Şablon (Template) İndirme#

Konteyner oluşturmadan önce bir kök dosya sistemi şablonuna ihtiyacınız var. Proxmox bunları pveam (Proxmox VE Appliance Manager) aracıyla yönetir. Önce mevcut şablon listesini tazeleyin:

# Şablon listesini güncelle
pveam update

# Sistem şablonlarını listele (Debian, Ubuntu, Alpine, Rocky...)
pveam available --section system

Çıktıda şuna benzer satırlar görürsünüz:

system          debian-12-standard_12.7-1_amd64.tar.zst
system          ubuntu-24.04-standard_24.04-2_amd64.tar.zst
system          alpine-3.20-default_20240908_amd64.tar.xz

Sürüm son ekleri zamanla değişir; kopyalayıp yapıştırmadan önce mutlaka kendi listenizdeki güncel adı kullanın. İstediğiniz şablonu local depolamasına indirin:

# Şablonu indir (local depolamasında vztmpl dizinine düşer)
pveam download local debian-12-standard_12.7-1_amd64.tar.zst

# İndirilmiş şablonları gör
pveam list local

Şablonlar diskte /var/lib/vz/template/cache/ altında durur. Web arayüzünde aynı işi Datacenter → Storage → local → CT Templates → Templates yolundan yapabilirsiniz. Bir şablonu bir kez indirdiğinizde o düğümdeki tüm konteynerler için tekrar tekrar kullanabilirsiniz; ağdan indirme maliyeti yalnızca ilk seferdir.

Alpine şablonu 3-5 MB, Debian standard şablonu 120-150 MB civarındadır. Küçük bir yardımcı servis için Alpine cazip görünür ama musl libc kullandığı için bazı ikili paketler beklediğiniz gibi çalışmayabilir; alışık olduğunuz dağıtımla başlamanızı öneririm.

Web Arayüzünden Adım Adım Konteyner Oluşturma#

Panelden gitmek istiyorsanız sağ üstteki Create CT düğmesi sizi yedi sekmeli bir sihirbaza götürür. Sıra şöyle işler:

1. General — Node, CT ID (örneğin 101), Hostname (web01), Password ve isterseniz SSH açık anahtarı. Buradaki Unprivileged container kutusu varsayılan olarak işaretlidir; özel bir sebebiniz yoksa işaretli bırakın.
2. Template — az önce indirdiğiniz şablonu depolama ve dosya adı olarak seçersiniz.
3. Disks — kök disk için depolama (local-lvm gibi) ve boyut (GB). LXC'de disk sonradan büyütülebilir ama küçültülemez; bunu akılda tutun.
4. CPU — Cores sayısı. LXC'de bu bir cgroup limitidir, ayrılmış çekirdek değil.
5. Memory — Memory (MiB) ve Swap (MiB).
6. Network — arayüz adı eth0, köprü vmbr0, IPv4 için Static seçip 185.12.34.56/24 ve ağ geçidi 185.12.34.1 yazarsınız ya da DHCP seçersiniz.
7. DNS — boş bırakırsanız ana makinenin /etc/resolv.conf ayarlarını devralır; çoğu durumda istediğiniz budur.

Son ekranda Finish'e bastığınızda Proxmox bir görev açar ve şablonu açıp diski hazırlar. İşlem tipik olarak 10-20 saniye sürer. Start after created kutusunu işaretlemediyseniz konteyner durur halde oluşur; soldaki ağaçtan seçip Start ile açarsınız.

pct ile Komut Satırından Konteyner Oluşturma#

Aynı işi tek satırda yapabilirsiniz ve bu, tekrarlanabilirlik açısından paneli her zaman yener. Aşağıdaki komut yukarıdaki sihirbazın tam karşılığıdır:

pct create 101 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname web01 \
  --cores 2 \
  --memory 2048 \
  --swap 512 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=185.12.34.56/24,gw=185.12.34.1 \
  --nameserver 1.1.1.1 \
  --unprivileged 1 \
  --features nesting=1 \
  --onboot 1 \
  --password

Parametrelerin ne yaptığını kısaca açayım: --rootfs local-lvm:8 kök diski local-lvm üzerinde 8 GB olarak oluşturur. --onboot 1 ana makine yeniden başladığında konteynerin otomatik açılmasını sağlar; unutulduğunda gece 03:00'te sunucu restart olduğunda servislerin geri gelmemesinin bir numaralı sebebi budur. --password parolayı etkileşimli olarak sorar, böylece parola komut geçmişine yazılmaz.

Oluşturduktan sonra günlük kullanımda ihtiyacınız olacak komutlar şunlardır:

pct start 101              # başlat
pct enter 101              # içine kabuk aç (ssh gerekmez)
pct exec 101 -- apt update # dışarıdan komut çalıştır
pct config 101             # yapılandırmayı göster
pct set 101 --memory 4096  # canlı olarak belleği değiştir
pct stop 101               # durdur
pct destroy 101            # sil (geri dönüşü yok)

pct enter komutu, konteynerde SSH sunucusu kurulu olmasa bile içine girmenizi sağlar. Bu yüzden birçok kurulumda konteynerlerde SSH hiç açılmaz; erişim yalnızca ana makine üzerinden yapılır ve saldırı yüzeyi ciddi biçimde küçülür.

Privileged ve Unprivileged Konteyner Farkı#

Bu, LXC'deki en önemli güvenlik ayarıdır ve sonradan değiştirilmesi zahmetlidir; baştan doğru seçin. Unprivileged konteynerde kullanıcı namespace'i devrededir: konteynerin içindeki root (UID 0), ana makinede 100000 gibi yetkisiz bir UID'ye eşlenir. Yani konteynerden kaçış açığı bulunsa bile saldırgan ana makinede sıradan bir kullanıcı olarak düşer. Privileged konteynerde ise konteyner root'u ana makine root'udur ve tek bir kaçış açığı tüm düğümün ele geçirilmesi anlamına gelir.

Unprivileged konteynerde en sık takıldığınız nokta, ana makineden bağlanan (bind mount) dizinlerde dosya sahipliğidir. Ana makinede 1000:1000 sahipli bir dizini konteynere bağlarsanız, konteyner içinde nobody:nogroup görünür. Çözüm, ana makinede dizini eşlenmiş UID'ye vermek ya da /etc/pve/lxc/101.conf içinde özel bir idmap tanımlamaktır:

# /etc/pve/lxc/101.conf içinde ana makine dizinini bağlama
mp0: /srv/veri,mp=/mnt/veri

Privileged konteynere gerçekten ihtiyacınız olan durumlar oldukça dardır: konteyner içinden NFS/CIFS mount etmek, bazı özel aygıtlara doğrudan erişmek gibi. Bunlar için bile önce alternatifi düşünün — mount'u ana makinede yapıp konteynere bind mount ile vermek, çoğu zaman aynı sonucu güvenli biçimde verir.

Kaynak Limitleri, Disk ve Ağ Ayarları#

LXC'de kaynak limitleri cgroup üzerinden uygulanır ve bu, KVM'e göre önemli bir avantaj sağlar: neredeyse hepsi konteyner çalışırken, yeniden başlatmadan değiştirilebilir. Belleği artırmak, çekirdek sayısını düşürmek, disk G/Ç sınırı koymak için konteyneri durdurmanız gerekmez.

# Bellek ve swap'i canlı değiştir
pct set 101 --memory 4096 --swap 1024

# CPU limitini ve önceliğini ayarla
pct set 101 --cores 4 --cpuunits 1024

# Kök diski 8 GB'tan 16 GB'a büyüt (küçültme yoktur)
pct resize 101 rootfs +8G

# İkinci bir ağ arayüzü ekle
pct set 101 --net1 name=eth1,bridge=vmbr1,ip=10.10.0.5/24

cpuunits mutlak bir limit değil, göreli bir ağırlıktır: CPU sıkıştığında hangi konteynerin öncelikli olacağını belirler. Sert bir tavan istiyorsanız --cpulimit 2 gibi bir değer kullanın; bu, konteynerin toplam 2 çekirdeklik CPU zamanı geçmesini engeller.

Bellek konusunda LXC'nin sevilen bir yanı var: ayrılan bellek gerçekten kullanılana kadar ana makineden alınmaz. 8 konteynere 2'şer GB tanımlayıp toplamda 16 GB'ı taahhüt edebilirsiniz; gerçek kullanım 3 GB ise ana makine yalnızca 3 GB harcar. Bu, disk tarafındaki thin provisioning mantığının bellek karşılığıdır ve aynı riski taşır: aşırı taahhüt ettiğinizde hepsi aynı anda dolarsa OOM killer devreye girer.

Disk tarafında kök dosya sistemini hangi depolamaya koyduğunuz performansı doğrudan etkiler. local-lvm (LVM-thin) hızlı ve anlık görüntü (snapshot) destekler; dizin tabanlı local depolamada konteyner diski raw bir dosya olur. Depolama formatlarının farkları için sanal disk formatları yazısına bakabilirsiniz.

Konteyner İçinde Docker ve nesting Ayarı#

Konteyner içinde Docker çalıştırmak isteyenlerin ilk karşılaştığı hata şudur: Docker daemon başlamaz, günlükte cgroup ya da mount izni hatası görürsünüz. Sebep, iç içe konteynerleştirmenin varsayılan olarak kapalı olmasıdır. Çözüm nesting özelliğini açmaktır:

# Konteyner durdurulmuşken
pct set 101 --features nesting=1,keyctl=1
pct start 101

keyctl=1, systemd ve bazı Docker depolama sürücülerinin ihtiyaç duyduğu çekirdek anahtarlık çağrılarına izin verir. Bu ikisi açıkken unprivileged bir konteyner içinde Docker genellikle sorunsuz çalışır ve overlay2 depolama sürücüsünü kullanır.

Yine de dürüst olalım: konteyner içinde konteyner çalıştırmak üretim için ideal bir mimari değildir. Docker iş yükleriniz büyüdüyse ya doğrudan ana makinede ya da ayrı bir KVM sanal makinesinde çalıştırmak daha temizdir. Docker'ın disk kullanımının nasıl kontrolden çıktığını ve nasıl temizlendiğini merak ediyorsanız Docker diski doldurdu yazısı bu konuyu ayrıntılı ele alıyor. Kendi hipervizörünüzü kurmak için iç içe sanallaştırma desteği arıyorsanız nested sanallaştırma sunucuları tam bu senaryo için yapılandırılmıştır.

Sık Yapılan Hatalar ve Çözümleri#

Yıllar içinde aynı hataların dönüp dolaşıp geldiğini görüyorum; en sık karşılaştığım altısını sebep-çözüm biçiminde toplayayım.

Konteyner açılıyor ama ağ yok. Genellikle köprü adı yanlıştır. --net0 içinde bridge=vmbr0 yazdınız ama düğümde köprü vmbr1 olabilir. Ana makinede ip -br link ve cat /etc/network/interfaces ile doğrulayın. İkinci sık sebep, ağ geçidini yazmayı unutmaktır; IP verilmiş ama gw yoksa konteyner yalnızca yerel ağı görür.

DNS çözümlenmiyor. Konteyner içinde ping 1.1.1.1 çalışıyor ama ping google.com çalışmıyorsa sorun DNS'tedir. pct set 101 --nameserver 1.1.1.1 ile açıkça bir çözümleyici verin. Şablona bağlı olarak /etc/resolv.conf dosyasının systemd-resolved tarafından yönetiliyor olması da sık bir kaynaktır.

Disk doldu ve büyütemiyorum. pct resize yalnızca büyütür. Küçültmek için yeni ve küçük bir konteyner oluşturup verileri taşımanız gerekir. Disk doluluk analizini nasıl yapacağınızı disk kullanımı df, du ve ncdu yazısında bulabilirsiniz.

Ana makine yeniden başladı, konteynerler açılmadı. --onboot 1 verilmemiştir. pct set 101 --onboot 1 ile düzeltin; ayrıca --startup order=2,up=30 ile açılış sırası ve gecikme tanımlayarak veritabanının uygulamadan önce ayağa kalkmasını sağlayabilirsiniz.

Bind mount'ta dosyalar nobody görünüyor. Unprivileged konteynerlerdeki UID eşlemesinin doğal sonucudur. Ana makinede dizini chown 100000:100000 yapmak en hızlı çözümdür.

Yedek aldım sandım, almamışım. Proxmox'un vzdump aracı konteyner yedeklerini de alır ama zamanlanmış bir görev tanımlamadıysanız hiçbir şey otomatik olmaz. Datacenter → Backup altından bir plan oluşturun ve geri yüklemeyi en az bir kez deneyin. Yedek stratejisi için Borg ile sunucu yedekleme yazısındaki artımlı yaklaşım konteyner içeriği için de geçerlidir.

Sıkça Sorulan Sorular#

LXC konteyner mi yoksa sanal makine mi daha hızlı#

LXC konteyner neredeyse her ölçüde daha hızlıdır çünkü arada bir çekirdek katmanı yoktur; süreçler doğrudan ana makinenin çekirdeğinde çalışır. Açılış süresi saniyeler yerine milisaniyeler mertebesindedir ve bellek yükü onlarca kat düşüktür. Ancak bu hız, izolasyonun daha zayıf olması pahasına gelir; güvenlik sınırı bir sanal makinenin sağladığı kadar sert değildir.

Proxmox LXC içinde Windows çalıştırabilir miyim#

Hayır, çalıştıramazsınız. LXC ana makinenin Linux çekirdeğini paylaşır, dolayısıyla konteyner içindeki her şey Linux olmak zorundadır. Windows çalıştırmanız gerekiyorsa KVM tabanlı bir sanal makine oluşturmalısınız. Aynı kısıt, farklı bir çekirdek sürümü ya da özel çekirdek modülü gerektiren Linux iş yükleri için de geçerlidir.

Unprivileged konteyner performansı düşürür mü#

Pratikte ölçülebilir bir performans farkı yaratmaz. Kullanıcı namespace eşlemesi çekirdek düzeyinde çok ucuz bir işlemdir ve CPU ya da bellek performansını etkilemez. Farkı hissedeceğiniz tek yer, bazı özel mount ve aygıt erişimlerinin kısıtlanmasıdır; bunlar da performans değil yetenek kısıtıdır. Güvenlik kazancı düşünüldüğünde varsayılanı değiştirmek için çok güçlü bir sebebiniz olmalı.

Bir LXC konteynerini başka bir Proxmox düğümüne nasıl taşırım#

En temiz yol vzdump ile yedek alıp hedef düğümde pct restore ile geri yüklemektir. Küme (cluster) kurulumunuz varsa web arayüzündeki Migrate düğmesi bu işi tek adımda yapar; paylaşımlı depolama kullanıyorsanız taşıma saniyeler sürer, yerel depolamada ise disk kopyalanacağı için boyuta bağlı olarak dakikalar alır. Taşımadan önce konteynerin durdurulması, veri tutarlılığı açısından en güvenli yaklaşımdır.

Konteynere kaç RAM vermeliyim#

Servisin gerçek kullanımını ölçüp üzerine pay ekleyerek karar verin. Küçük bir reverse proxy ya da DNS önbelleği için 256-512 MB fazlasıyla yeter; bir PostgreSQL örneği ya da orta ölçekli bir uygulama sunucusu için 2-4 GB mantıklı bir başlangıçtır. LXC'de ayrılan bellek kullanılmadıkça harcanmadığı için cömert davranabilirsiniz, ancak toplam taahhüdün ana makine belleğini aşırı geçmesine izin vermeyin.

LXC konteyner yedeğini nasıl alırım#

Proxmox'un vzdump aracı konteynerin tüm kök dosya sistemini ve yapılandırmasını tek bir arşive alır: vzdump 101 --storage local --mode snapshot komutu çalışan konteyneri durdurmadan anlık görüntü üzerinden yedekler. Düzenli koruma için Datacenter → Backup altında zamanlanmış bir plan tanımlayın ve saklama sayısını ayarlayın. Yedek almak yetmez; en az bir kez test geri yüklemesi yaparak arşivin gerçekten açıldığını doğrulayın.

Konteyner IP adresini sonradan değiştirebilir miyim#

Evet, hem de konteyner çalışırken. pct set 101 --net0 name=eth0,bridge=vmbr0,ip=185.12.34.60/24,gw=185.12.34.1 komutu arayüzü yeni adresle yeniden yapılandırır. Bazı dağıtımlarda ağ servisinin değişikliği tam olarak alması için konteyner içinde ağ servisini yeniden başlatmak ya da konteyneri kısaca yeniden başlatmak gerekebilir. Değişiklik /etc/pve/lxc/101.conf dosyasına da yansır.

Kapanış#

Proxmox'ta LXC konteyner oluşturmak teknik olarak birkaç dakikalık bir iştir, ama uzun vadede sorunsuz çalışan bir kurulum birkaç alışkanlığa bağlıdır: şablonları pveam ile güncel tutmak, özel bir sebep yoksa daima unprivileged konteyner kullanmak, --onboot 1 ve açılış sırasını baştan tanımlamak, ve kaynak limitlerini panelde değil pct set ile tekrarlanabilir biçimde vermek. Bir de yedeği kurulumun sonuna değil başına koymak — çünkü geri yüklemeyi denemediğiniz bir yedek, yedek değildir.

Kendi hipervizörünüzü kurup bu tür konteyner altyapılarını yönetmek istiyorsanız tam root erişimli VDS sunucular ve iç içe sanallaştırma desteği açık nested sanallaştırma paketleri bu iş için uygundur. Donanımı ve çekirdek ayarlarını tamamen kendiniz belirlemek istiyorsanız dedicated sunucu seçeneğine bakabilir, kurulum ve bakım yükünü üstlenmek istemiyorsanız sunucu yönetimi hizmetimizle bu işi bize bırakabilirsiniz. Yedekleme planınızı otomatikleştirmek için de yedekleme çözümlerimiz konteyner ve sanal makine arşivlerini birlikte kapsar.