第2回 JAWS−UG 神戸開発運用の現場でのChef活用

1. 第2回 JAWSUG 神戸 OpsWorks (Chef) 特集 ! 開発運用の現場での Chef活用２０１３年7月6日 NRIネットコム株式会社佐々木拓郎

2. 本日のアジェンダ ‣ 自己紹介（5分） ‣ SIerの現場でのChef活用（15分） ‣ 自動化の先に（15分） ‣ Q&A（5分） #jawsug

3. ✦ プロフィール ‣ NRIネットコム株式会社 Webクラウド事業部 ‣ Twitter: @katotaku, @dkfj（AWS関係はこちら） ‣ Facebook: takuro.sasaki ‣ blog: http://d.hatena.ne.jp/dkfj/ ‣ 好きなAWSサービス： S3,SQS ★ 備考 ‣ 認定スクラム・マスター ‣ AWS認定ソリューションアーキテクト- アソシエイトレベル @katotaku 自己紹介：佐々木拓郎

4. NRIネットコム ✦ NRIグループで唯一関西を本社とする会社 ‣ Webシステムを得意としているシステム会社 ‣ 設計開発から運用まで全て行う為、アプリケーション・インフラエンジニアが一杯いる ‣ Web系の仕事が多いため、ディレクター・デザイナーも一杯！！ ‣ 大阪本社だけど、東京の方が人が多い。でも関西Love

5. NRIネットコムとAWSと私 • 2006年米国の会社に出向中に、Amazon S3と出会うもEC2はスルー • 2007年 EC2が仮想サーバということを知って使いはじめる • 2008年ブログでAWSのことを書き始める ✦ 2009年会社の一部システムで、EC2を利用し始める ✦ 2010年 iPadを使った「モバイル会議」システムのインフラにAWSを採用 ✦ 2011年既存のお客様にも、徐々に勧め始める ✦ 2012年 AWSソリューションとして本格的に営業開始 ✦ 2013年趣味で使っていたものが本職になる。 ← イマココ

6. SIerの現場での Chef活用

7. Chefとは？インフラの構築・管理を自動化する為のフレームワーク

8. Chefの基本 • Ruby製のサーバー設定の自動化ツール • レシピと呼ばれる手順書を元にサーバを設定 • レシピを含め設定情報をまとめたものがクックブック Infrastructure as Code インフラをコードで制御する

9. と言ったものの Too Many Chefs どれを選べば良いの？ http://www.ﬂickr.com/photos/pvsbond/2256809428/

10. Chefの種類分類概要 OSS Chef •オープンソース版 •自前で管理 Hosted Chef •Opscode社によるSaaS版 •管理台数に応じて、課金される Private Chef •Hosted Chefと同等の機能をプライベート環境で提供。 •エンタープライズ向け参照：Chef | Opscode http://www.opscode.com/chef/

11. Chefの種類参照：Chef | Opscode http://www.opscode.com/chef/ 種類概要機能 Chef Server •サーバ／クライアント型 •構築が少し大変多い Chef zero •軽量版 Chef Server •認証/データ永続化/GUIなし Chef solo •スタンドアロン型 •Knife soloと組み合わせると便利 Chef apply •Recipe単位で利用出来る少ない OpsWorks •Chef soloをベースにしたAmazonの独自サービス別物

12. Chef Server/Client 参照：運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた http://d.hatena.ne.jp/dkfj/20130404/1365048462 chef server chef client chef client chef client chef clientがrecipieを取得＆実行 chef serverのRecipeを問い合わせ＆実行ノード情報の保存

13. Chef Solo 参照：運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた http://d.hatena.ne.jp/dkfj/20130404/1365048462 chef solo ローカルのRecipeを元に実行

14. Chef Solo + Knife Solo 参照：運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた http://d.hatena.ne.jp/dkfj/20130404/1365048462 chef solo knife solo からリモートで実行 knife solo knife soloからRecipeを転送＆実行 chef solo chef solo

15. OpsWorks 参照：運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた http://d.hatena.ne.jp/dkfj/20130404/1365048462 chef solo knife solo からリモートで実行 OpsWorks knife soloからRecipeを転送＆実行 chef solo chef solo ノード情報の保存

16. Chefのレイヤーミドルアプリ OS ネットワーク OS＆ミドルウェアの管理 • パッケージの管理 • 設定ファイルの管理 • サービスの管理 • ユーザの管理 • etc. 参照：サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係 http://d.hatena.ne.jp/dkfj/20130425/1366852899

17. Chefのレイヤー（実は）ミドルアプリ OS ネットワーク • checkout • migrate • symlink • restart Capistrano風のアプリ・デプロイ機能参照：deploy — Chef Docs http://docs.opscode.com/resource_deploy.html

