第5章 プロセス管理
このセクションではプロセス管理について扱いますが、以下の 2 つの異なるケースについて考慮します。
- 単一プロセスコンテナー: コンテナーのジョブの実行対象となるファイルを保管します。
- 管理対象の複数プロセスコンテナー: 同時に実行される複数の異種プロセスから構成されます。
Apache は単一プロセスコンテナーの一例です。Apache はすべてのジャーナリングを独自に実行します。外部コンテナーがそのジャーナリングを実行する必要はありません。つまり、この場合 systemd を使用しても意味がないことになります。
GNOME3 は管理対象の複数プロセスコンテナーの一例です。この種のコンテナーを手動で管理する試み (たとえば、upower および dbus ならびに logging を連動させること) は、単純に systemd を機能させるよりも煩雑になります。
5.1. コンテナーで systemd を実行する
管理対象の複数プロセスコンテナーの場合に、コンテナーで実行される複数のプロセスを管理するために systemd を実装します。systemd をコンテナーで実行するには、以下のコマンドと同様のコマンドを実行します。
$ sudo docker run -it --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro IMAGE /bin/bash
上記のコマンドは、systemd を実行するインタラクティブな -tty (-it) コンテナーを起動します。Docker のバージョンによっては、--privileged フラグは不要になります。
コンテナーで systemd を実行することに関する詳細な背景情報およびコンテキスト情報については、この点について論じている Dan Walsh 氏の 2014 年 5 月のブログ記事を参照してください。Running systemd within a Docker Container
5.1.1. コンテナーでの journald および systemd
コンテナー内でジャーナル監査 (journal auditing) を無効にします。docker ホストのみが journald を実行できるように許可します。ジャーナル監査はカーネル機能であり、一度にこの機能を使用できるのは 1 つの journald のインスタンスのみです。(docker ホストが journald を実行中の場合にはこの限りではありません。)
5.1.2. サービスおよびコンテナー
サービスは、コンテナーでは追加の設定なしで機能します。サービスはコンテナーでは「機能するのみ」となります。つまり、サービスをコンテナーで機能させるために特殊な設定は必要ありません。
5.1.3. コンテナー外のハードウェアの管理
外部のハードウェアを管理するために systemd を使用するコンテナーを作成することができます。ただし、コンテナーを設定すると、管理用のコンテナーを設定する際に使用した特定のハードウェアセットアップが想定されるようになるため、コンテナーの移植性はなくなります。
5.1.4. systemd およびゾンビ状態
systemd はゾンビ状態の問題を解決します。プロセスが終了し、ゾンビになる場合、init 1 はそれらのプロセスを回収 (reap) します。これはコンテナー外でもコンテナー内でも同様です。systemd がコンテナー内のゾンビプロセスを 回収 (reap) する方法は、コンテナー外にあるゾンビプロセスを回収 (reap) する方法と全く同じであることを予想できます。
systemd (または、sysv) なしにコンテナーを起動する場合、そのコンテナーで終了するプロセスの回収 (reap) が行われることはありません。
Comments