coreos / ignition

First boot installer and configuration tool

Home Page:https://coreos.github.io/ignition/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for podman-systemd.unit

dcode opened this issue · comments

Feature Request

Since release 4.4.0, podman supports a simplified systemd-like unit file that allow auto-generating systemd service units following a standard best practice. The problem is that if the container unit is created using ignition, any systemd generators have already run for that boot. Because of that, the generated service file won't be created until the next boot or if systemctl daemon-reload is manually run.

I'd like some process by which the transient service is created and started per the [Install] requirements. I think supporting this simplified format makes it much easier for users to manage their deployed containers.

Environment

What hardware/cloud provider/hypervisor is being used to run Ignition? gcp, using the fedora-coreos-testing image (37.20230218.2.0)

Desired Feature

I'd like to be able to create a podman-systemd.unit file using ignition, then have that service start when the first boot is complete.

Other Information

Here's an example real-world unit file that I'd like to install using ignition. The file is created as expected, but as noted above, the generator doesn't run, thus the service never starts.

# /etc/containers/systemd/logstash.container
[Unit]
Description=Logstash is a free and open server-side data processing pipeline.
After=network-online.target
Wants=network-online.target

[Container]
Environment=xpack.monitoring.enabled=false

PublishPort=5044:5044/tcp

User=1000
Group=1000

# Health checks
PodmanArgs=--health-cmd 'CMD-SHELL curl -s 127.0.0.1:9600 | grep green || exit 1'
PodmanArgs=--health-retries=5
PodmanArgs=--health-startup-cmd 'CMD-SHELL curl -s 127.0.0.1:9600 | grep green || exit 1'
PodmanArgs=--health-on-failure=kill

# Secret keyword not yet supported in 4.4.1
PodmanArgs=--secret=mysecret-file.json
PodmanArgs=--secret=CONFIDENTIAL_VALUE,type=env

# Volumes
Volume=/etc/logstash/pipeline:/usr/share/logstash/pipeline:z

Image=${LOGSTASH_IMAGE}:${LOGSTASH_VERSION}

[Service]
Environment=LOGSTASH_IMAGE=docker.elastic.co/logstash/logstash
Environment=LOGSTASH_VERSION=8.6.2
EnvironmentFile=-/etc/sysconfig/logstash

ExecReload=/usr/bin/podman kill --signal HUP systemd-%N

[Install]
WantedBy=default.target

The problem is that if the container unit is created using ignition, any systemd generators have already run for that boot.

Hmm, I'm not sure I understand that part. Is the desired flow that the config creates e.g. /etc/containers/systemd/logstash.container, and then a systemd generator creates a service unit from it during boot? That should work today, since Ignition runs in the initrd and the generator would run afterward in the real root.

Ugh... you are completely correct. I'm not sure how I did it, but after posting this I ran a fresh deploy (terraform -> gcp -> ignition) and it worked. Perhaps it failed to run and log the previous run because I had used the Secret keyword which isn't in that particular release. I mistook the lack of any log entry to mean that it hadn't run. Reading the sytemd-generator documentation, journald isn't running, so that log just disappears, I guess.

Sorry for unneeded issue. Hopefully it at least serves as some documentation for future users.