18. OpsWorksのレイヤーミドルアプリ OS ネットワーク • ネットワーク構築 • サーバ調達 • ミドルウェア設定 • アプリのdeploy OpsWorks 全てのレイヤーを担当（扱えるリソースは、まだ限定的）

19. 何を選んだのか？ Chef Server & Client

20. 理由 • AWS以外のシステム構築も行う OpsWorksが対象外に • 管理するサーバ台数／種類が多い Chef soloだと、少ししんどい • サーバの状態を管理したい Chef Serverを選択

21. レシピは、どうやって作っているか？ Community Cookbook • 大抵のプロダクトがある • 環境面の考慮が多く複雑 Custum Cookbook • 全部自前 • シンプルに書ける Community Cookbookを参考に、独自でレシピを書き起こし。 Community or Custum Cookbook?

22. ディストリビューションの選択についてディストリビューションメリット・デメリット Amazon Linux AMI •AWSのサポート対象 •無料 •RHEL互換 •AWS上でしか動かない Red Hat Enterprise Linux •サポート有り •サードパーティ製品の動作保証 •有料 CentOS •無料 •RHEL互換 •一時期、更新が停滞していた開発環境は、Vagrantにしたい RHEL/CentOSを基本にすることを検討中

23. アプリのリリース Chefのリリース機能は使わず • リリース専用ツールの方が、細かい制御が出来る言語ごとに最適されたロールバック機能、DBマイグレーション機能 • 既にノウハウが蓄積されている Maven,Capistrano • そもそもChefのリリース機能を知らなかった当面は、動向を注視する

24. プロジェクトの現場での使い方ローカル開発環境ステージング環境 Chef Server 本番サーバ本番サーバ本番サーバ •Chef開発、修正 •サーバの動作テスト •Chef修正 •サーバの動作テスト •アプリ含めてのテスト ①テスト済みレシピのアップロード ②レシピを Gitに登録 ③レシピを Chef Serverにダウンロード ④レシピを Chef Serverに登録 ⑤Capistranoを使いリリース対象サーバの Chef Clientをキック ⑥Chef Clientにより最新のレシピが取得され反映ポイント • Recipeはgitに集約 • Chef Clientの定期起動していない

25. 悩みどころ • AWSのAutoScaleを使っている場合は？ AMI化をどう考えるか？ • アプリのリリースは、どうするの？何を使うの？ • ChefのRecipeのテストは？手動でやってたら、何か変だよね？

26. AutoScaleとAMI Chefで環境構築後にAMI化する。 AMI A AMI A AutoScale AMI化この運用については、検討継続中 Jenkinsとの連携とかもしくはcfn-init利用

27. アプリのリリース Capistrano Rails向けにデザインされたデプロイツール複数の環境に同じコマンドを送るツール sshで通信 DB定義も更新 Capistrano 複数の環境にコマンド送信 AMI化は、システムに応じて柔軟に考えるフレームワークに応じて、MavenとかTFSも利用

28. ChefのRecipeのテスト参照：Chef Cookbook Testing and Continuous Integration http://www.slideshare.net/JulianDunn/cookbook-testing-and-ci-chefboston • test-kitchen • serverspec • ChefSpec • Minitests • foodcritic 色々なレイヤーのテストツールが存在どう組み合わせるか、悩み中。。。

29. Chefの継続的インテグレーション参照：ChefのrecipeをJenkinsで継続的インテグレーションする方法 | Ryuzee.com http://www.ryuzee.com/contents/blog/6371 ①テストの起動 ②まっさらなインスタンスの立ちあげ ③Recipeの適用 ④テスト Recipeが腐らないように、日々テスト

30. 自動化の先に

31. 何故、自動化？ Chefを使って自動化するのは、手段に過ぎない。アジャイルやDevOpsも然り。コアビジネスに集中出来る環境を作るのが目的

32. 本音 • 面倒くさいのは嫌だ • （私の）手作業のミスの確率は、異常に高い • 同じことをやっても面白くない

33. クラウド時代の前と後を比べると？

34. Before AWS 参照：マイナー三兄弟なAmazon SNS,SQS,SESを激しくお勧めする。 http://d.hatena.ne.jp/dkfj/20130204/1359966577

35. After AWS 参照：マイナー三兄弟なAmazon SNS,SQS,SESを激しくお勧めする。 http://d.hatena.ne.jp/dkfj/20130204/1359966577

36. サーバ調達と構築の時間調達構築 Before AWS 調達構築 After AWS 相対的に大きくなったインフラ構築のスピードアップを考える必要が出てきた

