Weitere ähnliche Inhalte Ähnlich wie 捕鯨!詳解docker (20) 捕鯨!詳解docker2. http://www.co-meeting.co.jp/
Happy Work! Happy Life!
株式会社co-meetingは、法人向けソフトウェアの開 発・販売に10年以上携わってきた4人のメンバーによっ て創業されたITベンチャー企業です。人生において大き な時間を占める「仕事をしている時間」。
co-meetingは、世界中の「仕事をしている人」に向け て、仕事時間を充実させ人生を豊かにするWebサービス を提供していきます。 4. 1. クラウドの啓蒙活動
講演、セミナー、執筆etc
2. マーケティング支援
1. 商品企画、記事広告
2. 総合的なアドバイス
3. イベントの企画、司会、登壇
3. 企業向け
1. “クラウド”コンサルテーション
プランニングから新規事業開発支援まで
2. “クラウド”社員教育
新入社員・営業・技術指導
3. 自社主催イベントへの協力
4. その他
1. 特定非営利活動法人aipセミナー講師
2. CompTIA Mobility+ Subject Matter Expert
3. 学生向けセミナーや地域活性化へのお手伝い
4. 放送大学非常勤講師
パクえのお仕事 7. クラウドの実際
物理
サーバ
物理
サーバ
物理
サーバ
仮想化基盤
管理
仮想化基盤
仮想化基盤
仮想
サーバ
仮想
サーバ
仮想
サーバ
作成・変更
削除・複製
実際は自動化された
仮想化基盤の管理機構を
経由している
<パターン>
・全て共有
・仮想基盤を占有
・物理サーバを占有 8. 入手は早くなったけど・・・
仮想
サーバ
OS
ミドルウェア
アプリケーション
OSの管理
ミドルウェアの管理
アプリの開発と管理
が面倒なのは相も変わらず
・仮想サーバを取り出せない
・サーバ構築作業も自動化
・冪等性が保障しにくい
Immutable Infrastructure
Blue-Green Deployment
面倒なものは捨ててしまえ
作り直せばいいじゃん 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~2GB)
•動き出すまでにハードの起動やOSの起動が無い
•アプリの起動と比較すると、サーバの作成や起動はとても遅い 23. これまでのデモを組み合わせます
images
container
run
Dockerfile
build
tar
save
commit
CloudA/ Server
ソースコード入り
構築の自動化
運び出せる
1
2
3
4
5
Server
images
container
run
tar
load
本番環境
同じ稼働環境
CloudB/ Server
scp
6
7
8
9 25. イメージの構築
docker–t build [イメージの名前].
文字が流れてビルドが実施される。
Server
Dockerfile
Cloud A
images
ソース
コード
完了後にimagesで確認すると、
完成したイメージが
格納されているのが確認できる
初回のbuildはかなり時間がかかる。
Tips diskI/Oが早い環境を使うと効果あり。 33. 起動して動作を確認する
Server
tar
images
Cloud A
Server
tar
images
Cloud B
container
ソース
コード
Dockerfile
ソース
コード
run
container
ソース
コード 36. 粒度が変化していることに注意!
物理
サーバ
仮想化基盤
管理
仮想
サーバ
仮想
サーバ
仮想
サーバ
仮想サーバ
DockerEngine
コ ン テ ナ
コ ン テ ナ
コ ン テ ナ
コ ン テ ナ
仮想サーバのリソースを共有する
つまり、サーバの管理自体は必要! 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. 簡単な話・・・
アプリ稼働環境として使うなら、以下の4つは個別に用意すること。
1、ロードバランサー
各コンテナへリクエストを分散させる
2、データの永続化部分
つまりDBはサービス使うか、自分で作っておく
3、キャッシュ部分
・L7のロードバランスで固定させる
・RedisなどのKVS使ってセッション情報を共有する
4、ログ
コンテナの中に残すと後で読めない
それ以外にも
・コンテナの死活監視が必要
・構成管理も要るよ
・環境変数にコネクト先を入れる仕組み
(もしくは、それに相当する何か) 44. Pod
Pod
かなりややこしい。。。
DockerEngine
コ ン テ ナ
コ ン テ ナ
コ ン テ ナ
コ ン テ ナ
DockerEngine
コ ン テ ナ
コ ン テ ナ
コ ン テ ナ
コ ン テ ナ
Master
Proxy
PrivateImages
Master: 各Pod内のコンテナを監視し、決められた数を生成する
Proxy: どこに通信するかを調整する 50. You will be billed for those instances according toCompute Engine's pricing,
until the clusters are deleted. 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インスタンスも完全に所有しコントロールできます。
以下、抜粋 73. これまでを振り返って感じること
•そもそも管理レイヤーがSPOF(単一障害点)にならないように しないと本番で使える気がしない。
•もし物理サーバレベルでの障害が起きた場合、これまで以上に 可動部分が被害を受ける。それに耐えられるような構成を組む必要があ るため、かなり大がかりな仕組みが求められる。
•ホストマシンのカーネルパニックが起きたら、全部影響を受けるので、 結果的には障害リスク箇所が増えていると感じる。
•管理レイヤーの構成や維持にかかる労力が相当かかるので、 ベンダーからのメニューで補強されないとしんどい。 小規模構成なら、これだけの管理レイヤーにかかる工数のほうが むしろ重荷になりかねないのが現状かと。
•クラウド環境で使う場合、稼働リソースが課金ポイントになるため 相当リソースをうまく使わないと厳しい。 小さ目サーバを多数、コンテナ少なめ:お金が厳しい 大き目サーバを少数、コンテナ多め:リスクが高い 75. 捕鯨!
詳解Docker
完
2014/12/15までの情報を元に作ってます。
明日、また大きな変化が起きるかもしれない
そんな日々が続いているお話でした。