Docker 1.13のリリースで、CLIを改善、SwarmモードのComposeファイルをサポート、Secrets APIを提供

Docker Incは、オープンソースのDockerコンテナエンジンプロジェクトのバージョン1.13をリリースした。このリリースには、Docker CLIの大幅な再構成、ディスクスペースを再利用するための‘clean-up’コマンドの導入が含まれる。また、イメージレイヤスカッシングや、ログ機能を改善するためのPrometheusスタイルのエンドポイントの追加など、いくつかの‘experimental’な機能も含まれている。Docker 1.13のリリースに加えて、それをサポートするツール一式を新たにリリースした。ツールには、Docker Compose 1.10、Docker Machine 0.9.0、Notary 0.4.3がある。これらのリリースはすべて、Docker for MacとDocker for Windowsのバンドルダウンロードに含まれる。

Docker CLIでは'container'や'image'などの管理オブジェクトに関して大幅な再構成があったが、今回のリリースでも、既存の1.13以前のコマンドを使用できる。Dockerブログでは、Docker 1.12に含まれている‘run’、‘build’、‘images’などの40以上のコマンドによって、ヘルプページは雑然としており、tab補完が困難となっていたことが述べられている。Docker 1.13では、すべてのコマンドを、管理オブジェクトと連携する論理オブジェクトと対応付けるため、再グループ化している。例えば、コンテナの‘run’と‘stop’は‘docker container’管理コマンドのサブコマンドとなり、imagesの‘build’と‘history’は‘docker image’コマンドのサブコマンドとなる。Docker CaptainのArun Gupta氏は、既存のコマンドから新しい管理コマンドへのマッピングを包括的に示したブログ記事を公開した。管理コマンドの例を以下に示す。

$ docker container run hello-world

$ docker image ls

$ docker image rm hello-world --force

Docker 1.13にはいくつかの‘clean-up’コマンドが導入されている。例えば、‘docker system df’は使用済みのディスク容量を表示し、‘docker system prune’は未使用のデータをすべて削除する（削除前にユーザに確認を促す）。system pruneからクリーニングできるデータは、停止している全てのコンテナ、どのコンテナからも使用されていない全てのボリュームとネットワーク、タグ付けされていない全てのイメージである。pruneを使用して特定のデータを削除することもできる。例えば、‘docker volume prune’と‘docker image prune’は、それぞれ、未使用のボリュームとタグ付けされていないイメージを対象としている。

1.13リリースではDockerデーモンに‘experimental’フラグが追加され、そのフラグによって、Dockerの安定版に含まれる実験的機能を有効化できる。experimentalフラグは、Docker for MacとDocker for Windowsの現在のダウンロードでは、デフォルトで有効になっている。一方、スタンドアロンのバイナリダウンロードでは有効になっていない。したがって、開発者とオペレータは、開発環境および本番環境の設定で、どの機能が有効になっているかを確実に把握する必要がある。

Docker 1.13の新しい実験的機能には‘docker build’ ‘--squash’フラグがある。このフラグによって、ビルドによって生成されたすべてのファイルシステムレイヤを新しい1つのレイヤに折りたたむことができる。Dockerブログによると、最小構成のコンテナイメージを作成するプロセスは簡略化できるが、複数のイメージを移動させるときにオーバーヘッドが若干高くなることがある（折りたたまれたレイヤをイメージ間で共有することができなくなったため）。Dockerは個々のレイヤをキャッシュして、その後のビルドを高速化する。Docker 1.13は、‘--compress’フラグを使ってCLIからデーモンに送られるビルドコンテキストを圧縮する機能もサポートする。圧縮により、送信されるデータ量が低減され、リモートデーモンでのビルドが高速化されるであろう。

Docker 1.13では、実験的なPrometheusスタイルのエンドポイントも追加され、コンテナ、イメージ、他のデーモン統計情報に関する基本的なメトリクスが提供される。‘docker service logs’は実験的なコマンドであり、サービスのデバッグをこれまでよりもシンプルにするための試みである。特定のサービスを実行するホストとコンテナを追跡し、それらのコンテナからログを取得する代わりに、‘docker service logs’は、サービスを実行する全てのコンテナからログを取得し、オペレータのコンソールに出力する。