37. 自動 or 手動？ http://www.ﬂickr.com/photos/bigberto/2680751025/http://www.ﬂickr.com/photos/polanyi/188032816/

38. プログラマの三大美徳 1.怠慢(Laziness) 2.短気(Impatience) 3.傲慢(Hubris)

39. 自動化しかない

40. アジャイルのレフトウィングとライトウィング ※株式会社チャンジビジョン平鍋さんの許可を得ての使用。 http://blogs.itmedia.co.jp/.shared/image.html?/photos/uncategorized/2012/09/09/whereisyouragile.png 自動化のヒント

41. 目指している所黒い画面を使わずに、サーバを管理したいでも、最近のターミナルは、白いですよね

42. サーバ設定以外の自動化 • アプリケーションのリリースロールバックの仕組み、DB定義管理 • ログ管理ログ集約＆閲覧システム • システム監視システムの監視＆障害通知

43. アプリのリリースデプロイツールとJenkinsの組み合わせ Jenkins Capistrano Maven Fabric アプリ DB定義も更新

44. ログ複数のサーバのログ管理が面倒くさいオンプレミス時代 AWS黎明期最近？自動的にサーバが増減

45. ﬂuentd 複数のサーバのログをリアルタイムで集約参照 S3

46. ログビューアー良いのが無いので、作りましたログ管理サーバログビューア参照 • Node.js • ruby • mongoDB ①S3にログ転送 ②未処理のログ取得 ③DBに格納参照

47. サーバの状態監視参考：クラウド監視サービス : 事例紹介 | NRIネットコム http://nri-net.com/products/cloud/aws_watch.html ツールを組み合わせて、センターで監視

48. ログインしないサーバ管理ほぼ管理出来るようになりつつありますでも、私はターミナルも好きです不要

49. 自律的なシステムもう少しで、自己修復するシステムが出来るのでは？ • システムのあるべき状態を知っている • あるべき状態から外れたことを検知出来る • 外れた所だけ直せばよいのでは？（プロセスの再起動、サーバの再起動）何か出来そう。（OpsWorkの自動復旧的なもの）

50. 最後に、繰り返しますが

51. 自動化は目的ではない目指しているのは、コアビジネスに注力すること（ビジネスのスピードアップの為の手段） http://www.ﬂickr.com/photos/jiteshjagadish/5178417174/ でも、エンジニアとして自動化自体が楽しい

52. 自動化に取り組む上でお勧めの書籍

53. リーン開発の本質何故、自動化するのかを整理する上でお勧め参照：リーン開発の本質 ¦ Amazon.co.jp http://amzn.to/12gH4uE

54. 継続的デリバリーどこを自動化していくのかを考える時に最適参照：継続的デリバリー ¦ Amazon.co.jp http://amzn.to/15jGpha

55. 入門Chef Solo Chefの入門書といえば、これでしょ！！参照：入門Chef Solo ¦ Amazon.co.jp http://amzn.to/19YeKU1 達人出版バージョンもお勧め！！参照：入門Chef Solo ¦ 達人出版 http://tatsu-zine.com/books/chef-solo

56. 参考スライド • AWS上でのWebアプリケーションデプロイ : http://www.slideshare.net/AmazonWebServicesJapan/20130506-23096544 • 入門 Chef Server #biglobetechtalk : http://www.slideshare.net/biglobedojo/chefserver-rev100 • ChefとOpsWorksで EC2 楽チンクッキング! : http://www.slideshare.net/classmethod/20130513-21235033 • Chef Cookbook Testing and Continuous Integration : http://www.slideshare.net/JulianDunn/cookbook-testing-and-ci- chefboston • Chef 11概要-osct : http://www.slideshare.net/jhotta/chef-11osct • 開発に関わらないＣｈｅｆユーザの日々 #eytokyo : http://www.slideshare.net/koemu/chef-casual-talks20130415-18859603

57. ご清聴ありがとうございました後日の質問は、@dkfjまで

http://d.hatena.ne.jp	952
http://benkana.hatenadiary.jp	321
http://blog.cloudpack.jp	303
https://twitter.com	80
http://blog.hatena.ne.jp	48
http://yoshidashingo.hatenablog.com	27
http://hatenatunnel.appspot.com	16
http://blog.takuros.net	14
http://jfeeds.carsmantra.com	12
http://www.feedspot.com	9
http://cloud.feedly.com	6
http://3449707904234438373_ebb5d0aa9dae40f61c46202be459da9b0f197f5a.blogspot.com	4
http://webcache.googleusercontent.com	2
http://54.249.80.26	1
http://s.deeeki.com	1
http://192.168.33.10	1

SlideShare for iOS

Views

Actions

Embeds 1,797

Report content

Transcript