Servizi Linux con Delphi in ambiente di produzione

I servizi in background sono in molte applicazioni aziendali la leva silenziosa della produttività: importazioni ed esportazioni di dati, elaborazione di file ed EDI, sincronizzazioni con ERP/DMS/CRM, workflow temporizzati, notifiche o l’esposizione di interfacce tecniche. In pratica però non decide la sola funzione applicativa sul successo, quanto la domanda: il servizio può essere gestito, aggiornato, monitorato e ripristinato in modo affidabile in caso di errore?

Proprio qui conviene uno sguardo pragmatico sui Linux-Services con Delphi. Delphi è già il nucleo della logica di dominio in molte organizzazioni. Se questa logica può essere riutilizzata in modo sensato sul lato server, si ottiene un’architettura coerente: le regole di business non sono implementate due volte, le interfacce restano stabili e i team operano con tool consolidati. Allo stesso tempo Linux porta nell’ambiente server componenti di comprovata utilità per il funzionamento, l’automazione e la sicurezza.

Il punto cruciale: un servizio Linux non è un “piccolo strumento di supporto” da avviare a margine. È una componente del prodotto con responsabilità operative. Questo articolo mostra concretamente come predisporre in produzione servizi Delphi-based su basi robuste: dal modello di processo e di stato all’integrazione systemd, logging, deployment e aggiornamenti fino a monitoring, accesso ai dati, sicurezza e tipici pattern di errore. L’obiettivo è uno setup che funzioni nella pratica – anche alle 3 del mattino.

Quando Delphi-Services sotto Linux hanno senso

Un servizio Delphi-Linux è indicato ogni volta che si verifica uno o più dei seguenti scenari:

• Logica di dominio Delphi esistente deve essere utilizzata sul server (es. validazioni, calcoli, regole, parser di import/export).
• Elaborazione in background è parte integrante dell’applicazione (es. pipeline PDF/reporting, code di job, processing batch).
• Carico di integrazione in aumento: molti sistemi, molte interfacce, molti formati; la ripetibilità affidabile (idempotenza) diventa importante.
• Modernizzazione senza rifare tutto da capo: porzioni di logica vengono estratte in servizi mentre il client desktop viene alleggerito gradualmente.
• REST-Server & Services vanno considerati insieme: stesso standard di codice, stesso logging/monitoring, stessi processi di rollout.

Meno indicato è un servizio Delphi sotto Linux quando un team non ha alcuna competenza Delphi e gli si impone rigidamente una piattaforma standardizzata (es. un ecosistema Java/.NET esistente). In questo caso non è Delphi il problema, ma l’inserimento organizzativo. In molte aziende Delphi è però un asset esistente che può essere riutilizzato stabilmente nella layer dei servizi – a condizione che architettura e operation siano pianificate con cura.

Fondamenti architetturali: modello di processo, stati, responsabilità

Un servizio produttivo raramente fallisce per la “funzione principale”. Più spesso fallisce per stati poco chiari: cosa succede in caso di caduta di rete? Come si comporta il servizio in un failover del database? Un job viene elaborato due volte? Il comportamento su SIGTERM è definito? Per questo ogni servizio necessita di un modello di processo e di stato ben definito.

Tipi di servizio: Always-on vs. Worker vs. Job-Runner

Nell’ambito B2B si sono affermati tre tipi fondamentali:

• Always-on Daemon: processo che gira continuamente, es. listener, consumer di code, dispatcher di eventi, componente websocket/push.
• Worker-Pool: più istanze che elaborano parallelamente job da una coda. La scalabilità si ottiene aumentando il numero di processi.
• Job-Runner (Timer): avvio periodico che esegue compiti e poi termina. Sotto Linux è spesso preferibile usare systemd-timer/cron invece di scheduler-thread custom.

Delphi può coprire tutti e tre i pattern. Per l’esercizio è però fondamentale scegliere il pattern consapevolmente. Un processo “always-on” che in realtà fa qualcosa solo ogni 15 minuti introduce complessità inutile (memory leak emergono più tardi, stati idle non sono gestiti). Viceversa un job-runner puro può essere inadatto se è richiesta bassa latenza.

