Delphi ile üretim ortamında Linux servisleri

Arka plan servisleri birçok kurumsal uygulamada sessiz bir verimlilik mekanizmasıdır: veri ithalatı, ihracatı, dosya ve EDI işleme, ERP/DMS/CRM ile eşitleme, zamanlanmış iş akışları, bildirimler veya teknik arayüzlerin sunulması. Pratikte başarının belirleyicisi yalnızca işlevsellik değil; sorulması gereken soru şudur: Servis güvenilir şekilde işletilebilir, güncellenebilir, izlenebilir ve hata durumunda kontrollü şekilde geri getirilebilir mi?

Tam da bu noktada, Linux-Services ile Delphi üzerine soğukkanlı bir değerlendirme fayda sağlar. Delphi birçok organizasyonda zaten iş mantığının omurgasını oluşturur. Bu mantık sunucu tarafında akıllıca yeniden kullanılabiliyorsa tutarlı bir genel mimari ortaya çıkar: iş kuralları iki kez uygulanmaz, arayüzler stabil kalır ve ekipler yerleşik araç setinde çalışır. Aynı zamanda Linux sunucu dünyasında işletim, otomasyon ve güvenlik için olgun bileşenler getirir.

Belirleyici nokta şudur: Bir Linux servisi “yanında çalıştırılan küçük yardımcı program” değildir. O, işletme sorumluluğu olan bir ürün bileşenidir. Bu yazı, Delphi tabanlı Linux servislerinin üretimde nasıl sağlam konumlandırılacağını somut şekilde gösterir: süreç ve durum modelinden systemd entegrasyonuna, logging, dağıtıma ve güncellemelere; izlemeye, veri erişimine, güvenliğe ve tipik hata örüntülerine kadar. Amaç, günlük kullanımda işe yarayan bir kurulumdur — gece 03:00’te de dahil.

Wann Delphi-Services unter Linux sinnvoll sind

Bir Delphi-Linux servisi, aşağıdaki kalıplardan biri veya birkaçı geçerliyse mantıklıdır:

• Mevcut Delphi iş mantığı sunucu tarafında kullanılmak isteniyor (ör. doğrulamalar, hesaplamalar, kural setleri, ithalat/ihracat ayrıştırıcıları).
• Arka plan işleme uygulamanın ayrılmaz bir parçasıysa (ör. PDF/raporlama pipeline’ları, iş kuyruğu, toplu işleme).
• Entegrasyon yükü artıyor: çok sayıda sistem, çoklu arayüzler, çok format; güvenilir tekrar edilebilirlik (idempotans) önemli hale geliyor.
• Modernizasyon ama tamamen yeniden başlama yok: mantığın parçaları servis katmanına taşınırken masaüstü istemci kademeli olarak hafifletiliyor.
• REST-Server & Services birlikte düşünülmeli: aynı kod standardı, aynı logging/monitoring, eş roll-out süreçleri.

Daha az uygun olduğu durumlar: bir ekipte hiç Delphi yetkinliği yoksa ve zaten zorunlu olarak standartlaştırılmış bir platform (ör. mevcut Java/.NET ekosistemi) kesinlikle dayatılıyorsa. Bu durumda sorun Delphi değil, organizasyonel yerleştirmedir. Birçok şirkette Delphi mevcut bir değerdir ve uygun planlama ile servis katmanında kararlı şekilde yeniden kullanılabilir.

Architekturgrundlagen: Prozessmodell, Zustände, Verantwortlichkeiten

Üretim niteliğindeki bir servis nadiren “ana işlev” yüzünden başarısız olur. Daha sık rastlanan sebep belirsiz durumlar: Ağ kesintisinde ne olur? Servis veritabanı failover’ında nasıl davranır? Bir iş iki kez mi işlenir? SIGTERM davranışı tanımlı mı? Bu yüzden her servisin açık bir süreç ve durum modeline ihtiyacı vardır.

Service-Typen: Always-on vs. Worker vs. Job-Runner

B2B ortamında üç temel tip öne çıkar:

