Linux-Services avec Delphi en production

Les services d’arrière-plan sont, dans de nombreuses applications d’entreprise, le levier de productivité discret : importations/exportations de données, traitement de fichiers et EDI, synchronisation avec ERP/DMS/CRM, workflows planifiés, notifications ou exposition d’interfaces techniques. En pratique, ce n’est pas seulement la fonction métier pure qui décide du succès, mais la question : le service peut-il être exploité, mis à jour, surveillé et, en cas d’incident, restauré de manière contrôlée ?

C’est précisément ici qu’un regard factuel sur Linux-Services mit Delphi est pertinent. Delphi constitue déjà, dans de nombreuses organisations, une part importante de la logique métier. Si cette logique peut être réutilisée côté serveur de manière judicieuse, on obtient une architecture cohérente : les règles métier ne sont pas implémentées en double, les interfaces restent stables et les équipes travaillent avec un outillage établi. En parallèle, Linux apporte dans l’univers serveur des briques éprouvées pour l’exploitation, l’automatisation et la sécurité.

Le point décisif : un service Linux n’est pas un « petit utilitaire » qu’on lance à l’occasion. C’est un composant produit avec une responsabilité d’exploitation. Cet article montre concrètement comment des services Linux basés sur Delphi peuvent être solidement organisés en production : du modèle de processus et d’état à l’intégration systemd, en passant par le logging, le déploiement et les mises à jour, jusqu’au monitoring, l’accès aux données, la sécurité et les patrons d’erreur typiques. L’objectif est une configuration fonctionnelle au quotidien — même à 3 heures du matin.

Quand Delphi-Services unter Linux sinnvoll sind

Un service Delphi-Linux est pertinent chaque fois qu’un ou plusieurs des motifs suivants s’appliquent :

• Logique métier Delphi existante doit être utilisée côté serveur (p. ex. validations, calculs, règles, parseurs d’import/export).
• Traitement en arrière-plan est une composante intégrale de l’application (p. ex. pipelines PDF/Reporting, files de jobs, traitement par lots).
• La charge d’intégration augmente : nombreux systèmes, nombreuses interfaces, nombreux formats ; la répétabilité fiable (idempotence) devient importante.
• Modernisation sans repartir de zéro : des parties de la logique sont externalisées en services, tandis que le client desktop est allégé progressivement.
• REST-Server & Services doivent être pensés ensemble : mêmes standards de code, même logging/monitoring, mêmes processus de rollout.

Un service Delphi sous Linux est moins adapté lorsqu’une équipe n’a aucune compétence Delphi et qu’une plateforme standardisée (p. ex. un écosystème Java/.NET existant) est imposée. Dans ce cas, le problème n’est pas Delphi lui‑même, mais l’intégration organisationnelle. Dans de nombreuses entreprises, Delphi représente cependant une valeur existante qui peut être réutilisée de manière stable dans la couche de services — à condition que l’architecture et l’exploitation soient bien pensées.

Architekturgrundlagen: Prozessmodell, Zustände, Verantwortlichkeiten

Un service en production échoue rarement à cause de sa « fonction principale ». Il échoue plus souvent à cause d’états flous : que se passe‑t‑il lors d’une panne réseau ? Comment le service réagit‑il à un basculement de base de données ? Un job est‑il traité deux fois ? Le comportement en cas de SIGTERM est‑il défini ? C’est pour ces raisons que chaque service a besoin d’un modèle clair de processus et d’états.

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

Dans l’environnement B2B, trois types fondamentaux se sont imposés :

• Always-on Daemon : processus en continu, p. ex. listener, consommateur de queue, event-dispatcher, composant WebSocket/Push.
• Worker-Pool : plusieurs instances traitant des jobs d’une queue en parallèle. La mise à l’échelle se fait par le nombre de processus.
• Job-Runner (Timer) : démarré périodiquement, exécute des tâches puis se termine. Sous Linux, il est souvent préférable d’utiliser systemd Timer/cron plutôt qu’un scheduler thread interne.

