Linux-szolgáltatások Delphi-vel üzemeltetése: architektúra, üzemeltetés és gyakorlati útmutató vállalatok számára

Aki Linux-Services mit Delphi betreiben szeretne, először a műszaki megvalósíthatóságra gondol: lefordítható-e az alkalmazás Linux-re? Stabilan fut? Ezek fontos kérdések — de vállalati üzemeltetésben ritkán az első indítás dönt a siker felől, sokkal inkább a mindennapok: leállás nélküli frissítések, reprodukálható telepítések, nyomon követhető naplók, egyértelmű felelősségi körök, tiszta biztonsági alapbeállítások és egy olyan szolgáltatásmodell, amely illeszkedik a meglévő Linux-üzemeltetésbe.

Delphi sok vállalatnál történelmi úton alakult ki — gyakran asztali közeli üzleti szoftverként, néha integrációs vagy backend-komponensként. Az Linux-alapú szolgáltatások felé történő elmozdulás (például REST-API-khoz, automatizáláshoz, adat-előkészítéshez vagy integrációkhoz) gyakran nem „új építés”, hanem modernizációs út: a logika egy része kiszakad a kliensből, a felületek stabilizálódnak, és az üzemeltetés szabványosabbá válik. Éppen ezért érdemes korán a működtetési szempontokról beszélni — nem csak közvetlenül a Go-live előtt.

Ez a bejegyzés áttekinti, hogyan üzemeltetnek tipikusan egy Delphi-alapú szolgáltatást Linux alatt, mely architektúra-döntések egyszerűsítik az üzemeltetést és mely gyakorlati buktatók relevánsak — különös tekintettel az IT-vezetésre, rendszergazdákra és technikai projektfelelősökre.

Miért Linux-szolgáltatások a vállalatnál – és miért marad fontos a Delphi

Linux sok adatközpontban és felhői környezetben a szerver-munkaterhelések sztenderdje. Ennek okai többek között: egységes üzemeltetési modell (SSH, csomagkezelés, systemd), jól bevált automatizálás (Ansible, Terraform-ökoszisztémák), tiszta biztonsági elemek (SELinux/AppArmor, systemd-sandboxing) és széles körű támogatás monitoring- és naplózó ökoszisztémák részéről.

Delphi nem „szokatlan” ezen a téren, sokszor éppen pragmatikus építőelem, ha a vállalatnál már kiterjedt Delphi-logika létezik. Ahelyett, hogy ezt a logikát teljesen újraimplementálnák, át lehet vinni vagy kiegészíteni szolgáltatás-szerűen — például mint REST-szerver, háttérfeldolgozás (batch/queue worker) vagy integrációs szolgáltatás ERP, DMS és további rendszerek között.

A lényeg a szemlélet: nem Delphi „ellen” Linux, hanem Delphi egy Linux-üzemeltetési modellben. Aki itt tisztán tervez, olyan jól adminisztrálható komponenst kap, amely egy „normál” Linux-szolgáltatáshoz hasonlóan viselkedik.

Delphi unter Linux: Laufzeitmodell, Abhängigkeiten, Packaging

Az üzemeltetés szemszögéből kevésbé a nyelv és az IDE számít, hanem az artefaktumok: mely fájlok kerülnek telepítésre? mely rendszerkönyvtárak szükségesek? mely konfigurációkra van szükség futásidőben?

Bináris, konfiguráció, adatok: világos elkülönítés

Egy Windows- és Linux-Services esetén a három terület tiszta szétválasztása döntő jelentőségű:

• Bináris/Programfájl: a lefordított végrehajtható állomány, lehetőleg kézzel beégetett (hardcoded) elérési útvonalak nélkül és a telepítési könyvtárban írási jogosultság nélkül.
• Konfiguráció: külön a bináristól, pl. fájlként a /etc/<service>/ alatt vagy Environment-változóként (környezeti változók), amelyeket a systemd kezel. Az Environment-változók üzemeltetés közben gyakran kényelmesebbek, mert könnyebben változtathatók környezetenként (Dev/Test/Prod).
• Adatok/Runtime: ideiglenes fájlok, cache-ek, PID/Socket-fájlok – jellemzően a /var/lib, /var/cache vagy /run alatt.

Ez a szétválasztás nem elméleti: lehetővé teszi a immutable Deployments-t (a bináris „változtathatatlan“), tisztább rollbackeket és kevesebb diff-driftet a szerverek között.

