DockerCon 2015 現地レポート（その4） #docker

2015年6月22日から23日まで実施されたDockerCon 2015 の現地レポートpart4です。

DockerCon 2015 現地レポート（その1）
DockerCon 2015 現地レポート（その2）
DockerCon 2015 現地レポート（その3）

------

Scott Johnson : SVP of product management

Docker in Productionのニーズ
プロダクション環境でDockerを利用するために最も必要な機能は？
これを広く顧客数千人にヒアリングした。
この中で特にエンタプライズ企業や特定の業界で規制の厳しい業界、セキュリティ要件でのニーズが強い

 

Open Source Registryのダウンロード
DockerのGitHubでも最もダウンロードの多いのはOpen Source Registry

 

Docker Trusted Registryの発表
オンプレミスでのDockerレジストリ機能のニーズに対応

キーとなる機能は顧客要望を反映
On premise registryでファイウォールの後ろにレジストリを設定
既存の認証システム（IDAP/Active Directory）との接続
アクセス管理の徹底（RBAC）
コンプラインスに対応すべく、ログ管理機能をサポート
使いやすさ：ワンクリックで実装／アップデートできる機能

 

GUI画面
GUIも非常に使いやすく設計している。

 

800社以上の利用者
昨年12月DockerCon Europeでα版を発表しているけど、その際には非常に限定されたユーザへ提供するのみ。
さらにプライベートβを32015年2月に提供開始4月にEarly Access Programを開始：800+ participants to the beta program
非常に広い分野の顧客での利用：Capital One, Disney, General Electric等が主要顧客

 

Docker Trusted Registryの主要顧客の紹介
Docker Trusted Registry顧客第一号：General Services Administration：米国連邦政府調達局
最初は開発テスト環境だけでの利用だったが、早い段階でプロダクションに推移
Dockerのような170名足らずのスタートアップにとっては、珍しい大規模な顧客
年間で$10億ドルの購買を米国政府のために行っている
Booz Allen HamiltonがSIを行っている

 

Booz Allen HamiltonにてSIを実施した責任者のプレゼン
Senior Lead Technologist, Strategic Innovation Group, Booz Allen Hamilton

 

今までのGSAでのアプリケーションの構造
巨大な一元化されたアプリケーションが複数存在する
このシステムで年間$10億ドルの調達を管理している
サービスは多重化している。
システムを見ると、50％~60%のコンポーネントはシステムを運用するためのもので、アプリケーションに対しては価値を提供しているわけではない、という事に気づいた

 

プラットホームの統合
このシステム部分のプラットホームをまずは統合し、アプリケーションに共通なものとして提供するインフラに変えた
重複している部分を統合する事により削減した。
各アプリケーションのビジネスロジックを重視した。
Dockerを使って、この共通基盤の上で稼働するアプリケーションをすべて移行した。
非常に簡単にオープンソースを導入する事ができた（Open Software Firstのポリシーを実現できる）

プロダクションシステムのフロー
オンプレミスにあるGitHub Enterpriseに対してGit Pushを行う
ここからJenkinsがDocker Imageを作成し、オンプレミスにあるDocker Trusted Registryに登録
AWS上にあるDocker Swarmクラスタに対してDocker Trusted Registry上のコンテナをPullする
Dockerのエンジニアの開発したInterlockというロードバランサツールを使って、Swarm上にPullされたコンテナを検知し、自動的にクラスタ上に配置する
図がデモプログラムのフローを示している。

 

 

GitHub Enterprise画面
GitHub EntepriseからアプリをPullする

 

GitHub Enterprise画面
Pull Requestを発行

 

Jenkins上にビルドを作成（赤い部分）、次のステップが自動化
ビルド作成、必要なテスト工程をすべて通る
Swarmの接続
Docker Imageの生成
オンプレミスのDocker Trusted RegistryにPush Up
LDAP認証を行っているので、Push UpはJenkinsでしかできないように設定
現在プロダクションで稼働しているコンテナをサーチし、この新しいビルドをデプロイする

 

