第2回 JAWS-UG 神戸 OpsWorks (Chef) 特集 !

開発運用の現場でのChef活用

２０１３年7月6日NRIネットコム株式会社　佐々木拓郎

本日のアジェンダ

‣ 自己紹介（5分）

‣ SIerの現場でのChef活用（15分）

‣ 自動化の先に（15分）

‣ Q&A（5分）

#jawsug

✦ プロフィール

‣ NRIネットコム株式会社　Webクラウド事業部

‣ Twitter: @katotaku, @dkfj（AWS関係はこちら）

‣ Facebook: takuro.sasaki

‣ blog: http://d.hatena.ne.jp/dkfj/

‣ 好きなAWSサービス：　S3,SQS

★ 備考

‣ 認定スクラム・マスター

‣ AWS認定ソリューションアーキテクト- アソシエイトレベル

@katotaku

自己紹介：　佐々木拓郎

NRIネットコム

✦ NRIグループで唯一関西を本社とする会社

‣ Webシステムを得意としているシステム会社

‣ 設計開発から運用まで全て行う為、

アプリケーション・インフラエンジニアが一杯いる

‣ Web系の仕事が多いため、ディレクター・デザイナーも一杯！！

‣ 大阪本社だけど、東京の方が人が多い。でも関西Love

NRIネットコムとAWSと私

• 2006年　米国の会社に出向中に、Amazon S3と出会うもEC2はスルー

• 2007年　EC2が仮想サーバということを知って使いはじめる

• 2008年　ブログでAWSのことを書き始める

✦ 2009年　会社の一部システムで、EC2を利用し始める

✦ 2010年　iPadを使った「モバイル会議」システムのインフラにAWSを採用

✦ 2011年　既存のお客様にも、徐々に勧め始める

✦ 2012年　AWSソリューションとして本格的に営業開始

✦ 2013年　趣味で使っていたものが本職になる。　←　イマココ

SIerの現場でのChef活用

Chefとは？

インフラの構築・管理を自動化する為のフレームワーク

Chefの基本

• Ruby製のサーバー設定の自動化ツール

• レシピと呼ばれる手順書を元にサーバを設定

• レシピを含め設定情報をまとめたものがクックブック

Infrastructure as Codeインフラをコードで制御する

と言ったものの

Too Many Chefsどれを選べば良いの？

http://www.flickr.com/photos/pvsbond/2256809428/

Chefの種類

分類 概要

OSS Chef •オープンソース版•自前で管理

Hosted Chef •Opscode社によるSaaS版•管理台数に応じて、課金される

Private Chef •Hosted Chefと同等の機能をプライベート環境で提供。•エンタープライズ向け

参照：Chef | Opscode

http://www.opscode.com/chef/

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の独自サービス 別物

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を問い合わせ＆実行

ノード情報の保存

Chef Solo

参照：運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみたhttp://d.hatena.ne.jp/dkfj/20130404/1365048462

chef solo

ローカルのRecipeを元に実行

Chef Solo + Knife Solo

参照：運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみたhttp://d.hatena.ne.jp/dkfj/20130404/1365048462

chef solo

knife solo から リモートで実行

knife soloknife soloからRecipeを

転送＆実行

chef solo

chef solo

OpsWorks

参照：運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみたhttp://d.hatena.ne.jp/dkfj/20130404/1365048462

chef solo

knife solo から リモートで実行

OpsWorksknife soloからRecipeを

転送＆実行

chef solo

chef soloノード情報の保存

Chefのレイヤー

ミドル

アプリ

OS

ネットワーク

OS＆ミドルウェアの管理

• パッケージの管理

• 設定ファイルの管理

• サービスの管理

• ユーザの管理

• etc.

参照：サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係http://d.hatena.ne.jp/dkfj/20130425/1366852899

Chefのレイヤー（実は）

ミドル

アプリ

OS

ネットワーク

• checkout　

• migrate　

• symlink　

