コンテナ内で systemd を実行する

私たちはコンテナ内で systemd を使用するというトピックを長い間追いかけてきました。 2014 年に遡りますが、当社のセキュリティ エンジニアであるダニエル ウォルシュは次の記事を書きました。 Dockerコンテナ内でsystemdを実行する、そして数年後、別の、と呼ばれた 非特権コンテナでの systemd の実行、その中で状況はあまり改善されていないと述べた。 特に彼は、「残念なことに、XNUMX 年経った今でも、「Docker システム」でグーグル検索すると、最初に彼の同じ古い記事が表示されます。 だから、何かを変える時が来たんだよ。」 さらに、すでに話しました Docker 開発者と systemd 開発者間の競合.

この記事では、時間の経過とともに何が変わったのか、そしてこの問題において Podman がどのように役立つのかを説明します。

コンテナ内で systemd を実行する理由は次のとおりです。

1. マルチサービスコンテナ – 多くの人は、マルチサービス アプリケーションを仮想マシンから引き出し、コンテナ内で実行したいと考えています。 もちろん、そのようなアプリケーションをマイクロサービスに分割する方が良いでしょうが、誰もがその方法をまだ知っているわけではありません。あるいは単に時間がありません。 したがって、このようなアプリケーションを、systemd によってユニット ファイルから起動されるサービスとして実行することは完全に理にかなっています。
2. Systemd ユニット ファイル – コンテナ内で実行されるほとんどのアプリケーションは、以前に仮想マシンまたは物理マシン上で実行されていたコードから構築されます。 これらのアプリケーションには、これらのアプリケーション用に作成されたユニット ファイルがあり、アプリケーションの起動方法を理解しています。 したがって、独自の init サービスをハッキングするよりも、サポートされている方法を使用してサービスを開始する方がまだ良いでしょう。
3. Systemd はプロセス マネージャーです。 他のどのツールよりも優れたサービス管理 (サービスのシャットダウン、再起動、またはゾンビ プロセスの強制終了) を行います。

とはいえ、systemd をコンテナーで実行しない理由はたくさんあります。 主なものは、systemd/journald がコンテナーや次のようなツールの出力を制御することです。 Kubernetes または OpenShift コンテナがログを stdout と stderr に直接書き込むことが期待されます。 したがって、上記のようなオーケストレーション ツールを通じてコン​​テナーを管理する場合は、systemd ベースのコンテナーの使用を真剣に検討する必要があります。 さらに、Docker および Moby の開発者は、コンテナーでの systemd の使用に強く反対することがよくあります。

ポッドマンの到来

ようやく状況が前進したことをご報告できることを嬉しく思います。 Red Hat でコンテナの実行を担当するチームは、 独自のコンテナエンジン。 彼には名前がありました ポッドマン Docker と同じコマンド ライン インターフェイス (CLI) を提供します。 また、ほぼすべての Docker コマンドを Podman で同じように使用できます。 私たちはよくセミナーを開催します。 Docker を Podman に変更するそして、一番最初のスライドでは、エイリアス docker=podman を記述する必要があります。

多くの人がそうします。

Podman と私は決して systemd ベースのコンテナーに反対しているわけではありません。 結局のところ、Systemd は最も一般的に使用されている Linux init サブシステムであり、これをコンテナー内で適切に動作させることは、何千人もの人々がコンテナーを実行することに慣れていることを無視することを意味します。

Podman は、コンテナ内で systemd を適切に動作させるために何をすべきかを知っています。 /run や /tmp に tmpfs をマウントするなどが必要です。 彼女は「コンテナ化された」環境を有効にすることを好み、cgroup ディレクトリの自分の部分と /var/log/journald フォルダへの書き込み権限を期待しています。

最初のコマンドが init または systemd であるコンテナを起動すると、Podman は systemd が問題なく起動するように tmpfs と Cgroups を自動的に構成します。 この自動起動モードをブロックするには、--systemd=false オプションを使用します。 Podman は、systemd または init コマンドを実行する必要があると判断した場合にのみ systemd モードを使用することに注意してください。

以下はマニュアルからの抜粋です。

マン・ポッドマン・ラン
...

–systemd=true|false

systemd モードでコンテナを実行します。 デフォルトで有効になっています。

コンテナ内で systemd または init コマンドを実行すると、Podman は次のディレクトリに tmpfs マウント ポイントを構成します。

/run、/run/lock、/tmp、/sys/fs/cgroup/systemd、/var/lib/journal

また、デフォルトの停止信号は SIGRTMIN+3 になります。

これらすべてにより、systemd を変更せずに閉じたコンテナー内で実行できるようになります。

注: systemd は cgroup ファイルシステムへの書き込みを試みます。 ただし、SELinux はデフォルトでコンテナーがこれを行うことを禁止します。 書き込みを有効にするには、container_manage_cgroup ブール値パラメーターを有効にします。

setsebool -Pcontainer_manage_cgroup true

次に、Podman を使用してコンテナー内で systemd を実行する場合の Dockerfile がどのように見えるかを見てみましょう。

# cat Dockerfile

