Chefのエンタープライズ事例 ossミドルウェアスタックishigakiテンプレートにおける事例-
•
3 likes•2,810 views
TISにて推進しているOSSミドルウェアスタックISHIGAKIテンプレートではChefを使っています。ISHIGAKIテンプレートで使っているChefの事例紹介です。 http://www.tis.jp/service_solution/ossmigration/#tabitem_3
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Chefのエンタープライズ事例 ossミドルウェアスタックishigakiテンプレートにおける事例-
Similar to Chefのエンタープライズ事例 ossミドルウェアスタックishigakiテンプレートにおける事例- (20)
More from 賢 秋穂
Recently uploaded
Recently uploaded (9)
Chefのエンタープライズ事例 ossミドルウェアスタックishigakiテンプレートにおける事例-
- 1. TIS株式会社 戦略技術センター 秋穂 賢 2014/9/18(Thu) @ データセンター管理者必見！セミナー【SDN/SDI】Arista x Chefで実現するデータセンター自動化への展開 Chefのエンタープライズ事例 ～OSSミドルウェアスタック ISHIGAKIテンプレートにおける事例～
- 2. TIS株式会社 戦略技術センター所属 自己紹介 秋穂 賢（あきほ すぐる）名前 Chef, Zabbix, JobScheduler, OTRSなど仕事 http://www.atmarkit.co.jp/ait/articles/1310/17/news006.html http://codezine.jp/article/detail/7767
- 7. テンプレート化による利点 従来型のSI ● 個々の顧客ごとの要件に合ったイ ンフラ構成（ミドルウェア）を選定 ● ベンダー支援のもとで検証を実施 し、構成を決定 ● ミドルウェアのインストールから設 定まで全て手作業で実施 ● 顧客ごとのインフラ環境を個別に サポートする必要がある テンプレートを利用したSI ● 要件に合うテンプレートを選択 ● 検証済みの構成から、要件に合う ものを選択 ● スクリプトで設定済みのテンプ レートを自動インストール ● テンプレート構成のサポートを集 約して管理可能
- 8. テンプレート化による利点 従来型のSI ● 個々の顧客ごとの要件に合ったイ ンフラ構成（ミドルウェア）を選定 ● ベンダー支援のもとで検証を実施 し、構成を決定 ● ミドルウェアのインストールから設 定まで全て手作業で実施 ● 顧客ごとのインフラ環境を個別に サポートする必要がある テンプレートを利用したSI ● 要件に合うテンプレートを選択 ● 検証済みの構成から、要件に合う ものを選択 ● スクリプトで設定済みのテンプ レートを自動インストール ● テンプレート構成のサポートを集 約して管理可能 テンプレートとしての決まった構成 Chefによる自動化を実現
- 9. ISHIGAKIテンプレートの構成要素 ISHIGAKIテンプレートは大きく2つのOSSミドルウェア群で成り立つ ● JavaのWebアプリケーションを稼働させるための基盤 ○ Apache / Tomcat / JBoss / PostgreSQL ● 運用監視基盤 ○ Chef / Zabbix / Amanda / JobScheduler ISHIGAKIテンプレートは大きく4つの構成を提供 ● 単一のサーバで構成される Single Edition. ● Active / Standbyで冗長化した HA Edition. ● Active / Activeで冗長化した高可用性の Cluster Edition. ● AWS環境で高可用性クラスタを実現した AWS Edition.
- 10. Single Edition Apache or ● 冗長化をしていない、シンプルな構成 ● 小規模案件向け ● chef-solo / knife-soloを用いて自動化
- 11. HA Edition ● Active / Standbyで冗長化された構成 ● 冗長化にはDRBD / Pacemakerを用いている ● Active系が停止した場合はStandby系を自動でActiveにする ● 運用サーバがあり、ここにChef Serverを導入 Standby サーバ システム 運用者 情報 収集 Apache JBoss AS Active サーバ 死活監視 データ同期 JBoss AS Apache リソース監視リソース監視 運用 サーバ
- 12. Cluster Edition ● Active / Activeで冗長化された構成 ● 冗長化にはミドルのレプリケーション機能を用いている ● 1台停止しても大きな影響はなく運用可能 ● 各ミドルウェアの構成台数は柔軟に変更可能 ● 運用サーバがあり、ここにChef Serverを導入 マスター スレーブ スレーブ JBoss AS pgpool-Ⅱ セッションレプリケーション 参照負荷分散 DBレプリケーション JBoss AS pgpool-Ⅱmod_jk mod_jk mod_jk JBoss AS pgpool-Ⅱ 負荷分散 情報収 集 運用 サーバ システム 運用者
- 13. AWS Edition マスター スレーブ スレーブ JBoss AS pgpool-Ⅱ セッションレプリケーション 参照負荷分散 DBレプリケーション JBoss AS pgpool-Ⅱmod_jk mod_jk mod_jk JBoss AS pgpool-Ⅱ 負荷分散 情報収 集 運用 サーバ G Elastic Load Balancer AWS Cloud システム 運用者 ● Active / Activeで冗長化された構成 ● Cluster EditionをAWS向けにカスタマイズ ● フロントにELBを配置 ● 各ミドルウェアの構成台数は柔軟に変更可能 ● 運用サーバがあり、ここにChef Serverを導入
- 14. ISHIGAKIテンプレートの自動化 Single Edition. HA Edition. AWS Edition.Cluster Edition. による自動化を実現
- 15. ISHIGAKIにおけるChef 〜Chef実行〜 setup.sh config.yml インストーラとしてChefを利用 Chefのラッパーとしてスクリプトを定義 ①OSの初期設定（ssh / firewall など） ②管理サーバにChef Server / Chef Client をインストール ③Chef Serverの初期設定 ④Cookbook / RoleをChef Serverにアップロード ⑤Databagの作成＆Chef Serverへのアップロード ⑥各ノードへのChef Clientインストール＆run_listの設定 ⑦Chef Clientの実行
- 16. ISHIGAKIにおけるChef 〜具体例〜 setup.sh config.yml 〜〜 base: session_replication: true 〜〜 Cluster EditionでのAP間セッションレプリケーションの設定例 ruby script Yaml => Hash変換後 params[:tomcat][:env][:session_replication] = config['base']['session_replication'] ruby script JSON変換＆databagとしてアップロード server.xml.erb <% if @node[:tomcat][:env] [: session_replication] == true -%>
- 17. ISHIGAKIにおけるChef 〜Attribute活用〜 Attributeの優先度を考慮してパラメータを設定 https://docs.getchef.com/essentials_cookbook_attribute_files.html インストールした 際の初期値 検証で得られた、 各エディションのミ ドル毎に設定すべ き最適値 ・ 各ノード固有の設定値（ ipアドレスなど） ・ ノード間で共有すべき設定値（エディション名など）
- 18. ISHIGAKIにおけるChef 〜supermarcket〜 ISHIGAKIではChef Supermarketにあるコミュニ ティで作成されたcookbookは使っていない ● 開発当初はコミュニティcookbook数が少なかった ● お客様への納品が必須 ○ 正式なサポートがなく（有志でのCookbook提供）内容を 全て把握することが難しい ○ 変更履歴を常にウォッチするのが難しい コミュニティのCookbookは実装時に参考にするのみ
- 19. ISHIGAKIにおけるChef 〜構築時間〜 Single Edition ・・・ 約20分程度（1 / 1 / 1 / 0） HA Edition ・・・ 約40分程度（1 / _ / _ / 1） Cluster Edition ・・・ 約60分程度（2 / 2 / 2 / 1） Chef導入前にCluster構成を構築すると、慣れてい る人が実施しても半日仕事（設定ミスの調査含む） 構築時間が劇的に短くなった！ 設定ミスがなくなった！ （Web / AP / DB / OP） ※ 人手が必要な時間は設定ファイルを書いて、 shellを実行する時間のみ
- 20. ISHIGAKIにおけるChef 〜開発スタイル〜 開発者 ④最新のコードを取得 ⑤開発対象チケット番号のブランチ作成 ⑥開発＆開発ブランチへのpush リーダ ①プロダクトバックログの登録 ②開発担当者の割当 ③担当機能の確認、チケットの更新 Git / Redmine連携 リーダ ⑦開発コードのレビュー 開発者 ⑧プロダクトブランチへマージ Redmineのチケットは自動でクローズ
- 21. Chef導入によるメリット ● 構築作業の短時間化 ○ Chef導入前後で４，５時間の作業 => 1時間程度に ● コード化による見える化 ○ 個々人が暗黙的に有していたノウハウがコードとして形 式知化され、ノウハウの共有がしやすくなった ● アプリ開発のノウハウを使った開発 ○ GitやRedmineを使ったレビューにて、設計から実装ま でレビューが出来る ○ チケットでの問題管理や変更履歴管理が出来る
- 22. Chef導入後の課題 ● Chefを使ってインフラをコード化することで様々 なメリットが得られた But… ● 構築後の確認は手作業で実施していた ○ 初期設定パラメータやRoleで指定した通りの設定になっ ているか？など ● Chefで享受出来るメリットが半減 インフラテストの自動化を推進
- 23. インフラテストの導入 ● テスティングフレームワークは当時、公開されて 間もないserverspecを導入 ○ 静的テストではなく、サーバ構築後の実際の状態をテス トしたかった ● テストはやり過ぎないように注意した ○ テストし過ぎると変更に弱くなる ○ プロセスが動いているか、適切なポートでリッスンしてい るか、といった基本的な内容をチェック ○ 設定ファイルはRoleで上書きしている値を中心にチェッ クし、デフォルト値はチェックしない
- 24. serverspecの紹介 ● 2013年3月末にリリース ● RSpecでサーバの状態をテスト ● 本質はサーバの状態を記述したコードをテスト ○ PuppetマニフェストやChefレシピなど ● インフラコードの開発やリファクタリングを効率よく 行うためのツール https://speakerdeck.com/mizzy/serverspec-at-jtf2014 より抜粋
- 25. serverspecの例 Apacheがインストールされてて、80番でリッスンしてるか describe package('httpd') do it { should be_installed } end describe port(80) do it { should be_listening } end 内部的には、sshで対象サーバにログインして rpm -q httpd を打ってパッケージがインストールされているか 内部的には、sshで対象サーバにログインして netstat -tunl | grep -- :80 を打って80ポートがリッスンしているか http://tech-sketch.jp/2014/04/serverspec.html
- 26. テストの自動化 serverspecでのテスト実装後、毎日自動で構築と テストを稼働させるように インフラCIの導入 ● Single / HA / Cluster構成から毎日1Editionの テストを夜間に実行 ● VMWareのスナップショット機能を活用 ● 最新のコードにてテストを実施
- 27. テストの自動化の構成 Cluster WebCluster Web Cluster APCluster AP Cluster DBCluster DB snap shot snap shot snap shot Cluster APHA snap shot Single snap shot ①VSphereAPIにて初期設定済みの スナップショットから初期化 管理サーバ 夜間実行 ②リポジトリより最新 のコードを取得 ③ISHIGAKI構築用のChefを実行 ④テスト用のserverspecを実行 ⑤テスト結果をAPIにてRedmineに登録 ＆メールにてテストレポートを送信
- 28. インフラCI導入による効果 ● 開発時に混入した不具合を早期に検知 ○ 4つのEditionを1つのchef-repoにて開発しているため、 開発時に不具合が混入する可能性 ● 自然に発生する不具合を早期に検知 ○ インフラ構築時に外部のリポジトリに依存 ○ リポジトリが突然消えることがあったが、早期に検知出 来るように ● 構築時の最新データを常に保持可能 ○ 実行時のattributeを保持しておくことで、最新の設定の 生データを保持出来る
- 29. インフラCI導入による効果 ● 開発時に混入した不具合を早期に検知 ○ 4つのEditionを1つのchef-repoにて開発しているため、 開発時に不具合が混入する可能性 ● 自然に発生する不具合を早期に検知 ○ インフラ構築時に外部のリポジトリに依存 ○ リポジトリが突然消えることがあったが、早期に検知出 来るように ● 構築時の最新データを常に保持可能 ○ 実行時のattributeを保持しておくことで、最新の設定の 生データを保持出来る Chefを使った開発では自動テストは必須！ テストを書いたらインフラCIを推奨！
- 32. Chefを導入して辛いと感じること① ● Cookbook作成の学習コスト・実装コスト ○ アプリとインフラが分業していることが多く、インフラエンジ ニアにはハードルがやや高い ○ 一度実装すれば便利だが、実装するまでに時間がかかる ○ attributeを多段に重ねた場合のデバッグがしづらい ■ 今後のツールに期待 テンプレート化することで、Chef開発を集約 shell開始 設定ファイル から生成 Attribute遷移 Webサーバの Role実行 APサーバの Role実行 DBサーバのRole 実行 管理サーバの Role実行 ※各Roleにて個別のRecipeを実行
- 33. Chefを導入して辛いと感じること② ● 個別のSI案件ではChefを活用しきれない ○ テンプレートが適用出来ないようなシステムは個別に構 築を実施 ○ テンプレートを使っても、運用フェーズからChefスクリプ トやChef Serverのメンテナンスが出来ない ■ 実質、構築時にChefを使っているのみ ■ 運用フェーズからは手作業によるメンテナンス Chef Serverによって享受できるメリット Chef Serverを使うまでの手間
- 34. まとめ ● ISHIGAKIにChefを採用したことで、様々なメ リットを享受できた ○ ノウハウ共有・開発手法・短時間化...etc… ● Chefでインフラをコード化したら必ずテストコー ドは書くべき ○ Chefでのコード化だけではメリット半減 ○ 更にインフラCIまで実践するとメリット大 ● Chef Serverの使いどころが難しい ○ SIでの活用場面が難しい...