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

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

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

ーーー

Keynote Speech: Ben Golub:CEO

Docker in Production
Dockerをプロダクションに向けて本格的に採用させる事が今日のテーマ。
とは言え、様々な課題に取り組む必要がある。
誰でも使える事（開発者、DevOps、運用管理者）
どこでも使える（複数のアーキテクチャ、OS、クラウド／オンプレミス）
拡張しやすい
明確なソリューションとロードマップがある
実際にDockerを使っているユーザがいる事

 

プロダクションで本格利用するための課題を4つの層に整理：
ビジネスソリューション　　＝＝＞これが今日のテーマ
開発プラットホーム　（Docker 1.7, Swarm, Compose, Machine, Plugins）
運用ツール　（runC, Notary）
オープン規格　（OCF, OCP）

 

ツールの整備
Dockerをプロダクションで商用化するためには3つのカテゴリーにおいて各々ツールを整備する必要がある。
開発段階：
開発プラットホーム
CI/CD統合
コードサイニング（証明書発行）
リリース段階：
Docker Trusted Registry
レポジトリ管理
アクセス権管理
ポリシー運用
運用段階：
オーケストレーション
GUI
運用管理
ログ管理

ツールの提供方法
Dockerで提供する開発／運用管理ツールは全ての段階において、統一したUX(User Experience)で提供される
昨日発表されたツールもこの一連の工程をサポートするコンセプトに基づいている。
オンプレミスでもクラウドでも使える
ツール同士の連携も保証
商用版としてコマーシャルサポートも提供
チャネルやパートナーからも販売
容易に導入できるような価格／パッケージ化

SVP of engineering: Marianna Tessel
以前はVMWareの開発責任者を務めた人間で、現在はDockerの開発責任者

 

Docker Hubの現状の紹介
元はDocker SaaSと呼ばれていた
ちょうど1年前にスタート

 

1年での急成長は目覚しい
24万人のユーザ
15万個のレポジトリ
5億回のプル

 

Official Repo
特に利用頻度の高いものを、Official Repoと呼んでいる
これだけで6000万回のプルが起きている

 

