Docker Engineサービスの管理

Docker Engineサービスの構成

様々な方法でDocker Engineランタイム・オプションを構成できます。可能な場合は、/etc/docker/daemon.jsonファイルを使用してこれらのオプションを構成することをお薦めします。この構成ファイルの形式とオプションの詳細は、https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-fileを参照してください。

ランタイム構成オプションの中にはまれに、/etc/docker/daemon.jsonに設定できる同等のオプションがないものがあります。以前は、/etc/sysconfig/docker、/etc/sysconfig/docker-networkおよび/etc/sysconfig/docker-storageの変数を編集することで、ユーザーがこれらのランタイム・オプションを設定できるようになっていました。まだこの目的でこれらのファイルを使用できますが、将来のリリースでは非推奨になる可能性があります。Docker Systemdサービス用に代替ドロップイン・ユニットを作成することをお薦めします。この場合、Docker Engineをロードするときに代替ランタイム・オプションを指定する必要があります。

たとえば、/etc/docker/daemon.jsonを作成して次のコンテンツを含めることができます。

{
  "selinux-enabled": true
}

構成ファイルの編集が終了したら、リロードして新規または変更されたユニットをスキャンします。

sudo systemctl daemon-reload

最後に、Docker Engineサービスを再起動します。

sudo systemctl restart docker

Docker Engineのリロードまたは再起動

dockerサービスの実行中にDocker Engineの構成を変更する場合、変更内容を反映するためサービス構成をリロードする必要があります。

dockerサービス構成をリロードするには、次のコマンドを入力します。

sudo systemctl daemon-reload

サービス構成をリロードしない場合、systemdは元のキャッシュされた構成を引き続き使用します。

dockerサービス自体を再起動する必要がある場合は、次のコマンドを入力します。

sudo systemctl restart docker

root以外のユーザーに対するDockerコマンドの実行の許可

注意:

Dockerコマンドを実行できるユーザーには、システムの有効なroot権限があります。この権限は信頼できるユーザーにのみ付与してください。

root以外のユーザーおよびsudoアクセス権を持つユーザーがDockerコマンドを実行できるようにするには:

dockerグループが存在しない場合は作成します。
```
sudo groupadd docker                     
```
dockerサービスを再起動します。
```
sudo systemctl restart docker
```
UNIXソケット/var/run/docker.sockは、dockerグループのメンバーによって読取りと書込みが可能になりました。
Dockerアクセス権限が必要なユーザーをdockerグループに追加します。
```
sudo usermod -a -G docker user1
```

ユーザー・ネームスペース再マッピングの構成

Dockerコンテナ内で実行されているプロセスに、ホスト・システムの代替ユーザー・ネームスペース・マッピングを使用した実行を強制するには、userns-remapオプションをDocker Engineの起動パラメータとして使用します。この機能により、ホスト・システムにセキュリティのレイヤーが追加されます。各コンテナ内で実行されているプロセスは、/etc/subuidおよび/etc/subgidで定義されている代替マッピングのUIDおよびGIDを使用して実行されます。shadow-utilsプロジェクトには、Linuxカーネル内のユーザー・ネームスペースの機能である従属ユーザー・マッピングが用意されています。詳細は、https://docs.docker.com/engine/security/userns-remap/を参照してください。

ユーザー・ネームスペース・マッピングを実装するには:

/etc/subuidファイルを作成して編集します。

