You are not logged in.
Pages: 1
In pull #324 I add a systemd socket activation / journal logging support for mORMot.
This allow to build a SaaS solutions with process-per-customer ideology (for many tasks multitenancy is not the thing customer expect, for example finance or personal information)
Or simply create a service what starts on demand, for example because most of the time it's idle (some statistic services etc.)
See systemd integration section in samples 36 for details
Feedbacks is wellcome
Online
For a while it used only for testing (intensive). mORMot part is ready for production, but In my case creating a new environment for a customer is a complex task (in opposite to a classic mORMot), so I still wrote a scripts for CD (our product use many services: nginx, Postgres, Redis for cache, RabbitMQ for message queues, nodejs for websockets, camunda for BPM, tesseract for document recognition, OnlyOffice to document edit and collaboration, certification authority for user certificates management and so on). Also several days ago I found a brilliant cockpit project what simplify administration UI a lot and allow to very easy wrote a plugins what we need.
I hope in 1-2 week we finish CD.
P.S.
@ab - please, look at libc problem (fcntl64). Current trunk is not usable - I temporary replace a sqlite3.o from a old (w/o new build) mORMot version for testing purpose (i don't use an encryption on SQLite3 level, but use encrypted FS instead)
Online
that's really cool, now that you've mentioned cockpit, does everyone use this gimacky php web UI to admin their servers? I used Proxmox for a while and after a few months I wasn't confident it would hold up when shit hits the fan. Like, I have 0 faith in this and I absolutely don't want to deal with another layer of abstraction just so I can look at some graphs or start a VM faster. Where is the value?
Offline
The main purpose of Proxmox is to manage VM. This is how we currently works - one VM for one customer. Proxmox to manage VMs.Very resources unfriendly...
The idea under systemd activation is to go away from VM, activate app in Control Groups (Cgroups) environment with limited resources (build-in feature in systemd) on the bare metal. In case of socket activation we can actually run an app "on demand" and shut it down after some period of inactivity.
I mentioned a cockpit project (it's written using C, not PHP) because it's main purpose is to manage a host from browser (including docker/podman containers). It's just a VERY thin layer between browser and host. But the main thing what important for me in cockpit is how simple is create a plugin.
Online
Thanks for explaining, I had no idea systemd can do that, looks very promising! I use LXC containers instead of VMs but this systemd socket activation could be very useful.
Offline
Systemd can also manage a LXC containers (machinectl) - see chapter 21 here. With optional socket activation. And thanks to SynLog journald integration - with centralized logging
Last edited by mpv (2020-06-21 18:14:31)
Online
Amazing, thank you! I've been using LXD container manager but machinectl looks amazing. Exactly what I need and now I can run stock debian without any external snap packages. Still blows my mind I missed this systemd functionality.
Thanks again very much.
Offline
This thread is a good read, thank you guys! The systemd socket activation is really interesting, the start-on-demand nature is similar to that of the 'serverless' (eg, AWS lambda) hype.
Not sure if Window server has the similar feature?
Delphi XE4 Pro on Windows 7 64bit.
Lazarus trunk built with fpcupdelux on Windows with cross-compile for Linux 64bit.
Offline
Important fix is added for journald logging - because sd_journal_print args strings processed using C printf semantic, % is a printf placeholder and should be either escaped using %% or all formatting args must be passed.
So better to use sd_journal_sendv for logging. See https://github.com/synopse/mORMot/pull/340
Last edited by mpv (2020-08-07 13:10:12)
Online
Pages: 1