Nasıl Deploynix’i Kendi Platformumuz Üzerinde Kullanıyoruz: Kendi Platformumuzu Kendi Platformumuzda Çalıştırmak

Bir dağıtım platformunu kendi üzerinde çalıştırmanın getirdiği belirli bir baskı vardır. Eğer Deploynix çökerse, Deploynix’i düzeltmek için Deploynix’i kullanamayız. Tüm bu yapı, güvenilirliğe ihtiyaç duyan bir döngüdür ve her parça son derece güvenilir olmalıdır.

Dogfooding yalnızca ekip toplantılarında havalı bir kelime değil. Bu, sahip olduğumuz en önemli kalite güvence uygulamasıdır. Gönderdiğimiz her özellik, tasarladığımız her iş akışı ve ele aldığımız her kenar durumu, kendimiz için en sıkı müşteri olduğumuz için ilk elden deneyimlenir. Bir dağıtım iki saniye daha uzun sürdüğünde, bunu hissederiz. Bir izleme uyarısı, yetersiz bir bağlamla tetiklendiğinde gece yarısı ona bakmak zorunda kalan biziz.

Bu yazı, Deploynix’i nasıl çalıştırdığımıza ışık tutmaktadır. Altyapı seçimlerimiz, dağıtım hattımız, dürüst olmamızı sağlayan izleme sistemimiz ve zor yoldan öğrendiğimiz dersler.

Altyapı Kurulumumuz

Deploynix platformu, bir Laravel 12 uygulamasıdır. Deploynix müşterilerinin kurduğu altyapıyla aynı alanda çalışır, hiçbir özel muamele yoktur. Gizli dahili araçlar veya ayrı bir dağıtım sistemi yok. Kullandığınız şey, bizim kullandığımızdır.

Uygulama Sunucuları: İki uygulama sunucusu, Least Connections dengeleme yöntemi ile Deploynix yük dengeleyicisi arkasında çalışmaktadır. Her uygulama sunucusu, sürdürülebilir çalışan süreçler ve bir dağıtım platformunun ihtiyaç duyduğu performans özelliklerini sağlayan FrankenPHP’yi Octane sürücüsü olarak çalıştırır. Bir müşteri dağıtımı tetiklediğinde, isteğin hızlı ve güvenilir bir şekilde işlenmesi gerekir ve FrankenPHP bunu sağlar.

Veritabanı Sunucusu: Tüm kalıcı verileri yöneten özel bir MySQL veritabanı sunucusu var. Dağıtım dönemlerinde veritabanı işlemleri yoğun kaynak kullanır, bu nedenle MySQL’i uygulama ile birlikte çalıştırmak yerine ayrı bir veritabanı sunucusu seçtik. Bu ayrım, eşzamanlı dağıtımlarda veritabanının CPU veya bellekten mahrum kalmadığından emin olmayı sağlar.

Önbellek Sunucusu: Önbellekleme, oturum saklama ve kuyruk yönetimi için özel bir Valkey sunucusu kullanıyoruz. Valkey, Redis ile uyumlu olduğu için Laravel ekosisteminde Redis ile çalışan her şeyi mükemmel bir şekilde desteklemektedir. Gerçekten açık kaynak olan ve geniş bir topluluk tarafından aktif olarak bakım yapılan Valkey’e geçtik.

İşçi Sunucuları: Kuyruk görevlerimizi işleyen iki özel işçi sunucusu çalıştırıyoruz. Bu sunucular, sunucu provision’lama, dağıtım yapma, SSL sertifikalarını senkronize etme, yedekleme rutinlerini çalıştırma ve GitHub, GitLab ve Bitbucket’dan webhook olaylarını işleme gibi zorlu görevleri üstlenmektedir. İşçi sunucular, müşterilerin ödemekte olduğu işin gerçek anlamda yapıldığı en kritik alandır.

Yük Dengeleyici: Gelen trafiği uygulama sunucularımız arasında dağıtan bir yük dengeleyici kullanıyoruz. İsteklerin süresi çok değişken olduğu için Least Connections yöntemini kullanıyoruz. Sunucu durumunu kontrol etmek için bir API çağrısı milisaniyeler içinde dönerken, tam bir dağıtımı tetikleyen ve çıktı akışını WebSocket üzerinden ileten bir istek birkaç dakika sürebilir.

Dağıtım Hattı

Deploynix platformuna yapılan her kod değişikliği, müşterilerimizin kullandığı aynı dağıtım hattından geçer. Uygulamadaki pratikte bu nasıl görünür?