Függőségek és könyvtárak: inkább tudatosan, mint véletlenszerűen

Sok üzemeltetési probléma nem magából az alkalmazásból ered, hanem a rendszerkönyvtárak eltéréseiből. A gyakorlatban korán tisztázni kell:

• Mely Linux-disztribúciók a célplatformok (pl. Debian/Ubuntu vs. RHEL/Rocky)?
• Mely verziók szerepelnek az IT-stratégiában és hogyan patchelik őket?
• Hogyan dokumentálják és ellenőrzik a natív függőségeket (build-pipeline, smoke-tesztelés)?

Robusztus megközelítés, ha a szolgáltatásokat egy definiált build-környezetben építik és a futtatókörnyezetet annak megfelelően alakítják ki. Alternatívaként a konténerüzem (pl. Docker/Podman) segíthet standardizálni a futtatást – ilyenkor azonban a konténer-operations modellt (Images, Registry, Security-Scanning, Ressourcenlimits) tisztán kell bevezetni.

systemd mint üzemeltetési horgony: Service-Unit, újraindítási stratégia, erőforrások

Modern Linux-környezetekben a systemd az alapértelmezett szolgáltatáskezelő: elindítja a szolgáltatásokat, felügyeli őket, gyűjti a logokat (journald-on keresztül) és képes egyszerű biztonsági- és erőforrás-szabályok érvényesítésére. Az IT-üzemeltetés számára ez központi, mert egységes vezérlési modellt teremt.

Service-definíció: indítás, leállítás, újraindulás

A legfontosabb kérdések, amire egy systemd-unitnak válaszolnia kell:

• Hogyan indul? (útvonal, paraméterek, munkakönyvtár)
• Mikor tekinthető a szolgáltatás „késznek”? (pl. azonnal vs. sikeres port-/socket-bind után)
• Mi történik hibák esetén? (újraindítási házirend, késleltetés, korlátok)
• Milyen felhasználó alatt fut a szolgáltatás? (Least Privilege root helyett)

Különösen az újraindítási stratégia gyakorlati jelentőségű. Egy szolgáltatás, amely konfigurációs hiba miatt újraindítási ciklusba kerül, terhelést és log-áradatot okoz. Érdemes korlátokat alkalmazni (pl. Start-Limit) és egyértelmű hibakezelést: ha egy kötelező paraméter hiányzik, a szolgáltatás tisztán, érthető üzenettel fejezze be a működését – ne „félig” induljon el.

Erőforrások és stabilitás: memória, CPU, fájlleírók

A systemd képes korlátozni az erőforrásokat (CPU-arányok, memóriahatárok, nyitott fájlok száma). Ez nem helyettesíti a tiszta szoftvert, de védelmet nyújt a kilengések ellen. Üzemeltetési szempontból tipikus pontok:

• Fájlleírók: sok egyidejű kapcsolatnál (HTTP, DB, socketok) relevánsak a korlátok.
• Memória: memóriaszivárgások vagy féktelen cache-ek korábban válnak láthatóvá, ha a korlátok aktívak.
• Időtúllépések: indítási és leállítási timeoutoknak illeszkedniük kell az adatbázis-migrációkhoz, warm-uphoz vagy leállás fázisaihoz.

Az adminisztrátorok számára egy korlátok között maradó szolgáltatás jelentősen könnyebben üzemeltethető, mint egy „ellenőrizetlen folyamat”, amely idővel destabilizálhatja a hostot.

Linux-szolgáltatások üzemeltetése Delphi-vel: szolgáltatástípusok és tipikus használati minták

A „Service” kifejezést a mindennapokban különböző módon használják. A Linux-környezetben három minta különösen releváns, amelyek működés szempontjából egyértelműen különböznek.

1) Hosszú ideig futó REST-Server

Egy REST-Server (Representational State Transfer, HTTP-alapú felület) gyakran az első célpont: a meglévő üzleti logikát API-n keresztül teszik elérhetővé portálok, integrációk vagy automatizálások csatlakoztatásához. Üzemeltetési szempontból fontosak:

• Port-kötés és reverse proxy (pl. Nginx/Apache) a TLS-hez, routinghoz és szükség esetén rate-limitinghoz.
• Health-Checks (Liveness/Readiness): Fogadni tudja-e a szolgáltatás a kéréseket? Elérhető-e az adatbázis?
• Kérések korlátai: védelem túl nagy payloadok és kontrollálatlan párhuzamosság ellen.

