Servis Yönetimi: Uygulamanız Çöktüğünde Onu Kim Ayağa Kaldırıyor?

SSH kapanınca uygulama duruyor mu? Servis tanımının öğeleri, yeniden başlatma politikası ve sağlık kontrolünün neden ayrı gerektiği. Servis Yönetimi…

Servis Yönetimi: Uygulamanız Çöktüğünde Onu Kim Ayağa Kaldırıyor?
İçindekiler
  1. Elle Başlatmanın Üç Sorunu
  2. Servis Denetleyicisi Ne Yapar?
  3. İyi Bir Servis Tanımının Öğeleri
  4. Çalışma Dizini ve Kullanıcı
  5. Yeniden Başlatma Politikası
  6. Bağımlılıklar
  7. Ortam Değişkenleri
  8. Kapanma Davranışı
  9. Sık Yapılan Hatalar
  10. Neler Servis Olmalı?
  11. Sonuç
  12. Sıkça Sorulan Sorular (SSS)
  13. Uygulamam SSH kapanınca neden duruyor?
  14. Elle çalışıyor ama servis olarak çalışmıyor, neden?
  15. Yeniden başlatma politikası nasıl olmalı?
  16. Süreç ayakta ama uygulama yanıt vermiyor, denetleyici kaldırmaz mı?

Servis Yönetimi: Uygulamanız Çöktüğünde Onu Kim Ayağa Kaldırıyor?

Uygulamanızı SSH ile başlattınız, çalışıyor. Bağlantıyı kapattınız — uygulama da kapandı. Ya da gece yarısı bir hata yüzünden süreç sonlandı ve sabah "site kapalı" mesajıyla uyandınız.

Bu iki senaryonun ortak çözümü servis yönetimidir. Sanal sunucunuzda çalışan her uygulamanın bir denetleyicisi olmalı — çöktüğünde onu yeniden başlatan, açılışta otomatik ayağa kaldıran bir katman.

Elle Başlatmanın Üç Sorunu

  1. Oturum kapanınca süreç ölür. Terminal oturumuna bağlı başlatılan program, bağlantı koptuğunda sonlanır.
  2. Çökme sonrası kimse kaldırmaz. Bir hata yüzünden süreç sonlanırsa, siz fark edene kadar hizmet kapalı kalır.
  3. Yeniden başlatmada geri gelmez. Sunucu yeniden başladığında elle başlattığınız her şey kapalı olur.

Üçüncü madde en can yakıcı olanıdır: sunucunuz beklenmedik bir şekilde yeniden başlar, web sunucusu ve veritabanı otomatik açılır ama sizin elle başlattığınız uygulama açılmaz. Sistem "çalışıyor" görünür, hizmet ise yoktur.

Servis Denetleyicisi Ne Yapar?

Yetenek Karşılığı
Açılışta başlatma Sunucu yeniden başlasa da hizmet döner
Çökme sonrası yeniden başlatma Kısa kesinti, otomatik toparlanma
Bağımlılık sırası Veritabanı hazır olmadan uygulama başlamaz
Log yönlendirme Çıktılar tek yerden okunabilir
Kaynak sınırlama Kaçak süreç tüm sunucuyu tüketemez
Kullanıcı ayrımı Uygulama root yerine kısıtlı kullanıcıyla çalışır

Son iki satır güvenlik açısından değerlidir: bir servis tanımı, uygulamanın hangi kullanıcıyla çalışacağını ve ne kadar kaynak kullanabileceğini de belirler. Elle başlatmada bu denetimlerin hiçbiri yoktur.

İyi Bir Servis Tanımının Öğeleri

Çalışma Dizini ve Kullanıcı

Uygulamanın hangi dizinde ve hangi kullanıcıyla çalışacağı açıkça belirtilmelidir. Varsayılana bırakılırsa uygulama beklenmedik bir dizinde başlar ve göreli yollar kırılır.

Yeniden Başlatma Politikası

Süreç sonlandığında ne yapılacağı tanımlanır. Yaygın seçim: her durumda yeniden başlat. Ancak sınırsız bırakılmamalıdır.

Kritik ayrıntı: yeniden başlatma denemeleri arasına bekleme süresi koyun. Aksi hâlde hatalı bir yapılandırma yüzünden açılamayan uygulama saniyede onlarca kez başlatılmayı dener ve sunucuyu meşgul eder.

Bağımlılıklar

Uygulamanız veritabanına ihtiyaç duyuyorsa, veritabanı servisi hazır olmadan başlamamalıdır. Açılışta ilk saniyelerde yaşanan "veritabanına bağlanılamıyor" hatalarının nedeni genellikle eksik bağımlılık tanımıdır.

Ortam Değişkenleri