Idempotenza e riavvio: il cuore della robustezza operativa

Operare in produzione significa: servizi vengono riavviati, deploy avvengono, le reti sono temporaneamente instabili, i database hanno finestre di manutenzione e i job possono arrivare duplicati. Per questo idempotenza (eseguire più volte senza effetti collaterali) è un principio guida per import, export e integrazioni.

Praticamente ciò significa:

• Ogni job ha una ID job univoca e uno stato (queued, running, succeeded, failed, dead-letter).
• Gli effetti collaterali (es. “fattura inviata”) sono registrati con una evidenza dedicata, non dedotti implicitamente dai log.
• Le strategie di retry sono controllate: backoff, tentativi massimi, criteri chiari di interruzione, dead-letter-queue.

Chi implementa l’idempotenza ottiene un grande vantaggio operativo: un riavvio non è più una crisi ma un caso d’uso standard.

systemd come fondamento operativo: Start, Stop, Restart, Limits

Sotto Linux systemd è nella maggior parte delle distribuzioni lo strumento centrale per gestire i servizi in produzione. Per i servizi Delphi systemd non è “solo” uno script di avvio, ma parte dell’architettura di stabilità. Un unit-file ben definito spesso è la differenza tra “gira in qualche modo” e “si gestisce professionalmente”.

Parametri importanti nell’Unit-File

Per tipici daemon Delphi sono rilevanti i seguenti aspetti:

• Restart-Policy: es. Restart=on-failure o always, combinata con RestartSec per evitare crash-loop.
• TimeoutStopSec e KillSignal: permettono uno shutdown ordinato (flush delle code, chiusura pulita delle transazioni DB).
• User/Group: i servizi dovrebbero raramente girare come root; principio del least privilege.
• WorkingDirectory e Environment: percorsi e ambienti riproducibili invece di assunzioni implicite.
• LimitNOFILE e limiti di risorse: importanti se ci sono molte connessioni/file concorrenti.
• Integrazione del logging: StandardOutput/StandardError su journald, con eventuale inoltro a sistemi di log centrali.

In particolare le Restart-Policy devono essere scelte consapevolmente. Un processo che si arresta immediatamente per un errore di configurazione non dovrebbe entrare in un loop di riavvii che sommerge il sistema. In questi casi sono utili exit-code chiari e la strategia “fail fast” con messaggi di errore espliciti.

Graceful Shutdown in Delphi: SIGTERM non è un dettaglio

In ambiente Linux un servizio viene tipicamente terminato tramite SIGTERM. Un servizio Delphi dovrebbe trattare questo caso come uno stato normale: non abort improvvisi, ma chiusura ordinata.

Sul piano pratico ciò implica:

• Impostare un flag di stop, non accettare nuovi job.
• Portare a termine i job in corso o interromperli in modo controllato (a seconda della semantica).
• Commit/rollback delle transazioni, chiusura delle connessioni.
• Persistere informazioni di stato rilevanti (es. “Job X interrotto, retry possibile”).

Un servizio che muore “di colpo” su SIGTERM genera incoerenze e complica ogni intervento di manutenzione.

Configurazione: riproducibile, versionabile, sicura

Molti problemi in produzione si riducono a problemi di configurazione: host DB sbagliato, credenziali errate, percorsi mancanti, valori di timeout divergenti tra gli ambienti. Per questo la configurazione non è solo “un file INI”, ma un concetto.

Fonti di configurazione e priorità

Un modello a più livelli si è dimostrato efficace:

• Configurazione di default nel codice (baseline sicura, timeout sensati).
• Configurazione basata su file (es. INI/JSON/YAML) distribuibile in modo versionabile.
• Variabili d’ambiente per segreti e specificità dell’ambiente (vicine a container/CI, evitare segreti nel repo).

Importante è una priorità chiara (es. Env sovrascrive File sovrascrive Default) e un controllo di avvio che valida la configurazione: campi obbligatori, raggiungibilità, permessi dei file, valori minimi.

