LXC mi Docker mı Sanal Makine mi? Doğru İzolasyonu Seçmek

Kısa cevap: LXC, Docker ve sanal makine arasındaki fark teknolojide değil, güven sınırının nereye çizildiğindedir. Sanal makine kendi çekirdeğini çalıştırır ve en sert sınırı verir. LXC bir sistem konteyneridir: hafif bir sunucu gibi davranır, uzun ömürlüdür, birden fazla servis barındırır. Docker ise uygulama konteyneridir: tek süreç çalıştırır, silinip yeniden oluşturulmak üzere tasarlanmıştır.

Üçü de “izolasyon” diyor, farkı ne?

Teknik temel şudur: sanal makine donanımı taklit eder ve içinde ayrı bir çekirdek çalıştırır. Konteynerler ise ana sistemin çekirdeğini paylaşır; izolasyonu iki çekirdek mekanizmasıyla sağlarlar:

• Namespace: Süreçlerin ne görebileceğini sınırlar. Konteyner içindeki süreç yalnız kendi süreçlerini, kendi ağ arayüzlerini ve kendi dosya sistemini görür.
• cgroup: Süreçlerin ne kadar kaynak tüketebileceğini sınırlar (CPU, bellek, disk giriş çıkışı).

Bu iki mekanizma hem LXC hem Docker tarafından kullanılır. Yani LXC ile Docker arasındaki fark teknolojide değil, kullanım felsefesindedir.

	Sanal makine	LXC (sistem konteyneri)	Docker (uygulama konteyneri)
Çekirdek	Kendi	Ana sistemin	Ana sistemin
İçinde ne çalışır	Tam işletim sistemi	init + birden fazla servis	Genellikle tek süreç
Ömür	Uzun (yıllar)	Uzun (aylar, yıllar)	Kısa (silinir, yeniden oluşturulur)
Yapılandırma	Sistem içinden	Sistem içinden	İmaj ve ortam değişkenleriyle
Açılış	Onlarca saniye	Saniyeler	Saniyenin altı
Disk maliyeti	Gigabaytlar	Yüzlerce megabayt	Megabaytlar (katman paylaşımlı)
İzolasyon gücü	En yüksek	Orta	Orta
Windows barındırma	Var	Yok	Yok

Sistem konteyneri ile uygulama konteyneri arasındaki fark nedir?

Bu ayrımı kavramak, doğru seçimin yarısıdır.

LXC’ye bir sunucu gibi davranırsınız. İçine SSH ile girersiniz, paket yöneticisiyle yazılım kurarsınız, systemd servisleri çalışır, güncellemelerini yaparsınız. Bir sanal makineye alışkın olan herkes LXC’de kendini evinde hisseder; fark, yalnız çok daha hafif olmasıdır. Uzun ömürlüdür: bir yıl önce kurduğunuz LXC hâlâ aynı LXC’dir.

Docker’a bir süreç gibi davranırsınız. İçine girmezsiniz, güncellemezsiniz. Yeni sürüm çıktığında konteyneri silip yeni imajdan yeniden oluşturursunuz. Yapılandırma dışarıdan (ortam değişkenleri, bağlanan dosyalar) verilir, veri dışarıda (hacimlerde) durur. Konteynerin kendisi geçicidir ve bu bir kusur değil, tasarımın merkezidir.

Buradan pratik bir sonuç çıkar: bir uygulamayı Docker’da çalıştırıp içine girerek elle yapılandırırsanız Docker’ı yanlış kullanıyorsunuzdur. O değişiklik, konteyner bir sonraki güncellemede yeniden oluşturulduğunda kaybolur. Docker’ın doğru üretim kullanımını Docker Compose üretim rehberinde, verinin nasıl kalıcı tutulacağını Docker veri kalıcılığı yazısında anlattım.

Ayrıcalıklı ve ayrıcalıksız konteyner: güvenlik farkı

Proxmox’ta LXC oluştururken karşınıza çıkan Unprivileged container kutusu, güvenlik açısından bu ekrandaki en önemli seçenektir.