• Always-on Daemon: sürekli çalışan süreç, örn. dinleyici, kuyruk-tüketici, olay-dağıtıcı, Websocket/Push bileşeni.
• Worker-Pool: kuyruktan paralel olarak işler işleyen birden çok örnek. Ölçekleme süreç sayısıyla yapılır.
• Job-Runner (Timer): periyodik olarak başlar, görevleri yapar ve kendini sonlandırır. Linux altında genellikle kendi zamanlayıcı thread’leri yerine systemd timer/cron tercih edilir.

Delphi üç deseni de destekleyebilir. İşletme açısından önemli olan desenin bilinçli seçilmesidir. Sadece her 15 dakikada bir iş yapan bir “always-on” süreç gereksiz karmaşıklık getirir (hafıza sızıntıları geç fark edilir, boşta bekleme durumları düzgün ele alınmaz). Tersine, düşük gecikme gerektiren senaryoda saf bir job-runner yetersiz kalabilir.

Idempotenz und Wiederanlauf: der Kern produktiver Robustheit

Üretim işletimi demektir ki: servisler yeniden başlatılır, dağıtımlar yapılır, ağlar geçici olarak kararsız olur, veritabanları bakım pencereleri geçirir ve işler çift gelebilir. Bu yüzden idempotans (birden çok çalıştırmanın yan etki üretmemesi) ithalatlar, ihracatlar ve entegrasyonlarda temel prensiptir.

Pratikte bunun anlamı:

• Her işin bir benzersiz iş-ID ve bir durumu vardır (queued, running, succeeded, failed, dead-letter).
• Yan etkiler (ör. “fatura gönderildi”) loglardan türetilmek yerine özel kanıt ile saklanır.
• Retry stratejileri kontrollüdür: backoff, maksimum deneme sayısı, net abort kriterleri, Dead-Letter-Queue.

İdempotansı düzgün uygulayanlar işletmede büyük avantaj sağlar: Bir yeniden başlatma kriz değil, standart bir durum olur.

systemd als Betriebsfundament: Start, Stop, Restart, Limits

Linux altında çoğu dağıtımda systemd servislerin işletimini düzenlemek için merkezi araçtır. Delphi servisleri için systemd sadece bir başlatma betiği değil, kararlılık mimarisinin parçasıdır. İyi tanımlanmış bir unit dosyası genellikle “bir şekilde çalışıyor” ile “profesyonelce işletilebilir” arasındaki farkı yaratır.

Wichtige Parameter im Unit-File

Tipik Delphi daemon’ları için aşağıdaki noktalar önemlidir:

• Restart-Policy: ör. Restart=on-failure veya always; Crash-loop’u önlemek için RestartSec ile kombinlenir.
• TimeoutStopSec ve KillSignal: düzgün bir shutdown sağlar (kuyrukların flush edilmesi, DB işlemlerinin düzgün kapatılması).
• User/Group: servisler nadiren root olarak çalıştırılmalı; principle of least privilege uygulanmalı.
• WorkingDirectory ve Environment: örtük varsayımlar yerine tekrarlanabilir yollar ve ortamlar.
• LimitNOFILE ve kaynak limitleri: çok sayıda eşzamanlı bağlantı/dosya varsa önemli.
• Logging-Anbindung: StandardOutput/StandardError journald’e, gerektiğinde merkezi log sistemlerine yönlendirme.

Restart politikaları özellikle bilinçli seçilmelidir. Bir yapılandırma hatası nedeniyle anında sonlanan bir süreç sonsuz döngüyle yeniden başlatılmamalıdır. Bu gibi durumlarda çıkış kodları ve açık bir hata mesajı ile “fail fast” yaklaşımı uygundur.

Graceful Shutdown in Delphi: SIGTERM ist kein Detail

Linux işletiminde bir servis tipik olarak SIGTERM ile sonlandırılır. Bir Delphi servisi bu durumu normal bir durum olarak ele almalıdır: ani kesintiler değil, düzenli bir kapanış.

Pratikte bu şunları kapsar:

