Docker için minimum sunucu gereksinimleri: Net kontrol listesi

Sunucuda Docker kullanmak, uygulamaları izole çalıştırmak ve ölçeklendirmek için pratik bir yöntemdir. Ancak “Docker kurdum, çalışıyor” noktası ile “üretim (production) yükünde sorunsuz çalışıyor” noktası farklıdır. Bu rehberde Docker için minimum gereksinimleri; CPU, RAM, depolama (disk), ağ ve işletim sistemi tarafında net eşikler ve ölçülebilir test önerileriyle anlatıyoruz. Böylece ihtiyacınız olan kaynakları doğru tahmin edip kapasite sürprizi yaşamazsınız.

1) Minimum hedefler: Docker tek konteyner mi, çoklu mu?

Docker’ın gereksinimleri, konteyner sayısına ve konteynerlerin yaptıklarına göre değişir. Minimum planı yaparken önce şu ayrımı netleştirin:

• Tek konteyner / hafif yük: Örnek olarak basit bir web statik sitesi, küçük bir API, kısa iş kuyruğu.
• Birden fazla konteyner / gerçek uygulama: Örnek olarak web + worker + cache (Redis) + veritabanı (mümkünse ayrı) gibi bir set.
• Üretim yükü (production): Trafik + log/metrics + yedek + güncelleme döngüsü olan kurulum.

Bu rehberde “minimum”u şu şekilde ele alıyoruz: Konteynerler çalışır, servisler temel trafik alır, sistem çökmeyecek şekilde kaynak payı bırakır.

Tek konteyner için pratik minimum

Aşağıdaki değerler, temel çalışma için başlanabilecek alt limitlerdir:

• CPU: 2 vCPU (en düşük), 4 vCPU (daha rahat)
• RAM: 2 GB (minimum), 4 GB (öneri)
• Disk: 20 GB (minimum), 50 GB (öneri)
• Ağ: 1 Gbps paylaşımlı hat bile minimum için çoğu senaryoda yeterlidir, ancak bant genişliği ve gecikme (latency) kritik olur.

Not: Disk “boş alan” değil, Docker’ın görüntü (image) katmanları, konteyner log’ları, uygulama dosyaları ve veri için kullanılacak toplam alanı kapsar.

2) CPU gereksinimi: En sık yanılgı “yeterli” sanmaktır

CPU, özellikle konteynerler aynı anda ayağa kalktığında, derleme/işleme yaptığında ve sık döngülü background job çalıştığında hızla darboğaz olur.

Hangi durumlar CPU’yu erken tıkar?

• Uygulama image üzerinde build süreçleri (ör. sürekli npm install, pip install) konteyner içinde yapılıyorsa
• Çok sayıda eşzamanlı istek (concurrency)
• Dosya sıkıştırma, şifreleme, görsel işleme gibi CPU yoğun işler
• Aynı sunucuda başka servislerin de çalışması (ör. kontrol panel, izleme ajanları)

Minimum CPU eşiği

• 2 vCPU: Tek konteyner + hafif trafik
• 4 vCPU: 2-3 konteyner (web + worker + cache) veya daha yüksek istek hacmi
• 8 vCPU+: Üretim ve daha yoğun iş yükleri (özellikle veritabanı da sunucuda ise)

CPU’yu net görmek için şu kontrolü yapın: - Konteynerler çalışırken docker stats çıktısında CPU yüzdelerine bakın. - Sunucu genelinde top/htop ile “CPU iowait” ve “user/system” dağılımına bakın.

3) RAM gereksinimi: Docker izolasyonu RAM’i artırır

Docker, her konteyner için süreç alanı sağlar; bu da “RAM’i paylaşınca sorun olmaz” gibi bir varsayımı yanıltıcı yapar. Özellikle uygulama runtime’leri (Java, Node, .NET, Python), cache, reverse proxy buffer’ları ve log yazma davranışı RAM tüketimini büyütür.

Minimum RAM eşikleri

• 2 GB RAM: Sadece çok hafif tek konteyner
• 4 GB RAM: Tek veya 2 konteyner (web + küçük worker)
• 8 GB RAM: 3-4 konteyner veya daha yoğun istek + log/metrics
• 16 GB ve üzeri: Üretim + ELK/Prometheus gibi ek ekosistemler

RAM’i yanlış okuma riski

Aşağıdaki durumlar “kurulum anında RAM az gözükürken” sonradan patlama yaşatır: - Uygulamada bellek sızıntısı - Cache’in büyümesi (Redis gibi bile olsa) - Konteyner log’larının kontrolsüz artması - Aynı sunucuda veri tabanı çalıştırılması

4) Disk (depolama) gereksinimi: Container değil, katman ve veri belirler

Docker’ın disk tüketimi sadece konteyner dosyalarıyla sınırlı değildir. Şunlar diski yer:

• Docker image katmanları
• Çalışan konteyner log’ları
• Volume (veri) kullanımı
• Build cache (ör. Dockerfile adımlarının tekrar tekrar üretilmesi)

Minimum disk eşikleri