Segreti: non in chiaro, non nei log

In ambienti B2B password DB, token API, certificati e chiavi private sono tra gli asset operativi più critici. Standard minimi:

• Non mettere i segreti in Git né in file di configurazione distribuiti in chiaro, quando possibile.
• Permessi di lettura per config/secret solo per l’utente del servizio.
• I log devono mascherare i segreti in modo coerente (anche nelle eccezioni).

Sia che si usi un sistema di vault sia che si operi con deployment classici e permessi restrittivi: l’importante è che la gestione dei segreti sia sistematica.

Logging: dal “messaggio di errore” alla diagnosi operativa

Un servizio Linux produttivo è efficace quanto la sua capacità diagnostica. “C’è stato un errore” non basta. In caso di incidente operation e sviluppo devono poter ricostruire: quale era l’input? Quale versione stava girando? In quale step si è verificato l’errore? È stato un errore transitorio o un problema di dati?

Logging strutturato e ID di correlazione

Per servizi con interfacce (REST, MQ, import file) due elementi sono centrali:

• Logging strutturato (key-value, simile a JSON): service, version, env, job_id, customer_id (se consentito), duration_ms, result.
• ID di correlazione: un ID mantenuto tra le componenti (es. dalla richiesta REST al worker-job).

Così gli errori in produzione non solo si individuano, ma si circoscrivono: riguarda tutti i clienti? Solo una fonte dati? Solo una versione? Solo un’istanza?

Livelli di log, rumore e segnali operativi

Un antipattern comune sono troppi log privi di segnale: megabyte di “Processing…” a ogni poll. Invece:

• INFO: cambiamenti di stato rilevanti (Start, Stop, config caricata, job iniziato/completato).
• WARNING: deviazioni previste (retry, errore di rete transitorio, timeout).
• ERROR: condizioni non previste, richiedono intervento manuale.
• DEBUG: attivabile in modo mirato e limitato nel tempo.

Soprattutto in ambienti systemd/journald è utile pianificare rotazione e retention dei log. Senza una politica di retention, i log vengono conservati troppo poco (nessuna diagnosi) o consumano spazio (problema operativo).

Monitoring e Health: non solo “gira” ma “eroga”

Un processo può essere attivo e al contempo morto sul piano funzionale (bloccato in un deadlock, in attesa di IO o che non elabora più job). La maturità di produzione significa: il monitoring controlla non solo lo stato del processo ma la salute del servizio.

Health Checks: Liveness, Readiness, Business-Checks

Per servizi Delphi sono utili tre livelli:

• Liveness: il processo è vivo (systemd status, watchdog, endpoint ping semplice).
• Readiness: il servizio è pronto (connessione DB possibile, configurazione valida, sistemi dipendenti raggiungibili).
• Business-Check: il servizio sta effettivamente elaborando? es. “ultimo job riuscito < 10 minuti” o “lunghezza coda < soglia”.

Il livello business è spesso il più rilevante in ambito B2B perché misura la reale creazione di valore.

Metrica: durate, tassi di errore, backlog

Con la crescita dei servizi i log da soli non bastano più. Le metriche aiutano a vedere le tendenze:

• Throughput (job/min), durata media job, p95/p99 delle durate.
• Tasso di retry, tasso di errore per classe di errore (rete, dati, auth).
• Backlog delle code, tempi di attesa, contatore dead-letter.

Anche senza uno stack di osservabilità complesso si può ottenere molto con semplici esportazioni (es. tramite un endpoint HTTP interno o parsing basato sui log). Importante è definire in modo coerente le metriche e le soglie.

Accesso ai dati e transazioni: FireDAC, gestione delle connessioni, pooling

Molti servizi Delphi sono centrati sul database. Sotto Linux l’accesso con Delphi è tipicamente organizzato tramite la BDE-Ablösung con binding nativo e librerie client native. Per la maturità produttiva non sono tanto i “driver giusti” la chiave, quanto il modello di connessione e transazione.

