DockerCon Europe 2017 – Keynote Speech 解説 2/3 #docker

2017年10月16日〜19日にDockerCon EU 2017がデンマークのコペンハーゲンにて開催されました。
https://europe-2017.dockercon.com/

このブログではKeynote Speechについてどのような内容が発表されたのかを解説していきたいと思います。
内容が盛りだくさんということもあり、3回に分けて公開いたします。

初回分はこちらをご参照ください。
https://www.creationline.com/lab/19073

ーーーーーー

MTAの開発推進役の一人、Banjotが登場。

同じく、デモの実施役としてBenとKristieが登壇。ペットストアのアプリについてデモを見せていました。

ドイツのクライアントから下記の要求を受けて、これをソースコードに一切手を入れずにDockerコンテナで対応しよう、というデモ。
1）トップページのイメージをオウムからジャーマンシェパードに変更する。
2）ドイツのセキュリティ規制は、ファイルと通信の暗号化を義務付けられているためそれに対応

まずは最初のデモで作成したコンテナを複製し、DTR(Docker Trusted Registry)にプッシュする。

次に、プッシュの完了

次に、Docker Composeファイルを開き、トップページのイメージの所在を確認
image: frenchben/jpetstoreweb:1.0

このイメージを、あらかじめ準備してあるジャーマンシェパードのイメージに変更
image: frenchben/jpetstoreweb:2.0-germany

さらに、コンテナイメージを全て暗号化する事を指定する
encrypted: true

ファイルをセーブ

この新しいファイルを使って、新しいスタックを構築する。

今度はUCP (Universal Control Plane)に移り、アップデートの状況をチェック

新規のスタックに対して、そのネットワーク設定のメニューを選択する（左側）

ネットワーク設定の項目で、Encrypted Communicationsをtrueに設定する。

無事、5分でかかる課題は解決し、ライブ発信が可能になった。

これらのデモでもわかる通り、エンタープライズでのアプリケーション開発／運用には多くの変更／修正を短期間で行う必要が高く、それをセキュアに行う事も必須の条件。これらの条件を満たすためにDocker Enterprise Editionは開発されている。

エンタープライズ企業の要件に答えるためにDocker Enterprise Editionは次の4つの機能を特に強化している。
Image Management: 企業内の各部門（開発、QA、運用）で個々にコンテナのイメージを管理し、厳密なRBACによるアクセス管理を徹底
Policy Automation: CI/CDの導入により、開発／テスト／QA／リリース／運用 のプロセスにおいて、コンテナイメージの詳細管理工程の自動化をフルサポート
End to End Security: このプロセスを通して、イメージのセキュリティ、保全性をDocker EEが保証
Multi Tenancy: そして上記の機能を、オンプレミス、ベアメタル、クラウドであろうとOSがLinux, Windowsであろうと、一貫したGUIで利用できる事を保証

イメージ管理、ポリシーの自動化においては、次のようなプロセスを自動化できる。
1）開発者が開発して自分の個人のディレクトリに登録したイメージに “latest”というタグをつけておけば、自動的に開発部門全体で共有しているディレクトリにプッシュする
2）イメージスキャンの結果、特に深刻な脆弱性が無い、と判断されれば自動的にQA部門のディレクトリにプッシュする

この自動化されたプロセスにおいて、Dockerは3つのセキュリティ面での保証をする。
Signing: 全てのコンテナイメージはデジタルサインされ、CI/CDの全ての工程を通り、その過程で不必要な改ざんがされていない事を保証
Scanning: コンテナイメージに含まれるコンポーネントは全てCVEデータベースを参照して脆弱性がチェックされ、問題が発覚した場合はパッチの付与を統一的にできる。
Secrets: コンテナイメージはDTR上での管理や通信経路を通る際に暗号化され、秘密キーはDTRで一括管理される。

Docker EEはRBAC機能をサポートし、開発チーム、運用チーム、毎にリソースに対する全てのアクセス（参照、改変、削除、など）を指定する事ができる。

これらのエンタープライズ系の機能はまだまだ初期段階であり、今後も開発、特にレガシーアプリに対するモダナイゼーションに向けてのエンハンスが行われる予定。

セッションの後半は、CTOのSolomon Hykes氏の登場。
例年、二時間近くプレゼンを行い、新機能の開発、新規戦略の発表などを行う。

ITランドスケープ内のDockerの位置付けを改めて簡単な絵で整理。
Dockerは非常に多くの接点を持っており、下位にITのインフラ、それも複数のインフラをサポートし、上位には大量のアプリケーションが存在する。
また、Dockerは開発者に対するインタフェースと、運用管理者に対するインタフェースの両方をサポートする機能を要求される。

こういった多くの接点を持つDockerのデザインのコンセプトはいくつかあり、その一つは；
Independence: 独立性：特定のアプリ、特定のインフラ技術に縛られない、完全に独立した開発コンセプトに基づく事を重要視している。

もう一つ重要視しているのは、
Openness: オープン性：どんなプラットホーム（HW, OS, VM）、アプリケーション、ミドルウェアでもサポートできるためのオープン性も非常に重要。特にDockerの開発はDocker社だけではなく、コミュニティによる支援が非常に大きく、そのためにもオープン性の重要性は大きい。

3つ目の要件は、
Simplicity: シンプル性：Dockerがこれだけ短期間でユーザ層を広げられたのも、使いやすいGUI、簡単なコマンド、等の設計コンセプトを徹底した事。
コンテナのような新しいコンセプトは、初期段階においては使いやすさを最重要視する事が必須である。