FROM fedora

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

EXPOSE 80

CMD [ "/sbin/init" ]

それだけです。

次に、コンテナを組み立てます。

# podman build -t systemd .

SELinux に systemd による Cgroups 設定の変更を許可するように指示します。

# setsebool -P container_manage_cgroup true

ところで、この手順を忘れている人が多いです。 幸いなことに、これを行う必要があるのは XNUMX 回だけであり、設定はシステムの再起動後に保存されます。

ここで、コンテナを起動するだけです。

# podman run -ti -p 80:80 systemd

systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)

Detected virtualization container-other.

Detected architecture x86-64.

Welcome to Fedora 29 (Container Image)!

Set hostname to <1b51b684bc99>.

Failed to install release agent, ignoring: Read-only file system

File /usr/lib/systemd/system/systemd-journald.service:26 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.

Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)

[  OK ] Listening on initctl Compatibility Named Pipe.

[  OK ] Listening on Journal Socket (/dev/log).

[  OK ] Started Forward Password Requests to Wall Directory Watch.

[  OK ] Started Dispatch Password Requests to Console Directory Watch.

[  OK ] Reached target Slices.

…

[  OK ] Started The Apache HTTP Server.

以上で、サービスが起動して実行されます。

$ curl localhost

<html  xml_lang="en" lang="en">

…

</html>

注: Docker ではこれを試さないでください。 このような種類のコンテナをデーモン経由で起動するには、やはりタンバリンで踊る必要があります。 (これをすべて Docker でシームレスに機能させるには、追加のフィールドとパッケージが必要になります。そうでない場合は、特権コンテナーで実行する必要があります。詳細については、を参照してください。 статье.)

Podman と systemd に関するその他の優れた点

systemd ユニット ファイルでは Podman が Docker よりもうまく動作します

システムの起動時にコンテナを開始する必要がある場合は、適切な Podman コマンドを systemd ユニット ファイルに挿入するだけで、サービスが開始され監視されます。 Podman は標準の fork-exec モデルを使用します。 言い換えれば、コンテナプロセスは Podman プロセスの子であるため、systemd はそれらを簡単に監視できます。

Docker はクライアント/サーバー モデルを使用しており、Docker CLI コマンドをユニット ファイルに直接配置することもできます。 ただし、Docker クライアントが Docker デーモンに接続すると、それ (クライアント) は、stdin と stdout を処理する単なる別のプロセスになります。 一方、systemd は、Docker クライアントと、Docker デーモンの制御下で実行されるコンテナとの間の接続についてまったく知りません。したがって、このモデル内では、systemd は基本的にサービスを監視できません。

ソケット経由で systemd をアクティブ化する

Podman はソケット経由でアクティベーションを正しく処理します。 Podman は fork-exec モデルを使用するため、ソケットを子コンテナ プロセスに転送できます。 Docker はクライアント/サーバー モデルを使用しているため、これを行うことはできません。

Podman がリモート クライアントとコンテナーとの通信に使用する varlink サービスは、実際にはソケット経由でアクティブ化されます。 Node.js で記述され、コックピット プロジェクトの一部である Cockpit-podman パッケージを使用すると、Web インターフェイスを通じて Podman コンテナーと対話できるようになります。 Cockpit-podman を実行している Web デーモンは、systemd がリッスンする varlink ソケットにメッセージを送信します。 次に、Systemd は Podman プログラムをアクティブにしてメッセージを受信し、コンテナーの管理を開始します。 ソケット経由で systemd をアクティブ化すると、リモート API を実装するときにデーモンを常に実行する必要がなくなります。

さらに、podman-remote と呼ばれる別の Podman クライアントを開発中です。これは同じ Podman CLI を実装しますが、コンテナを実行するために varlink を呼び出します。 Podman-remote は SSH セッション上で実行できるため、さまざまなマシン上のコンテナと安全に対話できます。 将来的には、podman-remote が Linux とともに MacOS および Windows をサポートできるようにする予定です。これにより、これらのプラットフォーム上の開発者は、Podman varlink が実行されている Linux 仮想マシンを実行し、ローカル マシン上でコンテナが実行されているという完全なエクスペリエンスを得ることができます。

SD_NOTIFY

Systemd を使用すると、必要なコンテナ化されたサービスが開始されるまで、補助サービスの起動を延期できます。 Podman は SD_NOTIFY ソケットをコンテナー化されたサービスに転送して、サービスが systemd に操作の準備ができたことを通知できるようにします。 また、クライアント/サーバー モデルを使用する Docker ではこれを行うことができません。

計画では

コマンド podman generated systemd CONTAINERID を追加する予定です。これは、指定された特定のコンテナーを管理するための systemd ユニット ファイルを生成します。 これは、特権のないコンテナのルート モードとルートレス モードの両方で機能するはずです。 OCI 互換の systemd-nspawn ランタイムを求めるリクエストもありました。

まとめ

コンテナ内で systemd を実行する必要があるのは理解できます。 そして Podman のおかげで、systemd と競合せずに使いやすいコンテナ ランタイムがついに完成しました。

出所： habr.com