Ayrıcalıksız konteynerde kullanıcı ad alanı eşlemesi devrededir: konteyner içindeki root (UID 0), ana sistemde yetkisiz yüksek numaralı bir kullanıcıya (örneğin 100000) eşlenir. Konteynerden çıkış sağlayan bir açık kullanılsa bile, saldırganın ana sistemde eline geçen şey sıradan bir kullanıcıdır.

Ayrıcalıklı konteynerde bu eşleme yoktur; içerideki root, ana sistemin root’una çok daha yakındır. Çekirdekteki bir açık, doğrudan ana sistemin ele geçirilmesine dönüşebilir.

Kural: zorunlu olmadıkça daima ayrıcalıksız. Ayrıcalıklı konteyner gerektiren durumlar azdır (bazı özel donanım erişimleri, belirli dosya sistemi bağlamaları) ve bunların çoğunda doğru cevap zaten sanal makineye geçmektir.

Docker tarafında benzer bir ayrım vardır ve daha az bilinir: varsayılan kurulumda Docker daemon root olarak çalışır ve docker grubuna eklenen bir kullanıcı, pratikte ana sistemde root yetkisi elde edebilir (bir konteyneri ana sistemin kök dizinini bağlayarak çalıştırmak yeterlidir). Bu yüzden docker grubu üyeliği, sudo yetkisi kadar ciddiye alınmalıdır. Alternatif olarak rootless Docker kullanılabilir; ayrıntısını Docker güvenlik sertleştirme yazısında ele aldım.

Proxmox’ta LXC içinde Docker: neden önerilmiyor?

Bu, Proxmox kullanıcılarının en sık sorduğu sorulardan biri ve cevabı net: yapmayın, Docker için ayrı bir sanal makine açın.

Gerekçe şu: Docker’ın ihtiyaç duyduğu bazı çekirdek yetenekleri ve dosya sistemi işlemleri, ayrıcalıksız bir LXC içinde kısıtlıdır. Çalıştırmak için ya konteyneri ayrıcalıklı yapmanız ya da güvenlik kısıtlarını tek tek gevşetmeniz gerekir. Bunu yaptığınızda LXC’nin size verdiği izolasyon avantajının önemli bir kısmını kaybedersiniz; geriye kalan, hem karmaşık hem de daha az güvenli bir kurgudur.

İkinci gerekçe pratiktir: iç içe geçmiş katmanlarda (LXC içinde Docker) ağ ve depolama sorunlarının teşhisi belirgin biçimde zorlaşır. Bir sorunun hangi katmandan kaynaklandığını bulmak, aynı sorunu düz bir sanal makinede çözmekten kat kat uzun sürer.

Önerilen kurgu:

Fiziksel sunucu
└── Proxmox VE (hipervizör)
    ├── LXC: DNS, izleme ajanı, dahili araçlar   (hafif sistem servisleri)
    ├── VM: Docker host                          (uygulama konteynerleri burada)
    │   ├── konteyner: web uygulaması
    │   ├── konteyner: veritabanı
    │   └── konteyner: ters vekil sunucu
    └── VM: veritabanı sunucusu                  (ayrı güven sınırı gerekiyorsa)

Bu yapı, her katmanı yaptığı işte kullanır: hipervizör güven sınırlarını çizer, LXC hafif sistem servislerini ucuza barındırır, Docker uygulamaları taşınabilir biçimde çalıştırır. Hipervizör kurulumu Proxmox VE kurulum rehberinde, ağ yapısı Proxmox ağ yapılandırması yazısında.

Hangi iş yükü için hangisi seçilmeli?

