2017.09.01

Docker Enterprise Edition 17.06の新機能 #docker

318

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は2017年8月21日「MY THREE FAVORITE NEW FEATURES IN DOCKER ENTERPRISE EDITION」を要約したものです。

Docker Enterprise Edition 17.06が発表されました。
新たな機能の中でも重要な３つを取り上げます。

1. WindowsとLinuxのノードを集中管理できるマルチアーキテクチャへの対応

DockerEE17.06（以下、17.06）では、WindowsとLinuxのノードが混在したクラスタをUniversal Control Plane(以下、UCP）で集中管理できるようになりました。これによりWindowsとLinuxのコンポーネントの組み合わせで動作するアプリケーションをUCPから統一して操作することが可能です。
例えば、LinuxのWebサーバとMicrosoft SQL Serverを用いたアプリケーションの管理がUCPから統一して行えます。
また、IBM Z systemメインフレーム上のLinuxもサポート対象に加わりました。

これらマルチアーキテクチャへの対応により、エンタープライズ・アプリケーションの動作環境としてより魅力のあるものとなりました。

2.ノードのロールベースアクセス制御（RBAC）

アクセス制御についても新しい機能が追加されています。

チームやユーザの利用可能なノードを承認されたノードに限定することにより、より詳細なコンテナの配置を計画することができるようになりました。これにより、特定のノードへのアクセスを制限することができ、機密性の高い作業を特定のノードに分離するなど複雑なコンプライアンス要件にも柔軟に対応可能です。

例えば、同じクラスタ内に異なるセキュリティゾーンを設定して、保護された情報へ特定のチームしかアクセス出来ない等の制限が設定できます。

これらに加え、以下のような権限のカスタマイズも可能になりました。

Custom Role：
クラスタの各リソースに対して実行できる操作を定義した権限のセットです。
今までと同じ定義済みの権限セット（View Only, Full Control など）に追加して、17.06では数十の詳細な権限から必要な権限を選択し、新しい権限セットを定義することが可能です。

Collections：
Collectionsは17.06で定義された新たな概念です。
"com.docker.ucp.access.label"を定義して、クラスタリソース（サービス、コンテナ、ボリューム、ネットワーク、secretsなど）をグループ化したものがCollectionsです。ディレクトリ構造のように階層化して定義することも可能で、
階層化したCollectionは親のCollectionから権限を継承できます。

これらを利用することで、付与する権限とその対象を柔軟に定義することが可能になり、エンタープライズで要求される多様なセキュリティニーズに対応することが可能になります。

例）

Dev Team は Dev Role(Custom権限)　で Dev Collection の各リソースへアクセスできる。
Dev Team は Staging Collection に Dev Collection と同様にアクセスできる（権限の継承）。
QA Team は QA Role(Custom権限) で Staging Collection のコンテナCへアクセスできる。
QA Team は view only 権限で Production Collection の各リソースへアクセスできる。
Production Team は Production Role(Custom権限) で Production Collection の各リソースへアクセスできる。

3.イミュータブルリポジトリとイメージの自動プロモート

この2つの新リリースはDockerイメージの整合性を確保するために重要な機能です。

イメージの自動プロモート：
あるDocker Trusted Registryリポジトリ(以下、DTRリポジトリ)から別のDTRリポジトリへイメージを自動的にプロモートするための定義を記述できます。
例えばイメージをプッシュした後に、脆弱性のチェックを行い問題がなかった場合にProduction用のリポジトリにプロモートするという定義を記述し、自動化することが可能です。

イミュータブルリポジトリ：
特定のDTR上のリポジトリに対して、イメージタグの変更を不可に設定することが可能です。
これによりリポジトリ内のイメージについて、更新されていないことを保証することが出来ます。

上記の2つを組み合わせると、
開発からプッシュされたイメージの脆弱性チェックを行い、問題が見つからなければProductionにプロモートするという一連のリリースの流れの自動化とProductionリポジトリのイメージの一貫性を保証できることになります。