• restart　

Capistrano風のアプリ・デプロイ機能

参照：deploy — Chef Docs

http://docs.opscode.com/resource_deploy.html

OpsWorksのレイヤー

ミドル

アプリ

OS

ネットワーク

• ネットワーク構築　

• サーバ調達

• ミドルウェア設定

• アプリのdeploy　OpsWorks

全てのレイヤーを担当（扱えるリソースは、まだ限定的）

何を選んだのか？

Chef Server & Client

理由

• AWS以外のシステム構築も行う　　⇒OpsWorksが対象外に

• 管理するサーバ台数／種類が多い　　⇒Chef soloだと、少ししんどい

• サーバの状態を管理したい　　⇒Chef Serverを選択

レシピは、どうやって作っているか？

Community Cookbook

• 大抵のプロダクトがある

• 環境面の考慮が多く複雑

Custum Cookbook

• 全部自前

• シンプルに書ける

Community Cookbookを参考に、独自でレシピを書き起こし。

Community or Custum Cookbook?

ディストリビューションの選択について

ディストリビューション メリット ・デメリット

Amazon Linux AMI

•AWSのサポート対象•無料•RHEL互換

•AWS上でしか動かない

Red Hat Enterprise

Linux

•サポート有り•サードパーティ製品の動作保証 •有料

CentOS •無料•RHEL互換 •一時期、更新が停滞していた

開発環境は、VagrantにしたいRHEL/CentOSを基本にすることを検討中

アプリのリリースChefのリリース機能は使わず

• リリース専用ツールの方が、細かい制御が出来る　　⇒言語ごとに最適されたロールバック機能、DBマイグレーション機能

• 既にノウハウが蓄積されている　　⇒Maven,Capistrano

• そもそもChefのリリース機能を知らなかった　　⇒当面は、動向を注視する

プロジェクトの現場での使い方

ローカル開発環境 ステージング環境

Chef Server

本番サーバ

本番サーバ

本番サーバ

•Chef開発、修正　

•サーバの動作テスト

•Chef修正

•サーバの動作テスト　

•アプリ含めてのテスト

①テスト済みレシピのアップロード

②レシピをGitに登録

③レシピをChef Serverにダウンロード

④レシピをChef Serverに登録

⑤Capistranoを使いリリース対象サーバのChef Clientをキック

⑥Chef Clientにより最新のレシピが取得され反映

ポイント

• Recipeはgitに集約

• Chef Clientの定期起動していない

悩みどころ

• AWSのAutoScaleを使っている場合は？ 　　⇒AMI化をどう考えるか？

• アプリのリリースは、どうするの？　　⇒何を使うの？

• ChefのRecipeのテストは？　　⇒手動でやってたら、何か変だよね？

AutoScaleとAMIChefで環境構築後にAMI化する。

AMI A AMI A’

AutoScale

AMI化

この運用については、検討継続中Jenkinsとの連携とかもしくはcfn-init利用

アプリのリリースCapistrano

Rails向けにデザインされたデプロイツール複数の環境に同じコマンドを送るツール

sshで通信

DB定義も更新

Capistrano

複数の環境にコマンド送信

AMI化は、システムに応じて柔軟に考える

フレームワークに応じて、MavenとかTFSも利用

ChefのRecipeのテスト

参照：Chef Cookbook Testing and Continuous Integration

http://www.slideshare.net/JulianDunn/cookbook-testing-and-ci-chefboston

• test-kitchen

• serverspec

• ChefSpec

• Minitests

• foodcritic

色々なレイヤーのテストツールが存在

どう組み合わせるか、悩み中。。。

Chefの継続的インテグレーション

参照：ChefのrecipeをJenkinsで継続的インテグレーションする方法 | Ryuzee.com

http://www.ryuzee.com/contents/blog/6371

①テストの起動

②まっさらなインスタンスの立ちあげ

③Recipeの適用④テスト

Recipeが腐らないように、日々テスト

