[ OK ]Kernel başlatılıyor...
~/im/blog
Beni İşe Alın

Konuşalım

Çözülmesi gereken bir altyapı probleminiz mi var veya projeniz için desteğe mi ihtiyacınız var? Yeni projeler için bana ulaşabilirsiniz.

İletişime geç

Bağlantılar

Beni sosyal medyada ve profesyonel ağlarda bulun.

© 2026 Irfan Miral. Tüm hakları saklıdır.Geliştiren:Irfan Miral
Gizlilik PolitikasıŞartlar & Koşullar
Ana SayfaHizmetlerHakkımda/ÖzgeçmişBlogİletişimAraçlar
2026-05-20• 5 dk okuma süresi

Proxmox'ta Docker vs LXC: Canlı Ortamda Gerçekte Ne Kullanıyorum?

DevOps Proxmox Docker Virtualization

Reklam

Yeni bir Proxmox sunucusunu ne zaman ayağa kaldırsam, sonunda hep aynı soruyla karşılaşıyorum: "Neden her şeyi Docker'da çalıştırmıyoruz?" Haklı bir soru. Docker imajları taşınabilirdir, ekosistemi devasadır ve yazılımcıların çoğu zaten bir Dockerfile yazmayı bilir. Ancak yıllarca MariaDB Galera cluster'ları, PostgreSQL, Redis, RabbitMQ ve müşterilerin önüme koyduğu envaiçeşit uygulama yığınını yönettikten sonra, artık neredeyse hiç dışına çıkmadığım katı bir ayrım oturttum.

Durum tutan (stateful) ve uzun ömürlü servisler için LXC

Veritabanları, önbellekler (cache) ve mesaj kuyrukları söz konusu olduğunda, doğrudan Proxmox üzerinde çalışan LXC konteynerlerine yönelirim. LXC, ana makinenin (host) çekirdeğini (kernel) paylaşır, bu yüzden ortada bir sanallaştırma yükü yoktur. Disk I/O ve bellek tüketimi tıpkı bare-metal bir sunucudaymış gibi davranır. Bir MariaDB Galera node'u veya Redis instance'ı için aradaki bu performans farkı, özellikle küçük VPS donanımlarında benchmark sonuçlarına anında yansır.

Diğer neden ise tamamen operasyoneldir. Bu servisler yıllarca yaşar. İstediğim zaman pct enter ile konteynere girip iostat kontrol edebilmek, innodb_buffer_pool_size ayarını yapabilmek veya araya dosya sistemini soyutlayan fazladan bir konteyner motoru girmeden hızlıca bir pg_dump alabilmek isterim. Proxmox seviyesinde alınan yedeklemeler (vzdump) tıkır tıkır çalışır ve tek bir LXC'yi geri yüklemek sadece beş dakikalık bir iştir.

Neden LXC içinde Docker asla seçenek değil?

Başlarda "LXC içinde Docker (Docker-in-LXC)" yolunu denedim. Hem LXC'nin hafifliği hem de Docker'ın paketleme kolaylığı bir arada olduğu için iki dünyanın da en iyi yanlarını sunuyor gibi görünüyordu. Ancak pratikte, tek bir çekirdek üzerinde iki katmanlı konteynerizasyon kurmak oldukça kırılgandır ve genelde en olmadık zamanlarda patlar.

Öncelikle nesting (iç içe geçme) özelliğini açmanız ve AppArmor profilini gevşetmeniz gerekir ki bu durum LXC'nin size en başta sunduğu güvenlik avantajını anında yok eder. Sonra bir gün ana makinede (host) yapılan rutin bir kernel güncellemesi, içteki Docker daemon'unun overlay depolama sürücüsünü sessizce bozar ve durumu ancak sıradan bir pct reboot sonrası konteynerler ayağa kalkmadığında fark edersiniz.

Daha yeni Proxmox sürümleri LXC içine yerleşik OCI imaj desteği ekledi. Bu gerçekten işe yarar bir orta yoldur: standart bir imajı çekip hiç Docker daemon kurmadan LXC olarak çalıştırabilirsiniz. Eskiden ufak bir Docker konteyneri açacağım küçük ve durum tutmayan (stateless) servisler için bunu kullanmaya başladım. Ancak altında bir veritabanı yatan herhangi bir şey için hala uzak duruyorum.

Docker, ama bir VM içinde

Bir müşteri bana Dockerfile veya docker-compose yığını olarak paketlenmiş bir uygulama teslim ettiğinde (ki bugünlerde çoğu böyle geliyor), bu yığın bir LXC'ye değil, kendi bağımsız Proxmox sanal makinesine (VM) gider.

VM, Docker'a kendine ait, izole edilmiş gerçek bir çekirdek sunar. Proxmox host çekirdeğindeki güncellemeler konteyner motoruna sıçramaz ve Docker'ın sürekli yeniden yazmaya bayıldığı iptables kuralları, ana makinenin güvenlik duvarıyla çatışmak yerine o VM'in içinde hapsolur.

Evet, bu Docker-in-LXC'ye kıyasla fazladan bir sanallaştırma katmanı demek. Ancak host kernel güncellemesi birinin iç içe geçmiş Docker daemon'unu bozduğu için gece 3'te bir çağrı cihazıyla hiç uyandırılmadım. Canlı sistemler için bu takas her zaman buna değer.

Asıl iş bölümü

Eğer bunu bir kural olarak yazmam gerekirse: durum tutan (stateful) altyapılar (veritabanları, kuyruklar, cache) doğrudan Proxmox üzerinde LXC olarak çalışır. Uygulama konteynerleri bir VM içinde Docker olarak koşar. Küçük, durum tutmayan araçlar ise seçenek mevcut olduğu için giderek artan oranda yerleşik OCI-in-LXC olarak çalıştırılıyor.

Bunların hiçbiri değişmez bir dogma değildir. Bir iş yükü gerçekten Kubernetes gerektiriyorsa, o tamamen farklı bir konuşmanın konusudur. Ancak yönettiğim küçük ve orta ölçekli altyapılar için bu ayrım bugüne kadar bulduğum en sıkıcı ve en öngörülebilir düzendir. Ve altyapı dediğiniz şeyden tam olarak beklediğiniz de "sıkıcı" olmasıdır.

Reklam

Yardıma mı ihtiyacınız var?

Eğer Konteynerleştirme ve Otomasyon işini sizin yerinize birinin halletmesini tercih ederseniz, benim asıl işim tam olarak bu.

İletişime Geç
ÖncekiTers Vekil (Reverse Proxy) Olarak HAProxy mi Nginx mi? Nasıl Karar VeriyorumSonraki Gerçekten Geri Yükleyebileceğiniz PostgreSQL Yedekleri: pgBackRest Kurulumu