CentOS 8 世代で Podman コンテナに SSH で入ろうとして、うまくいかなかった時のメモです。当時はコンテナも含めて Ansible で一律に扱いたいという発想でしたが、今から見ると、Podman コンテナを SSH 管理対象にすること自体を避ける方が自然です。
ストーリーで覚える Linux CLI 入門
Linux のコマンドライン操作やコンテナ環境を基礎から確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
発生したこと
root のパスワードを設定して SSH 接続しようとすると、systemd-journald 周りで次のようなエラーが出ました。
systemd-journald.service: Failed to add fd to store: Operation not permitted特権コンテナとして動かす、SELinux を緩める、systemd を前提にしたコンテナへ寄せる、といった方向に進めば回避できる可能性はあります。ただし、それはコンテナを軽量なプロセス実行環境として扱う考え方から外れやすくなります。
SSH で入る設計を避ける
コンテナは、基本的には SSH サーバーを常駐させてログインする対象ではなく、イメージ、起動コマンド、ボリューム、環境変数、ログ出力で管理する対象です。どうしても中に入って確認したい場合も、通常は SSH ではなく podman exec を使います。
podman ps
podman exec -it コンテナ名 /bin/bash
podman logs コンテナ名この考え方にすると、コンテナ内へ SSH 接続するためのユーザー、パスワード、sshd、systemd、ログイン制御を持ち込まずに済みます。
Ansible で管理したい場合
当時は、通常のサーバーもコンテナも同じように Ansible で管理したい、という発想がありました。ただ、コンテナに対しては SSH でログインして構成変更するより、Dockerfile、Containerfile、Buildah、Podman の起動定義として管理する方が筋が良いです。
- コンテナイメージは Dockerfile / Containerfile で作る。
- 設定値は環境変数や設定ファイルのマウントで渡す。
- 起動状態は systemd unit や Quadlet など、ホスト側の管理に寄せる。
- 確認は
podman logsやpodman execを使う。
このメモの結論
Podman コンテナで SSH を動かすこと自体は、条件を緩めれば不可能ではないかもしれません。しかし、サーバー管理の延長としてコンテナへ SSH する設計は、権限、SELinux、systemd、イメージ再現性の面で重くなります。
CentOS 8 世代の Podman を使うなら、コンテナを SSH 管理対象にするより、イメージと起動定義を正本にする方が運用として自然です。