Depomuz GitHub’da bulunuyor ve otomatik dağıtımlar için Deploynix’in Git sağlayıcı entegrasyonu üzerinden yapılandırılmıştır. Bir çekme isteği üretim dalımıza birleştirildiğinde, Deploynix GitHub’dan bir webhook alır ve sıfır kesinti süresi ile dağıtım başlatır.

Dağıtım süreci, Deploynix kontrol panelinde yapılandırdığımız dağıtım scriptini kullanarak aşağıdaki adımları sırayla yürütür:

Ön Yükleme Kancası: Uygulama, yalnızca dağıtılan belirli sunucu için bakım moduna alınıyor. Yük dengeleyicinin arkasında çalıştığımız için diğer uygulama sunucusu trafiği işlemeye devam eder. Bu, tam olarak ihtiyaç duyduğumuz için özel olarak yaptığımız bir özellik.

Yükleme Aşaması: Deploynix, deposundan en son kodu klonlar, composer install --no-dev --optimize-autoloader komutunu çalıştırarak PHP bağımlılıklarını alır ve npm ci && npm run build komutunu çalıştırarak ön uç varlıklarımızı derler. Yükleme aşaması, mevcut koddan tamamen ayrı bir yeni sürüm dizininde yürütülür.

Yükleme Sonrası Kancası: Bu aşamada veritabanı geçişleri çalıştırılır. Herhangi bir şema değişikliğini uygulamak için php artisan migrate --force komutunu çalıştırırız. Ayrıca php artisan config:cache, php artisan route:cache ve php artisan view:cache komutlarını çalıştırarak performansı optimize ederiz.

Aktivasyon Aşaması: Deploynix atomik olarak eski sürümden yeni sürüme sembol bağlantısını değiştirir. Bu, sıfır kesinti süresi deneyimidir. Eski kod, sembol bağlantısı değişene kadar istekleri çalıştırır ve yeni kod anında devralır. Hiçbir zaman bir boşluk, 502 hatası veya kopan bağlantı yoktur.

Aktivasyon Sonrası Kancası: Octane işçilerini yeniden başlatırız, böylece yeni kodu almış olurlar, işçi sunucularımızdaki kuyruk işçilerini yeniden başlatırız ve sunucuyu bakım modundan çıkarırız.

Tüm dağıtım süreci her sunucu için yaklaşık 45 saniye sürer. Yük dengeleyicinin arkasında uygulama sunucularımıza ardışık olarak dağıtım yaptığımız için, tüm süreç boyunca her zaman istekleri işleyen en az bir sunucu vardır.

İzleme ve Sağlık Uyarıları

Kendi izleme sistemimizi kullanıyoruz. Altyapımızdaki her sunucuda Deploynix sağlık izleme etkinleştirilmiştir ve müşteri önerilerimize uygun uyarı eşiği ayarlanmıştır.

CPU İzleme: CPU kullanımı 5 dakikadan fazla %80’i aşarsa uyarı alırız. Yoğun dağıtım dönemlerinde işçi sunucularımız %70-75 CPU’ya çıkabiliyor, bu nedenle eşiği yanlış alarm vermemek için ayarladık ama gerçek problemleri yakalamak için de yeterli.

Belirleyici İzleme: Bellek uyarıları %85 kullanıldığında tetiklenir. FrankenPHP işçi süreçleri stabil bir bellek ayak izine sahiptir, ama bu izleme sayesinde kuyruk işlerinde bellek sızıntılarını yakaladık. Bir seferinde, büyük Git havuzlarını işleyen bir işin, klonlama işleminden sonra belleği doğru bir şekilde serbest bırakmadığını tespit ettik. Bunu, kendi izlememiz işçi sunucunun belleğinin birkaç saat boyunca sürekli olarak yükselmesini işaret ettiği için yakaladık.

Disk İzleme: Disk kullanımı %80’de uyarı verir. Dağıtım sürümleri zamanla birikir ve Deploynix eski sürümleri otomatik olarak temizlerken, log dosyaları ve veritabanı yedekleri bir diski beklediğinizden daha hızlı doldurabilir. Bu durumu, bir özellik sprinti sırasında günde birden fazla dağıtım yaptığımız bir dönemde zor yoldan öğrendik.