自動化の先に

何故、自動化？

Chefを使って自動化するのは、手段に過ぎない。アジャイルやDevOpsも然り。

コアビジネスに集中出来る環境を作るのが目的

本音

• 面倒くさいのは嫌だ

• （私の）手作業のミスの確率は、異常に高い

• 同じことをやっても面白くない

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

Before AWS

参照：マイナー三兄弟なAmazon SNS,SQS,SESを激しくお勧めする。

http://d.hatena.ne.jp/dkfj/20130204/1359966577

After AWS

参照：マイナー三兄弟なAmazon SNS,SQS,SESを激しくお勧めする。

http://d.hatena.ne.jp/dkfj/20130204/1359966577

サーバ調達と構築の時間

調達

構築

Before AWS

調達

構築

After AWS

相対的に大きくなった

インフラ構築のスピードアップを考える必要が出てきた

自動 or 手動？

http://www.flickr.com/photos/bigberto/2680751025/http://www.flickr.com/photos/polanyi/188032816/

プログラマの三大美徳

1.怠慢(Laziness)

2.短気(Impatience)

3.傲慢(Hubris)

自動化しかない

アジャイルのレフトウィングとライトウィング

※株式会社チャンジビジョン　平鍋さんの許可を得ての使用。http://blogs.itmedia.co.jp/.shared/image.html?/photos/uncategorized/2012/09/09/whereisyouragile.png

自動化のヒント

目指している所黒い画面を使わずに、サーバを管理したい

でも、最近のターミナルは、白いですよね

サーバ設定以外の自動化

• アプリケーションのリリース　　⇒ロールバックの仕組み、DB定義管理

• ログ管理　　⇒ログ集約＆閲覧システム

• システム監視　　⇒システムの監視＆障害通知

アプリのリリースデプロイツールとJenkinsの組み合わせ

Jenkins

CapistranoMavenFabric

アプリ

DB定義も更新

ログ複数のサーバのログ管理が面倒くさい

オンプレミス時代 AWS黎明期 最近

？

自動的にサーバが増減

fluentd複数のサーバのログをリアルタイムで集約

参照

S3

ログビューアー良いのが無いので、作りました

ログ管理サーバ ログビューア

参照

• Node.js　

• ruby　

• mongoDB　

①S3にログ転送

②未処理のログ取得

③DBに格納 参照

サーバの状態監視

参考：クラウド監視サービス : 事例紹介 | NRIネットコムhttp://nri-net.com/products/cloud/aws_watch.html

ツールを組み合わせて、センターで監視

ログインしないサーバ管理ほぼ管理出来るようになりつつあります

でも、私はターミナルも好きです

不要

自律的なシステムもう少しで、自己修復するシステムが出来るのでは？

• システムのあるべき状態を知っている

• あるべき状態から外れたことを検知出来る

• 外れた所だけ直せばよいのでは？

　（プロセスの再起動、サーバの再起動）

何か出来そう。（OpsWorkの自動復旧的なもの）

最後に、繰り返しますが

自動化は目的ではない

目指しているのは、コアビジネスに注力すること（ビジネスのスピードアップの為の手段）

http://www.flickr.com/photos/jiteshjagadish/5178417174/

でも、エンジニアとして自動化自体が楽しい

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

リーン開発の本質何故、自動化するのかを整理する上でお勧め

参照：リーン開発の本質 | Amazon.co.jphttp://amzn.to/12gH4uE

継続的デリバリーどこを自動化していくのかを考える時に最適

参照：継続的デリバリー | Amazon.co.jphttp://amzn.to/15jGpha

入門Chef SoloChefの入門書といえば、これでしょ！！

参照：入門Chef Solo | Amazon.co.jphttp://amzn.to/19YeKU1

達人出版バージョンもお勧め！！

参照：入門Chef Solo | 達人出版http://tatsu-zine.com/books/chef-solo

参考スライド

• 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

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