第39章 Linux コンテナー

docker シンプール設定のループデバイスを設定する場合、docker の削除やコンテナー I/O 操作などの Docker 操作が遅くなる可能性があります。推奨される代替設定は、LVM シンプールを設定し、docker のストレージバックエンドとして使用することです。LVM シンプールの設定方法は、man ページの lvmthin (7) を参照してください。次に、/etc/sysconfig/docker-storage ファイルを変更して以下の行を追加し、コンテナーストレージに LVM シンプールを使用します。

DOCKER_STORAGE_OPTIONS= --storage-opt dm.thinpooldev=<pool-device>

一部のアプリケーションコンテナーがすでにアクティブな間に起動される Super-Privileged Container (SPC)は、これらのアプリケーションコンテナーのファイルシステムツリーにアクセスできます。ファイルシステムツリーはデバイスマッパーの thin ターゲットデバイスにあります。SPC はこれらのファイルシステムツリーの参照を保持するため、アプリケーションコンテナーの終了時に、docker デーモンはシンターゲットをクリーンアップできません（デバイスはビジーです）。これにより、以下のエラーメッセージが systemd のジャーナルに記録されます。

Cannot destroy container {Id}: Driver devicemapper failed to remove root filesystem {Id}: Device is Busy

{Id} はコンテナーランタイム ID のプレースホルダーで、アプリケーションコンテナーの終了後も古いデバイスマッパー thin target が残されます。

一部のアプリケーションコンテナーがすでにアクティブな間に起動される Super-Privileged Container (SPC)は、これらのアプリケーションコンテナーのファイルシステムツリーにアクセスできます。ファイルシステムツリーはデバイスマッパーの thin ターゲットデバイスにあります。SPC はこれらのファイルシステムツリーの参照を保持するため、アプリケーションコンテナーの終了時に、docker デーモンはシンターゲットをクリーンアップできません（デバイスはビジーです）。これにより、以下のエラーメッセージが systemd のジャーナルに記録されます。

Cannot destroy container {Id}: Driver devicemapper failed to remove root filesystem {Id}: Device is Busy

{Id} はコンテナーランタイム ID のプレースホルダーで、アプリケーションコンテナーの終了後も古いデバイスマッパー thin target が残されます。

docker デーモンは、Super-Privileged Container (SPC)の実行中に予期せず終了する場合があります。そのため、Super-Privileged コンテナーに関連する古いエントリーは /var/lib/docker/linkgraph.db に残され、コンテナーは後で正しく再起動できません。

GNU デバッガー(GDB)が Super-Privileged Container (SPC)内で実行し、Red Hat Enterprise Linux Atomic Host の別のコンテナーで実行されているプロセスに割り当てると、GDB は、デバッグするプロセスによって読み込まれた主な実行ファイルや共有ライブラリーのバイナリーイメージを見つけられません。その結果、GDB は、存在しないファイルに関連するエラーメッセージを表示するか、存在しないものの、GDB が正しくアタッチされたように見えることがありますが、後続のコマンドは失敗したり、破損した情報を表示する可能性があります。回避策として、以下のようにコマンドを実行する前に sysroot および file を指定します。

set sysroot /proc/PID/root					
file /proc/PID/exe			
attach PID