• 20 GB: Tek konteyner + sınırlı trafik + minimal log
• 50 GB: Ortalama üretim öncesi kullanım
• 100 GB+: Daha fazla konteyner, sık image güncellemesi, log/volume yoğun sistemler

Hız kritik mi?

Evet. Disk IOPS ve gecikme (latency) özellikle şu durumlarda fark yaratır: - Veritabanı aynı makinada çalışıyorsa - Çok sayıda küçük dosya (microfiles) yazılıyorsa - Loglar yoğun akıyorsa

Pratik yaklaşım: - Veri tabanını mümkünse Docker dışında veya ayrı bir disk/ayrı sanal disk mantığıyla konumlayın. - Volume için “kalıcı disk” kullanımını planlayın.

5) Ağ (network) gereksinimleri: Portlar, DNS ve gecikme

Docker gereksinimlerinde ağ çoğu kişi tarafından “kurulumdan sonra hallederim” diye geçilir. Oysa ters proxy, load balancer, DNS kayıtları ve container-to-host iletişimi performansı etkiler.

Minimum ağ planı

• 80/443 için gelen trafik akışı (reverse proxy üzerinden)
• Uygulama içi iletişim için doğru port eşleme ve container network planı
• DNS çözümlemesi (domain A/AAAA kaydı + gerekiyorsa CNAME)

Kontrol listesi

• Uygulama erişimi: Domain -> reverse proxy -> container
• HTTPS: sertifika yenileme planı (otomasyon)
• Rate limit: brute force ve ani trafiğe karşı (reverse proxy katmanında)
• İzleme: ağ gecikmesi ve hata oranları

6) Minimum işletim sistemi ve Docker kurulumu: Temel uyum

Docker; çekirdek (kernel) özellikleri, dosya sistemi (filesystem), cgroup ve network modülleriyle çalışır. Bu yüzden “minimum”u yalnızca RAM/CPU değil, OS uyumu olarak düşünmelisiniz.

Minimum OS yaklaşımı

• Debian/Ubuntu tabanlı sunucular: pratik ve yaygın
• AlmaLinux/Rocky Linux: kurumsal sürümlerde stabil tercih
• Versiyon: 64-bit, güncel kernel ve güvenlik güncellemeleri aktif

Kernel/cgroup uyumu için net beklenti

• Konteyner ağının (bridge/overlay) düzgün çalışması
• Resource limit’lerin (CPU/RAM limitleri) uygulanabilmesi
• Log rotasyonu ve disk dolmasına karşı önlem

7) Net gereksinimler özeti: “Docker çalıştırmak” ile “işletmek” farkı

Aşağıdaki tablo, farklı senaryolar için minimum başlangıç profilini özetler. Buradaki değerler “kuru kurulum” değil; gerçekçi, yönetilebilir bir minimumdur.

Docker işletiminde “minimum” diye atlanmaması gerekenler

• Yedekleme (backup): Volume’lar için düzenli plan
• Otomatik log yönetimi: log rotasyonu ve log boyutu kontrolü
• Resource limit: konteyner bazlı CPU/RAM sınırları
• Güncelleme stratejisi: image güncelleme + rollback planı

8) Production’a geçiş için test ve ölçüm planı

Minimum gereksinimleri bilmek tek başına yetmez. Sunucu “kâğıt üzerinde yeterli” olsa bile uygulama davranışı fark yaratır. Bu yüzden kısa bir ölçüm planı yapın.

Hızlı doğrulama testleri

1. Konteyner ayağa kaldırma testi: Sistem yükü altında (örn. docker compose ile) tüm servisleri aynı anda başlatın.
2. İstek yükü testi: Basit bir load testi yapın (ör. 1-2 dakika) ve hatayı/latency’yi kaydedin.
3. Disk artışı testi: Logları zorlayın; disk kullanımının ne kadar sürede şiştiğine bakın.
4. Uzun süre dayanıklılık: En az 30-60 dakika çalıştırın; RAM ve swap durumunu izleyin.

Sonuç eşikleri (pratik)

• CPU sürekli %70-90 bantlarında kalıyorsa: vCPU artırın veya iş yükünü ayırın
• RAM düzenli olarak %80+ bandına çıkıyorsa: konteyner limitlerini ve uygulama ayarlarını gözden geçirin
• Disk %70+ doluyorsa: log/volume temizliği veya disk büyütme planı yapın

Sonuç: Minimumu seçin, sonra ölçümle doğrulayın

Docker için minimum gereksinimler; 2 vCPU/2 GB/20 GB gibi “çalıştırma eşiği” ile 4+ vCPU/4+ GB/50+ GB gibi “yönetilebilir işletim” arasında net bir fark taşır. En doğru yaklaşım, hedef senaryonuz için bir başlangıç profili seçmek ve ardından docker stats, disk kullanımı ve temel yük testleriyle “gerçekten yeterli mi”yi doğrulamaktır. Aksiyon olarak: senaryonuza göre yukarıdaki tabloyu kullanın, konteynerleri resource limit ile başlatın ve ilk haftada disk/log/RAM değişimini düzenli izleyin. Böylece üretim sürprizleri olmadan kapasiteyi net şekilde sabitlemiş olursunuz.