Sıfır Kesinti ile Dağıtım Açıklandı: Deploynix’in Sorun Çıkarmadan Nasıl Gönderim Yaptığı

Her dağıtım, bir risk içerir. Uygulamanız geçiş aşamasındayken, eski kod yeni kodla değiştirilir, önbellekler temizlenir, hizmetler yeniden başlatılır. Geleneksel bir dağıtımda, bu geçiş süresi boyunca kullanıcılarınız hatalar görebilir, zaman aşımına uğrayabilir veya uygulamanın hem eski hem de yeni kodu aynı anda çalıştırıldığı bir durumla karşılaşabilirler.

Sıfır-downtime dağıtım, o geçiş süresini tamamen ortadan kaldırır. Kullanıcılarınız, bir anda eski sürümdeyken, bir sonraki anda yeni sürüme geçerler; arada hiçbir kesinti yoktur.

Deploynix üzerinde sıfır-downtime dağıtımı premium bir özellik veya isteğe bağlı bir konfigürasyon değildir. Her dağıtım, varsayılan olarak bu şekilde çalışır. İşte perde arkasında nasıl çalıştığı.

Geleneksel Dağıtımların Problemi

Sıfır-downtime’ın neden önemli olduğunu anlamak için, geleneksel bir dağıtım sırasında neler olduğunu inceleyelim.

Tipik bir dağıtım şu şekilde gerçekleşir:

1. git pull origin main — En son kodu canlı dizine çek

2. composer install --no-dev — PHP bağımlılıklarını yükle

3. npm run build — Ön yüz varlıklarını oluştur

4. php artisan migrate — Veritabanı göçlerini çalıştır

5. php artisan config:cache — Yapılandırmayı önbelleğe al

6. php artisan route:cache — Yolları önbelleğe al

7. php artisan view:cache — Görünümleri önbelleğe al

8. PHP-FPM veya Octane işçilerini yeniden başlat

Bu sıranın zaman alıcı olması en büyük problemdir — projenizin boyutuna, bağımlılık sayısına ve derleme karmaşıklığına bağlı olarak 30 saniyeden birkaç dakikaya kadar sürebilir. Bu süre zarfında, uygulamanız tutarsız bir durumda olabilir.

git pull çalıştığında, kod değişiklikleri hemen gerçekleşir. Ancak Composer henüz yeni bağımlılıkları yüklemedi. Eğer yeni kod, yeni bir paketi ya da güncellenmiş bir paketten yeni bir sınıfı referans alıyorsa, composer install süresince her istekte kritik hatalar oluşur.

php artisan migrate çalıştığında, veritabanı şeması değişir. Ancak eski kod hala istekleri işliyorsa, bu istekler hataya yol açabilir çünkü veritabanı artık kodun beklediği yapıyla uyuşmayabilir.

PHP-FPM yeniden başlatıldığında, mevcut bağlantılar sonlanır. Kullanıcılar isteğin ortasında hata alır. POST isteklerinde veriler kaybolur. Uzun süren işlemler kesintiye uğrar.

Bunlar varsayımsal problemler değil. Her geleneksel dağıtımda meydana gelir. Tek soru, birinin bunu fark edip etmeyeceğidir — cevap, trafik hacminize ve kullanıcılarınızın ne kadar şanssız olduğuna bağlıdır.

Atomik Sembolik Link Dağıtımlarının Çalışma Prensibi

Deploynix, bu sorunları ortadan kaldırmak için atomik sembolik link dağıtımlarını kullanır. İşte Deploynix ile yönetilen bir sunucudaki dizin yapısı:

/home/deploynix/your-site/
    current -> /home/deploynix/your-site/releases/20260318143022
    releases/
        20260318143022/    (şu anki sürüm)
        20260318120000/    (önceki sürüm)
        20260317090000/    (üç sürüm önce)
    shared/
        storage/
        .env

Ana fikir, current‘ın bir sembolik link olduğudur, bir dizin değil. Web sunucunuz (Nginx), current/public üzerinden hizmet vermek üzere yapılandırılmıştır. PHP-FPM, current dizininden çalışır. Her istek, hangi current‘a işaret ediyorsa ona ulaşır.

Dağıtım Sırası

Deploynix’te bir dağıtım tetiklediğinizde, aslında şu olanlar gerçekleşir:

Adım 1: Yeni bir sürüm dizini oluştur.

Yeni bir dizin, releases/ altında zaman damgasına dayalı bir isimle oluşturulur. Bu tamamen yeni bir dizindir — çalışan uygulama ile herhangi bir durumu paylaşmaz.

releases/20260318150000/  (yeni, boş)

Adım 2: Yeni dizinde klonlama ve inşa etme işlemi.

