• Like
捕鯨！詳解docker
Upcoming SlideShare
Loading in...5
×

捕鯨！詳解docker

  • 4,577 views
Uploaded on

2014/12/15にコワーキングスペースCo-Edoでお話したDockerに関するプレゼン資料です。好評でしたので、公開したいと思います。

2014/12/15にコワーキングスペースCo-Edoでお話したDockerに関するプレゼン資料です。好評でしたので、公開したいと思います。

More in: Software
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post
    Be the first to comment
No Downloads

Views

Total Views
4,577
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
60
Comments
0
Likes
57

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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