Egy REST-Server nemcsak „fut”, hanem terhelés alatt stabilan kell reagálnia, követhetően kell logolnia, és részleges hibák esetén (pl. az adatbázis rövid ideig nem elérhető) definiáltan kell degradálódnia.

2) Worker/Daemon für Hintergrundjobs

A háttérfeldolgozás gyakran jobb kiindulópont, mint egy API-szerver: fájlok importálása, jelentések előállítása, adatok egyeztetése, interfészek szinkronizálása. Az ilyen workerek jól leválaszthatók, ha sor (queue) kerül alkalmazásra (üzenetsor), például adatbázistáblákon, message brokeren vagy fájlrendszer-spoolokon keresztül.

Fontos üzemeltetési szempontok:

• Idempotencia (ismételhetőség): Egy feladat ismétlése nem okozhat kárt, pl. duplikált könyvelések.
• Dead-Letter/Fehlerablage: A sikertelen feladatokat külön helyen tárolják, és kiértékelhetők.
• Backpressure: Torlódás esetén világosnak kell lennie, hogyan szabályoz a worker vagy hogyan skálázódik.

3) Timer-basierte Dienste

Időszakos feladatok (pl. 5 percenkénti export) a Linux-ban gyakran már nem klasszikusan Cronnal vannak megoldva, hanem systemd-Timer-rel. Előny: központi menedzsment, tiszta naplók, függőségek és egységes hibakezelés. Vállalati környezetben ez vonzó, mert a Cron-feladatok gyakran „láthatatlanul” nőnek és nehezen auditálhatók.

Konfiguráció im Betrieb: Secrets, Umgebungen, Versionierung

Vállalati környezetben a konfiguráció ritkán csupán „egy Ini-Datei”. Ez egy governance-téma: Ki jogosult módosítani? Hogyan követhetők a változtatások? Hogyan védik a titkokat?

Konfigurationsquellen: Datei vs. Environment

Üzemeltetési szempontból vegyes megoldás jellemző:

• Statikus Defaults a binárisban (pl. alapértelmezett timeoutok), amelyek ritkán változnak.
• Environment-Variablen per-környezet paraméterekhez (DB-Host, Ports, Feature Flags). systemd képes ezeket központilag kezelni.
• Konfigurationsdateien strukturált beállításokhoz, különösen, ha több érték logikailag összetartozik.

Fontos, hogy a konfiguráció validiert legyen: Indításkor a szolgáltatásnak ellenőriznie kell az összes kötelező értéket és érthető hibát kell kiadnia, ahelyett, hogy később egy bizonytalan állapotban futna.

Secrets: Passwörter, Tokens, Zertifikate

A titkok nem tartoznak Gitbe és nem szabad őket tiszta szövegű konfigurációban tárolni. Gyakorlatban bevált lehetőségek:

• systemd-Umgebungsdateien restriktív fájlengedélyekkel és elkülönített felelősségi körökkel.
• Titoktárolók (pl. Vault-megoldások) – az infrastruktúrától függően.

Wenn ein Delphi-Service externe APIs nutzt, ist Token-Rotation ein echtes Betriebsthema: Der Dienst muss Tokens ohne Neustart oder mit kontrolliertem Neustart übernehmen können.

Adatbázis-hozzáférés és perzisztencia: Stabilitás a kényelem előtt

Sok Delphi-alapú szolgáltatás adatvezérelt. Ezért az adatbázis-hozzáférés kerül a középpontba: nem abban az értelemben, hogy az SQL „szép“ legyen, hanem hogy a kapcsolatok stabilak legyenek, a timeoutok helyesen legyenek beállítva, és a hibállapotok kezelhetők legyenek.

FireDAC, PostgreSQL és társai: kapcsolat-pooling, timeoutok, hibajelenségek

Akár PostgreSQL-t, MariaDB-t vagy SQL Servert köt be: az üzemeltetésben elsősorban ezek a pontok számítanak:

• Connection-Handling: A kapcsolatokat tisztán megnyitják és lezárják? Van poolozási koncepció, vagy legalábbis világos korlátok a párhuzamos adatbázis-munkamenetekre?
• Timeouts: Hálózati timeoutok, lekérdezés-timeoutok, zárolási várakozási idők – és egy nyomon követhető reakció arra az esetre, ha egy timeout bekövetkezik.
• Transaktionen: Egyértelmű tranzakcióhatárok, különösen worker-feladatok esetén, hogy elkerüljük a félkész adatok állapotát.
• Migrationen: Az adatbázis-séma változtatásainak illeszkedniük kell a deploy-okhoz (előrekompatibilis, rollback-stratégia).

Az IT-felelősök számára döntő: egy szolgáltatás nem okozhat „meglepetést“ az adatbázisnak. Ez azt jelenti: a terhelési csúcsokat kontrollálni, a lekérdezéseket figyelni, az indexeket karbantartani és a hibás eseteket (zárolás, deadlockok, hálózati megszakadás) normál üzemként kezelni.

Adattárolás a szolgáltatásban: cache-ek és ideiglenes fájlok

Ha egy szolgáltatás fájlokkal dolgozik (Import/Export/PDF/EDI), akkor a tárolóhelyeket tisztán kell kezelni: definiált könyvtárak, kvóták, takarítási stratégiák és egy terv az újrafeldolgozásra. Az ideiglenes fájloknak nem „valahol“ szabad keletkezniük, hanem az üzemeltetési modellben előre meg kell határozni őket – beleértve a jogosultsági koncepciót.

Naplózás, monitoring és hibaelhárítás: telemetria nélkül nincs üzemeltetés

A gyakorlatban a szolgáltatások ritkán programhibák miatt buknak el; sokkal inkább a láthatóság hiánya okozza a problémát. Egy szolgáltatás, amely nem állít elő hasznosítható naplókat, időt vesz el az üzemeltetéstől és a szakterülettől – különösen sporadikus hibák esetén.

Naplózási stratégia: strukturált események a hosszú szöveges bejegyzések helyett

A jó naplók:

• korrelálható (pl. Correlation-ID minden kéréshez/munkához, hogy egy művelet minden naplóbejegyzésen keresztül követhető legyen),
• strukturált (kulcs-érték információk, amelyek szűrhetők),
• takarékos (nincsenek érzékeny adatok, nincsenek felesleges payloadok),
• üzemeltetés szempontjából hasznos (egyértelmű hibaüzenetek, kilépési kódok, követhető állapotok).

Unter Linux ist das Zusammenspiel mit journald/systemd hilfreich, weil Start/Stop/RESTart und Prozessausgaben zentral zusammenlaufen. Für größere Umgebungen sollte ein Log-Forwarding (z. B. in zentrale Logsysteme) eingeplant werden.

Monitoring: metrikák, Health-Endpoints, riasztási szabályok

A naplók mellett metrikákra is szükség van. Tipikus metrikák, amelyek az üzemeltetésben beválnak:

• Kérések/feladatok száma időegységenként
• Hibaarányok végpontonként/feladattípusonként
• Átfutási idők (latencia), elkülönítve külső függőségek szerint (DB, külső API)
• Sorhossz és felhalmozódás (backlog)
• Erőforrások: memória, CPU, nyitott kapcsolatok

Fontosabb nem maga az eszköz, hanem a fegyelem: a riasztási szabályoknak illeszkedniük kell az üzemeltetési valósághoz. Egy riasztás, amely folyamatosan aktiválódik, figyelmen kívül marad. Egy riasztás, amely túl későn aktiválódik, nem segít.

Biztonság és hardening: jogosultságok, hálózat, frissítések

Egy Windows- und Linux-Services tartósan elérhető folyamat – így a támadási felület része. A jó hír: Linux és systemd számos mechanizmust kínálnak a szolgáltatások izolálására. A rossz hír: ezek a mechanizmusok csak akkor hatnak, ha tudatosan alkalmazzák őket.

Least Privilege: külön rendszerfelhasználó, minimális jogosultságok

Egy szolgáltatásnak külön rendszerfelhasználóként kell futnia, minimális fájlhozzáférésekkel. Írási jogosultság csak a ténylegesen szükséges könyvtárakra. Ez csökkenti a hibákból vagy kompromittálódásból eredő kockázatokat.

Hálózati interfészek: csak a szükségeset nyitni

A biztonsági hiányosságok gyakori oka a „túl sok hálózat”: a szolgáltatások minden interfészhez kötnek, az adatbázisok túl sok hálózatról elérhetők, az admin-végpontok nincsenek elkülönítve. Hasznosak az egyértelmű szabályok:

