Podmanでコンテナをサービス化、自動起動させる方法 「systemd」と「Quadlet」で解説：次世代コンテナエンジン「Podman」「Podman Desktop」入門（終）

次世代コンテナエンジンの一つ「Podman」と、そのデスクトップツールである「Podman Desktop」でコンテナを管理する方法を解説する本連載。最終回は、Podmanで動作するコンテナをサービス化させる、より実用的な運用方法を紹介します。

[鎌田啓佑，サイオステクノロジー]

　次世代コンテナエンジンの一つ「Podman」と、そのデスクトップツールである「Podman Desktop」でコンテナを管理する方法を解説する本連載。第4回は、Podman/Podman Desktopで複数のコンテナを「Pod」としてまとめて管理する方法を解説しました。最終回となる今回は、Podmanで動作するコンテナをサービス化させる、より実用的な運用方法を紹介します。

　「コンテナのサービス化」とは、一般的に、OSの起動と同時にコンテナを自動で起動させるプロセスのことを指します。「Docker」を利用する場合は、Docker自体がデーモンとして動作するため、自動起動の設定はDockerに対して実施します。一方、Podmanの場合はデーモンとして動作しないため、Dockerとは違った方法でサービス化する必要があります。ここで登場するのが、「systemd」と「Quadlet」です。

systemdとQuadletとは

　systemdはシステムとサービスを管理する最上位プロセスで、「Red Hat Enterprise Linux」（RHEL）や「Ubuntu」など、一般的によく使われるLinuxディストリビューションで採用されています。systemdにおけるサービスの定義は決まった書式が存在し、それに沿ったファイルを用意することでサービスを作成できます。

[Unit]
Description=Sample service
[Service]
ExecStart=/path/to/process
[Install]
WantedBy=multi-user.target

簡単なsystemdサービスの定義例

　systemdは、OS再起動時にサービスを自動起動させる仕組みを持つ他、サービスとして起動させているプロセスを監視し、異常終了した場合に自動で再起動するなど、運用に便利な機能を多数備えています。

　このsystemdの仕組みに、コンテナの管理を組み込むのが、Quadletです。Quadletはコンテナをsystemdの管理下に置くことを目的として作られており、その書式もsystemdのものとほぼ同様なので、すぐにコンテナをサービス化できます。

簡単なQuadletを作る

　早速、簡単なQuadletを作成してみましょう。今回作成するのは、本連載第2回でも扱った、Apache HTTDです。Quadletとして作成し、サービス化します。

　まずは次のような内容のファイルを作成します。

[Unit]
Description=Apache HTTPD container
[Container]
Image=docker.io/library/httpd:latest
PublishPort=12345:80
[Install]
WantedBy=multi-user.target

パラメーター名	内容
Image	使用するコンテナイメージを指定します
PublishPort	公開するポートを指定します。今回は、コンテナの80番ポートをホスト側の12345番ポートで受け付けるよう設定しています

　このファイルを、~/.config/containers/systemd/httpd-test.containerに配置します。途中のディレクトリが存在しない場合は、適宜作成してください。

　次に、作成したQuadletをsystemdに読み込ませるために、次のコマンドを実行します。

$ systemctl --user daemon-reload

　このコマンドを実行するとQuadletを読み込んでsystemdの管理下に置かれ、httpd-test.serviceというサービスが作成されます。

$ systemctl --user status httpd-test.service
○ httpd-test.service - Apache HTTPD container
     Loaded: loaded (/home/kkamada/.config/containers/systemd/httpd-test.container; generated)
     Active: inactive (dead)

　準備が整ったので、systemdからコンテナを起動してみます。次のコマンドを実行してコンテナを起動してください。

$ systemctl --user strart httpd-test.service

　これでコンテナが起動できているはずです。podman psコマンドを実行しても、期待通りにコンテナが起動できていることが分かります。

$ podman ps
CONTAINER ID  IMAGE                           COMMAND           CREATED        STATUS        PORTS                  NAMES
b8546342dc84  docker.io/library/httpd:latest  httpd-foreground  8 seconds ago  Up 8 seconds  0.0.0.0:12345->80/tcp  systemd-httpd-test

　今度は、systemd経由でコンテナを停止します。次のコマンドを実行しましょう。

$ systemctl --user stop httpd-test.service

　すると、コンテナは確かに停止するのですが、これまでpodmanコマンドなどで停止していたときと異なり、podman ps -aコマンドを実行しても、停止中のコンテナとして表示されることなく、コンテナ自体が削除されているように見えます。

$ podman ps -a
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES

　このように、Quadletでコンテナをsystemd管理下に置くと、コンテナを停止しているときはコンテナ自体が存在しない状態になります。

PodのQuadletを作成する

　次に、PodのQuadletを作成します。作成するPodは、本連載第4回で扱った「MariaDB」と「WordPress」のPodとします。