Depo, yeni sürüm dizinine klonlanır. Composer bağımlılıkları yüklenir. NPM varlıkları oluşturulur. Tüm bunlar, eski sürüm istekleri kesintisiz devam ederken yeni dizinde gerçekleşir.

releases/20260318150000/  (yapıldı, hazır)

Uygulamanız hala eski sürümden çalışıyor. Kullanıcılar hala hizmet alıyor. Onların bakış açısından hiçbir şey değişmedi.

Adım 3: Paylaşılan kaynakları bağla.

Belirli dizinler ve dosyalar sürümler arasında paylaşılır. storage dizini, kullanıcı yüklemeleri, günlükler ve çerçeve önbelleğini içerir. .env dosyası ortam yapılandırmanızı içerir. Bunlar her sürüm içinde bulunmaz — paylaşım dizininde yer alır ve her sürüme simbiyotik olarak bağlanır.

releases/20260318150000/storage -> /home/deploynix/your-site/shared/storage
releases/20260318150000/.env -> /home/deploynix/your-site/shared/.env

Bu, yüklenmiş dosyalarınızın, oturum verilerinizin ve günlüklerinizin sürümler arasında kalıcı olmasını sağlar. Silinmez, taşınmaz veya kaybolmaz.

Adım 4: Dağıtım kancalarını çalıştır.

Eğer ön yükleme kancaları (göçler, önbellek temizleme vb.) yapılandırdıysanız, bu kancalar yeni sürüm dizininde çalışır. Veritabanı göçleri, eski kod yine istekleri servis ederken işlenir. Bu, iyi yazılmış göçlerin geri uyumlu olmasından kaynaklanır — eski kodun bağlı olduğu bir şeyi silmeden veya yeniden adlandırmadan sütun ve tablolar ekler.

Adım 5: Sembolik linki değiştir.

Bu, atomik andır. current sembolik linki yeni sürüme işaret edecek şekilde güncellenir:

current -> /home/deploynix/your-site/releases/20260318150000

Linux’ta, ln -sfn komutu bu değişimi atomik hale getirir. current‘ın hiç bir zaman hiçbir yere işaret etmediği bir an yoktur. Hiçbir zaman kısmen oluşturulmuş bir dizine işaret ettiği bir an yoktur. Bir an eski sürüme, bir sonraki an yeni sürüme işaret eder.

Adım 6: PHP-FPM’i nazikçe yeniden yükle.

Sembolik bağlantı değiştikten sonra, PHP-FPM bir yeniden yükleme sinyali alır. Bu, bir yeniden başlatma değil, nazik bir yeniden yüklemedir. Mevcut PHP-FPM işçileri, eski sürüm dizininde bulunan eski kodu kullanarak mevcut istekleri işleyip tamamlar. Yeni işçiler, güncellenmiş current sembolik linkinden gelen yeni kodu alır.

Hiçbir istek sonlanmaz. Hiçbir bağlantı sonlandırılmaz. Eski istekleri bitiren işçiler normal bir şekilde sona erer. Yeni istekler yeni kodla işlem görmektedir.

Eğer Laravel Octane’yi (FrankenPHP, Swoole veya RoadRunner ile) kullanıyorsanız, bu süreç benzer şekilde işler — nazik bir yeniden başlatma sinyali, kalıcı işçilerin mevcut istekleri tamamlamasını ve yeni kod tabanıyla baştan baştan kurulmasını sağlar.

Adım 7: Yayın sonrası kancaları çalıştır.

Yeni sürüm aktif hale geldikten sonra yayın sonrası kancalar çalıştırılır. Bu, önbellek ısınma, bildirim gönderme veya entegrasyon pingleme gibi işlemleri içerebilir.

Adım 8: Eski sürümleri temizle.

Koruma yapılandırmanıza dayalı olarak, eski sürümler temizlenir. Varsayılan olarak, Deploynix, anında geri alma işlemini desteklemek için önceki sürüm sayısını korur. Koruma sınırını aşan sürümler silinir ve disk alanı geri kazanılır.

Paylaşılan Depolama: Dağıtımlar Arasında Neler Kalıcıdır?

Paylaşılan ve her sürüme özgü olanları anlamak, sıfır-downtime dağıtımları için kritik öneme sahiptir.

Dağıtımlar arasında paylaşılanlar:

• storage/app — Kullanıcı yüklemeleri ve uygulama dosyaları

• storage/app/public — Kamuya erişilebilir yüklenmiş dosyalar

• storage/framework/cache — Çerçeve önbelleği (dosya tabanlı önbellek kullanıyorsanız)

• storage/framework/sessions — Aktif kullanıcı oturumları

• storage/framework/views — Derlenmiş Blade görünümleri

• storage/logs — Uygulama günlükleri

• .env — Ortam yapılandırması