Docker 1.13では、‘docker stack deploy’コマンドにComposeファイルのサポートを追加している。‘docker-compose.yml’ファイルを使って、サービスを組み込みDocker Swarm Modeクラスタに直接デプロイすることができる。この機能追加で、Docker ComposeスタックをDocker Swarmモードに展開するときの、これまであった制限を克服している。これまでは、ComposeファイルをDistributed Application Bundles(DAB) ファイルにバンドルしなければならないという制限があった。また、DABファイルはボリュームのマウントのようなDocker Compose操作のすべてを完全にサポートしていなかった。（Docker Swarm Modeを別物であるDocker Swarm製品と混同しないように注意していただきたい。(別物であるほうの)Docker Swarm製品は、Docker Compose v2のシンタックスと互換性があるが、コンテナの実行中に、組み込みのDocker Engine Swarm Mode機能を使用しない。）

Docker Compose 1.10ではComposeシンタックスのバージョン3を導入した。バージョン3では、‘volume_driver’、‘volumes_from’、‘cpu_shares’などのさまざまなプロパティを削除し、‘deploy’プロパティを追加している。削除されたプロパティに関連付けられている操作は全て、他のプロパティを通して引き続き使える。また、以前のバージョンのComposeから移行するオペレータは、アップグレードガイドを参照する必要がある。サービスデプロイプロパティによって、コンテナレプリケーションファクタ、アップデートポリシー（ローリングアップグレード）、配置制約、リソース設定（既存のcpu-quota、cpu-shares、cpuset-cpusの代わりに新しい単純な'cpus'リソース制約を使うことができる）の仕様を利用できるようになる。

デプロイプロパティは‘docker stack deploy’でSwarm Modeクラスタに配備するときにのみ有効となる（‘docker-compose up’と‘docker-compose run’では無視される）。v3のシンタックスを含む'docker-compose.yml'ファイルの例を以下に示す。

version: "3"
services:
  web:
    image: web
    labels:
      com.example.description: "This label will appear on all containers for the web service"
    deploy:
      labels:
        com.example.description: "This label will appear on the web service"
      resources:
        limits:
          cpus: '0.001'
          memory: 50M
        reservations:
          cpus: '0.0001'
          memory: 20M
      mode: replicated
      replicas: 6
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.role == manager
          - engine.labels.operatingsystem == ubuntu 14.04

このリリースに含まれる最新バージョンのDocker Swarm Modeには、Swarmkit内に新しいSecret APIのサポートが追加されている。また、Swarm Modeクラスタ内の機密情報を管理するためのコマンドが追加されている。この機能は、Kubernetes Secretsやプラットフォームに依存しないHashiCorp Vaultオープンソース製品に似ている。関連するSecrets API GitHubのissueでは、バッキングストアがSwarmであり、また、SwarmはLinux専用であるため、この機能はSwarm Modeでのみ現在利用であることが述べられている。このリリースは、Dockerで将来、機密情報をサポートする上での基礎となるであろう。そして、Windowsのサポートや異なるバッキングストア対応などの改善がなされる可能性がある。

DockerシークレットはSwarmサービスでのみ利用でき、スタンドアロンコンテナでは利用できない。ただし、コンテナはSwarm内のスケール1のサービスとして実行するよう指定することができる。シークレット機能がどのように実装されているか、および関連する注意事項についての詳細な説明については、ドキュメントを入念に読み込む必要がある。

1.13リリースで他に注目すべきことは、Docker for AWSとDocker for Azureがpublic betaからready for productionになった発表である。DockerのマネージドPlugin APIはもうexperimentalではない。ただし、APIはDocker 1.12で導入されたバージョンと比べて大幅に変更されており、プラグインをDocker 1.13にアップグレードする前に'docker plugin rm'コマンドを使ってアンインストールする必要がある。‘MAINTAINER’ Dockerfileステートメントは非推奨となり、代わりに‘LABEL’を使用することが推奨されている。

さらに、Docker 1.13は、SELinux（Security Enhanced Linux）やAppArmorなど、Linuxの強制アクセス制御技術のアップデートも含んでいる。ただし、比較的目立つバグがopenのままになっている。例えば、Unixソケットを共有するためのサポートの追加や、マウントされたボリュームへのファイルアクセスが非常に遅い（これはサードパーティツールのdocker-syncで緩和することができるが）などである。

Docker 1.13のリリースに関する追加情報はDockerブログにあり、1.13リリースノートはDocker GitHubリポジトリにある。Docker 1.13バイナリと、‘for Mac’と‘for Windows’のバンドルはそれぞれ、DockerのWebサイトからダウンロードできる。

*訳注1：読者様から、これらはDocker for Mac固有のバグであり、Docker自体のものではないとのコメントをいただいています