Delphi peut implémenter ces trois motifs. Pour l’exploitation, il est toutefois crucial que le motif soit choisi délibérément. Un processus « always-on » qui ne fait quelque chose que toutes les 15 minutes introduit une complexité inutile (fuites mémoire visibles plus tard, états inactifs mal gérés). À l’inverse, un job‑runner pur peut être inadapté si une faible latence est requise.

Idempotenz und Wiederanlauf: der Kern produktiver Robustheit

Le fonctionnement en production implique : redémarrages de services, déploiements, instabilité réseau temporaire, fenêtres de maintenance des bases, et jobs dupliqués. C’est pourquoi l‘idempotence (exécution multiple sans effets secondaires) pour les imports, exports et intégrations est un principe directeur.

Concrètement :

• Chaque job possède une ID de job unique et un statut (queued, running, succeeded, failed, dead-letter).
• Les effets secondaires (p. ex. « facture envoyée ») sont enregistrés avec une preuve dédiée, et non déduits implicitement des logs.
• Les stratégies de retry sont contrôlées : backoff, nombre maximal de tentatives, critères d’abandon clairs, dead‑letter‑queue.

Qui implémente proprement l’idempotence gagne énormément en exploitation : un redémarrage devient un cas standard, pas une crise.

systemd als Betriebsfundament: Start, Stop, Restart, Limits

Sous Linux, systemd est, dans la plupart des distributions, l’outil central pour piloter proprement les services en exploitation. Pour des services Delphi, systemd n’est pas « juste » un script de démarrage mais fait partie de l’architecture de stabilité. Un unit‑file bien défini fait souvent la différence entre « ça tourne plus ou moins » et « exploitable professionnellement ».

Wichtige Parameter im Unit-File

Pour des daemons Delphi typiques, les aspects suivants sont pertinents :

• Restart-Policy : p. ex. Restart=on-failure ou always, combiné avec RestartSec pour éviter les crash‑loops.
• TimeoutStopSec et KillSignal : permettent un arrêt ordonné (flush des queues, fermeture propre des transactions DB).
• User/Group : les services ne devraient pas tourner en root ; principe du moindre privilège.
• WorkingDirectory et Environment : chemins et environnements reproductibles plutôt que suppositions implicites.
• LimitNOFILE et limites de ressources : important pour de nombreuses connexions/fichiers simultanés.
• Connexion de logging : StandardOutput/StandardError vers journald, et éventuellement redirection vers des systèmes de logs centraux.

Les Restart‑Policies doivent être choisies consciemment. Un processus qui s’arrête immédiatement en raison d’une erreur de configuration ne doit pas redémarrer en boucle et inonder le système. Dans ces cas, des codes de sortie explicites et un « fail fast » avec message d’erreur clair sont souhaitables.

Graceful Shutdown in Delphi: SIGTERM ist kein Detail

En exploitation Linux, un service est typiquement arrêté via SIGTERM. Un service Delphi doit considérer cela comme un état normal : pas d’interruptions brutales, mais un arrêt ordonné.

Concrètement :

• Définir un drapeau d’arrêt, ne plus accepter de nouveaux jobs.
• Terminer ou interrompre de manière contrôlée les jobs en cours (selon la sémantique).
• Commit/rollback propre des transactions, fermeture des connexions.
• Persister les informations d’état importantes (p. ex. « Job X interrompu, retry possible »).

Un service qui « meurt brutalement » au SIGTERM produit des incohérences et complique toute maintenance.

Konfiguration: reproduzierbar, versionsfähig, sicher

Beaucoup de problèmes en production sont finalement des problèmes de configuration : mauvais host DB, credentials erronés, chemins manquants, valeurs de timeout divergentes entre environnements. La configuration n’est donc pas « juste » un fichier INI, c’est un concept.

Konfigurationsquellen und Prioritäten

Un modèle multi‑couches a fait ses preuves :

• Configuration par défaut dans le code (baseline sécurisée, timeouts raisonnables).
• Configuration par fichier (p. ex. INI/JSON/YAML), déployable et versionnable.
• Variables d’environnement pour les secrets et spécificités d’environnement (proches du conteneur/CI, pas de secrets dans le repo).

