[casting] Podman Systemd Quadlets

[alexmaras]

Deployment platform

Deployment mode

Podman

Deployment flavor

Quadlets

Why this Casting?

Podman Quadlet enables rootless container deployments with systemd handling and containerisation built-in.

Managing quadlets is done just like systemd, but unlike raw systemd with binaries still allows everything to be containerised by default.

With this setup and the podman quadlet command, the output could even just be a .quadlet file which specifies all necessary files and can be run with podman quadlet install, or could be dropped straight into the ~/.config/containers/systemd/<folder> folder as multiple files.

Proposed Casting configuration

apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: podman
    mode: systemd # or mode: quadlets?

The above could use quadlet or systemd, and compose could easily be added as a secondary mode.

Expected Pours structure

pours/
└── deployment/
    └── signoz.quadlets

as in https://docs.podman.io/en/latest/markdown/podman-quadlet-install.1.html

It could alternatively output a set of files to drop into ~/.config/containters/systemd/signoz - .quadlets files just let you specify those all in one file and allows the user to run podman quadlet install to generate the output systemd files themselves.
From there, files can just be copied into ~/.config/containters/systemd/signoz. Perhaps the output path should be specifiable in the casting.yaml so that it can be copied without clashing.

Tooling requirements

podman
systemd

References

Podman Quadlet Install - for details on quadlet-specific commands
Podman Systemd Unit - for details on file formats for output - basically systemd units with special filenames that have special keys.

Additional context

As a reference point, I've converted the generated docker compose into quadlets and have:

signoz.clickhouse-keeper.container
signoz.clickhouse-keeper.image
signoz.clickhouse.container
signoz.clickhouse.image
signoz.collector-migrate.container
signoz.collector.container
signoz.collector.image
signoz.init-clickhouse.container
signoz.main.container
signoz.main.image
signoz.pod
signoz.postgres.container
signoz.postgres.image

The collector-migrate container is handling migrate sync check as a oneshot, and collector.container depends on the migrate script. The init-clickhouse container is doing the histogram fetch for clickhouse, and clickhouse depends on that and clickhouse-keeper. main depends on clickhouse and postgres. All up, this creates a clean systemd-native way to handle containerised deployments.

For reference, I'm using .image files here in order to be able to synchronise the versions, but it's optional. They just make image fetching act as a separate service which allows for slightly simpler updating at times.

[Nageshbansal]

Hey @alexmaras, thanks for raising this, and in such detail. If you'd like to contribute, please feel free to do so.