Systemd Unit Dosyaları ile Modern Linux Servis Yönetimi

 · 

Systemd Unit Dosyaları ile Modern Linux Servis Yönetimi

Systemd Unit Dosyaları ile Modern Linux Servis Yönetimi

Linux sistemlerde servis yaşam döngüsünü yönetmek, uygulamaların tutarlı ve güvenilir bir şekilde çalışmasını sağlamak için kritik öneme sahiptir. Systemd, modern Linux dağıtımlarında başlangıç sistemi ve servis yöneticisi olarak görev alarak bu süreci standardize eder. Systemd unit dosyaları, bir servisin nasıl başlatılacağı, durdurulacağı, bağımlılıkları ve genel davranışları hakkında detaylı talimatlar içerir.

Systemd Unit Dosyasının Anatomisi

Bir Systemd unit dosyası, genellikle .service uzantısıyla /etc/systemd/system/ dizininde bulunur ve üç ana bölümden oluşur: [Unit], [Service] ve [Install].

[Unit] Bölümü

Bu bölüm, servisin genel tanımını ve diğer unit'lerle olan ilişkilerini belirler.

  • Description: Servisin kısa bir tanımı.
  • Documentation: Servisle ilgili dokümantasyon URL'leri.
  • After: Bu servisin, belirtilen unit'ler başlatıldıktan sonra başlatılacağını garanti eder. Sıralama bağımlılığıdır.
  • Requires: Bu servisin başlatılabilmesi için belirtilen unit'lerin başarılı bir şekilde başlatılması gerektiğini ifade eder. Eğer bağımlı unit başarısız olursa, bu servis de başlatılmaz.
  • Wants: Requires'a benzer ancak daha zayıf bir bağımlılıktır. İlgili unit başlatılmaya çalışılır fakat başarılı olmasa bile bu servis çalışmaya devam eder.

[Service] Bölümü

Servisin nasıl çalıştırılacağına dair temel yapılandırmayı içerir. Bu bölüm, servisin tipini, yürütülecek komutları ve çalışma ortamını tanımlar.

  • Type: Servisin başlangıç tipini belirler (örn. simple, forking, oneshot, notify, idle). Çoğu daemon için simple veya forking kullanılır.
  • ExecStart: Servisi başlatmak için yürütülecek komut.
  • ExecStop: Servisi durdurmak için yürütülecek komut (isteğe bağlı).
  • ExecReload: Servisi yeniden yüklemek için yürütülecek komut (isteğe bağlı).
  • Restart: Servisin çökmesi veya durması durumunda nasıl tepki vereceğini belirler (örn. no, on-success, on-failure, always).
  • User/Group: Servisin hangi kullanıcı/grup altında çalışacağını belirler. Güvenlik için önemlidir.
  • WorkingDirectory: Servisin başlangıç dizini.
  • Environment/EnvironmentFile: Servis için ortam değişkenlerini tanımlar. Hassas bilgiler için EnvironmentFile kullanmak daha iyidir.
  • StandardOutput/StandardError: Çıktıların nereye yönlendirileceğini belirler (örn. journal, null, bir dosya).

[Install] Bölümü

Bu bölüm, servisin sistem başlangıcında nasıl etkinleştirileceğini kontrol eder.

  • WantedBy: Bu servisin hangi hedef (target) tarafından istendiğini belirler. Genellikle çok kullanıcılı sistemler için multi-user.target kullanılır.

Gerçek Dünya Senaryosu: Bir Node.js Uygulamasını Yönetmek

Bir üretim ortamında çalışan Node.js uygulamanız olduğunu varsayalım. Bu uygulama, bir API servisi sunuyor ve sürekli çalışması gerekiyor. Systemd ile bu uygulamayı nasıl yönetirsiniz?

1. Node.js Uygulaması (app.js)

// app.js basit bir HTTP sunucusu oluştururvar http = require('http');var port = process.env.PORT || 3000;http.createServer(function (req, res) {  res.writeHead(200, {'Content-Type': 'text/plain'});  res.end('Merhaba Systemd ile Node.js!
');}).listen(port);console.log('Sunucu ' + port + ' portunda çalışıyor...');

2. Systemd Unit Dosyası (/etc/systemd/system/nodejs-app.service)

Bu dosya, uygulamayı node komutuyla çalıştıracak ve hata durumunda otomatik olarak yeniden başlatılmasını sağlayacak şekilde yapılandırılmıştır.