メリット
IAM、負荷分散、等、アプリケーションと直接関係ないコンポーネントの設定／管理を大幅に短縮、顧客向けのビジネスロジックの開発に集中できる。
上記の作業が削減されるので早くアプリを世に出す事ができる
当然コストも下がる
2週間のスプリント開発を実現できる：CI/CD工程がほとんど自動化される事が大きなポイント
セキュリティ面でもメリット：監査に向けたセキュリティレビューが非常に簡単になった
Docker Notaryを使う事によって、Docker ImageにすべてDigital Signatureを徹底
頻繁に変更のある開発アプリを部門間でも共通に管理
大幅なコストの削減

 

次のステップ
Square.comの開発しているKeywhiz、というSecret管理ツールを導入（TLS証明書、GPG Keyring、非対称キー、DB認証キー、APIトークン、SSHキー等）
コンテナネットワークへのエンハンス
Interlockへのさらなるエンハンス
プロダクションは7月にスタートを予定

 

Scott Johnson : SVP of product managementが再度登場
もう一つDockerユーザからの強い要望としてあげられていた、「サポート」について、今度は説明する

 

現在のユーザの多くは、次の構成で利用している。
Docker Engineを搭載したマシンのクラスタ（今日からrunCと呼ぶ）
Dockerコンテナを統合管理するイメージレジストリ
Docker Trusted Registry: 企業内のプライベートレジストリ
Docker Hub Registry: パブリックに公開されているコンテナレジストリ

 

Dockerはこのすべてのコンポーネントをコマーシャルサポートする事を発表。
価格体系は次の通り：
3つのコンポーネントを筆とのサブスクリプションとして提供
価格は、Docker Engineの数と、サポートレベルによって決められる。==> ちなみに、10 Docker Engines = $150/month
現時点では、次の3カ所から販売：
AWS Marketplace
Microsoft Azure
IBM

 

Windows上でのDockerのデモ
Windowsの市場は、Linuxの市場より大きいものであり、Dockerコンテナ技術をWindows上にも搭載する事はMicrosoftにとっても非常に重要な目標であった。

 

 

昨年までのDockerに対する開発投資状況
投資はかなり大きく、MicrosoftとDockerは非常に緊密に連携してきた
Docker Extensions in Microsoft Azure
Libswarmサポート（Docker Swarm）
Docker Client for Windows
Docker VM Image in Azure
ASP.NET 5でのDocker Imageサポート
Azure上でのDocker オーケストレーション機能
Visual Studio 2015でのDocker Image サポート
Windows Serverをコンテナイメージとして提供

 

 

Windowsマシン上にVisual Studioを稼働
“Parts Unlimited”という、アプリのプロジェクトを題材にデモを実施
Multi Tierアプリ：
フロントエンド＝ASP.NET
ミドル：Node.js
バックエンド：MongoDB
画面はフロントエンドのASP.NETの管理画面
アプリケーションのコンテナ化をこの画面から行う

 

 

DockerアプリケーションをDockerホストにPublishする画面：
次の工程が自動化
イメージのビルド
DockerホストにイメージをPush Upする
TLSの設定などもすべて自動化
Windowsマシンで生成されたアプリをコンテナ化して、Linuxマシン上に自動的に起動する

 

Macintosh上で動く、Visual Studioのデモ
ミドルのNode.jsのアプリの編集画面

 

Docker Composeの機能もサポート
Intellisenseという自動入力の機能を使って、Visual StudioはDocker Hubと接続し、Image名を入力すると、Docker Hubから該当するImage名のリストが表示される。

 

Visual StudioでのDockerコンテナとDocker Hubに対する操作
Visual Studio Onlineでも管理され、Visual Studioで管理しているCI/CDのプロセスに対しても的確に反映するように設計されている。
Docker Image のビルド
コンテナ化されたユニットテストを実施
Docker HubにイメージをPushする
Azureリソースグループを生成（VMクラスタ）
Docker SwarmクラスタをそのVM上に登録する
アプリをDocker Composeとしてこの生成したDocker Swarmクラスタ上に乗せる

 

 

Microsoft Azure Marketplace上でもDocker Trusted Registryが提供開始
複数のクリックで自分のプラットホーム上にDocker Trusted Registryを実装する事が可能

 

