Kısaca özet
- Docker için hangi sunucu sorusunun kısa cevabı: root erişimi olan ve kendi çekirdeğini yönetebildiğiniz bir VPS ya da VDS; paylaşımlı hosting Docker çalıştırmaz.
- Docker’ın arka plan servisi (daemon), resmî güvenlik belgesine göre rootless mod seçilmedikçe root yetkisiyle çalışır; paylaşımlı hostingte root ve SSH erişimi yoktur.
- Tek konteynerli küçük bir web uygulaması 1–2 vCPU ve 2 GB RAM ile başlar; uygulama, veritabanı ve önbellekten oluşan bir Compose yığını için 2–4 vCPU ve 4–8 GB RAM daha gerçekçidir.
- Docker sunucularında çoğu zaman önce disk biter: imajlar, derleme önbelleği ve varsayılan ayarda döndürülmeyen log dosyaları hızla birikir.
- Sanallaştırma türü önemlidir; konteyner tabanlı bir sanal sunucuda Docker ya hiç çalışmaz ya da sağlayıcının özel ayarına bağlıdır.
- VPS ve VDS yönetimsizdir: Docker kurulumu, güncellemesi ve güvenlik duvarı düzeni sunucu sahibine aittir.
Bir uygulamayı geliştirici bilgisayarında Docker Compose ile ayağa kaldırdınız, şimdi aynı yığını canlıya almak istiyorsunuz. İlk akla gelen, zaten ödenen paylaşımlı hosting paketi oluyor; panelde ne Docker ne de komut satırı görünüyor. Sonraki soru hangi sunucu türünün ve ne kadar kaynağın yeteceği. Bu karar yanlış verildiğinde ya gereksiz büyük bir sunucuya para ödenir ya da ilk yoğun günde disk dolar ve konteynerler durur.
Docker İçin Hangi Sunucu Gerekir, Kısa Cevap
Docker için hangi sunucu seçileceğini üç şart belirler: root erişimi, Docker’ın çekirdek özelliklerini kullanabileceği bir sanallaştırma türü ve iş yükünü taşıyacak kadar işlemci, bellek ve disk. İlk iki şart sunucu türünü, üçüncüsü paket büyüklüğünü seçtirir.
Pratikte bu, root erişimli bir VPS ya da VDS demektir. Trafik dalgalanıyor ve kaynağı hızla büyütmeniz gerekebiliyorsa bulut sunucu, onlarca konteyneri sürekli yüksek yükte çalıştıracaksanız fiziksel sunucu devreye girer. Üç sunucu türünün genel karşılaştırmasını VPS mi VDS mi bulut sunucu mu rehberinde bulabilirsiniz.
Paylaşımlı Hostingte Docker Neden Çalışmaz
Paylaşımlı hosting yüzlerce hesabın aynı işletim sistemini paylaştığı, her hesabın kaynak kotasıyla sınırlandığı bir yapıdır. Bu yapıda root erişimi hiçbir müşteriye verilmez ve SSH erişimi de kapalıdır. Docker Engine güvenlik belgesi Docker daemon’ının rootless mod seçilmedikçe root yetkisi istediğini açıkça yazar; bu yetkinin paylaşımlı bir sunucuda bir müşteriye verilmesi, diğer tüm hesapları riske atmak anlamına gelir.
Rootless mod bu engeli kaldırmaz. O modda da sunucuya ek paketlerin kurulması, kullanıcı ad alanlarının tanımlanması ve sürekli çalışan bir arka plan sürecinin başlatılması gerekir; paylaşımlı hostingin sağladığı panel araçları bunların hiçbirine izin vermez. Aynı sınır Python ve Node.js uygulamalarında da geçerlidir; bu tarafı Python ve Node.js için hangi hosting yazısında ayrıca ele alınıyor.
Bilgi
Docker konteynerleri, Linux çekirdeğinin ad alanları (namespaces) ve kaynak grupları (cgroups) özelliğiyle birbirinden ayrılır. Bu yüzden Docker’ın çalışacağı sunucunun kendi çekirdeğini yönetebilmesi gerekir. Tam sanallaştırma kullanan sanal sunucular bu şartı sağlar; konteyner tabanlı sanallaştırmada ise çekirdek ana makineye aittir.
VPS, VDS, Bulut ya da Fiziksel Sunucu
Docker kendi başına hafif bir katmandır; konteynerler sanal makine gibi ayrı bir işletim sistemi taşımadığı için ek yükleri düşüktür. Bu yüzden sunucu türünü Docker değil, konteynerlerin içinde çalışan iş belirler.
Bir API, bir yönetim paneli ya da düşük trafikli bir web uygulaması VPS’te rahat çalışır. Veritabanı konteyneri yanıt süresine duyarlıysa ya da gün boyu sabit yük altında çalışan servisleriniz varsa, işlemci payı size sabit ayrılan VDS daha öngörülebilir sonuç verir. Kampanya dönemlerinde birkaç katına çıkan trafik için bulut sunucu, sürekli yüksek disk ve işlemci isteyen derleme çiftlikleri ya da çok sayıda müşteri ortamı için fiziksel sunucu mantıklıdır.
Dikkat
Paket sayfasında “root erişimi” yazması, Docker’ın çalışacağının garantisi değildir. Konteyner tabanlı sanal sunucularda Docker servisi başlamayabilir. Sipariş öncesinde sağlayıcıya Docker ve Docker Compose’un ek ayar gerekmeden çalışıp çalışmadığını sorun.
Docker İş Yüküne Göre Kaynak Tahmini
Aşağıdaki aralıklar başlangıç noktasıdır, kesin ölçü değildir. Aynı yığın farklı trafikte çok farklı kaynak tüketir. Küçük tarafta başlayıp gerçek kullanımı izlemek, ilk günden büyük paket almaktan daha isabetlidir.
| İş yükü | vCPU | RAM | Disk | Not |
|---|---|---|---|---|
| Tek konteyner web uygulaması veya API | 1–2 | 2 GB | 30–40 GB | Veritabanı dışarıdaysa en hafif senaryo |
| Compose yığını: uygulama, veritabanı, önbellek | 2–4 | 4–8 GB | 50–80 GB | Belleğin çoğunu veritabanı ister |
| CI runner (derleme ve test işleri) | 4 ve üzeri | 8 GB | 80–100 GB ve üzeri | Derleme önbelleği diski hızla doldurur |
| Çoklu servis, izleme ve log toplama | 4–8 | 8–16 GB | 100 GB ve üzeri | Log ve metrik saklama süresi diski belirler |
Veritabanını konteynerde çalıştırıyorsanız bellek hesabını önce ona göre yapın; uygulama konteynerleri çoğu zaman birkaç yüz megabaytla yetinirken veritabanı önbelleği eline geçen belleği kullanır. Genel kaynak hesabının mantığını VPS için ne kadar RAM ve CPU gerekir yazısında bulabilirsiniz.
Disk, İmaj Büyüklüğü ve Loglar Neden Önce Biter
Docker sunucularında en sık yaşanan kesinti işlemci ya da bellekten değil diskten gelir. Her imaj katmanlarıyla birlikte yüzlerce megabayttan birkaç gigabayta kadar yer kaplar; her güncellemede yeni sürüm indirilir, eskisi siz silene kadar diskte kalır. Derleme yapılan sunucularda derleme önbelleği de aynı şekilde birikir.
Loglar ikinci büyük kalemdir. Docker’ın log yapılandırma belgesi varsayılan json-file sürücüsünün geriye dönük uyumluluk için log döndürme yapmadan çalıştığını ve çok çıktı üreten konteynerlerde diski doldurabileceğini belirtir. Log boyutu sınırını kurulumun ilk gününde tanımlamak, aylar sonra gelen “disk dolu” kesintisini önler.
Örnek senaryo
Bir yazılım ekibi, müşteri paneli ve arka plan kuyruğunu Compose ile 4 vCPU ve 8 GB RAM’li bir sunucuda çalıştırıyor. Üçüncü ayda veritabanı yazmayı bırakıyor ve panel hata vermeye başlıyor. İncelemede 60 GB’lık diskin 22 GB’ını kuyruk servisinin log dosyası, 18 GB’ını da hiç silinmemiş eski imaj sürümleri kaplıyor. Log boyutu sınırı ve haftalık imaj temizliği tanımlandıktan sonra disk kullanımı yüzde 40’ın altında sabitleniyor; paket büyütmeye gerek kalmıyor.
İşletim Sistemi ve Mimari Gereksinimi
Docker Engine’in Ubuntu kurulum belgesi 64 bit bir Ubuntu LTS sürümü ister ve x86_64 ile arm64 dahil birkaç mimariyi destekler. Güncel LTS sürümlerinden biriyle kurulan bir sunucu bu şartı karşılar. Kurulum adımları Ubuntu’da Docker kurulumu kartında, birden fazla konteyneri tek dosyayla yönetme ise Docker Compose ile çoklu container yönetimi kartında anlatılıyor.
Aynı belge güvenlik duvarı konusunda önemli bir uyarı içerir: ufw ya da firewalld kullanıyorsanız, Docker ile dışarı açtığınız konteyner portları bu güvenlik duvarı kurallarını atlar. Veritabanı portunu yanlışlıkla dışarı açan bir Compose dosyası, güvenlik duvarı kapalı görünse bile veritabanını internete açabilir.
Sonuç
Docker için hangi sunucu gerektiğinin cevabı paket adında değil üç şartta saklı: root erişimi, Docker’ın çalıştığı bir sanallaştırma türü ve iş yüküne yetecek kaynak. Paylaşımlı hosting ilk iki şartı karşılamaz. Küçük bir VPS ile başlayın, disk ve bellek kullanımını izleyin, sabit yük altında VDS’e ya da ölçeklenme gerekiyorsa bulut sunucuya geçin.
Kontrol Listesi
- Sağlayıcıya Docker ve Docker Compose’un ek ayar gerekmeden çalıştığını yazılı olarak teyit ettirin.
- Çalıştıracağınız konteynerleri listeleyin ve belleği önce veritabanına göre hesaplayın.
- Diski imajlar, derleme önbelleği, volume’lar ve loglar için ayrı ayrı tahmin edin.
- Log boyutu ve dosya sayısı sınırını ilk kurulumda tanımlayın.
- Eski imaj ve durmuş konteynerleri düzenli aralıklarla temizleyin.
- Yalnız gereken portları dışarı açın; veritabanı portlarını iç ağda tutun.
- Volume’lardaki veriyi sunucu dışına yedekleyin; konteyner yeniden oluşturulabilir, veri oluşturulamaz.
Sıkça sorulan sorular
Docker için hangi sunucu en az kaynakla çalışır?
Tek konteynerli küçük bir uygulama için 1–2 vCPU, 2 GB RAM ve 30–40 GB disk makul bir başlangıçtır. Docker’ın kendi ek yükü düşüktür; asıl kaynağı konteynerlerin içindeki uygulama ve özellikle veritabanı tüketir. Gerçek kullanımı izleyip gerekirse paketi büyütmek daha doğru bir yoldur.
Paylaşımlı hostingte Docker kurulabilir mi?
Hayır. Docker’ın arka plan servisi root yetkisi ister ve sürekli çalışan bir süreçtir. Paylaşımlı hostingte root ve SSH erişimi olmadığı gibi, sunucuya paket kurmak ya da arka plan servisi başlatmak da mümkün değildir. Docker için root erişimli bir VPS ya da VDS gerekir.
Docker için VPS mi VDS mi seçilmeli?
Düşük ve dalgalı trafikli uygulamalar için VPS yeterlidir. Veritabanı konteyneriniz yanıt süresine duyarlıysa ya da servisleriniz gün boyu sabit yük altındaysa, işlemci payının size sabit ayrıldığı VDS daha tutarlı performans verir.
Docker sunucusunda disk neden hızla dolar?
Her imaj güncellemesi yeni katmanlar indirir ve eski sürümler silinmeden kalır. Varsayılan log sürücüsü de log döndürme yapmaz; çok çıktı üreten bir konteyner zamanla gigabaytlarca log biriktirir. Log sınırı ve düzenli imaj temizliği bu sorunu önler.
Docker kullanmak sunucuyu güvensiz yapar mı?
Doğru yapılandırılırsa hayır. Dikkat edilecek iki nokta var: Docker servisini yönetebilen kullanıcılar sunucunun dizinlerini konteynere bağlayabildiği için fiilen root düzeyinde yetki kazanır ve Docker ile açılan portlar ufw gibi güvenlik duvarı kurallarını atlayabilir. Yalnız gereken portları açmak ve kullanıcı yetkilerini sınırlı tutmak riski büyük ölçüde azaltır.
Aynı kümede sık sorulan bir başka soru Kubernetes nedir, küçük projede gerekir mi; ayrıntıları ayrı yazıda ele aldık.
Bu kararla bağlantılı bir soru daha var: n8n için VPS gerekip gerekmediği ayrı bir yazıda anlatıldı.
Narhost’ta
Narhost VPS paketlerinde tam root erişimi, NVMe disk, anında kurulum, 50 Gbps port ve tarayıcı üzerinden terminal erişimi standarttır; Docker kurulumu ve konteyner düzeni sizin kontrolünüzdedir. Sipariş öncesi sorularınızı 7/24 destek ekibimize iletebilirsiniz.