Important : une priorité claire (p. ex. Env remplace Fichier remplace Default) et un contrôle au démarrage qui valide la configuration : champs obligatoires, accessibilité, droits sur les fichiers, plages minimales.

Secrets: nicht im Klartext, nicht in Logs

Dans les environnements B2B, mots de passe DB, tokens API, certificats et clés privées comptent parmi les actifs opérationnels les plus sensibles. Standards minimaux :

• Ne pas stocker les secrets en clair dans Git ni dans des fichiers de configuration déployés si cela peut être évité.
• Droits de lecture sur config/secrets limités à l’utilisateur service.
• Les sorties de logs doivent masquer systématiquement les secrets (même dans les exceptions).

Que l’on utilise un vault ou des déploiements classiques avec droits restreints : l’important est une gestion systématique des secrets.

Logging: vom „Fehlertext“ zur betrieblichen Diagnosefähigkeit

Un service Linux en production n’est aussi bon que sa capacité de diagnostic. « Il y a eu une erreur » n’aide pas. En cas d’incident, exploitation et développement doivent pouvoir reconstituer : quel était l’input ? Quelle version tournait ? À quelle étape l’erreur est‑elle survenue ? S’agissait‑il d’une erreur transitoire ou d’un problème de données ?

Strukturiertes Logging und Korrelations-IDs

Pour les services exposant des interfaces (REST, MQ, imports de fichiers), deux éléments sont centraux :

• Logging structuré (paires clé‑valeur, format proche de JSON) : service, version, env, job_id, customer_id (si autorisé), duration_ms, result.
• ID de corrélation : un identifiant propagé entre composants (p. ex. du REST-request vers le job worker).

Avec cela, les erreurs en production se repèrent et s’isolent : touche‑t‑elle tous les clients ? seulement une source de données ? une version ? une instance ?

Log-Level, Noise und operative Signale

Un anti‑pattern fréquent est l’abondance de logs sans signal utile : des mégaoctets de « Processing… » à chaque poll. À la place :

• INFO : changements d’état pertinents (démarrage, arrêt, config chargée, job démarré/terminé).
• WARNING : écarts attendus (retry, erreur réseau transitoire, timeouts).
• ERROR : imprévu, action manuelle requise.
• DEBUG : activable de manière ciblée et limitée dans le temps.

Dans les environnements systemd/journald, il est utile de planifier rotation et rétention des logs. Sans stratégie de rétention, les logs sont soit trop peu conservés (pas de diagnostic), soit ils remplissent le stockage (problème d’exploitation).

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

Un processus peut tourner et être néanmoins mort sur le plan métier (bloqué dans un deadlock, en attente d’IO, ou ne traitant plus de jobs). La maturité en production signifie que le monitoring vérifie non seulement l’état du processus, mais la santé fonctionnelle du service.

Health Checks: Liveness, Readiness, Business-Checks

Pour des services Delphi, trois niveaux sont pertinents :

• Liveness : le processus vit (statut systemd, watchdog, endpoint ping simple).
• Readiness : le service est prêt (connexion DB possible, configuration valide, systèmes dépendants accessibles).
• Business-Check : le service traite réellement ? p. ex. « dernier job réussi < 10 minutes » ou « longueur de queue < seuil ».

Le niveau business est souvent le plus important en exploitation B2B car il mesure la création de valeur réelle.

Metriken: Laufzeiten, Fehlerraten, Backlog

Lorsque les services se développent, les logs seuls ne suffisent plus. Les métriques permettent d’identifier les tendances :

• Débit (jobs/min), durée moyenne des jobs, p95/p99 de latence.
• Taux de retry, taux d’erreur par classe d’erreur (réseau, données, auth).
• Backlog de queue, temps d’attente, compteur dead‑letter.

Même sans stack d’observabilité complet, des exports simples (p. ex. via un endpoint HTTP interne ou parsing de logs) apportent beaucoup. L’important est une définition cohérente des indicateurs et des seuils.

Datenzugriff und Transaktionen: FireDAC, Connection-Handling, Pooling