[Unit]Description=Node.js Uygulama ServisiAfter=network.target[Service]Type=simpleUser=www-dataGroup=www-dataWorkingDirectory=/opt/nodejs-appExecStart=/usr/bin/node /opt/nodejs-app/app.jsRestart=on-failureRestartSec=10  # Yeniden başlatmadan önce 10 saniye bekleEnvironment="PORT=8080"StandardOutput=journalStandardError=journal[Install]WantedBy=multi-user.target

Açıklamalar:

  • After=network.target: Uygulamanın ağ servisi başladıktan sonra başlatılmasını sağlar.
  • User=www-data/Group=www-data: Uygulamanın ayrıcalıklı olmayan bir kullanıcı altında çalıştırılması güvenlik açısından önemlidir.
  • WorkingDirectory=/opt/nodejs-app: Node.js uygulamasının bulunduğu dizini belirtir.
  • ExecStart=/usr/bin/node /opt/nodejs-app/app.js: Uygulamayı başlatmak için kullanılan komut. Tam yolu belirtmek önemlidir.
  • Restart=on-failure: Uygulama bir hata nedeniyle kapanırsa, Systemd onu otomatik olarak yeniden başlatmaya çalışır. Bu, uygulamanın esnekliğini artırır.
  • RestartSec=10: Yeniden başlatma denemeleri arasında 10 saniye bekler. Bu, hızlı hatalarda sürekli yeniden başlatma döngülerini önler.
  • Environment="PORT=8080": Uygulamanın dinleyeceği portu bir ortam değişkeni olarak ayarlar. Bu şekilde uygulamanın kodunu değiştirmeden yapılandırma yapılabilir.
  • StandardOutput=journal/StandardError=journal: Uygulamanın standart çıktı ve hata çıktılarını journald'ye yönlendirir. Bu, logların merkezi olarak yönetilmesini ve journalctl ile kolayca incelenmesini sağlar.
  • WantedBy=multi-user.target: Sistem çok kullanıcılı modda başlatıldığında bu servisin otomatik olarak başlatılmasını sağlar.

3. Servisi Etkinleştirme ve Başlatma

Unit dosyasını oluşturduktan sonra, Systemd'nin yeni yapılandırmayı okumasını sağlamak ve servisi etkinleştirmek için şu komutları kullanın:

sudo systemctl daemon-reload # Systemd'ye yeni unit dosyasını okumasını söyler.sudo systemctl enable nodejs-app.service # Servisi sistem başlangıcında otomatik başlaması için etkinleştirir.sudo systemctl start nodejs-app.service # Servisi hemen başlatır.

4. Servis Durumunu Kontrol Etme ve Logları İzleme

Servisin durumunu kontrol etmek ve loglarını görüntülemek için:

sudo systemctl status nodejs-app.service # Servisin mevcut durumunu gösterir.sudo journalctl -u nodejs-app.service -f # Servisin loglarını gerçek zamanlı olarak izler.

journalctl komutu, StandardOutput ve StandardError ayarları sayesinde uygulamanızın tüm çıktılarını tek bir merkezi yerden izlemenizi sağlar. Bu, hata ayıklama ve üretim sorunlarını giderme süreçlerinde önemli bir kolaylık sunar.

Kaynak Kısıtlamaları ve Güvenlik

Systemd, servisler için cgroup entegrasyonu sayesinde CPU, bellek ve I/O gibi kaynakları kısıtlama yeteneğine de sahiptir. Örneğin:

  • MemoryLimit=500M: Servisin kullanabileceği bellek miktarını sınırlar.
  • CPUShares=256: Servise ayrılacak CPU payını belirler (varsayılan 1024'tür).

Bu tür ayarlar, birden fazla servisin aynı sunucuda çalıştığı ve bir servisin kaynakları tüketerek diğerlerini etkilemesini engellemek istediğiniz üretim senaryolarında hayati önem taşır.

Sonuç

Systemd unit dosyaları, Linux sistemlerde servislerin yaşam döngüsünü, bağımlılıklarını ve kaynak kullanımlarını hassas bir şekilde yönetmek için güçlü ve esnek bir mekanizma sunar. İyi yapılandırılmış bir Systemd servisi, uygulamanızın hata durumlarında otomatik olarak kendini toparlamasını, güvenlik politikalarına uymasını ve üretim ortamlarında tutarlı bir şekilde çalışmasını sağlar. Bu derinlemesine kontrol yeteneği, AWS gibi bulut platformlarında veya on-prem altyapılarda sağlam ve sürdürülebilir sistemler inşa etmek için vazgeçilmez bir araçtır.

← Blog Listesine Dön