İş yükü	Seçim	Gerekçe
Windows sunucu, Active Directory	Sanal makine	Farklı çekirdek zorunlu
Sanal router (MikroTik CHR, pfSense)	Sanal makine	Kendi çekirdeği ve ağ yığını gerekir
Farklı müşterilere ait iş yükleri	Sanal makine	Güven sınırı sert olmalı
Veritabanı (üretim)	Sanal makine veya adanmış konteyner	Disk performansı ve tutarlılık kritik
DNS, dahili araç, izleme ajanı	LXC	Hafif, uzun ömürlü sistem servisi
Geliştirme ve test ortamı	LXC	Hızlı oluşturulur, ucuz
Web uygulaması, API servisi	Docker	Taşınabilir, sürüm yönetimi kolay
Sık deploy edilen uygulama	Docker (+ dağıtım katmanı)	Yeniden oluşturma modeli buna uygun
Çekirdek modülü yükleyen yazılım	Sanal makine	Konteynerde mümkün değil
Tek yükün donanımı tam kullandığı durum	Fiziksel	Sanallaştırma katmanı gereksiz yük

Uygulamalarınızı sürekli deploy ediyorsanız Docker’ı elle yönetmek yerine bir dağıtım katmanı kurmak işi belirgin biçimde kolaylaştırır; kendi sunucunuzda çalışan bu katman için Coolify ile self-hosted PaaS yazısına bakın.

Kaynak tüketimi: gerçek fark ne kadar?

Sayısal karşılaştırma, seçimi somutlaştırır. Basit bir web servisi çalıştırmak için tipik kaynak ihtiyacı:

	Sanal makine	LXC	Docker
Boştaki bellek	Yüzlerce MB (işletim sistemi)	Onlarca MB	Yalnız süreç kadar
Disk (temel kurulum)	Birkaç GB	Birkaç yüz MB	Onlarca MB (katman paylaşımlı)
Açılış süresi	20-60 saniye	1-3 saniye	1 saniyenin altı

Bu fark, tek servis için önemsiz görünür ama ölçekle çarpılır. Yirmi küçük servisi ayrı sanal makinelerde çalıştırmak, aynı işi konteynerlerle yapmaya göre kat kat fazla bellek ister ve bu bellek, iş yapmayan işletim sistemi kopyalarına gider.

Bununla birlikte ters yönde bir uyarı da gerekir: kaynak tasarrufu için güvenlik sınırını feda etmeyin. Farklı güven seviyelerine ait iki iş yükünü aynı çekirdek üzerinde çalıştırmanın tasarrufu, olası bir ihlalin maliyetinin yanında önemsizdir.

Konteyner seçiminde en sık yapılan hatalar neler?

1. Docker konteynerine sunucu gibi davranmak. İçine girip elle yapılandırmak, ilk güncellemede kaybolacak bir iş yapmaktır.
2. LXC’yi ayrıcalıklı açmak. Kutu varsayılan olarak işaretli gelir diye bırakmak, izolasyonun büyük kısmını feda etmektir.
3. LXC içinde Docker çalıştırmak. Karmaşık, daha az güvenli ve teşhisi zor.
4. docker grup üyeliğini hafife almak. Bu üyelik pratikte root yetkisidir.
5. Konteyner verisini konteyner içinde tutmak. Konteyner silindiğinde veri gider; ayrıntısı Docker veri kalıcılığı yazısında.
6. Her şeyi tek seçenekle çözmeye çalışmak. “Artık her şey Docker” veya “konteyner güvensiz, hepsi sanal makine” yaklaşımlarının ikisi de gereksiz maliyet üretir.

Sanallaştırma kararlarının genel çerçevesi için sanallaştırma rehberine, sunucu katmanlarının bütünü için Linux sunucu yönetimi yol haritasına bakabilirsiniz. Konteyner güvenliğini derinleştirmek isterseniz Docker güvenlik sertleştirme yazısı bu kararların güvenlik ayağını tamamlıyor.

Karma altyapı tasarımı (hangi iş yükü nerede çalışacak) kurumsal ölçekte planlanacaksa sistem yönetimi ve cloud çözümleri hizmet sayfalarına bakabilirsiniz.

Kaynaklar

• namespaces(7) manual page (konteyner izolasyonunun çekirdek mekanizmaları)
• Proxmox VE: Linux Container (LXC yönetimi, ayrıcalıklı ve ayrıcalıksız fark)
• Docker security (daemon yetkisi ve kullanıcı ad alanı eşlemesi)