Sağlık Kontrolleri: Deploynix her uygulama sunucusundaki sağlık uç noktasına her dakika ping atar. Eğer bir sunucu üç kez arka arkaya sağlık kontrolünü geçemezse uyarı alırız. Laravel sağlık uç noktamız, veritabanı bağlantısını, önbellek erişilebilirliğini ve kuyruk işçi yanıtını doğrulamak için ayarlanmıştır. 200 yanıtı, her şeyin gerçekten sağlıklı olduğu anlamına gelir, sadece Nginx’nin çalıştığı anlamına gelmez.

WebSocket ile Gerçek Zamanlı İzleme

WebSocket altyapımız için Laravel Reverb kullanıyoruz ve doğal olarak Reverb kendi yönettiğimiz Deploynix sunucularında çalışıyor. Deploynix kontrol panelinde dağıtım kaydını gerçek zamanlı olarak izlerken, bu veri Reverb üzerinden akıyor.

Reverb’i kendi platformumuzda çalıştırmak, aldığımız en değerli dogfooding kararlarından biriydi. Bağlantı zaman aşımı sorunları, yeniden bağlantı edge durumları ve ölçekleme kaygıları gibi sorunları, yalnızca sentez test üzerinden bulamayacağımızı keşfettik. Bir müşteri dağıtım yaptığında ve çıktı akışını izlerken her bir satırı anında görmek bekliyor; biz de aynı şeyi bekliyoruz ve bu beklenti, WebSocket altyapımızı optimize etmemizi sağladı.

Veritabanı Yedekleri

Üretim veritabanımız, Deploynix’in yerleşik yedekleme sistemi ile günlük olarak yedeklenmektedir. Yedekleri AWS S3 kovasında saklıyoruz ve versiyonlama etkinleştirilmiştir; günlük yedekler için 30 gün ve haftalık yedekler için bir yıl süreli bir yaşam döngüsü politikası uygulanmıştır.

Yedek geri yüklemeleri her çeyrek test edilmektedir. Çünkü üretimde geri yükleme yapmamız gerekmedi ancak hiç geri yükleme test edilmemiş bir yedek, aslında gerçek bir yedek değildir; bir umut. Deploynix, bir yedeği indirip test sunucusuna geri yüklemeyi kolaylaştırdığı için bu süreci düzenli olarak gerçekleştiriyoruz ve yedekleme hattımızın kullanılabilir anlık görüntüler üretip üretmediğini doğruluyoruz.

SSL ve Alan Yönetimi

Deploynix platformu, otomatik olarak sağlanan ve yenilenen SSL sertifikalarının arkasında çalışmaktadır. Wildcard sertifikaları elde edebilmek için Let’s Encrypt sertifikaları ve Cloudflare üzerinden DNS doğrulama kullanıyoruz.

Her Deploynix müşterisi, kendi siteleri için ücretsiz bir *.deploynix.cloud alan adı alır ve bu wildcard sertifikası bizim otomatik sertifika yönetimimiz tarafından yönetilmektedir. Sertifikayı uygulama sunucumuzda yerel olarak veriyoruz, şifreli olarak veritabanında saklıyoruz ve ihtiyaç duyan tüm yönetilen sunuculara senkronize ediyoruz. Yenileme süreci, her gün zamanlanmış bir görev olarak çalışır; sertifikanın 30 gün içinde süresi dolmaya yaklaşıp yaklaşmadığını kontrol eder ve eğer dolmaya yakınsa otomatik olarak yeniler.

Zor Yoldan Öğrenilen Dersler

Dogfooding, testlerin veya kullanıcı araştırmalarının açığa çıkaramayacağı şeyleri öğrenmemizi sağladı. İşte platformumuzu en çok şekillendiren dersler:

Dağıtım scriptleri idempotent olmalıdır. Erken dönemlerde veritabanı seeder’ı çalıştıran bir dağıtım scriptimiz vardı. Seeder idempotent değildi, bu nedenle bir dağıtım yarıda kesildiğinde ve tekrar dağıttığımızda, tekrar eden verilere ulaşmıştık. Şimdi Deploynix, güvenli bir şekilde birden fazla kez çalıştırılabilecek dağıtım scriptlerini teşvik etmekte ve bu kalıbı belirgin bir şekilde belgelemektedir.

İşçi sunucuları bağımsız dağıtılmalıdır. İlk başta, bir uygulama sunucusuna dağıtım yapıldığında kuyruk işçileri de yeniden başlatılıyordu. Ancak, kuyruk işçileri uzun süren işleri işleyeceklerinden, yarıda kesildiğinde hatalara yol açmaktadır. İşçi sunucularının bağımsız dağıtımlar yapabilmesi için yeniden yapılandırdık ve mevcut işleri tamamladıktan sonra yeni kodu almaları için nazik bir şekilde kuyruk işçilerini yeniden başlatan bir yapı oluşturduk.