• Stop flag set edilmesi, yeni işler alınmaması.
• Devam eden işlerin tamamlanması veya semantiğe göre kontrollü şekilde iptali.
• Transaksiyonların düzgün commit/rollback edilmesi, bağlantıların kapatılması.
• Önemli durum bilgilerinin kalıcılaştırılması (örn. “İş X iptal edildi, retry mümkün”).

SIGTERM’de “sert ölüm” üreten bir servis tutarsızlıklar üretir ve bakımı zorlaştırır.

Konfiguration: reproduzierbar, versionsfähig, sicher

Birçok üretim problemi özünde konfigürasyon hatasından kaynaklanır: yanlış DB host, hatalı kimlik bilgileri, eksik yollar, ortamlarda farklı zaman aşımları. Bu nedenle konfigürasyon sadece “bir INI dosyası” değil, bir konsepttir.

Konfigurationsquellen und Prioritäten

Çok katmanlı bir model işe yarar:

• Varsayılan konfigürasyon kod içinde (güvenli baz hattı, makul timeoutlar).
• Dosya tabanlı konfigürasyon (ör. INI/JSON/YAML), versiyonlu olarak dağıtılabilir.
• Environment değişkenleri gizli bilgiler ve ortam spesifikleri için (container/CI yakın, secrets repoda olmamalı).

Açık bir öncelik kuralı önemlidir (örn. Env dosyayı, dosya default’u ezer) ve başlatma kontrolü konfigürasyonu doğrulamalıdır: zorunlu alanlar, ulaşılabilirlik, dosya izinleri, asgari değer aralıkları.

Secrets: nicht im Klartext, nicht in Logs

B2B ortamlarında veritabanı parolaları, API token’ları, sertifikalar ve özel anahtarlar en değerli işletme varlıklarıdır. Asgari standartlar:

• Secrets mümkünse Git’te veya dağıtılmış konfigürasyon dosyalarında düz metin olarak bulunmamalıdır.
• Config/Secret dosyalarının okuma izinleri yalnızca servis kullanıcısına verilmelidir.
• Log çıktıları hatalarda dahi secret’ları sistematik olarak maskelenmelidir.

Vault gibi bir sistem kullanılsın veya kısıtlı izinlerle klasik dağıtımlar yapılsın: secret yönetiminin sistematik olması belirleyicidir.

Logging: vom „Fehlertext“ zur betrieblichen Diagnosefähigkeit

Üretim bir Linux servisi tanılama kabiliyeti kadar iyidir. “Hata oldu” demek yetersizdir. Arıza durumunda işletme ve geliştirme şunu izleyebilmelidir: Girdi neydi? Hangi versiyon çalışıyordu? Hata hangi adımda meydana geldi? Geçici bir hata mı yoksa veri kaynaklı bir problem mi?

Strukturiertes Logging und Korrelations-IDs

Arayüzü olan servisler (REST, MQ, dosya ithalatları) için iki şey merkezi önemdedir:

• Yapılandırılmış logging (anahtar-değer, JSON-benzeri): service, version, env, job_id, customer_id (mümkünse), duration_ms, result.
• Korrelasyon-ID: bileşenler arasında taşınan bir ID (örn. REST isteğinden worker işine kadar).

Bunlarla üretim hataları sadece bulunmaz, aynı zamanda sınırlandırılabilir: Tüm müşterileri mi etkiliyor? Sadece bir veri kaynağı mı? Sadece bir versiyon mu? Sadece bir örnek mi?

Log-Level, Noise und operative Signale

Yaygın bir anti-desendir: sinyal içermeyen çok fazla log — her poll’da megabaytlarca “Processing…”. Bunun yerine:

• INFO: ilgili durum değişimleri (Başlatma, Durdurma, Konfig yüklendi, İş başladı/sonlandı).
• WARNING: beklenen sapmalar (Retry, geçici ağ hatası, timeout).
• ERROR: beklenmeyen, elle müdahale gerektiren durumlar.
• DEBUG: hedefe yönelik etkinleştirilebilir, süreyle sınırlı.

