Servis Birimleri: Uygulamanizi Sunucuda Kalici Olarak Calistirmak

Servis Birimleri: Uygulamanızı Sunucuda Kalıcı Olarak Çalıştırmak

Uygulamanızı terminalden başlattınız, arka plana attınız, çalışıyor. Sonra oturum kapandı ve uygulama da kapandı. Ya da sunucu yeniden başladı ve kimse uygulamayı tekrar başlatmadı. Bu, süreç yönetiminin işletim sistemine devredilmediği her sunucuda yaşanır.

Bu yazı, uygulamaların servis olarak tanımlanmasını ele alıyor.

Elle Başlatmanın Sorunları

Üçüncü satır en pahalı olanıdır: planlı bir bakım veya beklenmedik bir yeniden başlatma sonrası elle başlatılmış uygulamalar geri gelmez — ve bunun fark edilmesi çoğu zaman müşteri şikayetiyle olur.

Bu, kesinti süresini gereksiz yere uzatır.

İkinci satır ise geçici hatalardan sonra kendiliğinden toparlanmayı engeller.

Dördüncü satır ise sorun anında hiçbir kayıt bulunamamasına yol açar.

Servis Tanımı Ne İçerir

• Çalıştırılacak komut.
• Çalışma dizini ve kullanıcı.
• Bağımlılıklar.
• Yeniden başlatma davranışı.

Üçüncü madde sıralama sorunlarını çözer: uygulamanız veritabanına bağımlıysa bunu tanımda belirtmek, sunucu açılışında uygulamanın veritabanı hazır olmadan başlamasını ve bağlantı hatasıyla ölmesini önler.

Bu hata yeniden başlatmalarda sık yaşanır.

İkinci madde ise güvenlik açısından önemlidir.

Uygulama yönetici yetkisiyle değil, kendi sınırlı kullanıcısıyla çalışmalıdır.

Yeniden Başlatma Politikası

İkinci satır önemli bir ayrımı korur: işini tamamlayıp normal biçimde çıkan bir betiği her durumda yeniden başlatacak şekilde tanımlamak, betiğin sonsuz döngüde çalışmasına yol açar — başarılı çıkış bir arıza değildir.

Bu hata, sunucu kaynaklarını hızla tüketir.

Birinci satır ise sürekli çalışması gereken servisler içindir.

Politika, uygulamanın doğasına göre seçilmelidir.

Yeniden Başlatma Döngüsü

1. Uygulama başlar ve hemen çöker.
2. Sistem tekrar başlatır.
3. Döngü sürer.

Bu döngü sunucuyu meşgul eder ve önlem gerektirir: yapılandırma hatası yüzünden açılışta çöken bir servis saniyede defalarca yeniden başlatılabilir ve bu, günlükleri şişirirken işlemciyi de gereksiz meşgul eder.

Çözüm, deneme sayısı ve zaman aralığı tanımlamaktır.

Belirli sürede belirli sayıdan fazla başarısızlık olursa servis durdurulur.

Bu durum ayrıca uyarı üretmelidir.

Günlük Yönetimi

• Çıktılar merkezî kayda gider.
• Servis bazında filtrelenebilir.
• Dosya döndürme otomatiktir.

Birinci madde önemli bir kolaylık sağlar: servis olarak tanımlanan uygulamanın ekrana yazdığı her şey otomatik olarak sistem kayıtlarına düşer — kendi günlük dosyası yönetimi yazmanız gerekmez.

Bu kayıtlar zaman damgalı ve aranabilir olur.

Üçüncü madde ise diskin dolmasını önler.

Elle yönetilen günlük dosyaları sık sık disk doldurur.

Düzgün Kapanma

1. Önce nazik sonlandırma sinyali gönderilir.
2. Uygulama işini bitirir.
3. Süre dolarsa zorla kapatılır.

