第5章 プロセス管理
プロセス管理に関する本セクションでは、以下の 2 つの状況について説明します。
- コンテナーがジョブを実行するために必要なファイルを格納する単一プロセスコンテナー
- 同時に実行される複数の異なるプロセスで設定される managed-multiprocess コンテナー
Apache は、単一プロセスコンテナーの例です。Apache は、すべて独自のロギングを行います。つまり、外部コンテナーがロギングを行う必要はありません。つまり、この場合は systemd を使用しても利点はありません。
GNOME 3 は、managed-multiprocess コンテナーの例です。この種のコンテナーを手動で管理しようとすると（例：upower と DBUS とログが連携しようとする場合など）、単に systemd が機能するようにするよりも有益です。
5.1. コンテナーでの systemd の実行
managed-multiprocess コンテナーの場合は、systemd を実装し、コンテナー内で実行中のプロセスを管理します。コンテナーで systemd を実行するには、以下のコマンドと同様のコマンドを実行します。
$ sudo docker run -it IMAGE /bin/bash
上記のコマンド(-it)は、systemd を実行しているインタラクティブな tty コンテナーを起動します。
コンテナーで systemd を実行する際の過去のコンテキストについては、Dan Walsh's May 2014 blog post on the matter: Running systemd within a Docker Container を参照してください。
5.1.1. コンテナー内の journald および systemd
コンテナーでジャーナル監査を無効にします。docker ホストのみが journald の実行を許可します。ジャーナル監査はカーネル機能であり、一度に使用できる journald のインスタンスは 1 つだけです。(docker ホストが journald を実行している場合は問題ありません。)
5.1.2. サービスおよびコンテナー
サービスは、コンテナーで追加設定なしで機能します。コンテナーでサービス のみ の作業を行います。サービスがコンテナーで機能するには、特別な設定は必要ありません。
5.1.3. コンテナー外にあるハードウェアの管理
systemd を使用して外部ハードウェアを管理するコンテナーを作成することは可能ですが、コンテナーを設定すると、コンテナーが管理に使用できるよう設定された特定のハードウェア設定を想定するため、移植できません。
5.1.4. Systemd および Zombies
systemd は、動機の問題を解決します。プロセスが停止して異常になると、init 1 はそれらを取得します。これはコンテナーの外部にあるため、コンテナー内で true に似ています。コンテナー内の systemd が、コンテナー外で異常を取り除くことを期待したように、異常な状態を取得することを想定しています。
systemd （または sysv）なしでコンテナーを起動すると、そのコンテナーで失われたプロセスは取得されません。