Marketplaceでは、Dockerコンテナ化されたアプリケーションもサポート。
シングルコンテナアプリのみならず、Composeで組み合わさった、マルチコンテナアプリも提供されている。
図はWordPress+MySQLのマルチコンテナアプリ

 

 

ワンクリックでマルチコンテナアプリを実装
スタートさせると、実装先のVMの指定はもちろんの事、使用するDockerコンテナの設定情報も指定できるようになっている。

 

Scott Johnson が再度登壇：Project ORCA（プロダクションで運用／管理するためのソリューション）の発表
ユーザの要求を分析：
プロダクションに移行したコンテナをどのように運用管理すべきか
コンテナの運用をより可視化したい
Engine, Swarm, Compose、さらに新ツールをどのように組み合わせて使うべきは、より自動化された、使いやすい（特にセキュリティ面で
スケールアップ／ダウンする簡単な手段が欲しい
運用管理者側としてセキュアな自動化運用方法が欲しい

 

 

 

統合されたツールスタック
現在開発している諸々のツールを統合するプラットホームを開発

 

Project Orcaは、アプリの運用側を統合するツールとして位置づけ
プラットホーム（図ではHostと表示）がVMWare, AWS, Azure, Digital Oceanであろうと、全く依存関係を持たず、アプリを運用する事ができるプラットホーム
Dockerから提供されるツールがすべて統合提供される
管理対象は、開発側のDocker Hub（プライベート、パブリック）から渡されるコンテナ資産

 

 

Evan Hazlett: Senior Software Engineer
デモはProject Orcaの開発責任者が実施

 

ログイン画面
非常にシンプルなデザイン

アクセス管理を設定する画面
ユーザアカウント毎にDockerコンテナに対してどういう権限を持っているかを管理
クラスタ内でどういうイベントが起きているのかをすべて把握、表示

 

イメージストアの統合管理
Docker Trusted Registryとの統合
何が動いているのか
タグの状態
どんなレポジトリがあるのか
イメージサイズ

 

イメージストア内のイメージの中も管理
起動するのにどんなコマンドが使われているのか
プラットホームの種類
アーキテクチャ

 

Swarmの管理
ホストの情報（どこにあるのか）
再起動、アップグレード等の管理機能
Swarmクラスタから外す
どんなイメージが稼働しているのか（Swarmクラスタ上で稼働しているイメージをすべて可視化）

 

Swarm上のDockerイメージの運用／管理
Redis検索を通して、大量のイメージに対して検索をかける事ができる
Swarmクラスタ全体に対して、Docker Hubから引っ張ってきたイメージを実装できる

 

コンテナ自体の管理
名称、作成日時、等の詳細情報（Docker psコマンドで表示できる情報）

コンテナ自体の管理
各コンテナの詳細情報を表示（Docker Inspectコマンドと同様の情報）

 

コンテナ自体の管理
ログ情報の表示（Docker Logコマンドと同様の情報）

 

コンテナ自体の管理
コンテナの稼働状況をリアルタイム表示（Docker statsコマンドと同様の情報）

 

コンテナ自体の管理
トラブルシュート／デバッグ機能（Docker execコマンドと同様の情報）

 

Docker Composeの管理(Stack)
Docker Composeの機能を使って、複数コンテナの管理機能を進化させている。
Stackは、Docker Composeをベースとしたメタコンセプトで、アプリのバージョン、概要、ソースリンク等の情報を管理

 

 

Docker Composeの管理(Stack)
Stackを起動すると、アプリが消費しているCPUとメモリの状況が表示される
Swarmクラスタのどこで動いているのかは表示されない（アプリ運用者からすればその情報は必要無い）
この画面から、scaleコマンドを発行し、CPU／メモリリソースをスケールアップすることができる。
アプリケーションのアップデートも可能（ComposeでRedisコンテナを追加し、cachiingを追加するデモを実施）

Project Orca = コンテナ運用の統合ツール
Project Orcaは最終的に、Dockerに関する開発／運用を連携させるフレームワークの最終形
まだコンセプト段階の若い技術なので、開発支援をしてくれる技術者を募集している