• API-portokat csak belsőleg nyitni, külső elérés csak Reverse Proxy/WAF-on keresztül.
• Public és Private interfészek szétválasztása, szükség esetén külön listener-ek.
• Kimenő kapcsolatokat korlátozni, ahol lehetséges.

Patchelhetőség és frissíthetőség: OS-t és alkalmazást külön kezelni

Az üzemeltetésben két frissítési áramlásnak kell együttműködnie: operációs rendszer javítások és alkalmazáskiadások. Tervezzen erre:

• Karbantartási ablak vagy Rolling-Update-Strategie
• kompatibilis konfigurációk (nem „kézi munka“ szerverenként)
• Rollback-képesség (előző verzió futtatható, adatbázis-migrációk összehangolva)

Különösen azoknál a szolgáltatásoknál, amelyek üzleti adatokat mozgatnak, a tiszta release-menedzsment fontosabb, mint a „gyors deploy”.

Deployment-Strategien: a „másolás és reménykedés”-től a reprodukálható kiadásokig

Sok, évek alatt kialakult Delphi-környezet ismeri a manuális deploy-t: bináris másolása, szolgáltatás újraindítása, kész. Linux alatt ez legkésőbb akkor hátrányossá válik, amikor több példány, környezet vagy csapat van érintett.

Reprodukálhatóság: Build-Artefaktum und Version müssen zusammenpassen

Egy üzemeltetési szempontból rendezett rendszer a következőket tartalmazza:

• Verziózott artefaktumok (bináris, konfigurációs séma, esetleg migrációs szkriptek)
• egy egyértelmű Deploy-Mechanismus (csomag, artefakt-repository, konténer)
• Smoke-Tests deploy után (Health-Check, egyszerű API-kérések, DB-kapcsolat)

A cél nem „DevOps als Buzzword”, hanem kevesebb kiesés véletlenszerű eltérések miatt.

Rollback és adatbázis-migráció: a gyakran figyelmen kívül hagyott pár

A rollback egyszerű, amíg csak a bináris változik. Amint az adatbázisséma migrálódik, összetetté válik: egy régi bináris esetleg nem ismeri az új táblákat/oszlopokat. A gyakorlatban beválnak:

• előre kompatibilis migrációk (először új struktúrákat hozzáadni, később eltávolítani a régieket),
• Feature Flags az új logika számára,
• tervezett migrációs ablakok a kemény vágásokhoz.

Ha egy Delphi-alkalmazást modernizálnak (pl. monolitikus desktopról Service + Portal irányba), ez a kölcsönhatás központi. Itt keletkeznek a tipikus projektkockázatok – és itt térül meg az architektúra-diszciplína.

Migráció: Windows-szolgáltatás Linux-re – hogyan korlátozzuk a kockázatokat

Sok vállalatnál már léteznek Windows-szolgáltatások, amelyek adatokat dolgoznak fel vagy integrációkat végeznek. A Linux-re való migráció ekkor nem pusztán technológiai projekt, hanem üzemeltetési és kockázatkezelési projekt.

Különbségek az üzemeltetési modellben

• Szolgáltatáskezelés: Windows Service Control Manager vs. systemd
• Naplózás: Event Log vs. journald/fájl alapú logok

Ezek a különbségek kezelhetők, de fel kell venni őket az ellenőrzőlistára – különben az üzemeltetésben „láthatatlan” többletfeladat keletkezik.

Lépésenkénti migráció a Big Bang helyett

Egy gyakran gyakorlatban bevált stratégia:

1. Szolgáltatás leválasztása: egyértelmű interfészek, egyértelmű adatfelelősség, lehetőleg ne legyenek közvetlen UI-függőségek.
2. Observability bevezetése: Javítsa a naplózást és a metrikákat már a Windows- és Linux-szolgáltatások esetén, hogy később összehasonlíthatóság alakuljon ki.
3. Párhuzamos üzem: Linux-szolgáltatás kezdetben árnyéküzemmódban vagy a feladatok/kérések egy részére.
4. Átváltás: kontrollált cutover, visszaállítási tervvel.

Így csökkenti annak a kockázatát, hogy a platformváltás egyidejűleg ütközzön folyamatszintű változtatásokkal.

