Asıl soru fiyat değil
Bir VPS faturasını platform aboneliğiyle karşılaştırmak yanlış soruyu cevaplar. Her seçenek konteynerinizi çalıştırabilir; farklı olan, ilk deploy'dan sonra ne kadar ilginizi istemeye devam ettikleridir.
Üretimdeki bir konteyner şunlara ihtiyaç duyar: bir alan adı ve kendini yenileyen bir sertifika, çöktüğünde yeniden başlama yolu, logların gideceği bir yer, kesintisiz güncelleme hikâyesi ve yedeklenen bir veritabanı. Bunların hiçbiri Docker'ın işi değildir. Bunları kimin halledeceği, aslında aralarında seçim yaptığınız şeydir — ve dürüst karşılaştırma yalnızca sunucuyu değil saatlerinizi de fiyatlar.
Seçenek 1 — kendi yönettiğiniz VPS
Bir sanal makine kiralayın, Docker kurun, konteynerinizi çalıştırın. En doğrudan yoldur ve gerçekten çalışır; tam root erişimi ve makineyle aranızda soyutlama yok.
Sonra sürekli iş başlar: işletim sistemi güvenlik güncellemeleri, önde bir ters proxy, yenilenmesi gereken sertifikalar, konteyner gece 4'te öldüğünde devreye girecek yeniden başlatma politikası, kimsenin temizlemediği loglar ve imajlarla dolan disk, ve yapılandırdığınız — ve kritik olarak test ettiğiniz — yedekler. Deploy kendi script'inizdir, kesintisiz yayına alma da kendi inşa ettiğiniz şeydir.
Root istiyorsanız, parçaların nasıl birleştiğini öğreniyorsanız ya da zaten sunucu işletiyorsanız ve bir tane daha marjinalse bunu seçin. Ürününüz altındaki altyapı değil uygulamanın kendisiyse kaçının.
Seçenek 2 — Kubernetes
Kubernetes gerçek problemleri çözer: çok sayıda servis, kademeli deploy'lar, kendi kendini iyileştirme, otomatik ölçekleme. Bir ekiple onlarca servis işletiyorsanız karmaşıklığını hak eder.
O ölçeğin altında oran tersine döner. Bir avuç konteyner çalıştırmak için bir cluster'ı, güncellemelerini, ingress'ini, sertifikalarını ve YAML'ını bakımda tutarsınız — ve cluster kendi uzmanlığını gerektiren bir sisteme dönüşür. Yönetilen Kubernetes bunun bir kısmını kaldırır, kavramsal ağırlığını değil.
Ölçeğiniz ya da ekibiniz zaten talep ediyorsa seçin. Ciddi şirketler kullanıyor diye seçmeyin; ciddiyet, aracı problemin boyutuyla eşleştirmektedir.
Seçenek 3 — yönetilen konteyner platformu
Burada konteyneri teslim edersiniz, platform çalıştırır: otomatik HTTPS'li bir alan adı, yeniden başlatmalar, loglar, sağlık kontrolüne bağlı yayına alma ve ihtiyaç duyduğunuzda bağlanan yönetilen Postgres, Redis ya da S3 uyumlu depolama.
cdn.com.tr'de bir deploy yeni konteyneri başlatır, sağlık kontrolü yolunuzun hazır demesini bekler, sonra trafiği kaydırır ve eskisini emekli eder — yani bozuk bir build servisi asla düşürmez, çünkü trafik hâlâ çalışan sürümde kalır. Önünde WAF ve DDoS koruması dahil edge CDN durur.
Takas gerçek ve söylenmeye değer: sunucuda root yok, işletim sistemi düzeyinde paket kurulumu yok ve dışa açık erişim keyfî TCP portları değil HTTP(S). Uygulamanız platformun sunmadığı bir şeye ihtiyaç duyuyorsa dürüst cevap VPS'tir.
Elinizdekine göre üç giriş yolu
Doğru yol, imajınızın nereden geldiğine bağlı.
İmajları zaten build edip bir registry'ye gönderiyorsanız Container Apps kullanın: imaj referansını ve portu verin, deploy etsin. Boru hattınızda başka hiçbir şey değişmez.
Kaynaktan push-to-deploy istiyorsanız GitHub Deploy kullanın. Build adımını sizin için o halleder — Dockerfile'ınız yalıtılmış bir builder'da build edilip özel registry'mize gönderilir, yani kendi registry hesabınıza gerek yoktur. Dalınıza push edin, yeni sürüm sağlık kontrolünün arkasından yayına çıksın.
Uygulamanız birden çok servisse Docker Compose Instant Deploy kullanın. build: bölümü olan servisler Dockerfile'larından build edilir; herkese açık image: referans eden servisler (veritabanları, cache'ler, kuyruklar) yönetilen eklenti ya da uygulama olarak bağlanır. Çok aşamalı build'ler, target: ve build.args desteklenir. Hiçbir şey oluşturulmadan önce planı görün, sonra uygulayın.
Compose dosyasının neye dönüşeceğini önce görün, sonra uygulayın
# once plani gor — hicbir sey olusturulmaz
cdnctl container compose preview --account <uuid> --file docker-compose.yml
# plan dogru gorunuyorsa uygula
cdnctl container compose apply --account <uuid> --file docker-compose.ymlKarar vermeden önce kontrol edilecekler
Hangi yolu seçerseniz seçin, sorulacak sorular aynı. Deploy nasıl yayına çıkıyor — başarısız bir build siteyi düşürüyor mu, yoksa trafik son çalışan sürümde mi kalıyor? Loglar nereye gidiyor ve SSH olmadan okuyabiliyor musunuz? Verinize ne oluyor: veritabanı yönetilen ve yedekleniyor mu, yoksa sorumluluğu sizde olan bir diskteki konteyner mi? Çıkabiliyor musunuz — imajınız taşınabilir mi, yoksa tescilli bir şeye mi dönüştürüldünüz?
Son soru insanların atlayıp sonra pişman olduğu sorudur. Kendi Dockerfile'ınızdan üretilmiş bir Docker imajı yapısı gereği taşınabilirdir: VPS'te, Kubernetes'te ve yönetilen platformda aynı çalışır. Onu öyle tutmak, seçimi geri dönülebilir kılan şeydir.
Sık sorulan sorular
İmajı kendim build etmek zorunda mıyım?
Yalnızca istiyorsanız. Container Apps, registry'ye gönderdiğiniz hazır bir imajı deploy eder. GitHub Deploy ve Docker Compose Instant Deploy, Dockerfile'ınızdan yalıtılmış bir builder'da build edip özel registry'mize gönderir; registry hesabınıza gerek kalmaz.
Burada konteyner içinde veritabanı çalıştırabilir miyim?
Çalıştırabilirsiniz ama önemsediğiniz her şey için yönetilen Postgres ya da Redis eklentilerini kullanın — onlar sizin için işletilir ve yedeklenir. Düz bir konteynerdeki veritabanı, sorumluluğu şahsen sizde olan bir disktir; sonradan canınızı yakan kısım da budur.
Uygulamam SSH ya da özel bir sistem paketi istiyorsa?
Sistem paketlerini Dockerfile'ınıza koyun — imajların varlık sebebi tam olarak budur. Sunucuya SSH, çalışma anında işletim sistemi kurulumu ya da dışa açık ham TCP portu gerekiyorsa yönetilen platform doğru seçim değildir; dürüst cevap VPS'tir.
Yönetilen platform kendi sunucumdan yavaş mı?
Doğası gereği değil ve pratikte genelde daha hızlı olur, çünkü önünde küresel edge önbelleği vardır. Konteyner aynı tür donanımda çalışır; kaybettiğiniz şey hız değil root erişimidir.