Podman #6 - Putting WordPress in a Pod

For this example, I wanted to pick something everyone recognizes: WordPress. It’s simple to deploy, has two containers that need to talk to each other, and is perfect for testing. We’ll need a MariaDB container and a WordPress container.

Step 1: Create Secrets

Like Kubernetes and Docker Swarm, Podman has the concept of secrets. We don’t want to store database passwords in an environment file, so we can use secrets:

# MariaDB root password
echo -n "example-root-pw" | podman secret create blog_db_rootpassword -

# Database name
echo -n "wordpress" | podman secret create blog_db_name -

# Database user
echo -n "wpuser" | podman secret create blog_db_user -

# User password
echo -n "example-wp-pw" | podman secret create blog_db_password -

Check your secrets with:

podman secret ls

Step 2: Create the MariaDB Quadlet

Now we create the MariaDB container Quadlet:

nano ~/.config/containers/systemd/mariadb.container

[Unit]
Description=MariaDB container for WordPress
PartOf=podracer.pod

[Container]
Image=docker.io/library/mariadb:11
Pod=podracer.pod
AutoUpdate=registry
StartWithPod=true
NoNewPrivileges=true
ContainerName=mariadb
Volume=%h/.local/share/containers/storage/volumes/wp-mariadb:/var/lib/mysql:z
Secret=blog_db_name,type=env,target=MYSQL_DATABASE
Secret=blog_db_user,type=env,target=MYSQL_USER
Secret=blog_db_password,type=env,target=MYSQL_PASSWORD
Secret=blog_db_rootpassword,type=env,target=MARIADB_ROOT_PASSWORD

[Service]
Restart=always

The target values above correspond to the environment variable names inside the container.

Also, Podman doesn’t create mapped folders for you. Systemd resolves %h to your home directory:

mkdir -p ~/.local/share/containers/storage/volumes/wp-mariadb
mkdir -p ~/.local/share/containers/storage/volumes/wp-html

Reload systemd and start the container:

systemctl --user daemon-reload
systemctl --user start mariadb.service

If the container fails to start, you can follow logs with journalctl -fe or podman logs mariadb.

Check if the service was created:

ls /run/user/$UID/systemd/generator/

If it isn’t there, troubleshoot using:

/usr/lib/systemd/user-generators/podman-user-generator -dryrun

Step 3: Create the WordPress Quadlet

nano ~/.config/containers/systemd/wordpress.container

[Unit]
Description=WordPress container
PartOf=podracer.pod
After=mariadb.service

[Container]
Image=docker.io/library/wordpress:latest
Pod=podracer.pod
AutoUpdate=registry
StartWithPod=true
NoNewPrivileges=true
ContainerName=wordpress
Volume=%h/.local/share/containers/storage/volumes/wp-html:/var/www/html:z
# Inject database secrets as environment variables
Secret=blog_db_name,type=env,target=WORDPRESS_DB_NAME
Secret=blog_db_user,type=env,target=WORDPRESS_DB_USER
Secret=blog_db_password,type=env,target=WORDPRESS_DB_PASSWORD

# Connect to MariaDB by container name
Environment=WORDPRESS_DB_HOST=127.0.0.1

[Service]
Restart=always

The key points here are:

• After=mariadb.service ensures WordPress starts only after MariaDB.
• WORDPRESS_DB_HOST is set to 127.0.0.1, connecting to the database on localhost.

Reload systemd and start WordPress:

systemctl --user daemon-reload
systemctl --user start wordpress.service

If everything started correctly, you can browse to your host on port 8080 (as specified in the pod Quadlet) and see WordPress running.

Extra Options: StartWithPod and AutoUpdate

The configuration option StartWithPod=true helps to avoid having to manually start each container. Once the pod is started, the containers will automatically follow. This makes pod-level orchestration much smoother.

Another useful setting is AutoUpdate=registry. This ties into the podman-auto-update.service which runs daily at midnight by default (though this schedule can be changed). It will pull the latest image of the container and apply updates. You can preview this behavior with:

podman auto-update --dry-run

And you can trigger it manually with:

podman auto-update

Enable the service for automatic updates

systemctl --user enable --now podman-auto-update.timer

You can check the timer to verify the schedule of the service

systemctl --user list-timers podman-auto-update.timer

Container update history can be followed with

journalctl --user -u podman-auto-update.service

This ensures your containers stay up to date with minimal effort.

https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html