Interfészek üzemeltetése a gyakorlatban: szerződések, verziókezelés, hibatűrés

Egy szolgáltatás többnyire az integrációs lánc része. Amint több rendszer érintett (ERP, DMS, CRM, portálok), az üzemeltetés koordinációs feladattá válik. Itt segítséget jelentenek az egyértelmű API-szerződések és egy verziózási stratégia.

Verziókezelés: a változtatások tervezhetővé tétele

Az API-verziózás azt jelenti: a régi klienseknek nem szabad hirtelen meghibásodniuk. A gyakorlatban ez azt jelenti:

• Breaking Changes elkerülése, vagy azok csak új verzióban történő bevezetése
• A válaszformátumokat visszafelé kompatibilisen bővíteni (új mezők hozzáadása a régi átnevezése helyett)
• Kivezetési (Deprecation) folyamat határidőkkel és a használat monitorozásával

Ha Ön Delphi-alapú REST-végpontokat üzemeltet, ez az egyik legfontosabb operációs minőségi dimenzió – mert közvetlenül megelőzi a szomszédos rendszerek kiesését. (Tartalmilag jól lehet kapcsolódni a meglévő belső anyagokhoz a REST-architektúráról, hibakezelésről és verziózásról.)

Hibakultúra: definiált válaszok a „valami elromlott” helyett

Az üzemeltetés és a szakmai területek számára fontos, hogy a hibák egyértelműek legyenek: HTTP-státuszkódok, hibakódok, nyomon követhető logok, és elkülönítés a „klienshiba” (hibás kérés) és a „szerverhiba” (probléma a szolgáltatásban vagy a függőségekben) között.

Ellenőrzőlista IT-felelősöknek: mit kell éles üzembe vétel előtt rendezni

Végül egy tömör ellenőrzőlista, amely projektekben bevált, amikor Delphi-szolgáltatások Linux alatt élesbe kerülnek:

• Szolgáltatás-egység: újraindítási szabályzat, időkorlátok, indítási limitek, külön felhasználó, jogosultságok az adatútvonalakon
• Konfiguráció: forrás, validálás, elkülönítés környezetek szerint, dokumentált alapértelmezések
• Secrets: tárolás, jogosultságok, rotáció, tanúsítványok élettartama
• Naplózás: korreláció, strukturált mezők, központi gyűjtés, adatvédelem (nincs érzékeny payload)
• Monitoring: Health-Checks, metrikák, riasztási szabályok, üzemeltetési dashboard
• Adatbázis: időkorlátok, tranzakciók, pooling/limitálás, migrációs terv és rollback
• Telepítés: verzionált artefaktok, reprodukálható folyamat, Smoke-Tests
• Biztonság: portok, Reverse Proxy/TLS, hardening, patch-folyamat
• Üzemátadás: Runbook (indítás/leállítás, tipikus hibaképek, log helyei), felelősségi körök

Összegzés: A siker az üzemeltetési modellben rejlik, nem az első indításban

Linux-szolgáltatások Delphi-al való üzemeltetése sok vállalati környezetben ésszerű módja annak, hogy a felhalmozódott logikát stabil, jól integrálható backend-komponensként biztosítsák. Döntő jelentőségű, hogy a szolgáltatást úgy működtesse, mint egy Linux-szolgáltatást: systemd, mint vezérlőközpont, egyértelmű konfigurációs és titokkezelési stratégia, tiszta naplózási és monitorozási jelek, valamint olyan telepítések, amelyek reprodukálhatók és visszagörgethetők.

Ha egy meglévő Delphi-környezetet lépésről lépésre szeretne REST-szolgáltatások, worker-folyamatok és integrációs komponensek irányába fejleszteni Linux-on, akkor egy korai architektúra- és üzemeltetési workshop megéri: az interfészeket, az adatfolyamokat, a biztonságot és az üzemeltetést együtt gondolják át – nem pedig csak a fejlesztés után „ráépítve”.

Ha ehhez műszaki értékelést szeretne a környezetére vonatkozóan, a strukturált kezdés a kapcsolaton keresztül a leggyorsabb út:

A szakmai környezetben a Delphi Linux-szolgáltatás és a systemd-szolgáltatás is fontos szerepet játszanak, amikor az integrációk, az adatáramlások és a további fejlesztés tisztán kell, hogy együttműködjenek.

Projekt vagy modernizációs terv megbeszélése Net-Base-vel.