BOSHで始めるImmutable Infrastructure
Upcoming SlideShare
Loading in...5
×
 

BOSHで始めるImmutable Infrastructure

on

  • 3,097 views

分散環境の構築に特化した環境構成ツールBOSHをつかってImmutable Infrastructureを実践するには。

分散環境の構築に特化した環境構成ツールBOSHをつかってImmutable Infrastructureを実践するには。

Statistics

Views

Total Views
3,097
Views on SlideShare
2,261
Embed Views
836

Actions

Likes
11
Downloads
22
Comments
0

5 Embeds 836

http://blog.udcp.net 670
https://twitter.com 154
http://feedly.com 8
http://s.deeeki.com 3
https://www.chatwork.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

BOSHで始めるImmutable Infrastructure BOSHで始めるImmutable Infrastructure Presentation Transcript

  • BOSHで始める Immutable Infrastructure 岩嵜 雄大 @ i_yudai NTT Laboratory Software Innovation Center 2013-11-29
  • 自己紹介  Twitter: https://twitter.com/i_yudai  Cloud Foundryの運用面を主に担当 – – – – Nise BOSH cf_nise_installer cf_aio_installer 現在はBOSHのCloudStack対応を主に担当
  • 発表の内容  Immutable Infrastructureの概要 – BlueGreen Deployment  BOSHが可能にしてくれること  Cloud Foundryとの違い  BOSHの課題 3
  • Immutable Infrastructureの概要 動いている環境はそのままに 新しい環境に切り替えよう
  • 昔の更新作業 新しい機能 既存の環境を 壊さないように 新機能はそっと乗せる 既存の機能 差分更新と新規構築で別手順が必要 環境ごとに必死にテストをして最後はお祈り 既存環境
  • 継ぎ足し継ぎ足し作られた秘伝の環境は しばしば爆発する
  • 最近の更新作業 新しい機能 既存環境を壊さないように 環境構成ツールが気を使っ てくれるようになった 既存の機能 構築手順も一本化された Chef、Puppet、etc. 既存環境
  • Photo by State Farm (http://www.flickr.com/photos/statefarm/10994875346/)
  • Immutable Infrastructureでの更新作業 そのまま 新しい機能 既存の機能 既存の機能 既存環境 新規環境 常に新しい環境を構築する(強制)
  • Photo by Chika Watanabe (http://www.flickr.com/photos/chikawatanabe/192112067/)
  • BlueGreen Deployment ルーター ロードバランサー 切り替え さわらない 新しい機能 既存の機能 既存の機能 既存環境 新規環境
  • 新環境がダメそうな場合も 切り戻しがしやすい Photo by 松林 L(http://www.flickr.com/photos/axio/5577620081/)
  • でも大変じゃないの? Photo by Tsahi Levent-Levi (http://www.flickr.com/photos/axio/5577620081/)
  • BOSHが可能にしてくれること 環境のライフサイクルマネージメント
  • BOSHとはなにか  分散環境構成ツール – 最初はCloud Foundryの構成用に作られた – ほかの分散システム構築にも使える  環境構築に必要な作業を全てCLIで制御 – VMのライフサイクルマネジメント • 作成・削除・監視・etc. – ソースコードの保存・コンパイル・配布 – 環境の追加・更新・削除 15
  • BOSHの簡単な仕組み ソースコード 構成情報 BOSH VM CLI VM VM VM VM VM VM VM VM VM 環境A VM VM VM VM 構成情報をコピーするだけで VM VM VM VM 別環境をゼロから構築できる VM VM VM 環境C VM VM VM VM生成 バイナリ配布 設定適用 VM VM VM VM VM VM VM VM VM VM VM VM 環境B AWS、OpenStack、Linux コンテナ (CloudStack、Google Cloud Platform)
  • BOSHの簡単な仕組み ソースコード 構成情報 BOSH VM VM VM VM VM生成 バイナリ配布 設定適用 VM VM VM VM VM VM VM VM IaaSの力を借りて BlueGreen Deployment CLI VM VM VM VM VM 構成情報をコピーするだけで VM VM VM VM 別環境をゼロから構築できる VM VM VM 環境C VM 環境A VM VM VM VM VM VM VM VM VM VM VM 環境B AWS、OpenStack、Linux コンテナ (CloudStack、Google Cloud Platform)
  • 3つの概念  Stemcell – ベースとなるVMイメージ Package A Package B Package C Job A Release Stemcell VM Agent  Release – ソースコードをまとめたGit レポジトリ  Deployment – 個別の環境の構成情報 • Manifestファイル
  • Stemcell  最低限のライブラリとツールが 入ったVMイメージ Package A Package B Job A Stemcell VM Package C Release Agent – Stemcell は幹細胞という意味 – Ubuntuベース(CentOSも開発中) • 後述の理由によりディストリビューション はあまり関係ない  BOSH Agentも含まれている – 設定適用などを行うプログラム – Monitも同梱  ファイルとして配布されている – AWSではAMI
  • Release  ソースコードをまとめたリポジトリ – Gitで管理すること前提 – リリース番号管理も可能  Package: Package A Package B Job A Stemcell VM Package C Release Agent – ソースコードのファイルリスト – パッケージングスクリプト  Job: – Packageのリスト – 設定ファイルのテンプレート(ERB) • Deploy時にManifestの値が代入される – 起動スクリプト • MonitがStartするスクリプト
  • Deployment  個別の環境と構成情報 VM VM VM VM VM VM VM VM VM VM VM VM 環境A – Deployment Manifestと紐付いている  Deployment単位で操作する – 構築・削除・更新 Manifest A  複数Releaseの混載も可能  設定項目の例: Manifest B VM VM VM VM VM VM VM VM VM VM VM VM 環境B 環境名 使用するReleaseとStemcellのバージョン Jobごとのリリース量(VMサイズ、数) ネットワーク設定(セキュリティグループ、 Floating IP) – Jobのテンプレートファイルに代入する値 – – – –
  • 環境構築のライフサイクル Getting deployment properties from direc Unable to get properties list from directo Compiling deployment manifest... Cannot get current deployment informati Please review all changes carefully Deploying `blue.yml' to `firstbosh' (type 'y Director task 6 # Stemcell をアップロードしておく Preparing deployment binding deployment (00:00:00) bosh upload stemcell bosh-stemcell-3-cloudstack-kvm-ubuntu.tgz binding releases (00:00:00) 開発 binding existing deployment (00:00:00) binding resource pools (00:00:00) # ソースコードが準備出来たらリリース番号を振る binding stemcells (00:00:00) # リリース番号を振るとリリース情報ファイルが作られる binding templates (00:00:00) binding properties (00:00:00) bosh create release --final binding unallocated VMs (00:00:00) binding instance networks (00:00:00) # ソースコードをアップロード Done 9/9 00:00:00 # リリース情報ファイルを与えると対応するソースコードがアップロードされる Preparing package compilation bosh upload release releases/wordpress-3.yml Preparing DNS binding DNS (00:00:00) Done 1/1 00:00:00 デプロイ # 使用するマニフェストを指定して環境切り替え # 適宜マニフェストファイルを環境に合わせて編集しておく Creating bound missing VMs bosh deployment ~/deployments/blue.yml common/3 (00:00:47) # 環境を構成 common/1 (00:00:52) common/0 (00:00:56) bosh deploy common/2 (00:01:02) Done 4/4 00:01:02 Binding instance VMs mysql/0 (00:00:01) nginx/0 (00:00:01) nfs/0 (00:00:01) wordpress/0 (00:00:01) Done 4/4 00:00:01
  • 新しい環境を増やす # マニフェストをコピーして編集 cp ~/deployments/{blue,green}.yml vi ~/deployments/green.yml # 環境切り替え bosh deployment ~/deployments/green.yml # 環境を構成 bosh deploy --name: green director_uuid: 12de20b6-56e1-40d1-3939 release: name: wordpress version: latest
  • 配備済みの環境を確認 bosh deployments +-------+-------------+------------------------------+ | Name | Release(s) | Stemcell(s) | +-------+-------------+------------------------------+ | blue | wordpress/3 | bosh-cloudstack-kvm-ubuntu/3 | +-------+-------------+------------------------------+ | green | wordpress/3 | bosh-cloudstack-kvm-ubuntu/3 | +-------+-------------+------------------------------+ Deployments total: 2
  • 配備済みの環境を削除 bosh delete deployment blue
  • 簡単 Photo by Jessica Merz (http://www.flickr.com/photos/94953676@N00/61994800/)
  • 参考)一般公開されているリリース  MariaDB – https://github.com/cloudfoundry-community/mariadb-boshrelease  ZooKeeper – https://github.com/cloudfoundry-community/zookeeperboshrelease  SkyDNS – https://github.com/cloudfoundry-community/skydns-boshrelease  Redis – https://github.com/cloudfoundry-community/redis-boshrelease  Riak – https://github.com/BrianMMcClain/riak-release
  • Cloud Foundryとの違い どこまで自分で管理するか
  • カスタマイズ性と管理コスト アプリケーション・サービス フレームワーク PaaS フレームワーク データベース ウェブサーバ ロードバランサ ウェブサーバ OS OS OS OS 仮想マシン 仮想マシン 仮想マシン 仮想マシン ハイパーバイザ ハイパーバイザ 物理マシン IaaS 物理マシン PaaSはミドルウェア層までがマネージド ※Cloud FoundryでもBlueGreen Deploymnetが可能 29
  • カスタマイズ性と管理コスト アプリケーション・サービス フレームワーク フレームワーク データベース ウェブサーバ ロードバランサ ウェブサーバ OS OS OS OS 仮想マシン BOSH 仮想マシン 仮想マシン 仮想マシン ハイパーバイザ ハイパーバイザ 物理マシン IaaS 物理マシン BOSHほとんど何も提供しない 30
  • 利点と欠点  利点 – フルカスタマイズ出来る自由度  欠点 – フルカスタマイズしないといけない
  • BOSHの課題 BlueGreen Deploymentは銀の弾丸か
  • ステートフルな環境のBGDは難しい  ステートフルな環境は不揮発データのコ ピーが必要になってしまう – 例)分散データベース、分散ストレージ  対応策 – ステートフルな部分とそれ以外を切り分ける • Application層とDB層を分けて構成する – ステートフル環境はMutableを受け入れる 33
  • ステートフルな部分に引きずられる  例)DBスキーマ変更を伴うApp層の更新 – GreenとBlueが共存できないケース  対応策 – 一時的にMuttableな更新を受け入れる?
  • BOSHはMutableな更新も出来る  Deploymentのアップデートも可能 – 擬似的なImmutable更新 – ルールを守らないと爆発する  ルール自体は難しくない – /var/vcapディレクトリ内で完結させる • ステートフルなデータは全て /var/vcap/store に保存 • OSが提供するパッケージ管理システムは使用しない
  • BOSH自体がまだまだ進化中  BOSH自体の構成ノウハウが必要 – Full BOSHはそれ自体が分散システム – BOSH-liteの登場で光明が差す • Vagrantで1VM BOSHを簡単に作れる  リリース管理に慣れる必要あり  全体的にヘビー  情報が少ない
  • まとめ  Immutable Infrastructureで安心感アップ – BlueGreen Deploymentが大事 – でもいますぐ全てをImmutableにするのは無理  BOSHはそのためのお手伝いをしてくれる – 環境のライフサイクル管理が比較的簡単 – フルカスタマイズ派におすすめ
  • 補足資料
  • ディレクトリルール  Packageの展開先 – /var/vcap/packages/:package_name – 複数Jobで共有される  Jobの展開先 更新時には 新しいバージョンで 置き換えられる (擬似Immutable) – /var/vcap/jobs/:job_name  揮発性データの保存 – /var/vcap/data  不揮発(ステートフル)データの保存 – /var/vcap/store – 更新時にVM再生成が行われた場合も引き継がれる 39
  • パッケージング  BOSHはソースコードのコンパイルも自動で行う – 複数VMで並列コンパイル – Bundleなどの処理もここで行う事ができる  パッケージングスクリプトはただのシェルスクリプト  初回のみ実行され結果がキャッシュされる – パッケージに変更があると自動で再実行される  各VMに配布されるのはパッケージング済みのファイル – パッケージ名に対応したディレクトリに展開されるだけ – OS環境が汚れない
  • ジョブの起動  Monitが起動スクリプトを実行 – 単なるシェルスクリプト – 大抵はパッケージのバイナリを実行する  設定ファイル – ERBテンプレートから自動生成される • 代入値はDeployment Manifestに書く • VMごとの固有値などは自動で与えられる – ジョブ名に対応した位置に保存されている • 起動スクリプト内でバイナリ実行時に渡すのが普通
  • 完全自前主義  BOSHではOSの提供するパッケージは使用しない – aptやyumを使用すると更新時に爆発する  全て自分でPackageとして管理する – 勝手にバージョンが更新されないので安全ではある – セキュリティフィックスも自分で行う – Cloud FoundryはPostgresやRubyも独自に管理している