systemd/journald ortamlarında log rotasyonu ve saklama politikasını planlamak mantıklıdır. Retention planı yoksa loglar ya çok kısa saklanır (tanı koymak için yetersiz) ya da depoyu doldurarak işletme sorununa yol açar.

Monitoring und Health: nicht nur „läuft“ – sondern „liefert“

Bir süreç çalışıyor olabilir ama işlevsel olarak etkisiz olabilir (deadlock içinde, IO bekliyor veya artık iş işlemiyor). Üretime hazır olmak demektir ki: monitoring sadece süreç durumunu değil, servis sağlığını da kontrol etmelidir.

Health Checks: Liveness, Readiness, Business-Checks

Delphi servisleri için üç katmanlı kontroller uygun olur:

• Liveness: süreç yaşıyor mu (systemd status, watchdog, basit ping endpoint).
• Readiness: servis hazır mı (DB bağlantısı sağlanabiliyor, konfig doğrulandı, bağımlı sistemlere erişim).
• Business-Check: servis gerçekten işlem yapıyor mu? örn. “son başarılı iş < 10 dakika” veya “kuyruk uzunluğu < eşik”.

Business seviyesi B2B işletmede genellikle en önemlisidir çünkü gerçek değer üretimini ölçer.

Metriken: Laufzeiten, Fehlerraten, Backlog

Servisler büyüdüğünde sadece loglar yeterli olmaz. Metrikler trendleri görmeyi sağlar:

• Throughput (işler/dk), ortalama iş süresi, p95/p99 süreleri.
• Retry oranı, hata oranı hata sınıfına göre (Ağ, Veri, Auth).
• Kuyruk-backlog, bekleme süreleri, Dead-Letter sayaçları.

Karmaşık bir observability stack’i olmadan da basit exportlar (ör. dahili bir HTTP endpoint veya log tabanlı parsing) ile çok şey başarılabilir. Önemli olan metriklerin ve eşiklerin tutarlı tanımıdır.

Datenzugriff und Transaktionen: FireDAC, Connection-Handling, Pooling

Birçok Delphi servisi veri tabanına odaklıdır. Linux altında erişim genellikle BDE-Ablösung ile yerel bağlanma ve yerel istemci kütüphaneleri üzerinden organize edilir. Üretime uygunluk açısından belirleyici olan doğru sürücüler değil, bağlantı ve işlem modelidir.

Connection-Lifecycle: kurzlebig vs. langlebig

Arka plan işleri için önerilen pratikler:

• Her iş veya iş partisinde bir bağlantı açıp, çalışıp kapatmak (ağ bozulmalarında sağlam).
• Yüksek frekansta işler varsa bağlantı havuzlama düşünülebilir, ancak işler arasında temiz reset ile.

Uzun ömürlü bağlantılar çalışabilir ama ağ kesintilerinde veya DB failover’larında hızla tanısı zor durumlara dönüşebilir. Kısa ömürlü bağlantılar genellikle daha sağlam varsayılan stratejidir — uygun timeoutlar ve retry’larla birlikte.

Transaktionsgrenzen und Sperrverhalten

Üretim sorunları sıklıkla çok büyük transaksiyonlardan kaynaklanır: uzun kilitler, bloke tablolar, “her şey takıldı”. Daha iyi olan:

• Transaksiyonları iş odaklı birimlere göre sınırlandırmak (örn. “bir ithalat kaydı” veya “bir doküman”).
• Ara sonuçları persist ederek yeniden başlatmayı mümkün kılmak.
• Hataları düzgün sınıflandırmak: veri hatası (retry değil), ağ hatası (retry), yan etkinin zaten gerçekleşmiş olması (idempotent ele alma).

Özellikle paralel worker’larda kilitlenme ve deadlock davranışı bir tasarım faktörüdür — sadece DBA meselesi değildir.

Deployment und Updates: reproduzierbar, rückrollbar, mit minimalem Risiko

Bir servis hiçbir zaman “bitmiş” değildir; güncellenir. Bu yüzden dağıtım işin bir parçasıdır. Üretim ortamında üç özellik önem kazanır: Tekrarlanabilirlik, Rollback yeteneği ve kısa kesinti süresi.