Dockerのドキュメントでは、このファイルを自動的に作成して移入することを提案していますが、この機能は、usermodコマンドで使用できるコードに依存しており、現在このコードはOracle Linuxに組み込まれていません。このファイルがない場合は手動で作成し、必要なユーザー・マッピングを移入します。
```
user:start_uid:uid_count
```
デフォルトのユーザー・ネームスペース再マッピングを構成する場合は、dockremapユーザーのエントリを追加します。あるいは、この目的に使用する予定の権限のないユーザーのエントリを追加します。たとえば:
```
dockremap:100000:65536
```
前述の例では、dockremapは、再マッピングに使用される権限のないシステム・ユーザーです。100000は、コンテナ内のプロセスの実行に使用される使用可能なUIDの範囲における最初のUIDです。65536は、コンテナで使用されるUIDの最大数です。このエントリ例に基づいて、rootユーザーとしてコンテナ内で実行されているプロセスは、ホスト・システムでUID 100000を使用して実行されるように起動されます。コンテナ内のプロセスがUIDが500のユーザーとして実行されると、ホスト・システムでは、UID 100500で実行されます。
/etc/subgidファイルを作成して編集します。ユーザーIDマッピングに適用されるのと同じ原則がグループIDマッピングに適用されます。

デフォルトのユーザー・ネームスペース再マッピングを構成する場合は、dockremapグループのエントリを追加します。あるいは、この目的に使用する予定のグループのエントリを追加します。たとえば:
```
dockremap:100000:65536
```
userns-remapパラメータを有効にして実行するようにdockerサービスを構成します。/etc/docker/daemon.jsonを作成または編集します。

このファイルを最初から作成する場合、次のようになります。
```
{
  "userns-remap": "default"
}
```
userns-remapをdefaultに設定すると、Dockerによってdockremapという名前のユーザーおよびグループが自動的に作成されます。dockremapユーザーおよびグループのエントリが/etc/subuidおよび/etc/subgidに存在する必要があります。あるいは、システムにすでに存在する別の権限のないユーザーおよびグループを使用して実行されるように、userns-remapオプションを設定します。これを選択した場合は、/etc/subuidおよび/etc/subgidファイルでdockremapユーザーを適切なユーザー名およびグループ名と置き換えます。

このファイルがすでに存在し、他のエントリが含まれている場合は、一般的なJSONフォーマットに準拠してstorage-driver構成変数の行を追加するようにしてください。

この構成ファイルの形式とオプションの詳細は、https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-fileを参照してください。
Docker Engineデーモンの起動時に、--userns-remapオプションがコマンドライン・スイッチとして起動されていないことを確認します。

このオプションが/etc/sysconfig/dockerファイルに記述されていないことを確認する必要があります。このファイルは非推奨であり、今後のリリースでは削除される可能性があります。このファイルに他の構成パラメータが含まれている場合は、それらを/etc/docker/daemon.jsonに移動すれば現在の構成を将来も使用できるかどうかを検討します。

また、このオプションが/etc/systemd/system/docker.service.d/のsystemdドロップイン・ファイルに記述されていないことも確認します。これはサポートされている構成オプションですが、可能な場合はすべてのDocker Engine構成を同じ場所に保持することをお薦めします。
dockerサービスをリロードし、サービス構成の変更を反映します。
```
sudo systemctl daemon-reload                     
```
dockerサービス自体を再起動する必要がある場合は、次のコマンドを入力します。
```
sudo systemctl restart docker                     
```
Docker Engineでは、コンテナの実行者やコンテナ内でのコマンドの実行者に関係なく、同じユーザー・ネームスペース再マッピング・ルールがすべてのコンテナに適用されます。

コンテナのライブ・リストアの有効化

Dockerにはlive-restoreオプションがあり、Docker Engineデーモンが使用できなくなった場合でもコンテナの実行を維持するために使用できます。このオプションは、クラッシュ、計画停止およびアップグレードによるコンテナのダウンタイムを短縮するのに役立ちます。この機能を有効にするには、/etc/docker/daemon.jsonを編集してlive-restoreパラメータをtrueに設定する必要があります。この機能の詳細は、https://docs.docker.com/config/containers/live-restore/を参照してください。

コンテナ・レジストリ・オプションの設定

Oracle Container Runtime for Dockerには数多くの構成オプションが用意されており、Docker Engineに適用することでDockerレジストリにアクセスするコマンドの処理を制御およびカスタマイズできます。

レジストリの追加

