Embed Size (px)
Citation preview
捕鯨！詳解 Docker
株式会社co-meeting
パブリッククラウドエバンジェリスト
吉田パクえ
http://www.co-meeting.co.jp/
Happy Work! Happy Life!株式会社co-meetingは、法人向けソフトウェアの開発・販売に10年以上携わってきた4人のメンバーによって創業されたITベンチャー企業です。人生において大きな時間を占める「仕事をしている時間」。co-meetingは、世界中の「仕事をしている人」に向けて、仕事時間を充実させ人生を豊かにするWebサービスを提供していきます。
1. クラウドの啓蒙活動講演、セミナー、執筆 etc
2. マーケティング支援1. 商品企画、記事広告2. 総合的なアドバイス3. イベントの企画、司会、登壇
3. 企業向け1. “クラウド” コンサルテーション
プランニングから新規事業開発支援まで2. “クラウド” 社員教育
新入社員・営業・技術指導3. 自社主催イベントへの協力
4. その他1. 特定非営利活動法人 aip セミナー講師2. CompTIA Mobility+ Subject Matter Expert 3. 学生向けセミナーや地域活性化へのお手伝い4. 放送大学 非常勤講師
パクえのお仕事
Dockerはなぜ生まれたのか
クラウド(IaaS)の仕組み
仮想サーバ
作成・変更削除・複製
・中にサーバができる・サーバの管理は利用者の責任・OSより上を管理する
・数分で手に入る
クラウドの実際
物理サーバ
物理サーバ
物理サーバ
仮想化基盤
管理
仮想化基盤 仮想化基盤
仮想サーバ
仮想サーバ
仮想サーバ
作成・変更削除・複製
実際は自動化された仮想化基盤の管理機構を経由している
＜パターン＞・全て共有・仮想基盤を占有・物理サーバを占有
入手は早くなったけど・・・
仮想サーバ
OS
ミドルウェア
アプリケーション
OSの管理ミドルウェアの管理アプリの開発と管理が面倒なのは相も変わらず
・仮想サーバを取り出せない・サーバ構築作業も自動化・冪等性が保障しにくい
Immutable InfrastructureBlue-Green Deployment
面倒なものは捨ててしまえ作り直せばいいじゃん
“作り直す”＝冪等性の担保
冪等性ある操作を1回行っても複数回行っても結果が同じであることをいう概念
構築そのものをプログラムしてしまう自動化・再現性の向上
重宝されたのは“手順化”の仕組み
正確にはChefではなく、Chef-soloが使われるようになった
新しい課題・Chef-soloは環境にクライアントを入れる必要がある。・Rubyで書くため、Rubyを知る必要がある。・異なるOSによって手順が異なるためレシピを作るのがかなり手間がかかる
・もともと大型の環境を想定しており、仕組みが煩雑
最近はこっちのほうが人気Pythonでできている
アプリ開発者が求めるものは？
・完成したものをそのまま持ち込みたい（もしくは、全く同じことを保障してほしい）
・VMではサイズが大きいので運びにくい・作るのをもっと早くしたい
OS
ミドルウェア
アプリケーション
ここだけで何とかしたい！
昔からあった技術の復興 ～ コンテナ
OS
ミドルウェア
アプリケーション
コンテナ
コンテナ実行基盤
物理 or 仮想サーバ
ミドルとアプリで塊を作り、その下に基盤を設けることでどこでも動く状態を確保する
実際のところを見てみよう
～新規のサーバを稼働させる
デモについて
•デモで実際に行った手順は以下にて公開してあります。
https://gist.github.com/yuyalush/5ddd4668fca01f58e25e
是非、同じくやってみてください。
デモ：公開イメージをカスタマイズ
dockerhub
imagespull
container
run
tar
save
psstart / stoprestarttopcommit
Server
カスタマイズする
運び出せる
１
２
３
４
５
完全に同じものを迅速に作り出せる
images containerrun
Cloud AServer
・仮想イメージの複製よりも早い・同一性が担保される
・OSの起動が無いので早い
・コンテナのサイズはとても小さいcontainer
container
デモ：クラウド間の移動
Server
images containerrun
tar
load
Server
images container
commit
tar
Save
Cloud A Cloud B
scp
構築環境 本番環境
・数コマンドで実施できるのでお手軽・シェルコマンドのみなので、自動化もしやすい・ダウンタイムの発生をコントロールする仕組みが必要
同じ稼働環境
ポイント
•コンテナはイメージからの差分しか持たない• runコマンドでコンテナ作成と実行
• psコマンドでコンテナの一覧
• rmコマンドでコンテナの削除
• Commitコマンドでimageに昇格させ、使い回しが可能になる
•カーネルの上位で動くため、サイズが小さい• 仮想サーバ： ディスクイメージのサイズ（20GB～30GB)
• コンテナ： 実行する部分＋アルファ（100MB～２GB）
•動き出すまでにハードの起動やOSの起動が無い• アプリの起動と比較すると、サーバの作成や起動はとても遅い
実際のところを見てみよう
～開発したものを他へ持っていく
Docker Hubでの公開イメージを活用
無料イメージを使いコンテナを作成する。稼働させるソースコードは独自のものを準備する流れです。
最新版のRubyやRailsのインストールを割愛できる
Dockerfileを作り、ローカルでビルドしRunで動き出すそうだ。
Ruby:2.1.5のイメージを使い、必要なインストールを行っている。実行したところにあるソースコードを練りこんで、最後にサーバを起動している。
これまでのデモを組み合わせます
images
container
run
Dockerfile
build
tar
save
commit
CloudA / Serverソースコード入り
構築の自動化
運び出せる
１
２
３
４
５
Server
images containerrun
tar
load
本番環境
同じ稼働環境
CloudB / Server
scp6
7
8
9
Dockerfileを作成＜下準備＞１、イメージを作るマシンにはDockerとアプリの開発環境を作っておく２、今回は簡単なRailsアプリの可動環境を作ります
・RubyとRailsのセットアップを実施・簡易なアプリを作る
＜作業＞１、RailsのアプリのディレクトリにDockerfiileを作成し、
以下を一行書く。FROM rails:onbuild
Server
Dockerfile
Cloud A
構築環境
ソースコード
イメージの構築docker –t build [イメージの名前] .
文字が流れてビルドが実施される。
Server
Dockerfile
Cloud A
images
ソースコード
完了後にimagesで確認すると、完成したイメージが格納されているのが確認できる
初回のbuildはかなり時間がかかる。Tips diskI/Oが早い環境を使うと効果あり。
作成されたイメージの稼働を確認するdocker run –d –p 3000:3000 bookshelf-app
Server
Dockerfile
Cloud A
images containerrun
ソースコード
ソースコード
ソースコードを書き換える
タイトルを「書籍一覧」へ
Server
Dockerfile
Cloud A
images container
ソースコード
ソースコード
イメージのリビルド
量が少ないとほぼ一瞬で終わる
Server
Dockerfile
Cloud A
images
ソースコード
もう一度コンテナを作り直す
Server
Dockerfile
Cloud A
images container
run
ソースコード
ソースコード
container
ソースコード
イメージをファイルへ出力する
docker save –output=bookshelf.tar bookshelf-app
885MBでした
Server
tar
Cloud A
imagessave
別のクラウドへ転送する
Server
tar
images
Cloud A
Server
tar
images
Cloud B
scp
イメージを取り込む
Docker load –input=bookshelf.tar
Server
tar
images
Cloud AServer
tar
images
Cloud B
container
ソースコード
Dockerfile
ソースコード
起動して動作を確認する
Server
tar
images
Cloud A
Server
tar
images
Cloud B
container
ソースコード
Dockerfile
ソースコード
runcontainer
ソースコード
Dockerを読み解くポイント
Dockerにまつわる誤解
英語 https://devopsu.com/blog/docker-misconceptions/日本語 http://postd.cc/docker-misconceptions/
誤解その1：Dockerを習得したら、他のシステムツールを学ぶ必要はない誤解その2：Dockerコンテナごとに1つのプロセスだけを持たせる誤解その3：Dockerを使えば、構成管理（CM）ツールを使う必要はない誤解その4：今すぐDockerを使うべき誤解その5：速度と一貫性を実現するためにはDockerを使うべき
粒度が変化していることに注意！
物理サーバ
仮想化基盤
管理
仮想サーバ
仮想サーバ
仮想サーバ
仮想サーバ
Docker Engine
コンテナ
コンテナ
コンテナ
コンテナ
仮想サーバのリソースを共有する
つまり、サーバの管理自体は必要！
コンテナはロールで作ること
Docker Engine
コンテナ コンテナ
Docker Engine
コンテナ
コンテナ
コンテナ
コンテナ
APP DB
スケールさせにくい スケールさせやすい
どこにいるか、外から解らない
Docker Engine
コンテナ
コンテナ
コンテナ
コンテナ
仮想サーバ
Docker Engine
コンテナ
コンテナ
コンテナ
コンテナ
仮想サーバ
Docker Engine
コンテナ
コンテナ
コンテナ
コンテナ
仮想サーバ
・むしろ管理するものが増えてる・仮想サーバが飛ぶと被害はむしろ増えている
管理レイヤーが必要
どれが楽かは場合によるDocker
サーバ
サーバ
Docker
サーバ
Docker
サーバ
Docker
構成管理系
サーバ
サーバ
Web
サーバ
Web
サーバ
Webサーバ サーバ
クラウドイメージ系
サーバ
サーバ
Web
サーバ
Web
サーバ
Web
サーバ
Web
スケーラブルなアプリへの開発方針に沿っているかが重要なポイント
http://12factor.net/
http://orangain.hatenablog.com/entry/12factor-ja
•コードベースバージョン管理されている1つのコードベースと複数のデプロイ•依存関係依存関係を明示的に宣言し分離する•設定設定を環境変数に格納する•バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱う•ビルド、リリース、実行ビルド、リリース、実行の3つのステージを厳密に分離する•プロセスアプリケーションを1つもしくは複数のステートレスなプロセスとして実行する•ポートバインディングポートバインディングを通してサービスを公開する•並行性プロセスモデルによってスケールアウトする•廃棄容易性高速な起動とグレースフルシャットダウンで堅牢性を最大化する•開発/本番一致開発、ステージング、本番環境をできるだけ一致させた状態を保つ•ログログをイベントストリームとして扱う•管理プロセス管理タスクを1回限りのプロセスとして実行する
簡単な話・・・
アプリ稼働環境として使うなら、以下の４つは個別に用意すること。
１、ロードバランサー各コンテナへリクエストを分散させる
２、データの永続化部分つまりDBはサービス使うか、自分で作っておく
３、キャッシュ部分・L7のロードバランスで固定させる・RedisなどのKVS使ってセッション情報を共有する
４、ログコンテナの中に残すと後で読めない
それ以外にも・コンテナの死活監視が必要・構成管理も要るよ・環境変数にコネクト先を入れる仕組み（もしくは、それに相当する何か）
Dockerを補強する動き
Kubernetes : クーバネティス
PodPod
かなりややこしい。。。
Docker Engine
コンテナ
コンテナ
コンテナ
コンテナ
Docker Engine
コンテナ
コンテナ
コンテナ
コンテナ
MasterProxy
PrivateImages
Master: 各Pod内のコンテナを監視し、決められた数を生成するProxy: どこに通信するかを調整する
ログについてはFluentdになりました
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/contrib/logging/fluentd-ek/README.md
Dockerを扱う専用OSの登場
etcd : 実体はKVS。クラスタ間での設定を共有する
ISOイメージで１３４MBほど
CoreOSによるクラスター管理
Apache2.0ライセンスによるオープンソース提供
個人的な印象
•難しすぎる
•超巨大な構成の中で使わないと効果を発揮できない
•そもそも、サーバのリソースが共有になるので物理サーバを使う or 巨大なインスタンスを使うでもしないと、管理工数増が目立ってしまうのでは？
• クラウドベンダーが管理機構を含めて用意してくれないと事実上使えないと考えてます。
各ベンダーの最新動向
You will be billed for those instances according to Compute Engine's pricing, until the clusters are deleted.
CoreOSの狙い
つまり、クラウドベンダーがDockerのクラスタ管理機構を独自に提供するようにすること。
Kubernetes Visualizerのリリース
Amazonは？
2014/11/12辺りに何かありそう・・・
https://gigaom.com/2014/11/09/887434/
Amazon EC2 Container Service
http://aws.typepad.com/aws_japan/2014/11/aws_container.html
•簡単なクラスター管理 - ECSはDockerコンテナから成るクラスターをセットアップし管理します。ECSはコンテナの起動や終了を行い、クラスターのステート情報を保持します。複数のアベイラビリティゾーンにまたがる数万のコンテナを保持するクラスターに簡単にスケールすることができます•ハイパフォーマンス - アプリケーションのビルディングブロックとしてコンテナを用いることができます。数秒で数千のコンテナを起動、停止、管理できます•柔軟なスケジューリング - ECSは組み込みスケジューラーを持っており、可用性、効率性の面でコンテナをクラスター上で適切に管理します。ECSはステート情報へのアクセスを提供しますが、もちろん、独自のスケジューラーや既存のオープンソースのスケジューラを用いてサービスAPIを利用することも可能です•拡張可能でポータブル - ECSはオンプレミスで用いるのと同様のDockerデーモンを用います。オンプレミスで用いたものを容易にAWSに持ち込み、持ち出すことが可能です•リソースの効率的利用 - コンテナ化されたアプリケーションはリソースを非常に効果的に使えます。単一のEC2インスタンスの上で複数のお互いに関係のないコンテナを走らせることができます。例えば、同じインスタンスの上で、短期間だけ画像処理を行うコンテナと、長期間にわたって動かすWeb
サービス用のコンテナを同時に動かすことができます•AWSの他サービスとの統合 - ECS上のアプリケーションは、もちろん、Elastic IPアドレスやリソースタグ、Virtual Private Cloud (VPC)といったAWSの機能を利用できます。コンテナはEC2やS3と同様に新しいレベルのビルディングブロックとして用いることができるでしょう•セキュアなサービス - VPCの中のEC2インスタンスでタスクを動かすことができます。タスクはIAM
ロール、セキュリティグループなどのAWSセキュリティ機能を活用できます。コンテナはマルチテナント環境で動作し、定義されたインタフェースを通じてお互いに会話することができます。コンテナが稼働するEC2インスタンスも完全に所有しコントロールできます。
以下、抜粋
説明から読み解く
１、クラスター管理のサービスEC2のインスタンスを追加することで、以降の管理をしてくれる
２、タスクベースJSONにてタスクを設定することで、元となるイメージや必要なコンテナ数を確保してくれたりする。コンテナ同士のリンクも可能。
すでに、アプリケーションが必要とするサービス群（DB,キャッシュ,メッセージング,ストレージなど）があるため、フロント側の管理に特化したサービスになっている印象
IBM BluemixでもDocker対応
OSの動き
Ubuntu Core
Ubuntuさんは管理機構などを用意せず、コンテナ技術に特化したOSの準備まで
Project Atomic
構成管理にはKubernetesを使っている
次世代WindowsServerでもコンテナーが動く
http://weblogs.asp.net/scottgu/docker-and-microsoft-integrating-docker-with-windows-server-and-microsoft-azure
その他
こんなのも登場
日本時間で2014/11/12
最大のポイントは、Herokuのワークフローをそのまま持ち込めること
LB、死活監視、ロギング、構成管理も持っている
CI環境のサービスdorone.io
オープンソース版が公開されており、テスト環境としてDockerを使っている
http://blog.drone.io/2014/2/5/open-source-ci-docker.html
慌ただしいDocker
http://blog.docker.com/2014/12/announcing-docker-machine-swarm-and-compose-for-orchestrating-distributed-apps/
Docker環境構築を楽にするツールクラスタリング環境の管理機能コンテナの管理機構を作っているそうです
http://blog.docker.com/2014/12/docker-announces-docker-hub-enterprise/
Docker Hub Enterpriseのリリース
Dockerで作られたイメージを保存しておくリポジトリ。プライベート環境にHubを構築できる。
IBMがパートナーシップを結んだと発表があり販売する。BluemixやSoftLayerでの展開がありそう。
CoreOSが独自にコンテナ作るとか言い出した
https://coreos.com/blog/rocket/
Dockerには根本的なところで問題があり、かつ機能が増え続けていることへの懸念から独自の技術へシフトするというのが主張
当面はDockerもサポートする体制を維持するようだ
まとめ
これまでを振り返って感じること
• そもそも管理レイヤーがSPOF(単一障害点)にならないようにしないと本番で使える気がしない。
• もし物理サーバレベルでの障害が起きた場合、これまで以上に可動部分が被害を受ける。それに耐えられるような構成を組む必要があるため、かなり大がかりな仕組みが求められる。
• ホストマシンのカーネルパニックが起きたら、全部影響を受けるので、結果的には障害リスク箇所が増えていると感じる。
• 管理レイヤーの構成や維持にかかる労力が相当かかるので、ベンダーからのメニューで補強されないとしんどい。小規模構成なら、これだけの管理レイヤーにかかる工数のほうがむしろ重荷になりかねないのが現状かと。
• クラウド環境で使う場合、稼働リソースが課金ポイントになるため相当リソースをうまく使わないと厳しい。
小さ目サーバを多数、コンテナ少なめ ： お金が厳しい大き目サーバを少数、コンテナ多め ： リスクが高い
まとめ（というか私見）
• Dockerは流行っているので、勉強しておくのはしておこう
•アプリケーションの開発を12facoterAppsに従い、アーキテクチャーを変えられるかが今後のカギとなる
•もし使うなら、まずはDevOps環境として。
•次に、セットアップのスクリプトを作るとき
•本番で使うためには課題が多い。ベンダーからメニューも提供され始めているのでしばし待て。
•現在はサーバベースのリソース課金であるが、今後はプロセス課金の方向になるかも。（というか、PaaSはすでにそうだしね）
捕鯨！詳解 Docker
完2014/12/15までの情報を元に作ってます。明日、また大きな変化が起きるかもしれないそんな日々が続いているお話でした。