Geri Alma anında gerçekleştirilmelidir. Geri alma özelliğini kendimiz gerektiği için geliştirdik. Kötü bir geçiş, staging ortamımızdan geçip üretime ulaşmıştı ve üretimde hatalara sebep olmuştu. Sadece sembol bağlantısını geri almak suretiyle beş saniyenin altında önceki sürüme geri dönme kabiliyeti, uzatılmış bir kesinti süresinden kurtardı. Geri alma özelliği, Deploynix’in sunduğu en önemli özelliklerden biri olarak kalmaktadır.

Güvenlik duvarı kuralları düşündüğünüzden daha önemlidir. Veritabanı sunucumuz yalnızca uygulama ve işçi sunucularımızdan gelen bağlantıları kabul etmelidir. Altyapımızı ilk kurduğumuzda, veritabanı aynı ağ üzerindeki herhangi bir sunucudan erişilebilir hale gelmişti. Deploynix’in güvenlik duvarı yönetimi, erişimi kısıtlamayı basit hale getirerek, veri tabanı sunucumuzda yalnızca uygulama ve işçi sunucularımızın belirli IP adreslerine izin vermektedir.

Planlı dağıtımlar yalnızca müşteriler için değildir. Planlı dağıtım özelliğini kurumsal müşterilerin talebi üzerine geliştirdik, ama sonrasında düşük trafikli saatlerde veritabanı ağır geçişlerini dağıtmak için kendimiz kullanmaya başladık. Cuma akşamı bir PR birleştirip dağıtımı Cumartesi günü sabah 3’te zamanlamanın özgüvenini sağlıyor, böylece biri garip saatlerde çevrimiçi olmak zorunda kalmıyor.

Geri Bildirim Döngüsü

Dogfooding’in en değerli yönü, oluşturduğu sıkı geri bildirim döngüsüdür. Deploynix’e yeni bir özellik eklediğimizde, bunu kendi iş akışımızda hemen kullanırız. Eğer özellik kafa karıştırıcıysa, biz de o kafa karışıklığını hissederiz. Eğer yavaşsa, o yavaşlığı hissederiz. Eğer bir kenar durumu eksikse, o duruma çarparız.

Bu geri bildirim döngüsü, bir özellik müşterilere ulaşmadan önce, ona bağımlı bir ekibin incelemesinden geçtiği anlamına gelir. Geri alma mekanizmasında ince bir hata olan bir dağıtım sistemi göndermeyeceğiz, çünkü kendi geri almalarımızın sorunsuz çalışması gerekiyor.

Her Deploynix ekibi üyesinin, üretim Deploynix kontrol panelimize erişimi vardır. Geliştiriciler, tasarımcılar ve destek ekibi üyeleri, tümü müşterilerin gördüğü aynı arayüzü görmektedir. Ekstra bilgi veya kısayollar sunan bir dahili yönetim panelimiz yoktur. Bir ekip üyesi “bu iş akışı geçersiz görünüyor” dediğinde, doğrudan deneyimden bahsediyor.

Bu Sizin İçin Neden Önemli

Deploynix’i Laravel uygulamalarınızı yönetmek için kullandığınızda, aynı platformu, aynı özellikleri ve kendi kullandığımız altyapı düzenlerini kullanıyorsunuzdur. Bir aracı geliştirmiyoruz ve onu dışarıya atmamışız. Bizim kendi üretim sistemlerimiz buna bağlı olduğu için, mükemmel olması gerektiği bir aracı inşa ediyoruz.

Tetiklediğiniz her dağıtım, haftada onlarca kez kullandığımız kod yollarından geçmektedir. Aldığınız her sağlık uyarısı, kendi sunucularımızı izleyen aynı izleme hattını kullanmaktadır. Yapılandırdığınız her yedek, kendi verilerimizi koruyan aynı sistemi kullanmaktadır.

Dogfooding mükemmeliyet garantisi vermez. Hala hatalar buluyoruz, hala olaylarımız oluyor ve hala iyileştirilmesi gereken özelliklerimiz var. Ama bu, o problemleri hızlı bir şekilde bulabileceğimiz, onları düzeltme konusunda aciliyet hissettiğimiz ve yaptığımız her kararın gerçek dünya üzerindeki etkisini anladığımızı garanti eder. Bu tür bir hesap verebilirlik, bir dağıtım platformunu güvenilir kılar.