Deployments

Use an FQDN as the pod name

All units forming a podluck pod need to share the same prefix name (i.e., the %p systemd specifier). The prefix name is used as the podman pod name and also is part of the path to individual config and runtime files.

Hence, it is important that the pod name does not clash with any existing systemd unit. This is especially important when running pods in the system domain. Thus, it is recommended to use a FQDN as the pod name for any pod managed by podluck.

As a convenience, container names are generated by prepending the prefix name with the systemd instance name. Hence, container will look like subdomains of the pods FQDN. Consider the minimal rootless example. The following systemd units are deployed:

• minimal.example.com.service (pod)

• minimal.example.com@.service (containers)

With only one container, the following services are started:

Podman name	Systemd Service Instance	Systemd Unit File
minimal.example.com	minimal.example.com.service	minimal.example.com.service
hello-world.minimal.example.com	minimal.example.com@hello-world.service	minimal.example.com@.service

For a rails app with an application, a database and a http frontend this might look as follows:

Podman name	Systemd Service Instance	Systemd Unit File
railsapp.example.com	railsapp.example.com.service	railsapp.example.com.service
app.railsapp.example.com	railsapp.example.com@app.service	railsapp.example.com@.service
nginx.railsapp.example.com	railsapp.example.com@nginx.service	railsapp.example.com@.service
db.railsapp.example.com	railsapp.example.com@db.service	railsapp.example.com@.service

Use named volumes for storage

In order to simplify deployment of podluck units accross infrastructure (and also locally on developer machines) it is recommended to use named volumes for persistent storage.

Use the fully qualified podman container name as the basis for a volume name. If the container requires multiple volumes, prepend some label. E.g.:

• logs.app.railsapp.example.com (log directory for a rails application container)

• data.app.railsapp.example.com (data directory for a rails application container)

• pgdata.db.railsapp.example.com (data directory for a postgres container)

Specify system wide defaults

Specify system wide defaults for pods using PODLUCK_POD_ARGS_DEFAULT in /etc/podluck/default/systemd-pod-env. Good candidates for system wide pod defauls are:

• --dns (specify correct DNS resolver)

• --label "io.containers.autoupdate=image" (enforce podman auto updates)

Specify system wide defaults for containers using PODLUCK_CONTAINER_ARGS_DEFAULT in /etc/podluck/default/systemd-container-env. Good candidates for system wide container defaults are:

• --read-only (mount container images read-only)

• --label "io.containers.autoupdate=image" (enforce podman auto updates)

• --pull=always (always pull image upon container creation)

• --cap-drop=ALL (start with all capabilities dropped, containers must explicitly specify --cap-add arguments for any capability required by application).

• --log-driver=journald (Send stdout / stderr to systemd journal)

Alternatively or in addition, specify defaults for all containers in a specific pod using PODLUCK_CONTAINER_ARGS_POD in /etc/podluck/pod/%p/systemd-container-env.