この様なコンセプトに基づいて登場したDockerは、アプリケーションをインフラとの依存性から切り離し、インフラからの影響を全く受けずに、開発、運用を進められる事が一番大きな役割である。

Dockerの構造をもう少し詳しく解説すると、図にある様な構造になる。それぞれのコンポーネントは密接に関係をもって開発されている。
container: コンテナを動かすランタイムエンジン
Swarm: 複数のコンテナのオーケストレーションを行う機能
Docker Community Edition: 開発者のためのツール
Docker Enterprise Edition: 運用管理のためのツール／サービス

Dockerのもう一つの開発ポリシーは、常に改善をし続ける、という事。
Dockerからリリースされるコードは、広く世界で利用され、評価され、そして多くのフィードバックを生む。
その受けたフィードバックを元に、常に製品を改善し続ける、ということが非常に重要と考えていて、そしてそれは終わることが無い、ということも強く意識している。

去年から今年にかけて受けていたフィードバックの最も大きなものとして、オーケストレーションのレイヤーがあります。
Dockerがオーケストレーションのツールとして提供していた Swarm、このスタックに一貫して踏襲している、使いやすさ、優れたユーザエクスペリエンスを守っているが、必ずしもオーケストレーションにおいてはそれが完全に受け入れられていない、ということを認識するに至りました。

そこで、世界で最もオーケストレーション機能として広まっている、Kubernetesの採用を決意し、図に示されるように、SwarmとKubernetesの両方を標準的にサポートすることに決定しました。
このKubernetes、重要なの要件として徹底したのは、Native Supportです。オープンソースとして世に出ているKubernetesに手を入れることなく、ネイティブでサポートすることにしました。これによって、このDockerコンテナのスタックは次の特長を持つこととなりました。
1）Docker Enterprise Edition: コンテナのセキュリティ／管理機能が最も優れている運用管理ツール
2）Docker Community Edition: 最も広まっているコンテナ開発ワークフロー
3）Kubernetes+Swarm: コンテナのエコシステムの全てをサポートする、Kubernetesのネイティブサポートの追加
4）containerd: 業界標準であるコンテナランタイムエンジン

そもそも、KubernetesとDockerの関係は深く、長い歴史を共に歩んで来た経緯がある。
共にオープンソースとして生まれ、そのモデルを踏襲
どちらも大きなコミュニティに支えられて、そして成長している。
DockerコミュニティとKubernetesのコミュニティでは、重複しているメンバーが非常に多い
両方の関連イベントに参加している人も非常に多く、2つの技術の連携に対しては強い要望が昔から多かった

そのKubernetesのコミュニティの代表者でもある、マイクロソフト社の Brendan Burns氏に登壇をしてもらう。

風貌はこんな人

コンテナ技術に関しては、今後ますます利用される領域が広がる事が期待されており、特にクラウドネイティブの時代の到来とともに一つの選択肢ではなく、標準的なプラットホームとして採用される事が普通になっていく、と見られている。

Kubernetesは、そういった予測の中で生まれた技術であり、そのコミュニティはGoogleやマイクロソフトの中だけではなく、短期間で世界中に広まっていった、という実績があります。その成長においては、ヨーロッパでのコミュニティの力強い支援があった事が大きな要因であり、その点に関しては、Kubernetesを支えてくれたヨーロッパのコミュニティの皆様に強く感謝の意を示したい。

Kubernetesの考え方は、OSのいかんにかかわらず、点在しているコンテナの動きを統合的にオーケストレーションできる事であり、現在多くのユーザが存在する、macOS、Windows、そしてLinuxに対しては、等しくサポートする事が、開発当初からのデザインコンセプトにありました。

Kubernetesは、多くの標準化団体やオープンソースプロジェクトに参画しており、コンテナ技術に関してはOCI、
mobyプロジェクト、CNCF等、深く関与している。

今回のDockerのKubernetesサポートは、そういった中でごく自然に結びついたものであり、Kubernetesのコミュニティとしては大きく賛同するものであり、今後の両プロジェクトの協業の中からさらに大きく成長していく事を強く願っている。

従来のKubernetesはどの様にDockerの中に統合されていくか、というと、この図に示すとおり。
運用環境でKubernetesがオーケストレーションのツールとして使われる環境に対して、開発チームに対してはDockerから明確なソリューションが提供されていなかった。（？の部分）
そのため、この抜けている部分を埋めるべく最初のプロジェクトとして開発投資した。

今回の開発において、SwarmとKubernetesの2つの環境は統合され、SwarmもしくはKubernetesで開発されたコンテナは、運用環境において、Swarm、Kubernetesのいずれの環境においてもデプロイできる様になった。
具体的には、Swarm環境でテストされコンテナ化されたアプリは、Kubernetes上でデプロイさせる事が可能になっている。　

---

Vol.2いかがだったでしょうか？

Solomon Hykes氏が登場してきました。
最終のVol.３でもSolomon Hykes氏の発表内容について解説していきます。

より具体的なk8s対応内容についてもデモを交えて説明しています。
次回の更新をお楽しみに！

動画自体もこちらで公開されていますので、雰囲気を感じるのに動画も合わせてご覧いただくと良いかもしれません。
https://dockercon.docker.com/
＃閲覧には登録が必要となります。

特に、Solomon Hykes氏がKubernetes対応を発表したところは、聴講者の反応なども面白いので是非御覧ください。（17日分のセッション動画 1:06:40前後）