• database/database.sqlite — SQLite veritabanı (uygunsa)

Her dağıtım için benzersiz olanlar:

• vendor/ — Composer bağımlılıkları (her sürümde tam bağımlılık versiyonları sağlanır)

• node_modules/ — NPM paketleri (uygunsa)

• public/build/ — Derlenmiş ön yüz varlıkları

• Tüm uygulama kodu

Bu ayrım, kullanıcı oturumlarınızın dağıtımlar arasında kalıcı olmasını sağlar. Yüklenmiş dosyalarınız kaybolmaz. Günlükleriniz kesintisiz devam eder. Ancak her sürüm kendi bağımlılık kurulumuna sahip olur, bu da sürümler arasında bulaşma olmamasını sağlar.

PHP-FPM Nazik Yeniden Yükleme: Ana Detay

Nazik yeniden yükleme, sıfır-downtime’ın pratikte çalışmasını sağlayan faktördür, sadece teorik değil.

PHP-FPM SIGUSR2 sinyalini (yeniden yükleme sinyali) aldığında, şu olanlar gerçekleşir:

1. Eski havuzdan yeni işçiler almaya son verir

2. Mevcut işçiler, mevcut isteklerini işlemeye devam eder

3. Yeni işçiler, güncellenmiş current sembolik bağlantısından kod alır

4. Eski işçiler, isteklerini bitirdiklerinde sonlandırılır

5. Sonunda, tüm işçiler yeni kodu çalıştırır

Bu süreç genellikle birkaç saniye içinde tamamlanır, ancak önemli olan şu: hiçbir isteğin kesintiye uğramamasıdır. Bir kullanıcı, dağıtımdan birkaç milisaniye önce form gönderimine başlamışsa, POST isteği eski bir işçi tarafından tamamlanır. Bir sonraki yaptığı istek yeni kodu çalıştıran bir işçi tarafından ele alınır.

Octane uygulamaları için nazik yeniden yükleme, süreç düzeyinde değil, uygulama düzeyinde çalışır. Octane işçileri, mevcut isteğin döngülerini tamamlar, ardından yeni sürümden Laravel uygulamasını yeniden başlatır.

Anlık Geri Alma

Önceki sürümler, tam, kendi kendine yeterli dizinler olarak disk üzerinde saklandığından, geri almak son derece hızlıdır.

Deploynix kontrol panelinde “Geri Al” butonuna tıkladığınızda, neler olur:

1. current sembolik bağlantısı, önceki sürüme işaret edecek şekilde güncellenir

2. PHP-FPM nazikçe yeniden yükleme sinyali alır

Hepsi bu. Eski kodu yeniden indirmek, bağımlılıkları yeniden yüklemek, varlıkları yeniden derlemek yoktur. Önceki sürüm, disk üzerinde zaten mevcut ve hizmet vermeye hazırdır. Geri alma süreci saniyeler içinde gerçekleşir.

Bu, önceki bir “geri alma” işleminin tam tersidir. Yeniden dağıtım, hala birkaç dakika alır. Hala bağımlılıkları indirmek ve varlıkları derlemek gerektirir. Eski kodu kullanıyor gibi görünen yeni bir dağıtım söz konusudur. Ancak bir sembolik geri alma işlemi, anlık çünkü eski sürüm zaten mevcuttur.

Herhangi bir saklanan sürüme geri dönebilirsiniz, sadece hemen önceki olanla sınırlı değildir. Son üç dağıtımda sorun yaşadıysanız, üç dağıtım önceki sürüme geri dönebilirsiniz, aynı tek tıkla süreçle.

Göç Güvenli Kod Yazma

Sıfır-downtime dağıtımları, veritabanı göçlerinizin geri uyumlu olduğunda en iyi şekilde çalışır. Bu, eski kodun, göç çalıştığında ama sembolik bağlantı değişmeden önce doğru işlev görmesi gerektiği anlamına gelir.

Önerdiğimiz yönergeler:

Güvenli göç işlemleri:

Dikkat gerektiren işlemler:

• Bir sütunun adını değiştirme — iki aşamalı bir yaklaşım kullanın (yeni sütunu ekleyin, her ikisini de kullanan kodu dağıtın, eski sütunu kaldırın)

• Bir sütunu kaldırma — öncelikle sütunu kullanmayan kodu dağıtın, ardından kaldırın

• Bir sütun tipini değiştirme — istenen tipte yeni bir sütun ekleyin, verileri aktarın, kodu güncelleyin, eski sütunu kaldırın

Bu, yalnızca Deploynix’e özgü değildir — bu, sıfır-downtime dağıtım sistemi için bir en iyi uygulamadır. Ana prensip, geçiş süresi boyunca veritabanınızın hem eski hem de yeni kodla uyumlu olmasıdır.