Uygulamanız ortam değişkenlerinden yapılandırma okuyorsa, bunlar servis tanımında veya ayrı bir dosyada belirtilmelidir. Terminalinizde tanımlı bir değişken, servis çalışırken mevcut değildir — elle çalışırken sorunsuz olan uygulamanın servis olarak çalışmamasının en yaygın nedeni budur.

Kapanma Davranışı

Servis durdurulduğunda uygulamaya önce nazik bir kapanma sinyali gönderilir. Uygulamanız bu sinyali yakalayıp işini tamamlayabilmelidir — devam eden bir isteği yarıda kesmek veri tutarsızlığı üretir.

Sık Yapılan Hatalar

  • Uygulamayı root ile çalıştırmak. Kolaydır ama bir açık bulunduğunda saldırgan doğrudan tam yetki elde eder.
  • Sonsuz yeniden başlatma döngüsü kurmak. Bekleme süresi ve deneme sınırı tanımlanmazsa sunucu kilitlenir.
  • Logları hiçbir yere yazmamak. Servis çöküyorsa nedenini logsuz bulamazsınız.
  • Açılışta etkinleştirmeyi unutmak. Servis tanımlanır ama açılışta başlaması için etkinleştirilmezse, yeniden başlatmada gelmez.
  • Sağlık kontrolü yapmamak. Süreç ayakta olabilir ama yanıt vermiyor olabilir; denetleyici bunu bilmez.

Son madde önemli bir sınırı gösterir: servis denetleyicisi süreç ölünce müdahale eder, ancak askıda kalmış bir süreci fark etmez. Uygulamanız yanıt vermiyor ama süreç yaşıyorsa, denetleyici hiçbir şey yapmaz.

Bu boşluğu doldurmak için ayrı bir sağlık kontrolü gerekir: belirli aralıklarla uygulamaya istek gönderip yanıt alınmıyorsa servisi yeniden başlatan bir mekanizma.

Neler Servis Olmalı?

Pratik ölçüt: sürekli çalışması gereken her şey.

  • Web uygulaması ve API sunucuları
  • Kuyruk işçileri ve arka plan görev süreçleri
  • Önbellek ve arama servisleri
  • Özel yazılmış dinleyici uygulamalar

Buna karşılık periyodik çalışıp biten işler servis değil zamanlanmış görev olmalıdır. İkisini karıştırmak, sürekli yeniden başlatılan ve sürekli biten bir süreç yaratır.

Bu düzeyde süreç denetimi, paylaşımlı hosting hesaplarında mümkün değildir — kendi servislerinizi tanımlamak kök erişimi gerektirir. Uzun ömürlü arka plan süreçleri çalıştırmanız gerekiyorsa, sanal sunucu bu ihtiyacın karşılandığı en düşük maliyetli seçenektir.

Sonuç

Elle başlatılan bir uygulama, geçici bir çözümdür — oturum kapandığında ölür, çöktüğünde kalkmaz, yeniden başlatmada geri gelmez. Sürekli çalışması gereken her uygulamayı servis olarak tanımlayın; kullanıcı, çalışma dizini, ortam değişkenleri ve bağımlılıkları açıkça belirtin. İki ayrıntıyı atlamayın: yeniden başlatma denemeleri arasına bekleme süresi koyun ve açılışta başlaması için servisi etkinleştirin. Bir de sınırını bilin — denetleyici ölen süreci kaldırır, askıda kalanı fark etmez; onun için ayrı bir sağlık kontrolü gerekir.

Sıkça Sorulan Sorular (SSS)

Uygulamam SSH kapanınca neden duruyor?

Terminal oturumuna bağlı başlatılan süreçler, oturum kapandığında sonlandırılır. Kalıcı çözüm, uygulamayı bir servis olarak tanımlamaktır — böylece oturumdan bağımsız çalışır, açılışta otomatik başlar ve çöktüğünde yeniden kaldırılır.

Elle çalışıyor ama servis olarak çalışmıyor, neden?

En yaygın neden ortam değişkenleridir. Terminalinizde tanımlı olan değişkenler servis çalışırken mevcut değildir. Ayrıca çalışma dizini farklı olabilir ve göreli yollar kırılabilir. Her ikisini de servis tanımında açıkça belirtin.

Yeniden başlatma politikası nasıl olmalı?

Çökme durumunda yeniden başlatma açık olmalı, ancak denemeler arasına bekleme süresi konmalıdır. Aksi hâlde açılamayan bir uygulama saniyede onlarca kez başlatılmayı dener ve sunucuyu meşgul eder. Deneme sınırı tanımlamak da faydalıdır.

Süreç ayakta ama uygulama yanıt vermiyor, denetleyici kaldırmaz mı?

Hayır. Servis denetleyicisi süreç sonlandığında müdahale eder; askıda kalmış ama yaşayan bir süreci fark etmez. Bunun için belirli aralıklarla uygulamaya istek gönderen ve yanıt gelmezse servisi yeniden başlatan ayrı bir sağlık kontrolü kurmanız gerekir.