Beaucoup de services Delphi sont centrés sur la base de données. Sous Linux, l’accès depuis Delphi s’organise typiquement via la BDE-Ablösung mit nativer Anbindung et des bibliothèques clientes natives. Pour être opérationnel en production, ce ne sont pas tant les « bons drivers » qui comptent que le modèle de connexion et de transaction.

Connection-Lifecycle: kurzlebig vs. langlebig

Pour les jobs d’arrière-plan, une pratique éprouvée :

• Ouvrir une connexion par job ou par lot de jobs, travailler, fermer (robuste face aux interruptions réseau).
• Pour des jobs à très haute fréquence, éventuellement pooling de connexions, mais uniquement avec un reset propre entre jobs.

Les connexions longues peuvent fonctionner mais deviennent fragiles lors d’interruptions réseau ou de failovers DB et mènent à des états difficiles à diagnostiquer. Les connexions éphémères sont souvent la stratégie par défaut la plus robuste — avec timeouts et retries appropriés.

Transaktionsgrenzen und Sperrverhalten

Les problèmes en production proviennent souvent de transactions trop larges : verrous longs, tables bloquées, « tout bloque ». Mieux vaut :

• Aligner les transactions sur des unités métier (p. ex. « un enregistrement d’import » ou « un document »).
• Persister des résultats intermédiaires pour permettre la reprise.
• Classer proprement les erreurs : erreur de données (pas de retry), erreur réseau (retry), effet secondaire déjà appliqué (traiter idempotemment).

Particulièrement avec des workers parallèles, le comportement de verrouillage et de deadlock est un facteur de conception — pas seulement un sujet pour le DBA.

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

Un service n’est jamais « fini » ; il est mis à jour. Le déploiement n’est pas un travail annexe mais une partie de la solution. En production, trois propriétés comptent : reproductibilité, capacité de rollback et downtime minimale.

Versionierung und Artefakte

Les bonnes pratiques :

• Chaque build porte un identifiant de version unique (SemVer ou Build‑ID) et l’écrit dans les logs au démarrage.
• Les artefacts sont immutables : une même version n’est pas « reconstruite » et remplacée.
• Les dépendances (p. ex. bibliothèques natives) font partie du déploiement ou sont clairement documentées.

Ainsi on évite le problème fréquent où la « version X » diffère légèrement d’un serveur à l’autre.

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

La stratégie dépend du motif :

• Stop/Start : pour les job‑runners ou services non critiques ; simple mais avec une courte indisponibilité.
• Rolling Update : redémarrage séquentiel des instances ; adapté aux systèmes basés sur des queues.
• Blue/Green : deux environnements séparés, switch via load‑balancer ; coût plus élevé, risque minimal.

Important : une mise à jour n’est « sûre » que si le service au démarrage attend une version de schéma/DB compatible ou que les migrations sont exécutées de manière contrôlée. Les changements de schéma nécessitent une étape de déploiement dédiée avec plan (compatibilité avant/après ou fenêtre de maintenance).

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

Les services Linux sont souvent proches des données, des interfaces et des credentials. La hardening n’est pas un luxe. Quelques standards réduisent significativement les risques.

Least Privilege und Dateirechte

• Utilisateur service dédié sans accès shell, droits de groupe minimaux.
• Fichiers de configuration et secrets lisibles uniquement par cet utilisateur.
• Droits d’écriture uniquement là où nécessaire (p. ex. working‑directory, spool, temp).

Netzwerkgrenzen und Port-Management

Si un service Delphi ouvre des ports (p. ex. en tant que REST-Server), il convient :

• De binder sur des interfaces internes si l’accès externe n’est pas requis.
• D’utiliser des règles de firewall et des réseaux segmentés plutôt que « ouvert sur le LAN ».
• De planifier proprement la terminaison TLS (reverse proxy, rotation des certificats), selon l’environnement.

Même en interne, les services ne doivent pas « faire confiance » au fait que seuls de bons clients appellent. Authentification et autorisation font partie du design.

Typische Fehlerbilder in der Praxis – und wie man sie vermeidet

En production, ce sont souvent des motifs récurrents qui font perdre du temps aux équipes. Quelques cas typiques et moyens de prévention :

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

