Dokku ya da Coolify işletmek vs yönetilen git-push platformu

Dokku ve Coolify'ın iyi yaptıkları

Önce hakkını verelim, çünkü hak edilmiş. Dokku, Heroku'nun çekirdek döngüsünü — git push, build'i izle, uygulama yayında — on yıldır güvenilir olan tek-sunuculuk bir araca damıttı. Coolify aynı fikri tek-tık veritabanları ve büyüyen bir şablon kütüphanesiyle, gerçekten keyifli bir arayüze sardı. İkisi de TLS'i halleder, ikisi de Dockerfile konuşur ve ikisi de tamamen sizin kontrolünüzdeki donanımda çalışır — verinin yerinde kalması şartsa ya da sabit fiyatlı bir VPS bütçenin tamamıysa bu önemlidir.

Bugün bunlardan birini mutlulukla işletiyorsanız, aşağıdaki hiçbir şey hata yaptığınızı savunmuyor. Bu rehberin cevapladığı soru daha dar ve ancak zamanla ortaya çıkıyor: platformunuzun altındaki platformu kim işletiyor — ve bu hâlâ saatlerinizin en iyi kullanımı mı?

README'nin atladığı kalem: platform ekibi sizsiniz

Kendin barındırılan PaaS, kendi işlettiğiniz sunucuda kendi işlettiğiniz yazılımdır. İki katman, ikisi de sizin. Sunucu işletim sistemi güvenlik yamaları ve SSH sıkılaştırması ister; disk, sabah deploy'ları "no space left on device" ile patlamaya başlayana kadar Docker imajları ve build cache'leriyle sessizce dolar — klasik Dokku olayıdır ve anını hep iyi seçer. PaaS'in kendisi, changelog'unu okuyarak yaptığınız güncellemeler ister; çünkü kodunuzla üretim arasında oturur ve oradaki kırıcı değişiklik bir üretim değişikliğiDİR.

Sonra daha keskin sorular. Yedekler: PaaS'inizin tek tıkla var ettiği veritabanları — kim döküyor, dökümler nereye gidiyor ve en son ne zaman biri bir geri yüklemeyi test etti? Yüksek erişilebilirlik: tek sunucu, host yeniden başlatmasının tüm uygulamaları birlikte düşürmesi demektir. Bunların hiçbiri egzotik iş değil. Kurulum script'iyle sessizce gelen, akşamlarınızdan faturalanan yarı zamanlı bir platform mühendisliği işidir.

Aynı döngü, sizin yerinize işletilen

Gerçekten sevdiğiniz akış push-to-deploy ve vazgeçeceğiniz şey o değil. cdn.com.tr'de GitHub Deploy bir depoyu bağlar ve push'u deploy'a çevirir: platform dalı çeker, Dockerfile'ınızı yalıtılmış bir builder'da build eder (registry hesabı gerekmez), tanımladığınız adımları çalıştırır ve sürümü sağlık kontrolü arkasından yayına alır — trafik yeni konteynere ancak hazır olduğunu bildirdiğinde geçer, yani bozuk build siteyi asla düşürmez. Öndeki edge cache deploy'da otomatik purge edilir.

Değişen şey, nöbeti kimin tuttuğudur. Sunucu yamaları, builder güncellemeleri, disk ve platformun kendi erişilebilirliği masanın sizin tarafı olmaktan çıkar. Yönetilen Postgres ve Redis, tek-tık konteynerlerin yerine servis olarak işletilip yedeklenen veritabanları koyar; S3 uyumlu object storage, yüklemeler için bu-sunucudaki-volume deseninin yerini alır. Dürüst takas her zamanki gibi: host'ta root yok, işletim sistemi kurulumu yok, dışa açık trafik HTTP(S). Dockerfile'ınız sözleşmedir — sizi ayrılabilir kılan da odur.

Panel tarafı neye benziyor

Özellikle Coolify kullanıcıları şekli tanıdık bulacaktır: alan adlı uygulamalar, ortam değişkenleri ve secret'lar, SSH'sız okunabilen loglar ve uygulamalara bağlı veritabanları — sunucu ayar sayfaları hariç, çünkü altta size ait bir sunucu yok. Container uygulamaları sağlık kontrolünü, replika sayısını ve kalıcı depolamayı birinci sınıf ayar olarak taşır ve ekrandaki her şey aynı CLI'dan da yazılabilir; yani arayüz platforma açılan tek kapı değil, platformun bir görünümüdür.

Paneldeki her şey aynı zamanda bir CLI uzağınızda

# uygulamalarinizi gorun, SSH'siz log okuyun
cdnctl container apps list --account <uuid>
cdnctl container apps logs --account <uuid> --app <app_uuid> --tail 100

# olcekle, yeniden baslat, geri al — gercekte uzandiginiz islemler
cdnctl container apps scale   --account <uuid> --app <app_uuid> --replicas 2
cdnctl container apps restart --account <uuid> --app <app_uuid>
cdnctl container apps rollback --account <uuid> --app <app_uuid> --revision <revision_uuid>

Geçiş: sandığınızdan küçük

Uygulamanız zaten Git'te yaşıyor ve Dokku ya da Coolify altında zaten bir Dockerfile'dan ya da build edilebilir bir düzenden build oluyor — yani geçişin zor kısmı çoktan olmuş. Taşınmak, push'un gittiği yeri değiştirmek artı bir veri geçişidir.

Depoyu GitHub Deploy'a bağlayın (ya da uygulama bir docker-compose.yml ile tanımlıysa onu içe aktarın: build: bölümü olan servisler Dockerfile'larından build edilir, veritabanları yönetilen eklentiye dönüşür). Ortam değişkenlerini ve secret'ları yeniden oluşturun. Veriyi taşıyın: veritabanını döküp yönetilene geri yükleyin, yüklenmiş dosyaları object storage'a kopyalayın. Birkaç gün iki platformu paralel çalıştırın — eski sunucu sunmaya devam ederken yeni deploy'u doğrularsınız — sonra DNS'i çevirin ve kutuyu kendi takviminizde emekli edin.

Compose ile tanımlı uygulama: planı görün, sonra uygulayın

# compose dosyanizin tam olarak neye donusecegini gorun — henuz hicbir sey olusturulmaz
cdnctl container compose preview --account <uuid> --file docker-compose.yml

# plan dogru gorununce uygulayin
cdnctl container compose apply --account <uuid> --file docker-compose.yml

# veri: eski kutuda dokun, yonetilen veritabanina geri yukleyin
pg_dump -Fc appdb > appdb.dump
pg_restore -d "$MANAGED_DATABASE_URL" appdb.dump

# yuklemeler: eski sunucunun volume'undan object storage'a
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./uploads s3://app-uploads

Ne zaman kendin barındırmaya devam etmeli

Simetri bu bölümü şart koşar. Sunucu sizin için gerçekten bedavaysa — bir homelab, zaten sahip olduğunuz ve işletmekten keyif aldığınız donanım — Dokku ya da Coolify'da kalın. Veri yerelliği katı bir kısıtsa ve makine sizin olmak zorundaysa kalın. İşletme işinin kendisi amaçsa kalın: kendi platformunuzu işletmek bu alanın tamamını öğrenmenin en iyi yollarından biridir. Ve yönetilen takasın dışladığı bir şeye ihtiyacınız varsa kalın — root, ham TCP portları, konteyner imajına ait olmayan egzotik sistem bağımlılıkları.

Bunların hiçbiri sizi tarif etmiyorsa — uygulamalarınızın altındaki platform bir hobi ya da gereklilik değil angaryaysa — sevdiğiniz akış taşınabilir ve nöbet opsiyoneldir.