DockerCon Europe 2017 – Keynote Speech 解説 3/3 #docker
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
2017年10月16日〜19日にDockerCon EU 2017がデンマークのコペンハーゲンにて開催されました。
https://europe-2017.dockercon.com/
このブログではKeynote Speechについてどのような内容が発表されたのかを解説していきたいと思います。
内容が盛りだくさんということもあり、3回に分けて公開いたします。
初回分
https://www.creationline.com/lab/19073
2回目分
https://www.creationline.com/lab/docker/19146
はこちらをご参照ください。
実際に、そのSwarmとKubernetesの混在環境でのデモを見せるために、Dockerのエンジニアである、David Gageoit氏が登壇しました。
Docker Swarmを使って、アプリケーションスタックを登録するプロセスをまず紹介。
画面に示される様に、Composeによって構成されている、3 Tierのアプリケーションの構造が示されている。
Webサーバ：docker demos/lab-web
アプリサーバ：docker demos/lab-words ←言葉をランダムに選択し、表示するアプリ
DBサーバ： docker demos/lab-db
まずはDockerイメージをビルドするコマンド。
今度は、ビルドしたComposeファイルをスタックとしてデプロイする。
docker stack deploy demo -c docker-compose/yml
スタックが無事作られて、スタックのリスト、demoスタック内のタスクのリストを表示する。
docker stack ls
docker stack ps demo
データベースサーバの中のログをのぞく。
これが実際に動いているアプリ。
それぞれのブロックにランダムにワードを挿入して、文章を作る単純なもの。
今度は、Kubernetesに移って、まずはNodeのリストを取得。
NodeはKubernetesにおいては、Worker Machineのことを指し、元はMinionと呼ばれていたもので、KubeleteとContainer Runtimeを保有する。
今度は、クラスターで稼働しているリソースを全て表示する。
kubectl get all
先ほど、Swarmでビルドしたアプリケーションのコンポーネントがある事がわかる。
アプリのリソースがSwarm、Kubernetesの両方から見えている。
さらにスタックのリストを探すと、Swarmで構築したスタックがkubectlコマンドでも表示可能。
kubectl get stacks -o name
整理すると、今回の開発で、Swarm／Kubernetes の両方で構築したスタックをそれぞれ参照し、運用管理する事ができる。
また、これらは、WindowsとほとんどのLinuxに対して全てサポートされることも保証。
今度は、コンテナのライフサイクルサポートの機能を見せるために、Universal Control Plane を通してSwarm/Kubernetes の両方から管理するデモを見せるため、この2名が登壇。
まずはDocker EEにログイン
UCP (Universal Control Plane）を表示。
ダッシュボード上に、ノードの稼働状況が表示されるが、注目は、左側のメニューと右側のメニュー。SwarmとKubernetesの両方のそれぞれ管理下のサービスやPodの状況が表示されている。
左側のUser Managementのメニューを見ると、DockerのRBAC機能によるグループやユーザ管理の状況を表示／管理できる。これらの管理はSwarm/Kubernetesに共通して適用できる事がポイント。
左側のSwarmのメニューを見ると、Swarm管理下に置かれているリソースの状況を見る事ができる。
同じ画面から、今度は Kubernetes 管理下のコンポーネントの状況を見る事ができる。
さらに興味深いのは、Shared Resources と呼ばる新しい機能で、SwarmとKubernetesの両方で管理されているリソースの状況も見る事ができる。
合計6つのノードが稼働していて、それぞれの稼働状況を見ると、画面中心に表示される。
ここで稼働している6つのワークロードはSwarm/Kubernetesの両方から管理ができる。
今度は、Docker Trusted Registry を開く。
前段のデモで使用されたランダムに文字を表示するアプリのリソースがリストアップされている。
そのリソースの中で、開発チームのリソースの一つである、アプリのウェブサーバのコンテナイメージの詳細を表示する。
このイメージのポリシーの編集を行うためのページを表示。
このページを通して、開発チームのイメージにおいて、脆弱性が見つからなかった際に、自動的にプロダクションレポジトリに昇格する新規ポリシーの設定を行う。
まずは、昇格の条件を設定。
Critical Vulnerabilitiesがゼロ、であることを条件として設定する。
そのあと、その条件に合致した場合に、昇格するレポジトリ先の指定を行う
dockerdemos/lab-web-prod
また、同時にタグネームを付与することにより判別できる様にする。
tag name on target = %n
さて、実際にこのイメージをビルドするコマンドを投入
docker build -t dtr1.dockercon-demo.com/dockerdemos/lab-web-dev
ビルドが無事終了。
さらに出来上がったビルドをDTRにプッシュ
docker push dtr1/dockercon-demo.com/dockerdemos/lab-web-dev
こちらも無事終了。
実際にプッシュされたイメージをDTRで見ると、どうも脆弱性がいくつか発見されている事が表示されている。
プッシュと同時に脆弱性チェックが行われる。
実際にDockerファイルを見ると、Alpine Linuxのバージョン番号が古い事が発覚。
このバージョン3.2には既知の脆弱性があり、それをDockerが指摘していることになる。
このバージョン番号を、3.2から3.6に変更し、問題を回避
改めてビルド作業を行う。
また、改めてプッシュを行う。
無事、脆弱性のチェックが通り、さらに先ほど設定した自動的にプロダクションチームのレポジトリへの昇格も行われている事がわかる。表示されているのは、プロダクションチームのレポジトリ（lab-web-prod）。
これで、脆弱性を開発側でチェックした上でプロダクションのレポジトリにイメージを届ける自動化プロセスができることになる。
Docker EEがソフトウェアサプライチェーンと呼ばれる所以はこういう機能によるものである。
イメージがプロダクション側に無事渡ったところで、次は、このアプリをデプロイするステップに入る。
Shared Resourceとしてイメージが登録されているので、そこからスタックを作成する。
Create Stackのコマンドを選択する。
スタックを作る際に、
・Swarm Services
・Basic Container
・Kubernetes Workload
の3つから選択する事が可能。
スタックの名前は、Wordsapp とする。
ModeはKubernetes Workloadを選択する
Name SpaceはDefaultを選択する。
このあと、.yml のComposeファイルをアップロードする。
Composeファイルを見ると、プロダクション側のものを採用している事がわかる。
image: dtr1.dockercon-demo.com/dockerdemos/lab-web-prod
また、レプリカも図には5台と設定されているが、可用性を増すために、11台に増やす。
これで、スタックはKubernetes Workloadとしてデプロイされてる事が示されている。
実際にKubernetesで動いているかどうかを確認するために、Kubernetesのメニューに行き、Load Balancersを選択すると、画面の右側に新しくデプロイされたアプリのURLが見える。
URL: http://ucp1.dockercon-demo.co:32075
最初はDocker Swarmでデプロイされたアプリが、簡単な操作でKubernetesのワークロードとして動かす事ができる。
Kubernetesをベアでサポートしているため、Kubernetes上で提供される様々なツールも標準的にDockerでもサポートされる事が保証されている。
上記の様に、Swarm/Kubernetes 両方のコマンドで同じノード群を参照する事ができる。
ここで、Kubernetesで提供されるバックアップツールを使って、バックアップ処理を行うデモ。
backup.yml ファイルを探して、表示する。
見た所、標準的なKubernetesバッチジョブのようで、指定されているイメージに一回コンテナをデプロイをする処理が指定されている。
実際にそのコマンドをKubernetesで実行してみる。
kubectl create -f backup.yml
ダッシュボードで実際にこのバックアップが構築されたかどうか確認して見ると、画面にあるとおり、無事作られている事がわかる。
Docker EEでは、DockerとKubernetes両方のコマンドラインツールを使う事が可能であることと、ComposeとKubernetes の.ymlファイルを並列で使える事が示される。
整理すると、次の事ができる。
Docker EE を利用して、SwarmとKubernetesが同じクラスターと暗号化IDを共有する事ができる。
SwarmとKubernetes両方のワークロードに対して、セキュアなソフトウェアサプライチェーンを構築
Docker Composeファイルを、Kubernetesの上でデプロイする事ができる。
KubernetesエコシステムのツールをDocker EEの上で使う事ができる。
今回のKubernetesの統合のポイントは、開発側、運用側の両方でも問題なく利用できる様にする事。
これを実現するのに、かなりKubernetesのコミュニティとは密接に開発を行ってきた。
また、これを実現できたのも、オープンソースである、Moby Project をベースに全ての開発が行われているから。
Moby Projectは分解すると、複数のプロジェクトによって構成されており、Kubernetesの統合もこれらの複数のプロジェクトを組み合わせて、一年くらいの開発期間をかけて行われたもの。
例えば、containerd を一つ取ると、最初の1.0の開発はKubeConにおいて、Kubernetesメインテイナー数名がスタートしている。
この当時から、containerd はKubernetesにとって最適化されたコンテナランタイムエンジンとしての設計思想が込められている。
Dockerのネットワークも同様であり、SwarmのlibnetworkとKubernetesの CNI はお互い互換性がなかったが、コミュニティの支援を通して、今では相互互換を提供できる様になっている。
セキュリティの機能も同様：SwarmとKubernetesはそれぞれ別のセキュリティ機能がそれぞれ提供されているが、秘密キー管理、暗号化ノードID、等は実際には舞台裏では両者が協業して開発していた、という背景がある。
これらの背景があってこそ、今回の発表の主軸である、moby projectとKuberbetes、という世界で最も大きいコンテナのコミュニティが協業する必然性がある。
次に登壇したのは、Google社のTim Hockin氏。Kubernetesのリードメインテイナーの一人。
Kubernetesのコミュニティにとっては Dockerの参画は何も目新しい話ではなく、今まで一緒にコンテナのコミュニティを一緒に作り上げてきたエンジニア同士が改めて一つの目的に向けて動き出した、という事。
また、念を推したいのは、今回の発表で提供されているKubernetesは、特別な開発を施したフォークアウトバージョンではなく、Kubernetesのオリジナルのコードそのものであり、KubernetesのExtension Features（拡張機能）の上でSwarmが実装されているものである。
今回の発表はまだ協業の始まりであり、これからさらに両チームはさらなる開発を続ける予定。
一方、両社の元々のコンテナ技術に対するコンセプトは元来違っていて、その違いが両社の違いを表面化させる状況も過去にあった。
Docker: 使いやすさとシンプル性を重要視
Google: 10年来のコンテナ技術の経験
この違いは、Solomon氏のGoogleに対する提案で両社が協業して埋める方向に向けられることになり、具体的には、containerd を、Swarm/Kubernetesの両方をサポートするランタイムエンジンとして再開発しよう、という事を決めた。当時、Kubernetesコミュニティは、Container Runtime Interface という、コンテナのランタイムと上位のオーケストレータの間の機能を開発していたが、今年一年かけて、containerd の上で動くContainer Runtime Interface を開発してきた。現在アルファで、年内にベータリリースができる予定。
もう一つ重要な要件は、containerd に対するガバナンスモデルを大きく変え、Docker中心で開発していく形から、OCIとCNCFに公開した事である。これにより、広くコミュニティで開発が進められる様になってきている。
最近両チームが取り組んでいるプロジェクト
・CSI (Container Storage Interface) という、共通のストレージのためのAPIの開発
・CNI (Container Network Interface) に対してDockerのコンテナネットワークアーキテクチャを採用
・CNCFに対して、containerdのみならず、Notaryも提供する
このプロジェクトに対するContributorのリスト。
日本人も含まれている事に注目！
このKubernetes／Dockerの統合プラットホームの提供は来年の、Q1/2018 に出荷を開始する予定。
先立って、ベータ版の提供は早々に行われる予定で、上記のサイトに対して申し込みをすれば手に入れる事ができる、とのこと。
Keynote 解説最終回のVol.3いかがだったでしょうか？
Kubernetes対応については、かなり時間を費やし対応してきたのがデモを通じて伝わってきました。
また注目のこのプロジェクトのContributorの一人に日本人がいることにも注目してください。素晴らしいですね。
今後、日本からもこのようなビッグプロジェクトに参画できるエンジニアが多く輩出されることを弊社としても強く望んでおります。
＃弊社からもひとりでも多くのエンジニアを輩出できるようにがんばりたいと思います^^
動画自体もこちらで公開されていますので、雰囲気を感じるのに動画も合わせてご覧いただくと良いかもしれません。
https://dockercon.docker.com/
＃閲覧には登録が必要となります。
この記事を御覧いただき興味を持たれた方は、是非次回のDockerConにご参加ください。
会場でお会いしましょう！