Build & Ship (DevOpsの統合）
今や、Docker Hubは開発だけではなく、プロダクションでも利用している顧客が多く、この一連のDocker Hubを使ったプロセスを、
"Build And Ship”と呼んている。
開発者、QA、運用管理部門をつなげるための重要なレポジトリ機能としてDocker Hubが重要な役割を担ってる
現在、1万3千社がDocker Hubを使っている。

 

主要顧客
Docker Hubを利用している主要企業のリスト：業界広く分布している
その顧客の一つ、Business Insider社にプレゼンを依頼している。

 

Business Insider社による導入事例紹介
Business Insider社：Director of DevOps: Chris Buckley

 

 

IT環境の構成要素：
企業内のベアメタルシステムとAWSの組み合わせ
PHPとGoを開発言語に採用
データベース：MongoDB
DevOpsはPuppet
そしてDocker

なぜDockerを採用したのか？
何故、Dockerを採用したのか？＝＝＞　純粋に楽しいから
楽しい：Free BSD Jails、Linux Container等と比較して、可能性が飛躍的に大きい
利用環境：
ローカル開発環境
ローカル開発／QA／プロダクション のそれぞれの開発環境の差分による問題を解消
Shared Infrastructureにおいて、アプリケーションを独立して運用する環境を作る

 

 

最初のステップ
最初はJenkinsを通してコンテナを使ってソフトウェアのリリースを開始した
開発したコードがプロダクションの環境で問題なく稼働する事がが保証できる、という点が大きかった。

 

 

長期運用アプリへの適用
同じクラスタ上でアプリを運用していて、最初に遭遇した問題
MemcachedのKey Valueの不整合
APC opcodeの不整合
＝＝＞ コンテナをより独立させ、プラットホームとの依存度を下げる事によりこの問題を解決できる、と考えた

 

 

いくつか課題が発生：
コンテナをどのようにリリースするか？
コードをコンテナ内に置くか、ボリュームとしてマウントするか？
障害時の対策をどうするのか？
既存のPuppetの環境との整合性
コードアップデートはPuppet Server/AgentとHeiraを使っていた

 

 

結果的に次の方針で進めた。
アプリケーションコードはボリュームとしてコンテナにマウントする
Jenkins Capistranoを使い、コンテナでコードの出荷を行う
長期で使うアプリは、Linuxサービスとして使用、コンテナ化しDocker Hubでホスト

 

一応動くには動くが。。
Memcached/APCの問題は解決された。
イメージは全てDocker Hubで管理
プロダクション後のコンテナを開発部門に戻す作業が困難

 

 

学んだ事：
プロダクション環境向けに開発するのではなく、ローカルで開発する環境を重視すべき
プロダクション環境のアプリを開発環境に戻す行為はそもそもおかしい
その環境に関する工程が開発者の時間を浪費していた

 

FIGを使ってみた
そこで FIG (現在のCompose)を使い始め、我々の目的に合致している事を発見
YAMLで定義されたシステムスタックを管理可能
リンク、ポート、ボリューム、環境設定情報などが全部一箇所で管理可能
Dockerfileからコンテナの作成、もしくはDockerHubからイメージをプルする事が可能
図の左側は、社内のCMSシステムの環境設定情報がComposeで管理されている事を示している。

 

アプリ開発所要時間の大幅な短縮
アプリケーションの開発環境の立ち上げに従来は1〜2日かかっていたのが、Vagrant+Docker+Composeの組み合わせで数時間で完了。
開発者の生産性向上の面で大きく寄与している。

 

 

プロダクションアプリの運用の見直しを行い、次の方針を決めた。
シングルホストアプリの運用はDocker Composeを利用
マルチホスト／分散アプリの運用は、LInuxサービスとしてコンテナを利用した。(Upstart, SysV経由）
まだ、upstartスクリプトの運用はかなり手間がかかった。

 

その改善のために、Puppetでコンテナを運用する方針をとった。
Puppetが提供するDockerモジュールを採用
init.dスクリプトに下記の全てを実装できた
イメージバージョン管理
ランタイム環境の設定管理
リンク関係
スタートアップの依存関係

PuppetでのDockerコンテナの管理
図が、Docker Puppet Forgeモジュールを使ったPuppetクラスの例
Docker Hubで管理し、再利用が非常に簡単

 

Docker導入前のフロー
開発部門とオペレーション部門が並行して業務を遂行、AWS上で統合運用するモデル

 

Docker導入後のフロー
開発部門、運用部門、ともにイメージをDocker Hubにアップロード管理。
そこからPuppetもしくはJenkinsを使って実装、運用ができるようになった

 

Business Insider社の将来について
オーケストレーションに今後はフォーカスしたい（種類が多いな、が実感）
Docker Machine/Swarm/Composeの導入
Kubernetes
Mesosphere DCOS
EC2 Container Service
CoreOS/Fleetcti
自動化をさらに拡張
Docker Hubの自動ビルド機能
コンテナビルドにJenkins Dockerプラグインを採用

 

 

まとめ：
すでに蓄積しているノウハウを最大限に利用する
Business InsightはPuppetのノウハウが多く、それをうまく利用できた
他にも選択がいっぱいあるので色々実験すべし
Dockerのエコシステムは巨大で、必ず期待できるソリューションが見つかるはず
間違った組み合わせ、と言うものはまだ存在しない
楽しむこと

 

MarianTesselがまたステージに戻る

 

Docker Hub ==> 品質向上
これに力を入れている。
セキュリテイ、性能、ユーザビリティ、等多方面にわたる改善

 

新しいレジストリのPull性能の向上
CDNの改善とネットワークプロトコルも変更
エラーも少なくなり、信頼性が向上

 

UIの変更
ダッシュボード上のページ間の遷移もスムーズに
検索スピードも向上

 

Docker Hubの信頼性向上
レポジトリに対するリクエストで起きるエラーレートが非常に向上している。

 

 

セキュリティも大きく向上
外部組織からのセキュリティの監査を行い、様々な提案を受け入れている
Registry V2を採用し、コンテンツの保全性を高めている
認証を行うマイクロサービスを採用している
One Time Build Host機能（ホストをビルドして一定条件／時間で完全に自動削除される）

 

ログイン画面の新デザイン
新しいログインのUI:凄くシンプルになっている

 

新しいチームワークフローのページ
以前より使いやすいシンプルなGUI

 

Docker Hub内のイメージサイズが見えるダッシュボードも追加
現在パブリックベータが提供開始されている。
www.hub-beta.docker.com