Lifecycle della connessione: breve vs. lunga

Per i job in background una pratica consolidata è:

• Aprire una connessione per job o per batch di job, lavorare e chiudere (robusto in caso di problemi di rete).
• Per job ad alta frequenza valutare il connection-pooling, ma solo con reset pulito tra i job.

Le connessioni di lunga durata possono funzionare, ma in caso di interruzioni di rete o failover DB tendono a entrare in stati difficili da diagnosticare. Le connessioni efimere sono spesso la strategia di default più robusta – con timeout e retry adeguati.

Confini transazionali e comportamento di lock

I problemi in produzione nascono spesso da transazioni troppo ampie: lock lunghi, tabelle bloccate, “tutto si blocca”. Meglio:

• Allineare le transazioni alle unità funzionali (es. “un record di import” o “un documento”).
• Persistere risultati intermedi per consentire il riavvio.
• Classificare gli errori: errore dati (non retry), errore rete (retry), effetto collaterale già avvenuto (gestire idempotenza).

Soprattutto con worker paralleli il comportamento di lock e deadlock è un fattore di progetto, non soltanto una questione per il DBA.

Deployment e aggiornamenti: riproducibile, rollbackabile, a rischio minimo

Un servizio non è mai “finito”; viene aggiornato. Per questo il deployment non è un rifacimento ma parte della soluzione. In produzione contano tre proprietà: riproducibilità, capacità di rollback e minima finestra di indisponibilità.

Versionamento e artefatti

Buone pratiche:

• Ogni build ha un numero di versione univoco (SemVer o Build-ID) e lo scrive nei log all’avvio.
• Gli artefatti sono immutabili: la stessa versione non viene “ricostruita” e sovrascritta.
• Le dipendenze (es. librerie native) fanno parte del deploy o sono documentate chiaramente.

Così si evita il problema comune in produzione per cui “Versione X” in realtà differisce leggermente tra server.

Strategie di aggiornamento: Rolling, Blue/Green, Stop/Start

La strategia adatta dipende dal pattern:

• Stop/Start: per job-runner o servizi non critici; semplice ma con breve downtime.
• Rolling Update: più istanze aggiornate una dopo l’altra; adatto a sistemi basati su code.
• Blue/Green: due ambienti separati e switch via load-balancer; maggiore sforzo, rischio minimo.

Importante: un aggiornamento è “sicuro” solo se il servizio all’avvio aspetta una versione compatibile del DB/schema o le migrazioni sono eseguite in modo controllato. Le modifiche di schema sono un passo di rollout a sé con piano (compatibilità avanti/indietro o finestra di manutenzione).

Sicurezza e hardening operativo: piccole misure, grande effetto

I servizi Linux spesso stanno vicino a dati, interfacce e credenziali. Perciò l’hardening non è un lusso. Pochi standard già riducono notevolmente i rischi.

Least Privilege e permessi sui file

• Utente di servizio dedicato senza shell login, permessi minimi dei gruppi.
• File di configurazione e secret leggibili solo da questo utente.
• Permessi di scrittura solo dove necessario (es. Working-Directory, spool, temp).

Confini di rete e gestione delle porte

Se un servizio Delphi apre porte (es. come REST-Server), è opportuno:

• Bind su interfacce interne se non è richiesta raggiungibilità esterna.
• Regole di firewall e segmentazione di rete invece di “aperto nella LAN”.
• Pianificare la terminazione TLS (reverse proxy, rotazione certificati) a seconda dell’ambiente.

Anche internamente: i servizi non devono presumere che chiamino solo client affidabili. Autenticazione e autorizzazione fanno parte del progetto.

Error pattern tipici in pratica – e come evitarli

In produzione spesso emergono pattern ricorrenti che consumano tempo ai team. Alcuni casi tipici e contromisure:

“Il servizio gira, ma non elabora più”

• Cause: deadlock, IO bloccante, problema di reconnect silenzioso.
• Contromisure: timeouts ovunque; watchdog/health-business-check; architettura a worker invece che single-thread; fail-fast su dipendenza compromessa.