Dağıtım Senaryoları: Sıfır-Downtime Kapsamında

Deploynix, en yaygın Laravel dağıtım görevlerini otomatik olarak gerçekleştiren varsayılan bir dağıtım sırası çalıştırır. Yeni sürüm oluşturulduktan sonra, sembolik bağlantı değişmeden önce şu adımlar çalıştırılır:

• Bağımlılıkların yüklenmesi (composer install, npm install)

• Varlıkların derlenmesi (npm run build)

• Önbelleğin optimizasyonu (php artisan config:cache, php artisan route:cache, php artisan view:cache)

• Veritabanı göçleri (php artisan migrate --force)

• Kuyruk işçi yeniden başlatma (php artisan queue:restart)

Ayrıca, siteniz için özel bir dağıtım betiği tanımlayabilirsiniz. Bu betik, varsayılan dağıtım adımlarından sonra çalışır ve önbellek ısınma, bildirim gönderme veya özel doğrulama gibi proje spesifik komutları eklemenin bir yolu sağlar.

Dağıtım sırasındaki herhangi bir adım başarısız olursa, dağıtım iptal edilir. Sembolik bağlantı, en son çalışan sürüme işaret etmeye devam eder. Kullanıcılarınız asla başarısız bir dağıtımı görmez.

Dağıtımları Gerçek Zamanlı İzleme

Deploynix, dağıtım günlüklerini gerçek zamanlı olarak WebSocket bağlantıları üzerinden aktarır. Her adımı izlersiniz — kod kontrolü, bağımlılık yüklemesi, varlık oluşturma, betik yürütme, sembolik bağlantı değiştirme ve hizmet yeniden yükleme.

Bu gerçek zamanlı görünürlük, dağıtımın tamamlanıp tamamlanmadığını merak etmeden sayfayı yenilemenize gerek olmadığı anlamına gelir. Herhangi bir hata veya uyarılar da dahil olmak üzere, çıktıyı canlı olarak görürsünüz. Eğer bir şey başarısız olursa, hemen hangi adımda ne olduğunu bilirsiniz.

Sık Sorulan Sorular

Sıfır-downtime, Octane ile işe yarar mı?

Evet. Deploynix, üç Octane sürücüsü — FrankenPHP, Swoole ve RoadRunner için nazik yeniden başlatmaları yönetir. Yeniden başlatma sinyali sürücüye göre değişir, ancak etkisi aynıdır: mevcut istekler tamamlanır, ardından işçiler yeni kod ile yeniden başlatılır.

Kuyruk işçileri hakkında ne durumda?

Kuyruk işçilerinin yeni kodu alabilmek için yeniden başlatılması gerekir. Deploynix, sembolik bağlantı değiştikten sonra kuyruk işçilerini nazikçe yeniden başlatır. İşçiler, mevcut işlerini bitirdikten sonra yeni kodla yeniden başlatılır.

Saklanan sürümler ne kadar disk alanı kullanır?

Her sürüm, uygulama kodunuzu, vendor dizinini ve derlenmiş varlıkları içerir. Tipik bir Laravel uygulamasının sürümü, bağımlılıklara ve varlıklara bağlı olarak 50-200 MB arasında değişir. Beş sürümlük bir koruma ile, sürümler için 250 MB ile 1 GB arasında bir disk alanına ihtiyacınız vardır. Disk sınırlarınıza bağlı olarak koruma sayısını yapılandırabilirsiniz.

Birden fazla sunucuya dağıtım yapabilir miyim?

Eğer yük dengeleyici arkasında birden fazla sunucunuz varsa, her sunucuya ayrı ayrı dağıtım yapabilirsiniz. Deploynix, yük dengeleyici konfigürasyonunu ayrı yönetir, böylece her sunucu güncellenirken trafik normal şekilde yönlendirmeye devam eder.

Sonuç

Sıfır-downtime dağıtım, bir sihir değil. Atomik sembolik bağlantı geçişlerine, paylaşılan depolama ve nazik hizmet yeniden yüklemeye dayanan iyi bilinen bir tekniktir. Bireysel parçalar basittir. Deploynix’in değeri, bu parçaların doğru bir şekilde bir araya getirilmesi, kapsamlı bir şekilde test edilmesi ve her dağıtımda varsayılan olarak uygulanmasıdır.

Dağıtım yaptığınızda, kesinti düşünmek zorunda kalmamalısınız. Kullanıcılarınız, yeni kod gönderdiğinizde bunu fark etmemelidir. Geri alma işlemi de paniklemek yerine tek tıkla yapılmalıdır.

Sıfır-downtime dağıtım, pratikte böyle bir şeydir ve Deploynix’te her dağıtım bu şekilde çalışır.

Daha fazlası için deploynix.io‘yu ziyaret edebilirsiniz.