　前述の通り、コンテナの停止時はコンテナ自体が削除される（ように見える）ため、データベースコンテナも停止時にデータが削除されてしまいます。従って、DB（データベース）に保存するデータを永続化するためには、コンテナボリュームを別途用意する必要があります。これも含めて、Podとして定義してみましょう。

　まずは、データベースのデータを保存するボリュームを作成します。以下のように定義した後、~/.config/containers/systemd/wordpress-data.volumeとして保存します。ほぼ設定が存在しないような内容となっていますが、これで問題ありません。

[Volume]

~/.config/containers/systemd/wordpress-data.volume

　次に、MariaDBとWordPressをまとめるPodを作成します。以下のように定義した後、~/.config/containers/systemd/wordpress.podとして保存します。

[Pod]
PodName=wordpress-pod
PublishPort=9000:80

~/.config/containers/systemd/wordpress.pod

パラメーター名	内容
PodName	Podの名前を指定します

　MariaDBとWordPressのコンテナをそれぞれ作成します。まずは、MariaDBのコンテナを以下のように定義し、~/.config/containers/systemd/wordpress-mariadb.containerとして保存します。

[Unit]
Description=MariaDB for WordPress
[Container]
Image=docker.io/library/mariadb:latest
Volume=wordpress-data.volume:/var/lib/mysql
Pod=wordpress.pod
Environment=MARIADB_DATABASE=wordpress
Environment=MARIADB_USER=wordpress
Environment=MARIADB_PASSWORD=wordpress
Environment=MARIADB_RANDOM_ROOT_PASSWORD=1
[Install]
WantedBy=multi-user.target

~/.config/containers/systemd/wordpress-mariadb.container

パラメーター名	内容
Volume	コンテナにマウントするボリュームを指定します。今回は、先ほど作成したwordpress-data.volumeを使用し、コンテナ内の/var/lib/mysqlにマウントするよう設定しています
Pod	コンテナにひも付けるPodを指定します。今回は、先ほど作成したwordpress.podにひも付けるよう設定しています
Environment	コンテナに渡す環境変数を指定します

　最後に、WordPressのコンテナを以下のように定義し、~/.config/containers/systemd/wordpress-app.containerとして保存します。

[Unit]
Description=WordPress
[Container]
Image=docker.io/library/wordpress:latest
Pod=wordpress.pod
Environment=WORDPRESS_DB_NAME=wordpress
Environment=WORDPRESS_DB_USER=wordpress
Environment=WORDPRESS_DB_PASSWORD=wordpress
Environment=WORDPRESS_DB_HOST=127.0.0.1
[Install]
WantedBy=multi-user.target

~/.config/containers/systemd/wordpress-app.container

　全て保存し終わったら、Quadletをsystemdに読み込ませて、Podの起動を試みます。

$ systemctl --user daemon-reload
$ systemctl --user start wordpress-pod.service
$ podman ps
CONTAINER ID  IMAGE                                    COMMAND               CREATED        STATUS        PORTS                           NAMES
b5a9299e71e5  localhost/podman-pause:5.4.0-1751987092                        2 seconds ago  Up 2 seconds  0.0.0.0:9000->80/tcp            wordpress-pod-infra
a1ef1945cbe9  docker.io/library/wordpress:latest       apache2-foregroun...  2 seconds ago  Up 2 seconds  0.0.0.0:9000->80/tcp            systemd-wordpress-app
958760fa8613  docker.io/library/mariadb:latest         mariadbd              2 seconds ago  Up 2 seconds  0.0.0.0:9000->80/tcp, 3306/tcp  systemd-wordpress-mariadb

　正常にPodが起動し、MariaDBとWordPressが起動できていることが確認できます。データベースのデータをボリュームとして別で保存するようにしているため、このPodを再起動してもデータは保持されます。

　また、systemdで管理しているため、OS再起動後も自動で起動するよう設定できます。

　以下のコマンドを実行して自動起動を有効化します。

$ systemctl --user enable wordpress-pod.service

まとめ

　全5回にわたって、PodmanとPodman Desktopを使ったコンテナ管理を解説しました。Dockerや「Docker Desktop」と同等の機能に加え、デーモンレスやルートレスである利点を生かすことで、より気軽にコンテナ環境に触れることができます。また、Quadletによりコンテナをサービス化することで、実運用にも活用できるものになるはずです。

　Podに関する知識は、Kubernetesなどのコンテナオーケストレーションを推進する上でも役立ちます。PodmanやPodman Desktopに慣れ親しむことで、コンテナやコンテナオーケストレーションをもっと使いこなせるようになるでしょう。最後までお読みいただき、ありがとうございました。

筆者紹介

鎌田啓佑

サイオステクノロジー所属。OSS よろず相談室でサポート対応をしているテクニカルサポートエンジニア。Ansibleに出会ってから自動化に取り憑かれ、自身の業務やプライベートであらゆるものの自動化に取り組む。プライベートではJavaでちょっとしたツールの開発を趣味にしている。

サイオス OSS よろず相談室

サイオステクノロジーエンジニアブログ

サイオステクノロジーエンジニア YouTube チャンネル