İkinci madde uygulamanın da iş birliği yapmasını gerektirir: sonlandırma sinyalini yakalayıp devam eden isteği tamamlayan bir uygulama, yeniden başlatmada tek bir isteği bile kaybetmez — sinyali yok sayan uygulama ise ortadaki işi yarım bırakır.

Bekleme süresi de tanımda belirtilmelidir.

Uzun süren işler için bu süre uzatılmalıdır.

Aksi hâlde zorla kapatma devreye girer ve veri kaybı olabilir.

Zamanlı Çalıştırma

Birinci satır klasik zamanlayıcıya göre gerçek bir üstünlüktür: sunucu bakım nedeniyle kapalıyken gelen zamanlanmış çalışma klasik yöntemde tamamen atlanır — servis tabanlı zamanlayıcı, açılışta bu kaçırılan işi telafi edebilir.

Bu, günlük yedekleme gibi işlerde önemlidir.

İkinci satır ise çok sunuculu ortamlarda yükü dağıtır.

Aynı anda başlayan yüzlerce görev, ortak kaynakları tıkar.

Doğrulama

• Açılışta otomatik geldiğini test edin.
• Süreci öldürüp toparlandığını görün.
• Günlüklerin aktığını doğrulayın.

Birinci madde en sık atlanan testtir: servisi tanımlamak ile açılışta başlamasını etkinleştirmek ayrı işlemlerdir — tanımı yapıp etkinleştirmeyi unutmak, ilk yeniden başlatmada uygulamanın gelmemesi demektir.

Bu ayrım çok sık gözden kaçar.

İkinci madde ise yeniden başlatma politikasının çalıştığını kanıtlar.

Test edilmemiş bir kurtarma mekanizması, olmayan bir mekanizmadır.

Servis tanımlarını yönetebilmek ve açılış davranışını denetleyebilmek tam sistem erişimi gerektirir; fiziksel sunucu altyapı paketleri ile sunucu yapılandırmanızı baştan sona kendiniz yönetebilirsiniz.

Sonuç

Elle başlatılan uygulamalar ilk yeniden başlatmada kaybolur ve bunun fark edilmesi çoğu zaman müşteri şikayetiyle olur. Servis tanımı bunu çözer: bağımlılıkları belirtin, uygun yeniden başlatma politikasını seçin — işini bitirip çıkan bir betiği her durumda yeniden başlatmak sonsuz döngü üretir — ve açılışta otomatik geldiğini mutlaka test edin.

Sıkça Sorulan Sorular (SSS)

Uygulamam neden yeniden başlatmadan sonra gelmiyor?

Elle başlatılmış olabilir ya da servis tanımlı olsa da açılışta başlaması etkinleştirilmemiştir. Servisi tanımlamak ile açılışta başlamasını etkinleştirmek ayrı işlemlerdir; bu ayrım çok sık gözden kaçar. Yeniden başlatarak test edin.

Servisim sürekli yeniden başlıyor?

Yapılandırma hatası yüzünden açılışta çöküyor olabilir; bu durumda saniyede defalarca başlatılır, günlükleri şişirir ve işlemciyi meşgul eder. Deneme sayısı ve zaman aralığı tanımlayın: belirli sürede belirli sayıdan fazla başarısızlıkta servis durdurulur ve uyarı üretilir.

Hangi yeniden başlatma politikasını seçmeliyim?

Sürekli çalışan servisler için her durumda, işini bitirip çıkan işler için yalnızca hatada. İkincisi önemlidir: normal biçimde çıkan bir betiği her durumda yeniden başlatmak sonsuz döngüye yol açar çünkü başarılı çıkış bir arıza değildir.

Yeniden başlatmada istek kaybediyorum?

Uygulamanın sonlandırma sinyalini yakalayıp devam eden isteği tamamlaması gerekir. Sinyali yok sayan uygulama ortadaki işi yarım bırakır. Bekleme süresini de tanımda belirtin; uzun süren işler için bu süreyi uzatın, aksi hâlde zorla kapatma devreye girer.