Versionierung und Artefakte

İyi uygulamalar:

• Her build benzersiz bir versiyon numarası (SemVer veya Build-ID) taşır ve başlangıçta loglara yazılır.
• Artefaktlar immutable olmalıdır: aynı versiyon yeniden build edilip üzerine yazılmaz.
• Bağımlılıklar (örn. native kütüphaneler) deployment’ın parçası ya da net olarak belgelenmiş olmalı.

Bu, “Versiyon X” in gerçekte her sunucuda hafif farklı görünmesi gibi sık rastlanan bir üretim sorununu önler.

Update-Strategien: Rolling, Blue/Green, Stop/Start

Hangi stratejinin uygun olduğu desenlere bağlıdır:

• Stop/Start: job-runner’lar veya kritik olmayan servisler için; basit ama kısa bir downtime vardır.
• Rolling Update: birden çok örnek sırayla yeniden başlatılır; kuyruk tabanlı sistemler için uygundur.
• Blue/Green: iki ayrı ortam, Load-Balancer ile geçiş; daha fazla çaba ama minimum risk.

Önemli: Bir güncelleme yalnızca güvenli sayılırsa servis başlangıcında uyumlu bir veritabanı/şema versiyonu beklemeli veya migration’lar kontrollü çalışmalıdır. Şema değişiklikleri ayrı bir roll-out adımı ve plan gerektirir (ileri/geri uyumluluk veya bakım penceresi ile).

Sicherheit und Betriebshärtung: kleine Maßnahmen, große Wirkung

Linux servisleri genellikle veri, arayüzler ve kimlik bilgilerine yakındır. Bu nedenle sertleştirme lüks değil, gerekliliktir. Birkaç standart uygulama riski önemli ölçüde azaltır.

Least Privilege und Dateirechte

• Ayrı bir servis kullanıcısı, shell giriş izni olmadan, asgari grup izinleriyle.
• Konfigürasyon ve secret dosyaları yalnızca bu kullanıcı tarafından okunabilir olmalı.
• Yazma izinleri yalnızca gerekli yerlere verilmeli (örn. Working-Directory, spool, tmp).

Netzwerkgrenzen und Port-Management

Bir Delphi servisi port açıyorsa (ör. bir REST-Server olarak), şu konular önemlidir:

• Harici erişim gerekmiyorsa dahili interface’lere bind etmek.
• LAN içinde “açık” bırakmak yerine firewall kuralları ve ağ segmentasyonu.
• TLS terminate etme planı (reverse proxy, sertifika rotasyonu) ortam gereksinimlerine göre.

İç ağda bile servislerin “sadece iyi istemciler çağırır” varsayımına güvenmemek gerekir. Kimlik doğrulama ve yetkilendirme tasarımın parçasıdır.

Typische Fehlerbilder in der Praxis – und wie man sie vermeidet

Üretim işletmede ekiplerin zamanını yiyen tekrar eden kalıplar sıklıkla görülür. Bazı tipik durumlar ve karşı önlemler:

„Der Service läuft, aber verarbeitet nichts mehr“

• Neden: Deadlock, bloke eden IO, sessiz reconnect problemi.
• Önlem: Her yerde timeout; watchdog/Health-Business-Check; tek iş parçacığı yerine worker mimarisi; bozuk bağımlılıkta fail-fast.

„Nach einem Update sind Jobs doppelt“

• Neden: idempotans eksik, ad hoc job tablosu yok, yan etkiler atomik değil.
• Önlem: İş durumunu DB’de tutmak, benzersiz kısıtlar, Outbox/Inbox deseni, deduplike edilebilen eventler.

„Logs helfen nicht – nur Stacktraces ohne Kontext“

• Neden: yapılandırılmamış logging, korrelasyon-ID yok, iş bağlamı eksik.
• Önlem: yapılandırılmış log alanları, iş-ID, input kaynağı, süre, sonuç, hata sınıfı.

