![構築を自動化する
Chefでサーバーを管理する
•インスタンス起動
•[Chefで自動化] アカウント作成（SSH公開鍵を配備）
•[Chefで自動化] パッケージをインストール
•[Chefで自動化] ディレクトリ/ファイルの配備
•[Chefで自動化] 設定ファイル修正
•iptables
•logrotate
•crontab
•ミドルウェア（Apacheなど）
•[Chefで自動化] etc…](https://image.slidesharecdn.com/5-131123062403-phpapp02/85/VPC-Chef-AWS-24-320.jpg)
![レシピ例 パッケージインストール
Chefでサーバーを管理する
# Packages
パッケージを
インストール
%w{httpd24 httpd24-devel httpd24-tools}.each do |pkg|
package pkg do
action :install
end
end
!
# Service
サービスに登録
サービスを起動
service "httpd" do
supports :status => true, :restart => true, :reload => true
action [ :enable, :start ]
end
!
# Configuration
ERBで書かれた
設定ファイルを
指定の権限で配置
template "httpd.conf" do
path "/etc/httpd/conf/httpd.conf"
source "httpd.conf.erb"
owner "root"
group "root"
mode 0644
end](https://image.slidesharecdn.com/5-131123062403-phpapp02/85/VPC-Chef-AWS-29-320.jpg)
![詳しくは入門Chef Soloがお勧め
Chefでサーバーを管理する
入門Chef Solo - Infrastructure as Code [Kindle版]
http://www.amazon.co.jp/入門Chef-Solo-Infrastructure-as-Code-ebook/dp/B00BSPH158
@naoya_ito さんによるChef解説本
サーバー状態管理フレームワークChef、そのスタンドアロ
ン版であるChef Soloの使い方について、はじめの一歩から
実戦投入レベルに至るまでを解説。試験環境の構築方法、自
動化コードの書き方、Chef のアーキテクチャや思想までを
実例を通して説明します。](https://image.slidesharecdn.com/5-131123062403-phpapp02/85/VPC-Chef-AWS-31-320.jpg)
![× Chef実験環境 → 本番導入
Chefの導入に失敗しないために
•[問題] 実験用インスタンスで試しただけですぐに本番導入
•実験のみだと「実験が成功 = レシピが完成 = 実験終了」
•レシピが枯れていない → 本番で思わぬエラーなどに出会う可能性
•とはいえ、実験用の同じ構成で何回実行しても結果は同じ
•[解決] 開発環境をChefで管理するところから始める
•プログラムと同じように開発 -> ステージング -> 本番の流れにする
•できるだけ開発環境と本番環境のレシピを共通化
•開発環境で普段からChefを実行 → レシピが枯れる
•logrotateなども実際に歳月を重ねつつ動作を検証できる](https://image.slidesharecdn.com/5-131123062403-phpapp02/85/VPC-Chef-AWS-36-320.jpg)
![× いきなりコミュニティのレシピ
Chefの導入に失敗しないために
•[問題] いきなりコミュニティのレシピのみで構築しようとする
•コミュニティのレシピは巨大で一見複雑なことが多い ※注1
•RoleやAttributeなどの知識がないとまともに運用できない
•OS別の分岐なども多く何が起こっているのか把握しずらい
•[解決] 自分たちに必要最低限の記述をしたレシピから始める
•インフラは作ったら終わりではない
•運用こそ重要 = レシピを自分たちで修正できることが大切
注1 コミュニティのレシピが悪い訳ではなく、コミュニティのものが優れていたとしても、という意味です](https://image.slidesharecdn.com/5-131123062403-phpapp02/85/VPC-Chef-AWS-37-320.jpg)
![× 最初から完全自動化を目指す
Chefの導入に失敗しないために
•[問題] 最初から完全に自動でサーバー構築することを目指してしまう
•Chefは最初の一歩は簡単だが、複雑なことをするにはまだ情報が少ない
•ちょっとしたことがエレガントにできず挫折する可能性
•導入までのコストが大きすぎて導入メリットを見失う
•部長『それ、いつまでやってるの？』
•C子『すすすみません、これを導入すればコスト削減がががが』
•[解決] 部分的にChefで管理するところから始める
•新規サーバー構築時に毎回実行するものだけでも十分価値がある
•管理サーバーが少なければchef-soloだけで構築するのもあり](https://image.slidesharecdn.com/5-131123062403-phpapp02/85/VPC-Chef-AWS-38-320.jpg)
More Related Content
What's hot (20)
Viewers also liked (8)
Similar to 小さく始めて後で困らないためのVPCとChefを使ったAWS運用 (20)
![さくらのクラウドフォーメーション with Chef [XEgg session]](https://cdn.slidesharecdn.com/ss_thumbnails/xegg01-chef-140214221012-phpapp02-thumbnail.jpg?width=560&fit=bounds)
Recently uploaded (8)
小さく始めて後で困らないためのVPCとChefを使ったAWS運用
- 1. 小さく始めて後で困らないための VPCとChefを使ったAWS運用 2013/11/23 第5回 関西ソーシャルゲーム勉強会 すずな株式会社 代表取締役 中村 悟
- 2. 目次 • 自己紹介 • 小さく始めて後で困らないために •Amazon VPCを利用する •Chefでサーバーを管理する •Chefの導入に失敗しないために
- 3. Twitter @cloned 自己紹介 営業マン 派遣エンジニア 株式会社アスク ドット ジェーピー ウノウ株式会社 ジンガジャパン株式会社 すずな株式会社 代表取締役 中村 悟 http://www.suzna.com/
- 5. すずなのゲームについて 自己紹介 インサイド クリプト https://play.google.com/store/apps/details?id=com.suzna.labyrinth.android 2013/4/25 リリース（Android 2.3 〜 4.3） サクサク快適にプレイできるシミュレーションゲームを舞台 に、盗まれた国家機密が保存された暗号化ディスクに潜入する ミステリアスなストーリー、友達と一緒に遊ぶ・他プレイヤー を倒すソーシャル性、ゲームを盛り上げるゲームミュージック が魅力なゲームです。
- 7. AWSを利用しています 弊社ゲームのサーバー構成例 利用しているサービス • Amazon VPC (Amazon Virtual Private Cloud) • Amazon EC2 (Amazon Elastic Compute Cloud) • Elastic Load Balancing • EBS (Amazon Elastic Block Store) • Elastic IP • Amazon S3 (Amazon Simple Storage Service) • Amazon Route 53
- 8. 弊社ゲームのサーバー構成例 弊社ゲームのサーバー構成例 Amazon S3 VPC 10.0.0.0/24 HTTPS Elastic Load HTTP Balancing VPC 10.0.1.0/24 E C 2 Apache E C 2 SSH E C 2 E C 2 踏み台 Nagios Capistrano E C 2 MySQL Memcached NAT ※構成は若干省略。台数・IPアドレスはイメージです。
- 10. Amazon VPCを利用する
- 11. Amazon VPCとは？ Amazon VPCを利用する •仮想ネットワークが構築可能 •IPアドレス範囲の選択 •サブネットの作成 •ルートテーブル、ネットワークゲートウェイの設定 •EC2の使用料以外の追加料金はなし
- 12. なぜVPCが必要か？ Amazon VPCを利用する Amazon VPCトレーニング-VPCの説明 P6 より引用 http://www.slideshare.net/AmazonWebServicesJapan/amazon-vpcvpc •ネットワークセキュリティを高める •きめ細かなアクセス制御が可能 •Security Group, NACL, Route Table, etc •VPN, DXを使って完全に外部と閉じた環境を実現 •自由なネットワーク設計が可能 •既存のネットワークルールを適用可能 •ローカルIPを固定で使用可能
- 14. なぜサービス開始時点？ Amazon VPCを利用する •クラウドを利用する動機の一つとして •サービス規模に見合ったコストにしたい •小規模で始めたい •負荷が上がればサーバーを増やしたい
- 15. なぜサービス開始時点？ Amazon VPCを利用する ! •負荷が上がればサーバーを増やしたい •負荷が上がるのはどういう時？ •サービスに人気が出た時 •プロモーションを行った時 •プログラムが変更された時
- 16. なぜサービス開始時点？ Amazon VPCを利用する •負荷が上がってしまうと？ •サービス人気 → 一刻も早くサーバーを増設したい！ •プロモーション → 落ちると困るから増設して対応しよう！ •プログラム変更 → 改修は時間がかかるからまずは増設で！※注1 •VPCのことなど忘れてEC2インスタンスがどんどん増える・・・ •気付いた時にはインターネット上に大量のEC2インスタンスが・・・ •規模大きくなってからのVPC移行は大変 注1 本来的には増設を行わずに原因を修正するべきですが、運用上の可能性として
- 17. インターネットにEC2を増やすと Amazon VPCを利用する •並列にインスタンスが存在するため、インスタンスの把握が難しい •グローバルIPを持ったインスタンスが大量になる •ネットワークを利用したセキュリティを確保できない ※注1 •例: 3306(MySQL)を自分の管理するサーバーのみにアクセス制限 •適切なIPアドレスの範囲を指定できない・・・ •セキュリティグループが複雑怪奇に・・・ •再起動毎にグローバルIPが変わりメンテナンス地獄 •Elastic IP付与したとしても大量のElastic IPが必要になる 注1 ここではネットワークのみ言及しておりMySQLによるアカウント制限やOSの機能には触れていません
- 18. まとめ Amazon VPCを利用する •EC2を使う場合は最初からVPCにした方が良い •VPCが不要かもしれないケース •インスタンス1台で運用を始めたい •サービス用途ではなく今すぐ立ち上げたい
- 19. Chefでサーバーを管理する
- 20. Chefとは？ Chefでサーバーを管理する Chef http://www.opscode.com/chef/ Chef is an automation platform that transforms infrastructure into code. Chefはインフラをコードに変える自動化プラットフォーム •Server + Nodes + Workstation •Server(クライアント管理)とNodes(管理対象サーバー) とWorkstation(操作端末)の3つで構成される基本構成 •chef-solo •サーバーアクセス不要でローカルホストのみで動作可能 •弊社では今のところchef-soloのみを利用
- 21. 手作業で構築すると？ Chefでサーバーを管理する •インスタンス起動 •アカウント作成（SSH公開鍵を配備） •パッケージをインストール •ディレクトリ/ファイルの配備 •設定ファイル修正 •iptables •logrotate •crontab •ミドルウェア（Apacheなど） •etc…
- 23. 手作業の問題点 Chefでサーバーを管理する •手順が多い •ミスが発生しやすい •同じ作業をサーバーN台分繰り返し •作業者のモチベーションが撃沈墜落 •確認項目が多い（目視！ 目視！ 目視！） •見逃す可能性が高い •一子相伝☆秘伝のシェル •ノウハウが個人依存なことが多い •（経験的にですが）大抵はメンテ不能のスパゲティ🍴
- 24. 構築を自動化する Chefでサーバーを管理する •インスタンス起動 •[Chefで自動化] アカウント作成（SSH公開鍵を配備） •[Chefで自動化] パッケージをインストール •[Chefで自動化] ディレクトリ/ファイルの配備 •[Chefで自動化] 設定ファイル修正 •iptables •logrotate •crontab •ミドルウェア（Apacheなど） •[Chefで自動化] etc…
- 25. 自動化すれば Chefでサーバーを管理する •手順が多い •→ 手順はChefを実行するだけ •同じ作業をサーバーN台分繰り返し •→ 各サーバー（ノード）がどのレシピを使うか設定する •確認項目が多い（目視！ 目視！ 目視！） •→ Chefには冪等（べきとう）性があり同じ状態になる筈 •ただし、レシピが正しい前提にはなるので serverspec を使ってさらに確 認するケースもあるようです •一子相伝☆秘伝のシェル •→ Chefはオープンソースでノウハウも公開されている
- 26. Chefも最初から導入すべき？ Chefでサーバーを管理する • 小規模だからこそ • サーバーが増えれば増えるほど恩恵が得られる • 最初から導入していれば • Chefのレシピを修正して反映 → 日常的な運用の一つ • 最初から導入していないと • Chefそのものを導入する → 試験のコスト、導入のリスクが大きい • 最初にChefを導入する時は、手動構築よりコスト増では？ • Chefのノウハウは次のサービスでも利用できる • 構成の修正がある度に使えるので、すぐに元は取れると思われる
- 29. レシピ例 パッケージインストール Chefでサーバーを管理する # Packages パッケージを インストール %w{httpd24 httpd24-devel httpd24-tools}.each do |pkg| package pkg do action :install end end ! # Service サービスに登録 サービスを起動 service "httpd" do supports :status => true, :restart => true, :reload => true action [ :enable, :start ] end ! # Configuration ERBで書かれた 設定ファイルを 指定の権限で配置 template "httpd.conf" do path "/etc/httpd/conf/httpd.conf" source "httpd.conf.erb" owner "root" group "root" mode 0644 end
- 30. レシピ例 crontab設定 Chefでサーバーを管理する crontabを設定 cron "sync-s3" do user "suzna" weekday "*" day "*" hour "4" minute "00" command "s3cmd sync /home/suzna/backups s3://com.example/" action :create end /var/spool/cron/suzna # Chef Name: sync-s3 00 4 * * * s3cmd sync /home/suzna/backups s3://com.example/
- 31. 詳しくは入門Chef Soloがお勧め Chefでサーバーを管理する 入門Chef Solo - Infrastructure as Code [Kindle版] http://www.amazon.co.jp/入門Chef-Solo-Infrastructure-as-Code-ebook/dp/B00BSPH158 @naoya_ito さんによるChef解説本 サーバー状態管理フレームワークChef、そのスタンドアロ ン版であるChef Soloの使い方について、はじめの一歩から 実戦投入レベルに至るまでを解説。試験環境の構築方法、自 動化コードの書き方、Chef のアーキテクチャや思想までを 実例を通して説明します。
- 32. 参考: 弊社Chef管理対象 Chefでサーバーを管理する •インスタンス起動 •アカウント作成（SSH公開鍵を配備） → YES •パッケージをインストール → YES •ディレクトリ/ファイルの配備 → YES •設定ファイル修正 → YES
- 33. 弊社Chef設定ファイル管理対象 Chefでサーバーを管理する •SSH /home/<USER>/.ssh/ •Apache /etc/httpd/ •MySQL /etc/my.cnf, /var/lib/mysql/ •Memcached /etc/sysconfig/memcached •Nagios /etc/nagios/ •logrotate /etc/logrotate.d/ •crontab /var/spool/cron/ •etc…
- 34. まとめ •サーバー構築を自動化して手作業のコストとリスクを減らす •時代は自動化の流れ •入門Chef Soloがお勧め
- 35. Chefの導入に失敗しないために
- 36. × Chef実験環境 → 本番導入 Chefの導入に失敗しないために •[問題] 実験用インスタンスで試しただけですぐに本番導入 •実験のみだと「実験が成功 = レシピが完成 = 実験終了」 •レシピが枯れていない → 本番で思わぬエラーなどに出会う可能性 •とはいえ、実験用の同じ構成で何回実行しても結果は同じ •[解決] 開発環境をChefで管理するところから始める •プログラムと同じように開発 -> ステージング -> 本番の流れにする •できるだけ開発環境と本番環境のレシピを共通化 •開発環境で普段からChefを実行 → レシピが枯れる •logrotateなども実際に歳月を重ねつつ動作を検証できる
- 37. × いきなりコミュニティのレシピ Chefの導入に失敗しないために •[問題] いきなりコミュニティのレシピのみで構築しようとする •コミュニティのレシピは巨大で一見複雑なことが多い ※注1 •RoleやAttributeなどの知識がないとまともに運用できない •OS別の分岐なども多く何が起こっているのか把握しずらい •[解決] 自分たちに必要最低限の記述をしたレシピから始める •インフラは作ったら終わりではない •運用こそ重要 = レシピを自分たちで修正できることが大切 注1 コミュニティのレシピが悪い訳ではなく、コミュニティのものが優れていたとしても、という意味です
- 38. × 最初から完全自動化を目指す Chefの導入に失敗しないために •[問題] 最初から完全に自動でサーバー構築することを目指してしまう •Chefは最初の一歩は簡単だが、複雑なことをするにはまだ情報が少ない •ちょっとしたことがエレガントにできず挫折する可能性 •導入までのコストが大きすぎて導入メリットを見失う •部長『それ、いつまでやってるの？』 •C子『すすすみません、これを導入すればコスト削減がががが』 •[解決] 部分的にChefで管理するところから始める •新規サーバー構築時に毎回実行するものだけでも十分価値がある •管理サーバーが少なければchef-soloだけで構築するのもあり
- 40. ご清聴ありがとうございました