Podman の最も優れた特長の一つは、systemd との連携の良さです。Podman は標準的な fork/exec モデルを採用しており、systemd のシステムおよびサービス管理モデルに容易に適応できます。
[ 今すぐダウンロード:Podman 基本チートシート ]
Valentin Rothberg は エッジにおける Podman の中で次のように述べています。
「コンテナ化されたワークロードを systemd で実行することは、信頼性の高い強固なデプロイを実現するシンプルかつ強力な手段です。systemd との統合は、自動アップデートやロールバック、あるいは systemd での Kubernetes ワークロード実行といった高度な Podman 機能の基盤をさらに強化します。この統合により、systemd はサービス依存関係の管理、ライフサイクルおよびサービス状態の監視、さらに障害発生時にはサービスの再起動も実行できます」
Podman が systemd ユニットファイルで適切に動作することを管理者が認識すると、Podman のアップストリームには Podman を systemd サービスとして実行するためのベストプラクティスに関する問い合わせが寄せられるようになりました。私たちはこの点について調査し、アップストリーム systemd のチームと協力してベストプラクティスのテンプレート化に取り組みました。Podman は実行中のコンテナから直接ユニットファイルを作成する podman generate systemd コマンドを追加しました。
[ systemd コマンドチートシートを入手 ]
Alex Larsson 氏は、汎用的な systemd ユニットファイル定義を用いてサービスをオンザフライで再生成する systemd ジェネレーターを活用した、このテンプレート化のより優れた利用方法を考案した後、Quadlet プロジェクトを立ち上げました。Quadlet は、systemd の下でコンテナを実行する際の複雑性をユーザーから隠蔽し、ユニットファイルをゼロから作成する手間を大幅に軽減しました。これは systemd 用の Compose または Kubernetes ファイルのようなものです。一度作成すれば、どこでもデプロイできます。
Quadlet とは
オリジナルの Quadlet リポジトリでは、Quadlet を次のように説明しています。
Kubernetes kubelet を圧縮したらどうなりますか?
quadlet になります
Quadlet は、コンテナを systemd で宣言的に実行できるようにすることで、Podman コンテナを systemd で最適に実行するためのツールです。Podman 4.4 に統合されました。
Quadlet リポジトリ (現在は凍結) には次のように記されています。
「コンテナはクラウド環境で頻繁に利用され、Kubernetes のようなオーケストレーターと組み合わせて使用されます。また、開発やテストの際に、必要に応じて手動でコンテナを管理するためにもよく使用されます。
しかし、ある種の自動的なコンテナ管理が必要となるユースケースもあります。規模が小さくシングルノードで構成される環境や、システムの他の部分と緊密に統合されている場合などです。この典型的な例としては、システム管理者が存在しない組み込みシステムや車載システム、あるいはネットワークから切り離されたサーバーやエッジサーバーなどがあります。
これには systemd を使ってコンテナをオーケストレーションすることが推奨されます。なぜなら systemd はすでに稼働しているプロセスマネージャーであり、Podman コンテナは単なる子プロセスだからです。Podman を systemd と直接連携させる方法について記述したドキュメントは数多くありますが、最終的に生成される systemd 設定ファイルは通常、大規模で保守が困難なものになります。また、コンテナのセットアップが最適でないこともよくあります」
基本的に、人的介入を必要とせずにコンテナ化されたシステムサービスを実行したい場合には、ローカルで稼働中の Podman コンテナの管理に systemd を使用するのが賢明です。
[ Podman 4.4 の新しいコンテナイベントと監査機能を確認 ]
Podman で Quadlet を使用する
Podman 4.4 の Quadlet では、CTRNAME.container ユニットファイルを作成し、以下のいずれかのディレクトリに配置できます。
/usr/share/containers/systemd/
/etc/containers/systemd/ルートレスユーザーの場合:
$HOME/.config/containers/systemd/次の例では、ubi9-minimal コンテナイメージで sleep 1000 コマンドを実行する mysleep.container ユニットファイルを作成します。
cat $HOME/.config/containers/systemd/mysleep.container
[Unit]
Description=The sleep container
After=local-fs.target
[Container]
Image=registry.access.redhat.com/ubi9-minimal:latest
Exec=sleep 1000
[Install]
# Start by default on boot
WantedBy=multi-user.target default.target[Container] セクションに注目してください。実行する Image と実行するコマンド (Exec) を指定するだけで、systemd ユニットファイルで通常指定される他のすべてのフィールドを使用できます。
ここで、新しいユニットファイルについて systemd に通知する必要があります。以下のコマンドを入力してください。
$ systemctl --user daemon-reloadこれにより、mysleep.container ファイルに基づいて mysleep.service ファイルが作成されます。
$ systemctl --user status mysleep.service
○ mysleep.service - The sleep container
Loaded: loaded (/home/dwalsh/.config/containers/systemd/mysleep.container; generated)
Active: inactive (dead)ここで、このサービスを有効にするか、起動します。
$ systemctl --user start mysleep.service生成されたサービス内の podman コマンドは、ubi9-init イメージをダウンロードし、指定されたコマンド sleep 1000 を開始します。
[ このチュートリアルで Podman を実際に使ってみる ]
サービスのステータスは次のように確認できます。
$ systemctl --user status mysleep.service
● mysleep.service - The sleep container
Loaded: loaded (/home/dwalsh/.config/containers/systemd/mysleep.container; generated)
Active: active (running) since Thu 2023-02-09 18:07:23 EST; 2s ago
Main PID: 265651 (conmon)
Tasks: 3 (limit: 76815)
Memory: 1.6M
CPU: 94ms
CGroup: /user.slice/user-3267.slice/user@3267.service/app.slice/mysleep.service
├─libpod-payload-421c8293fc1ba7b6b08263e6895ed8187abb5ff136a7dfb073ed931883a68491
│ └─265653 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000
└─runtime
├─265648 /bin/slirp4netns --disable-host-loopback --mtu=65520 --enable-sandbox --enable-seccomp >
└─265651 /usr/bin/conmon --api-version 1 -c 421c8293fc1ba7b6b08263e6895ed8187abb5ff136a7dfb073ed>
Feb 09 18:07:23 fedora systemd[2261]: Starting mysleep.service - The sleep container...
Feb 09 18:07:23 fedora podman[265630]: 2023-02-09 18:07:23.504068408 -0500 EST m=+0.044907849 container create >
Feb 09 18:07:23 fedora podman[265630]: 2023-02-09 18:07:23.542799094 -0500 EST m=+0.083638534 container init 42>
Feb 09 18:07:23 fedora systemd[2261]: Started mysleep.service - The sleep container.Podman がインストールされると、上記のディレクトリ内のファイルを検索し、/usr/libexec/podman/quadlet 実行可能ファイルを実行する systemd-generator ツールが登録されます。
Quadlet が作成するサービスファイルは、Quadlet のコマンドラインを使用して確認できます。
$ /usr/libexec/podman/quadlet -dryrun -user
quadlet-generator[265731]: Loading source unit file /home/dwalsh/.config/containers/systemd/mysleep.container
---mysleep.service---
[Unit]
Description=The sleep container
Before=local-fs.target
SourcePath=/home/dwalsh/.config/containers/systemd/mysleep.container
RequiresMountsFor=%t/containers
[X-Container]
Image=registry.access.redhat.com/ubi9-minimal:latest
Exec=sleep 1000
[Install]
# Start by default on boot
WantedBy=multi-user.target default.target
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
KillMode=mixed
ExecStopPost=-/usr/bin/podman rm -f -i --cidfile=%t/%N.cid
ExecStopPost=-rm -f %t/%N.cid
Delegate=yes
Type=notify
NotifyAccess=all
SyslogIdentifier=%N
ExecStart=/usr/bin/podman run --name=systemd-%N --cidfile=%t/%N.cid --replace --rm --log-driver passthrough --runtime /usr/bin/crun --cgroups=split --sdnotify=conmon -d registry.access.redhat.com/ubi9-minimal:latest sleep 1000Quadlet が生成するサービスファイルは、podman generate systemd –new と同じライブラリを使用していますが、その複雑性はユーザーからは見えません。
メリットの一つは、Podman の新しいバージョンがリリースされ、ジェネレーターに修正や機能強化が加えられた場合、次回 systemctl daemon-reload が実行される (再起動時など) 際に、サービスが自動的に強化版にアップデートされることです。
コンテナの説明では、関連するコンテナの詳細にのみ焦点を当て、Podman との連携方法に関する技術的詳細は含まれません。つまり、作成や保守が容易であり、Podman の新しい機能が追加されると、統合が自動的に改善されます。これで、systemd 内で Podman の他の優れた機能 (自動アップデートやロールバックなど) を使用して、コンテナ化されたサービスのライフサイクルをハンズフリーで管理できるようになります。
Quadlet は、.container に加えて、他の高度なユニットファイルもサポートしています。
- .kube を使用すると、Kubernetes に基づいて systemd サービス下で Pod とコンテナを実行するためのサービスファイルを作成するように Quadlet に指示する Kubernetes.yaml ファイルを指定できます。
- .network は、Quadlet に Podman コンテナ・ネットワーク・デバイスを定義するサービスファイルを作成するように指示します。これらのネットワークデバイスは、.container および .kube ユニットファイル内で使用できるようになります。
- .volume は、Quadlet に Podman ボリュームを定義するサービスファイルを作成するように指示します。これらのボリュームは、.container ユニットファイル内で使用できるようになります。
詳細については、podman-systemd.unit(8) ファイルを参照してください。
今後の記事では、Quadlet の高度なユースケースについて説明します。
まとめ
Quadlet を使用すると、systemd の下で宣言的にコンテナを実行できます。Compose ファイルや Kubernetes ファイルと同様に、実行したいものを宣言すればよく、ワークロードの実行に伴うあらゆる複雑な作業に対処する必要はありません。
Podman は先進的な Linux システムへの統合において長い実績を持ち、Quadlet はその統合を次のレベルへと押し上げます。Podman 4.4 は、CentOS Stream や Fedora など、多くの Linux ディストリビューションにすでにリリースされています。Quadlet をお試しいただき、ご感想をお聞かせください。
執筆者紹介
Daniel Walsh has worked in the computer security field for over 30 years. Dan is a Senior Distinguished Engineer at Red Hat. He joined Red Hat in August 2001. Dan leads the Red Hat Container Engineering team since August 2013, but has been working on container technology for several years.
Dan helped developed sVirt, Secure Virtualization as well as the SELinux Sandbox back in RHEL6 an early desktop container tool. Previously, Dan worked Netect/Bindview's on Vulnerability Assessment Products and at Digital Equipment Corporation working on the Athena Project, AltaVista Firewall/Tunnel (VPN) Products. Dan has a BA in Mathematics from the College of the Holy Cross and a MS in Computer Science from Worcester Polytechnic Institute.
類似検索
F5 BIG-IP Virtual Edition is now validated for Red Hat OpenShift Virtualization
More than meets the eye: Behind the scenes of Red Hat Enterprise Linux 10 (Part 4)
Can Kubernetes Help People Find Love? | Compiler
Scaling For Complexity With Container Adoption | Code Comments
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
仮想化
オンプレミスまたは複数クラウドでのワークロードに対応するエンタープライズ仮想化の将来についてご覧ください