„Der Service bricht bei Last zusammen“

• Neden: kontrolsüz paralellik, backpressure eksikliği, fazla DB bağlantısı, çok büyük transaksiyonlar.
• Önlem: Worker limitleri, kuyruk boyutu sınırları, connection limitleri, küçük transaksiyonlar, buffer ve retry mekanizmaları.

Zusammenspiel mit REST-Servern und bestehender Unternehmenssoftware

Birçok mimaride tek bir servis yoktur; bir paket halinde REST-server, background worker ve istemciler bulunur. Delphi projelerinde ortak iş mantığını net modüllerde tutmak, taşıma ve işletmeye özgü parçaları ayırmak genellikle akıllıca olur.

Schichten sauber trennen (fachlich und technisch)

Pragmatik bir yapı şöyle olabilir:

• Domain/Fachlogik: kurallar, doğrulama, hesaplamalar, kullanım senaryoları.
• Infrastruktur: DB erişimi, dosya sistemi, HTTP istemcileri, messaging.
• Adapter: REST endpoint’leri, servis döngüsü, CLI-runner, systemd’ye yakın başlatma mantığı.

Bu ayrım akademik değildir. Aynı iş mantığının hem REST-server’da hem de worker’da kullanılmasını sağlar; işletme tarafı (timeout, retry, logging, health) tutarlı uygulanabilir.

Multiplattform-Gedanke: Delphi als einheitliche Codebasis

Şirket Delphi’yi zaten Windows istemciler için kullanıyorsa, Linux servisi mantıklı bir sonraki adım olabilir: aynı dil, benzer kütüphaneler, tekil build pipeline’ları. Ancak fayda sadece platform sınırlarına saygı gösterildiğinde ortaya çıkar (dosya yolları, büyük/küçük harf duyarlılığı, locale/encoding, servis kullanıcı izinleri, dağıtım konvansiyonları). Çoklu platform işletimde hep „detay işi“dir — bu nedenle erken planlanmalıdır.

Praxischeckliste: Was ein produktiver Delphi-Linux-Service mindestens braucht

• systemd unit, makul restart/timeout kuralları, ayrı servis kullanıcısı, tanımlı yollar.
• Graceful shutdown (SIGTERM), durdurmada veri tutarsızlığı yok.
• Doğrulama yapan konfigürasyon modeli, secret’lar güvenli, loglarda secret yok.
• Versiyon, iş-ID, korrelasyon-ID, süre, hata sınıfı içeren yapılandırılmış logging.
• Health check’ler (en azından Readiness + Business-Check) ve tanımlı metrikler.
• Idempotent iş işleme, retry/backoff, Dead-Letter konsepti.
• Net sürümleme ile dağıtım, rollback stratejisi, planlanabilir şema migration’ları.
• Kaynak ve yük konsepti: paralellik, limitler, timeoutlar, connection handling.

Fazit: Delphi unter Linux ist kein Spezialfall – wenn Betrieb mitgedacht wird

Linux servisleri Delphi ile üretim ortamında sağlam bir seçenek olabilir; yeter ki tam teşekküllü bir sistem bileşeni gibi ele alınsın: net bir mimari, düzgün systemd entegrasyonu, sağlam hata ve durum modeli, izlenebilir logging, monitoring ve tekrarlanabilir dağıtım ile. Teknik uygulama nadiren asıl risk kaynağıdır; risk „işletme detayları“nın geç kalınmış çözümünde yatar.

Bu detayları baştan planlayanlar, bakım yapılabilir bir servis ekosistemi elde eder: iş mantığını tutarlı kullanır, entegrasyonları stabil işler ve günlük işletmede güvenilir şekilde çalışır — güncellemeler, yeniden başlatmalar ve arızalar dahil.

Mevcut Delphi iş mantığınızın Linux servislerine, worker’lara ve REST-server’a (işletme ve dağıtım konsepti dahil) nasıl aktarılabileceğini incelemek isterseniz, teknik ilk görüşmede sınır koşulları yapısal olarak netleştirebiliriz: Kontakt.