Oracle Container Runtime for Dockerには複数のレジストリに接続できるオプションがあり、レジストリ・リストを構成してコンテナ・イメージをプルできます。デフォルトでは、追加のレジストリが定義されていない場合、Docker EngineはDocker Hubから直接イメージをプルするように構成されています。複数のレジストリを指定し、順次問合せてイメージをプルできるようにレジストリ・リストを構成できます。これを使用すると、まずローカル・レジストリからイメージをプルし、次にOracle Container Registryなどの代替レジストリにフォールバックし、最後に構成済のデフォルト・レジストリを使用するようにDocker Engineを構成できます。このためには、/etc/docker/daemon.jsonにadd-registryオプションを設定します。

...
  "add-registry": [
    "container-registry.oracle.com"
  ],
...

add-registryオプションのみを使用してこのファイルを最初から作成する場合、次のようになります。

{
  "add-registry": [
    "container-registry.oracle.com"
  ]
}

追加する1つ以上のドメインを同じリストに追加して、複数のレジストリを追加できます。

...
  "add-registry": [
    "container-registry.oracle.com",
    "registry.example.com"
  ],
...

Docker Engineサービスを再起動して変更を適用します。

sudo systemctl restart docker

レジストリのブロック

Oracle Container Runtime for Dockerには、コンテナ・イメージをプルしようとしたときに特定のレジストリにアクセスできないようにするオプションが用意されています。これを使用すると、ユーザーが特定の外部レジストリからイメージをプルできないようにすることができます。このためには、/etc/docker/daemon.jsonにblock-registryオプションを設定します。

...
  "block-registry": [
    "docker.io"
  ],
...

ブロックする1つ以上のドメインを同じ行に追加して、複数のレジストリを無効にできます。

...
  "block-registry": [
    "docker.io",
    "registry.example.com"
  ],
...

/etc/docker/daemon.jsonの編集が終了したら、Docker Engineサービスを再起動します。

sudo systemctl restart docker

デフォルト・レジストリの設定

デフォルトでは、追加のレジストリが定義されていない場合、Docker EngineはDocker Hubから直接イメージをプルするように構成されています。

/etc/docker/daemon.jsonにdefault-registryオプションを設定することで、デフォルト・レジストリを変更できます。

...
  "default-registry": "test.registry.com",
...

最後に、Docker Engineサービスを再起動します。

sudo systemctl restart docker

デフォルト・レジストリを変更すると、Docker Hubからプルされたイメージに対するDocker Engine内からのイメージ参照がdocker.io接頭辞を正しく表示するように更新されます。たとえば、nginx:latestはdocker.io/nginx:latestを反映するように更新されます。新しいデフォルト・レジストリにあるイメージは、接頭辞なしで表示されます。

デフォルト・レジストリによって、イメージの検索またはプル時にDocker Engineがチェックする最後のレジストリが決まります。add-registryオプションを使用して複数のレジストリを構成した場合、それらのレジストリは順番にチェックされ、構成した他のレジストリにイメージが見つからない場合にはデフォルト・レジストリが常に最後の選択肢として使用されます。

セキュアでないレジストリの追加

Oracle Container Runtime for Dockerには、テスト目的で自己署名証明書を使用する場合などHTTPSを使用するものの証明書の検証を行わずにコンテナを配信するレジストリを有効にしたり、HTTPのみを使用するレジストリの使用を有効にするオプションが用意されています。このためには、/etc/docker/daemon.jsonでinsecure-registryオプションを使用します。

...
  "insecure-registries" : ["insecure-registry.example.com"],
...

insecure-registryオプションを使用すると、Dockerはレジストリから提供された証明書を検証することなくレジストリへのHTTPS接続を試行できます。レジストリがHTTPS経由でアクセスできない場合、DockerはフォールバックしてHTTPを使用して接続を試行します。

Docker Engineサービスを再起動して変更を適用します。

sudo systemctl restart docker