“Dopo un update i job sono duplicati”

• Cause: mancanza di idempotenza, assenza di tabella job dedicata, effetti collaterali non atomici.
• Contromisure: stato job in DB, vincoli univoci, pattern Outbox/Inbox, eventi deduplicabili.

“I log non aiutano – solo stacktrace senza contesto”

• Cause: logging non strutturato, nessuna correlazione-ID, nessun contesto job.
• Contromisure: campi di log strutturati, job-ID, sorgente input, durata, risultato, classe di errore.

“Il servizio crolla sotto carico”

• Cause: parallelismo incontrollato, assenza di backpressure, troppe connessioni DB, transazioni troppo grandi.
• Contromisure: limiti worker, lunghezze di coda, limiti di connessione, transazioni piccole, buffer e retry.

Interazione con REST-Server e software aziendale esistente

In molte architetture non esiste “un solo servizio” ma un pacchetto che comprende REST-Server, worker in background e client. Nei progetti Delphi spesso conviene tenere la logica di dominio in moduli chiari mentre separare le parti legate al trasporto e all’operatività.

Separare chiaramente i layer (funzionale e tecnico)

Una struttura pragmatica:

• Domain/Logica di business: regole, validazioni, calcoli, use-case.
• Infrastructure: accesso DB, file system, client HTTP, messaging.
• Adapter: endpoint REST, loop di servizio, CLI-runner, logica di avvio vicina a systemd.

Questa separazione non è accademica. Permette di riutilizzare la stessa logica di dominio nel REST-Server e nel worker, mentre aspetti operativi (timeouts, retry, logging, health) sono implementati in modo coerente.

Approccio multiplatform: Delphi come base di codice unificata

Se un’azienda usa già Delphi per client Windows, un servizio Linux può essere il passo logico successivo: stessa lingua, librerie simili, pipeline di build unificata. Il vantaggio però nasce solo se i confini di piattaforma sono rispettati consapevolmente (percorsi file, case-sensitivity, locale/encoding, permessi utente di servizio, convenzioni di deploy). Il multiplatform in esercizio operativo è sempre “lavoro di dettaglio” – per questo va pianificato presto.

Checklist pratica: cosa serve almeno a un servizio Delphi-Linux produttivo

• Unit systemd con regole Restart/Timeout sensate, utente di servizio dedicato, percorsi definiti.
• Graceful Shutdown (SIGTERM), nessuna incoerenza dati al termine.
• Modello di configurazione con validazione, segreti gestiti in sicurezza, niente segreti nei log.
• Logging strutturato con versione, job-ID, correlazione-ID, durata, classe di errore.
• Health checks (almeno Readiness + Business-Check) e metriche definite.
• Elaborazione job idempotente, retry/backoff, concetto di dead-letter.
• Deployment con versionamento chiaro, strategia di rollback, migrazioni di schema pianificabili.
• Concetto di risorse e carico: parallelismo, limiti, timeouts, gestione della connessione.

Conclusione: Delphi sotto Linux non è un caso speciale – se si pensa anche all’operatività

I servizi Linux con Delphi sono in produzione una opzione solida se trattati come componenti di sistema a tutti gli effetti: con architettura chiara, integrazione systemd curata, modello di stato ed errori robusto, logging e monitoring tracciabili e deployment riproducibile. L’implementazione tecnica raramente è il rischio principale; il rischio sta nei “dettagli operativi” chiariti troppo tardi.

Chi pianifica questi dettagli fin dall’inizio ottiene un paesaggio di servizi manutenibile, che sfrutta la logica di dominio in modo coerente, gestisce le integrazioni in modo stabile e si amministra con affidabilità nella pratica – inclusi aggiornamenti, riavvii e guasti.

Se volete verificare come la vostra logica di dominio Delphi esistente possa essere trasferita in servizi Linux, worker e REST-Server (inclusi concetti di operazione e deployment), definiamo volentieri i vincoli in modo strutturato nel colloquio tecnico iniziale: Contatto.