• Cause : deadlock, IO bloquant, problème de reconnexion silencieuse.
• Contre‑mesure : timeouts partout ; watchdog/health business‑check ; architecture worker plutôt que single‑thread ; fail‑fast en cas de dépendance cassée.

„Nach einem Update sind Jobs doppelt“

• Cause : absence d’idempotence, pas de table dédiée aux jobs, effets secondaires non atomiques.
• Contre‑mesure : statut des jobs en DB, contraintes d’unicité, pattern outbox/inbox, événements dé‑dupliquables.

„Logs helfen nicht – nur Stacktraces ohne Kontext“

• Cause : logging non structuré, pas d’ID de corrélation, pas de contexte job.
• Contre‑mesure : champs de logs structurés, job‑ID, source d’entrée, durée, résultat, classe d’erreur.

„Der Service bricht bei Last zusammen“

• Cause : parallélisme non contrôlé, absence de backpressure, trop de connexions DB, transactions trop volumineuses.
• Contre‑mesure : limites de workers, longueurs de queue, limites de connexions, petites transactions, buffers et retries.

Zusammenspiel mit REST-Servern und bestehender Unternehmenssoftware

Dans de nombreuses architectures, il n’existe pas « un seul service » mais un ensemble comprenant REST-server, background workers et clients. Dans les projets Delphi, il est souvent utile de maintenir la logique métier partagée dans des modules clairs, tandis que les parties liées au transport et à l’exploitation restent séparées.

Schichten sauber trennen (fachlich und technisch)

Une structure pragmatique :

• Domain/Logique métier : règles, validation, calculs, use cases.
• Infrastructure : accès DB, système de fichiers, clients HTTP, messaging.
• Adaptateurs : endpoints REST, boucle service, CLI‑runner, logique de démarrage proche de systemd.

Cette séparation n’est pas académique. Elle permet d’utiliser la même logique métier dans le REST-server et dans le worker, tout en implémentant de manière cohérente les aspects opérationnels (timeouts, retries, logging, health).

Multiplattform-Gedanke: Delphi als einheitliche Codebasis

Si une entreprise utilise déjà Delphi pour des clients Windows, un service Linux peut être l’étape logique suivante : même langage, bibliothèques similaires, pipelines de build unifiés. Le bénéfice n’apparaît toutefois que si les limites de plateforme sont respectées consciemment (chemins de fichiers, sensibilité à la casse, locale/encodage, droits de l’utilisateur service, conventions de déploiement). Le multiplateforme demande toujours des travaux de détail en exploitation — d’où l’intérêt de le planifier tôt.

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

• Unit systemd avec règles de Restart/Timeout raisonnables, utilisateur service dédié, chemins définis.
• Arrêt ordonné (SIGTERM), pas d’incohérences de données à l’arrêt.
• Modèle de configuration avec validation, secrets sécurisés, pas de secrets dans les logs.
• Logging structuré avec version, job‑ID, ID de corrélation, durée, classe d’erreur.
• Health checks (au moins readiness + business‑check) et métriques définies.
• Traitement idempotent des jobs, retry/backoff, concept de dead‑letter.
• Déploiement avec versioning clair, stratégie de rollback, migrations de schéma planifiables.
• Concept de ressources et de charge : parallélisme, limites, timeouts, gestion des connexions.

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

Les services Linux basés sur Delphi constituent en production une option très solide, dès lors qu’ils sont traités comme des composants systèmes à part entière : architecture claire, intégration systemd propre, modèle d’erreur et d’état robuste, logging traçable, monitoring et un déploiement reproductible. La mise en œuvre technique est rarement le facteur de risque ; le risque se situe dans les « détails d’exploitation » clarifiés trop tard.

Qui prend ces détails en compte dès le départ obtient un paysage de services maintenable, qui réutilise la logique métier de manière cohérente, traite les intégrations de façon stable et se pilote de façon fiable au quotidien — y compris lors des mises à jour, redémarrages et incidents.

Si vous souhaitez vérifier comment votre logique métier Delphi existante peut être transférée vers des services Linux, des workers et des REST-server (incl. concept d’exploitation et de déploiement), nous clarifions volontiers les conditions cadre de manière structurée lors d’un premier entretien technique : Contact.