Tek VPS üzerinde onlarca container yönetmek

Neden önce tek sunucu?

Yeni bir ürün geliştiren küçük bir ekip için en değerli kaynak zamandır. Birden fazla sunucu, yük dengeleyici ve Kubernetes kümesiyle başlamak; daha ilk kullanıcı gelmeden ciddi bir bakım yükü ve maliyet demektir.

Tek bir güçlü VPS, onlarca küçük servisi, veritabanlarını ve arka plan işlerini rahatça taşıyabilir. Kendi altyapımda farklı ürünlerin web siteleri, API'leri ve yönetim panelleri aynı sunucuda, birbirinden yalıtılmış container'larda çalışıyor. Önemli olan sunucu sayısı değil, düzenin, yedeğin ve izlemenin doğru kurulmasıdır.

Sunucu nasıl hazırlanmalı?

Container'lara geçmeden önce sunucunun kendisi güvenli ve öngörülebilir bir hale getirilmelidir. Temel kurulum adımları şunlardır:

• Uzun süreli destekli (LTS) bir Linux dağıtımı kullanın.
• SSH erişimini yalnızca anahtarla yapın, parola ile girişi ve root girişini kapatın.
• Güvenlik duvarında yalnızca gerekli portları (22, 80, 443) açık bırakın.
• Otomatik güvenlik güncellemelerini etkinleştirin.
• Bellek yoğun anlarda sunucunun kilitlenmemesi için swap alanı tanımlayın.
• Docker'ı resmi deposundan kurun ve sürümünü kayıt altına alın.

Dokploy düzeni nasıl kolaylaştırır?

Onlarca container'ı komut satırından yönetmek bir noktadan sonra karmaşıklaşır. Dokploy gibi açık kaynaklı bir panel; uygulamaları git deposundan derleyip yayına almayı, alan adı bağlamayı, SSL sertifikasını otomatik almayı ve ortam değişkenlerini tek bir arayüzden yönetmeyi sağlar.

Dokploy, gelen trafiği Traefik ters vekil sunucusu üzerinden doğru container'a yönlendirir. Böylece her uygulama kendi alan adıyla, kendi sertifikasıyla ve diğerlerinden bağımsız olarak çalışır. Bir uygulamanın yeniden başlatılması ya da güncellenmesi diğerlerini etkilemez.

Git'ten canlıya: yayın akışı nasıl kurulur?

Düzenli bir altyapının en büyük kazancı, yayına almanın sıkıcı ve güvenli bir işlem haline gelmesidir. Kendi akışımda kod GitLab'a gönderildiğinde CI süreci testleri çalıştırıyor, uygulamanın Docker imajını derleyip kayıt deposuna (registry) yüklüyor ve ardından Dokploy'a bir webhook ile yeni sürümü haber veriyor.

Dokploy yeni imajı çekip container'ı yeniden başlatıyor; Traefik trafiği yeni container hazır olduğunda ona yönlendiriyor. Bir sorun çıkarsa önceki imaj etiketiyle birkaç dakika içinde geri dönmek mümkün. Her imajın bir sürüm etiketi taşıması, hangi kodun canlıda çalıştığını her zaman net kılıyor.

Mobil uygulamalar için de benzer bir düzen kurulabilir: derlemeler CI üzerinde, imzalama anahtarları güvenli değişkenlerde tutulur ve mağaza gönderimi tek bir komutla yapılır. Elle yapılan her adım, bir gün unutulacak bir adımdır.

Kaynaklar container'lar arasında nasıl paylaştırılır?

Tek sunucunun en büyük riski, bir servisin kontrolden çıkıp tüm kaynakları tüketmesidir. Bellek sızıntısı olan tek bir uygulama, aynı sunucudaki her şeyi durdurabilir. Bunu önlemek için:

• Her container için bellek ve CPU üst sınırı belirleyin.
• Yeniden başlatma politikası tanımlayın; çöken servis kendiliğinden ayağa kalksın.
• Log dosyalarına boyut sınırı koyun; sınırsız loglar diski sessizce doldurur.
• Kullanılmayan imaj ve volume'ları düzenli olarak temizleyin.
• Veritabanlarını mümkünse ayrı container'larda ve kalıcı volume'larda çalıştırın.

Yedekleme nasıl yapılmalı?

Sunucu ne kadar düzenli olursa olsun, yedeksiz bir kurulum güvenli değildir. Yaygın kabul gören 3-2-1 kuralı burada da geçerli: verinin üç kopyası, iki farklı ortamda ve en az biri sunucunun dışında olmalı.

• Veritabanı yedeklerini her gün otomatik alın.
• Yedekleri S3 uyumlu bir nesne depolama servisine, sunucunun dışına gönderin.
• Eski yedekleri belirli bir süre sonra otomatik silen bir saklama politikası tanımlayın.
• En önemlisi: Yedekten geri yüklemeyi düzenli olarak test edin. Hiç geri yüklenmemiş bir yedeğe güvenilmez.

İzleme ve uyarılar neden şart?

Sorunu kullanıcıdan önce sizin fark etmeniz gerekir. Büyük ve pahalı izleme sistemlerine ihtiyaç yok; birkaç basit uyarı çoğu felaketi önler:

• Disk kullanımı yüzde 80'i geçtiğinde uyarı.
• Her alan adı için dışarıdan çalışan bir erişilebilirlik kontrolü.
• Sık yeniden başlayan container'lar için bildirim.
• SSL sertifikası bitiş tarihi yaklaştığında hatırlatma.

Tek sunucudan ne zaman çıkılmalı?

Tek sunucu sonsuza kadar yeterli olmaz. Sunucu kaynaklarının sürekli sınırda çalışması, tek bir arızanın kabul edilemeyecek bir kesintiye yol açması ya da ekibin büyüyüp farklı servislerin bağımsız ölçeklenmesi gerektiğinde ikinci bir sunucuya veya Kubernetes gibi bir orkestrasyon çözümüne geçmek mantıklı hale gelir.

Bu geçişi kolaylaştıran şey, baştan container mantığıyla çalışmış olmaktır. Her servis zaten ayrı bir container olduğu için başka bir sunucuya taşımak çoğu zaman yapılandırmayı kopyalamaktan ibarettir.

Sık sorulan sorular