この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
- 2013/07/20 JAWS-UG 横浜支部 第5回勉強会「chef on AWS ベストプラクティス」 #jawsug - Togetter
- JAWS-UG 横浜支部 第5回勉強会「chef on AWS ベストプラクティス」 on Zusaar
最近のChefの人気っぷりと言ったらもうすごい感じですね。(後述しますが)Chefにちなんだエントリや記事のはてブでの勢い然り、またChef絡みの勉強会やイベントについては申込開始後即定員が埋まるような盛況っぷりです。
そしてこの度、JAWS-UG横浜第5回が『chef x AWS』という何とも興味深いテーマで開催されるとの事でしたので、発見即申込！この日参加してきました。
開催会場は情報科学専門学校＠横浜。横浜駅西口、バスターミナルのある所から程無く近い場所にある専門学校の1室をお借りする形で行われました。会場が専門学校という事で、学校感満載な会場風景。(当たり前と言えば当たり前ですが)当日は他の会場(a.k.a 教室)でも様々な催し物が行われていたりで割と賑やかな感じの雰囲気でございました。
13:00 - 14:00 初めてのchefの教室
初めてのChefの教室 (v1.2 Chef11対応版) // Speaker Deck
- 自己紹介等
- 懇親会ピザ発注アプリ：勉強会でのピザ発注自体、母数が少ないのであまり…w 個人的には便利なので使っています、との事。
- AWS x Chefサポート
- EC2上にWebアプリが動作する環境を全部AWSで。監視等の環境も盛り込み。
- 2008年からChefを採用している。これは相当早い。2009年公開なのでそれよりも早い。
- 早かった理由→初期のコントリビュータのうち、3人がengineyardの中のひとがいた。
- 相当ディープにchefを使っている。
- Engine yard、chef超スキです。ほぼほぼchefの集団と言っても過言では無い。
Chefとは
- 現在、めちゃくちゃ流行っています。
- はてぶの件数、7月頭で1500件超。3月末で300だったので異常な伸び率。
- 個人的感想としてはgithub,jenkinsのポジションに居るのでは。
- Chef
- Opscode者のCCO, Adam Jacob 氏作。
- Ruby製のシステム管理ツール
- 設定ファイルを元にサーバを自動設定
- unix/linux/mac/windows対応、2013年に日本で大ブレイク。
- chefの歴史
- 2009/01/15 version 0.5
- 2009/04/29 version 0.6
- 2009/06/10 version 0.7
- 2010/06/21 version 0.9
- 2011/05/02 version 0.10
- 2013/02/04 version 11
- EngineYardでは主要3系統全てを使っている。Opsworksでは0.9。利用局面とバージョンをよく考えて使おう。
- Chefのトレンド
- 2010年のトレンド：[Adopt]の中に"infrastructure as code"として既に入っていた。
- 日本のエンジニアはすごい熱心、精緻な手順書を作成するのが得意。な反面IAAS as Codeに移行しづらい局面があった。
- インフラをコードで記述する時代が到来した。
- cookbookを元に設定
- Rubyで書かれたレシピの集まりがクックブック
- chefではレシピを元にホストを自動で設定する
- Chef client/server
- ローカルで設定ファイルを作る→サーバーに上げる→クライアントNodeはサーバChefServerに何をすべきか聞きに行く
- ohai:これを使って設定内容を返す
- 実行OS環境に問わず、システム情報をJSONで返してくれる仕組み。chef導入時に併せてばら撒かれる。
- About Ohai — Chef Docs
- ohaiを使ってサーバの情報をプログラムで扱おう - インフラエンジニアway - Powered by HEARTBEATS
- 豆知識 - 冪等性(べきとうせい)とohai
- 冪等性:何度実行しても同じ結果へ収束する
- ohai:実行中の環境の情報を取得するchefのプラットフォームを支えるモジュール。インストール＆アップデートのスクリプトを合わせたようなもの。
- バリエーション
- Hosted Chef
- OpsCodeがホスティングする。ノード数に応じた課金。
- Private Chef
- Firewall内で稼働、有償版はサポート有り。
- Chef Server
- OSSとしてChefServerを利用する事も出来る。管理対象が100台とかになるならCHefserverを立てるほうが良い？しかし安藤さんは使ったこと無い…サーバ用意とか面倒？
- Chef-Solo
- サーバー不要のChef
- ローカル上のクックブックを実行可能
- GUIは使えない
- chef-soloをキックするツールも多い。例)vagrant, engine yard, knife solo
- Hosted Chef
- なんか簡単そう？chef-solo大人気。
- 伊藤さんのあの本、大人気。分厚くて心が折れる本が多い中、120ページ位で挫折しない。スマホでも読める！
- 『ローカルからchef-soloを叩いていいのは小学生まで』by 伊藤直也さんのスライド『Vagrant + chef』
- chef-soloがknife-soloが全部やってくれるようになったので、だいぶ楽になってきた。
- まずはchef-soloでレシピを使った構築に慣れるのが吉。
セットアップ
- Ruby:自動化されたので気にしないで良し。
- solo.rb, node.jsson:書かなくても動く。
- /optに必要なruby等を全てインストール。
- この辺りの情報も参考になります。
- install
- curlを使った手法を紹介。※gemインストールは古い方法らしい。
- solo.rb
- 一時ディレクトリの場所の設定、クックブックのパスの設定等
- node.json
- chefサーバからのデータの代替
- クックブックへ渡す変数を設定
- 実行するレシピを指定
- chef-soloのヘルプに興味深い記述が：node.jsonに書く内容をコマンドラインに含めて動かす事も出来る。
- つまり...
- 未設定の状態からでも任意のクックブックを実行出来る。
- vagrant、すごい便利です！仮想マシンの管理に使ってないかたは是非試してみてください。
レシピの記述
- knifeコマンド
- chef-soloで利用する場合はクックブックの初期化作業に使う
- プラグインでサブコマンドを拡張可
- 割となんでも作れます。knife-twitter等も。/ higanworks/knife-twitter
- しかしヘルプは150行...
- クックブック作成
- knife cookbook create #{name}
- -> /var/chef/cookbook以下に作成
- chefサーバを使わないのでよしなにgithubやs3で管理
- ディレクトリ構造
- attributes/ レシピで利用したい変数等
- recipes/ レシピを置く場所。(platformごとにも出来る)
- templates/ 設定ファイルの雛形
- レシピ
- packageコマンド :パッケージをインストールする。 パッケージ名は各プラットフォームでブレがある場合も
- serviceコマンド :デーモンとしてサービスを実行。
- apt-getで良くね？
- →templateリソースの出番
- そして...
- engine yardの場合、突然の脆弱性問題も随時対応、配信している。
- engine yard Local / 活発なメンテナンス:月毎週10コミットとか
- knife cookbook create #{name}
情報の探し方
- 公開されているレシピ: 様々な方法で様々な団体がクックブックを公開。
- Opscode Community
- Github上のリソース
- opscode/cookbooks：公式
- rightscale/cookbooks_public
- engineyard/ey-cloud-recipes
- aws/opsworks-cookbooks：各プラットフォーム向け
- jsierles/chef_cookbooks：かつては37signalsのリポジトリだったもの
- pivotal/pivotal_workstation：ちょっと変わりどころで1つ。Pivotal開発者のPCセットアップ等に関するクックブック。chromeやMacの壁紙導入なども。
- 教訓
- 公式レシピはマルチプラットフォーム
- pass系は工夫が実装されている
- 独自に書くなら決め打ち可能
- 『手順書』を自動化する記述力
- クックブックの運用をどうする？
- 結論
- 頑張りたい人はとにかくレシピを書く。
- 頑張れない人はEngine Yardへどうぞ！
14:05 - 14:35 chef と capistrano の組み合わせ
Chef の気まぐれ環境構築 〜季節の Capistrano を添えて〜 #jawsug
- 自己紹介
- python関連のツールなどを作っている,blockdialog等
- chef歴は1.5年 community-cookbook推進派
Chefを使って環境構築しよう
- OSの設定、ミドルウェアのインストール、アプリのデプロイ
- あれ、chefでどうやってやるんだろう？
- application.cookbookを使う/opscode公式cookbook
- Java,php,Python,Railsに対応
- 利用事例が少ない(ググりづらい)
- 運用方法がよくわからない…バージョンアップの仕方/切り戻し方法/実験的に一部のサーバだけに入れたい
- デプロイ時にやること
- アプリの配布
- リリース前の準備: asset precompile, javascript compile/minify
- トラブル発生時のバージョンダウン(切り戻し)
- DBマイグレーション
- データ修正
- 一部の操作は冪等性と相性が悪く、chefに任せづらい。
- capistrano
- capistrano/capistrano
- Capistrano - Wikipedia
- 手元の端末からデプロイを行うツール
- デプロイ以外のメンテナンス用途にも使える
- 切り返しが考慮されている
- 情報が沢山ある
- デプロイは専用ツールの方がやりやすいのでは。環境構築・更新はchef-solo、アプリのデプロイはcapistrano、というように。
- なぜchef-soloなの？
- 扱うサーバの台数が少ない(〜10台)
- chef-serverを使うのは大げさ
- chef-serverを入れるリソースが勿体無い
- 殆ど構成が変化しない
- 運用保守に入ると変化が少なくなる
- 定期的にセキュリティアップデートをするくらい
- chef-client分のメモリが惜しい
- 扱うサーバの台数が少ない(〜10台)
Let's Cooking! -Paratrooper chefの紹介-
tk0miya/capistrano-paratrooper-chef
- knife-soloを複数台で扱う場合
- でもホスト名を並べるのはありえない…？並列実行がしずらい。
- ホストを列挙しないといけない
- それAWS SDKで出来るよ
- AWS SDKで対象ホストを自動抽出
- Webにはサンプルが大量に
- 幾つかgemもある
- ELB配下のホスト、タグ検索、特定の名前…
- 並列実行出来ない
- それxargsで(ry
- 基本的に全ての処理が並列に行われる
- max_hosts指定で制限も掛けられる
- capi経由でchef-soloを実行する
- 沢山ブログ記事がある。gemも幾つもある
- gemは幾つもあるが…
- 試しに作ってみた系の実装が多い。
- という訳で作ってみた。-> paratolooper-chef
- 既存のgemsとの違い
- rolesやdata_bagsに対応
- data_bagsの暗号鍵も使える
- librarianに対応
- ホスト毎に設定が変えられる
- windowsでも動く(rsyncを使っていない)
- Paratrooper chefの紹介:この辺りの資料も詳しい。( Paratrooper chef の紹介 @ Chef Casual Talks Vol.2 #eytokyo )
- chefのインストールもやって欲しい:対応しています。gem 経由,omnibus installer経由
- ホスト毎に設定を変えたい
- knife-soloっぽい仕組みを用意
- ホスト毎の定義ファイルを用意しておく
- cookbookマネージャを使いたい
- librarianに対応
- capistrano使った事無いんだけど...
- knife paratrooper initコマンドを用意、近日リリース予定
- capistrano+chef-soloの弱点
- 規模が大きい場合はやっぱりchef-server
- autoscalingには別の仕組みが必要
14:50 - 15:20 AWS OpsWorks を乗りこなせ
OpsWOrksって何？
- AWSの統合アプリケーションマネージメントソリューション。レイヤでアプリをモデル化して自動制御。
- 役割としては近いが、＝Chef Serverという訳では無い。
- コアとなる仕組み
- [OpsWorks→EC2]：Chef recipes,スタック全体の構成情報(JSON)、ライフサイクルイベントの通知を行う。
- [EC2→OpsWorks]：Chef recipesの実行結果、更新した構成情報(JSON)を返す。
- AWSのアプリケーション管理ソリューション、幾つかある。
- [フレキシブル(低)/使いやすさ(高)]
- [↑] Elastic Beanstalk
- [ ] OpsWorks
- [ ] CloudFormation
- [↓] EC2
- [フレキシブル(高)/使いやすさ(低)]
- 全て追加費用無しで使えます！いつも通りの従量課金。
- OpsWorksの管理単位
- OpsWorksによるライフサイクル管理
- Setup: インスタンスの構築、ソフトウェアのインストール
- Configure: 依存性のアップデート
- Deploy/Undeploy: アプリケーションのデプロイ/削除
- Shutdown: インスタンスをレイヤから削除
- AWS Opsworksのデモ:URL短縮サービス squishというRailsのサンプルアプリのデプロイを実施。
Opsworksを使う時の大事なポイントなど
- Opsworksを使う時の大事なポイント
- 各ライフサイクルステージの処理内容を適切に。
- setup: インスタンス起動時に1回だけ実行
- configure: インスタンスが増減した際に実行
- deploy: アプリケーションデプロイ時に実行
- アンチパターン:
- DBクラスタの参加処理をSetupフェーズで
- OSのソフトウェアパッケージのインストールをdeployフェーズで
- 各ライフサイクルステージの処理内容を適切に。
- スタック内の情報交換はJSONで。
- その他Tips
- カスタムレシピのテストはOpsworksの外でも: Knife-solo,Vargant-berkshelf
- Default VPCなアカウントならVPCの機能も: 復数インタフェース,復数IPアドレス
- 注意点やハマリどころ
- ChefやRubyのバージョンに気を付ける。
- カスタムレシピのアーカイブのディレクトリ構造
- カスタムレシピをアップデートしたらupdate_custom_recipesコマンドを実行
15:25 - 15:45 AWSでプロダクトつくってみた話
Services on AWS #jawsug yokohama // Speaker Deck
- 自己紹介
- KAYACの中の人、サーバやネットワーク周りを担当。
- 『クイズキングダム』等も担当。
- ISUCON(Iikanji Speed Up Contest)のお知らせ:優勝賞金ドドンと100万円！ 第三回 ISUCON 開催のお知らせ #isucon : ISUCON 結果が全てのガチンコバトル！
- (注意)これから話すのは会社ではなく個人の見解、だそうです。
- (注意)今回、Chefについては話しません。周りの話をします。
環境構成
- LTSV
- Labeled Tab-separated Values (LTSV)
- web-nginxのログはLTSVにすることでawk,sed祭りを回避。オペレーション的には楽に。
- fluentd
- Fluentd: Open Source Log Management
- ログ収集。adminサーバにログを流し、集めたログはS3バケットに飛ばす。
- ELBはデータ取れない(cloudwatchからしか)ので可視化出来る情報をこれで可視化。
- serverspec
- serverspec - Home
- chefが冪等性を保持するものの働きであれば、状態を全て把握しておこう、というもの。
- chef meets serverspec
- ブログ、書いてます。( testing #chef cookbook by #serverspec #devops - さよならインターネット )
- ちゃんとしてるだろう、ってサーバで動かしてみると色々出て来て面白い。中々ひとが目に付かない箇所を気づける。
- Chef
- 基本的にAWSでchefを使う際は特別な設定は必要ない。全く同じように動かせる。
- Capistrano
- capistrano/capistrano
- 手元でcoobookをごにょる
- pull req でgithubにレビュー後マージ
- マージしてもらったら対象サーバからpull
- サーバから各サーバにdeploy
- Zabbix
- ZABBIX-JP | Japanese Zabbix Community
- 監視ツール。
基本的にAWSとオンプレで特に変わる事無く動かせた。(繰り返しますが)基本的にAWSでchefを使う際は特別な設定は必要ない。全く同じように動かせます。
15:50 - 16:20 ChefとPuppetの比較: Puppetユーザーから見たChef(仮)
- 自己紹介
- 白金台の方から来ました。
- puppetユーザーから見たchefについてお話したいと思います。
クックパッド株式会社とpuppetのお付き合い
- 2009年
- 一部サーバにpuppetを導入
- 大嫌いでした：適用時にエラーが一杯/リソース競合の解消がめんどくさい/サーバとの認証でエラーが出る/外部DSLが分かり難い…等の理由で。
- 2010年
- AWSの検証開始、とりあえずpuppetを選択
- 2011年
- AWSに移行: 現在と概ね同じPuppet構成。ENCは未使用(ノードの更新は手動)、manifestの書き方が無茶苦茶
- puppetに嫌気が指していたのでchefに移行しようとしていた…
- 2012年
- VPCに移行
- puppet周りも刷新: ENCの導入/スタイルガイドに従ってリファクタリング/各種プラクティスに従って設計を変更
現在のサーバ構成
クライアント側の機能の比較
- ディレクトリ構成
- puppetにchefのような決められたディレクトリ構成は無い
- ベストプラクティスを追求するとだいたい似たような構成になる
- 基本的には殆ど同じ。
- ChefのRUby DSLは羨ましいです
- ビルドインのリソースはchefの方が充実しているかも
- puppetのロールの実体はモジュールです
- ロールにリソースを定義しているので、chefよりもやや柔軟かも。ohaiの代わりにfacterというツールを使う
- 継承
- リソース競合につながる事が多い。
- 一言で言えば『使うな』。二言で言えば『死んでも使うな』。使って良い事は無いw
- run stage
- 適用順を制御出来る。
- chefで必要になる機能では無いですね...
- Function
- server-idを設定
- 共通で使う関数を定義出来る
- シンタックスは例に漏れずダサいです
運用の機能の比較
- chef-server
- ノード管理
- chef-server+gitとENCについて
- ※どなたかgitを使える軽量chef-serverを作ると良いと思います。
16:35 - 17:05 Lightning Talk
今回のLTは合計3本でした。
もっと気軽に AWS CloudFormation
CloudFormationの概要やメリットなどを説明した後、所属会社のリリースプロダクトである『ダービーゲート』に関する紹介・説明をCloudFormationを重ねあわせて行う、という内容でした。
Chef with AWS
Chef with AWS by Hiroyuki Urasoko
Trotter Cashionの発表した以下スライド(普通に解説をすると4〜50分は掛かる、非常に内容の濃いもの)を、意訳しながらLT時間内でざっくり解説するという内容。これは改めて、じっくり読み解いて見たい内容ですね。
Chef and the Cloud – Trotter Cashion | Opscode Blog
全部見せます！Chefを1ヶ月半ほど使って学んだアレコレ
20130720 jaws yokohama-lightning_talk
クラスメソッドからは植木さんがLT参戦!!業務でChefを使い始めて感じた点をコンパクトに分り易くまとめたLTでした。
17:15 - 18:15 パネルディスカッション「環境構築自動化 on AWS ベストプラクティス」
- モデレーター：松尾 康博(TwitterID:@understeer)さん
- パネラー：講演者全員＋参加者のみなさん
JAWS-UG横浜代表の吉田真吾(TwitterID:@yoshidashingo)さん曰く、『今回一番やりたかった』こちらのディスカッション企画。色々なTipsが出て来てはいるものの、いざ自分のケースに当てはめてみると途端に情報が波の様に溢れかえっているので判断が難しかったりします。このディスカッションではその辺りのテーマなどに関して、議論を交わしてみよう！という訳です。
ディスカッションではモデレータとして松尾康博さん(実は横浜市在住だそうです)、パネラーとして今回の講演及びLTで発表された以下の8名による構成で進み、併せて参加者が時折コメント等で参加する形となりました。
以下、ディスカッションの内容をざっくりではありますが記録したものです。(発言者の名前については伏せさせて頂きます。ご了承ください。)
<お題その1> なぜChefだけこんなに盛り上がったんでしょう？ ChefとPuppetの棲み分けとか教育(洗脳)とかとかやっていますか？ (皆さんの周りで宗教戦争起きてます？)
- 全部Puppetなので使わざるを得ない。ユーザーがそんなに増えているという印象は無い？Puppetは古くから使い続けている場合はそのまま(使い続けてる)なのではないだろうか。
- Chef x Puppetのやり取りって、あんまない？
- Chefオンリーです。対立という感じは見られないのでは、と思う。一方で、DevはRubyを知ってるけど、インフラの人はRubyとインフラを両方覚える位ならManifestを覚えちゃう方が近いんじゃね？とも思う。
- 実はPuppetが好き、という人は？
- 『24x365(24時間365日)』が話題になった頃、Puppetにチャレンジしてみたが概念が中々頭の中に入って来なかった。今回改めてChefを学んでみて、(Chefは)言葉と概念がマッチしている、という印象を受けた。良いと思います。
- (Chefは)ググラビリディは低いですけどねw
- (ChefとPuppetは)入り口が違うというだけで、どっちが好き嫌いというのはあまりないのでは？と思います。
- 最近chefが採り上げられるのが多い印象がありますが…
- Chef x Puppetという戦いという印象ではない。双方試した事はあるけれど...最近はどちらも成熟しているし、第3精力的なツールとしてAnsibleというツールを追ってみている。これはツールを入れなくていい、と言うものです。そっち推し(第3勢力的な)なのは最近ちょっとあります。
- 新しい世代、ですね。
- ツールの移り変わりは早いです。
- なおやさんのブログがだいたいトレンド掴んでますね。
<お題その2> 自動構築の文脈でChefはよく出て来ますが、 本番運用に入った後Chefをどう活用していますか？ (レシピ変更後に本番適用するまでのプロセスとか)
- 本番反映後ミスるのを避けるための方策を検討中。画像サーバ立てて結果を検証し、serverspecを回すなどして対応している。本番サーバを模したものを用意するのが最善なんだろうけど…兼ね合いは難しい。
- CIのようにしていく、方針的なものは皆さん考えて居られますか？
- 色々試してみたが実践には至っていない。環境の都合、VMで挙がっているのでその辺はちょっと難しい。やりたいけどやっていない。
- ポリシーとしてrestart/reloadをむやみに書かないようにしている。ログもわかりやすいのを書くようにしている。それを目視。
- chef-serverを使ってcookbook毎の世代管理をするなど必要が出てくるのではないか。chef-soloだけでやる場合、カバー仕切れないのではないか。
- インフラ見て更にアプリまで…という人はなかなか居ない印象ですね。その辺は難しいですね…
- テストについてはプログラムから考えると、結合テストまでは行かない、という認識はあると思う。テストコードを仕込む事によって人為的ミスは防げる。いくら自動化しても最終的な品質保証は人の手。それ以外をどうするか。Devopsについては、会社が違うとそこで思考が止まってしまうのでは。SOAの究極がdevops？自分たちの手の及ぶ範囲でいかに効率化していくかが大事。
- (うちの会社では)今のところは上手くやっている。再発防止策も立てて対応している。一番活発なのはアプリデプロイ時、CIがずーっと回っていてステージング環境ででも確認している。コードはgithubでレビューし、ロールバック出来る環境を構築している。
- 運用ルールにも仕組みが必要なのですかね？
- やはり、ふわっと書いたもの(設定ファイル等)が出てしまうのは良くないと思います。
<お題その3> レシピの開発、テスト、メンテナンス、、、、 時間とお金(インスタンス代)かかりませんか？ どういう工夫していますか？
- 趣味でやっているのでコスト度外視という考え方も…w基本的にクックブックのバグを見つけたらRull Requestを送るという、割と面倒な方に時間を割いている。なるべくラフなクックブックを作っている。動けばいいものは動けばいい。後で自前のを使わなくても良いような感じにしている。
- OpsCodeが作っているものはレビューを通っている。一応人の手を介しているのでそちらにリソースを集中させる事で負担も減っていくのでは無いか。実感として負担が減って来た感はある。あと好みの問題もあるかも？
- 今やっているのはKVMでインスタンスを立ててテストを回したりして...というのをやっている。ポリシーとして『複雑な事はやらない』。バグの潜む危険性は避けている。機能ごとにクックブックを分けているのでバグは無いし、サービスが落ちることは無いような構成にしている。
- 複雑な仕組みが必要になった場合は？
- インフラ側で複雑なところって、最初にやるか、どっかで勇気を出してやるか、のどちらかしか無いと思う。これだったらうまく行くね、っていうのを確認してから導入するのが多いと思う。
<お題その4> 最終的には、Chef Server使ったほうがいいですか？ Chef-soloでどこまで頑張れますか？ どんなツールやAWSの機能(OpsWorks, CloudFormation, Metadata)と 組み合わせて頑張ってますか？
- (Chef Serverは)Rsyncに相当する部分が無いので楽。サーバの種類が10数種類という局面があったが、そういう場合だと大変かも。Chef-serverを立てるインスタンスの部分の料金をお客様が認めてくれるか。何百台となった時に管理するサーバとして用途的に必要かどうか。
- 使わない派です。3-4台に対して(適用させる)ならNoかな。こだわりとして実機と言う人も居る。やるとすると、色んな案件をまたがるchef-server…というのも考えたが...そうなるとchef-serverはno？capi位でカバー行けそうな気も。大きい台数なら需要がありそうかも？
- 構築ツールになってしまった感はある。ミドルウェアを最新状態にまで管理するというchef-soloでカバー出来ないところを何かでカバーする必要がある。バージョン管理を追いたいというのであれば良いかも知れないが...
- chefを環境構築ツールとしてみるか、構成情報管理としてみるか、というところがポイントですね。ちなみに、cloudfomaionとchefでカブる部分は？
- 良いラインを見つけるのは難しいですね。
- 全部chefに任せてしまったほうが良い？
- chefが使える環境であれば、chefに全部任してしまったほうが良いのでは。
- cloudformationのテストは大変です。これはAWSの中の人でもそう思いますw
- AWSに特化しないようにしている。特化したものを使うと引越しの際に困る。
- cloudformationは全然使ってません。使うとすればやはりどちらかに寄せるでしょうね。
<お題:ツイートより> AMIとの兼ね合いはどうしている？ どこまでcookbookでやって、どこからAMIで対応するか。バランス感覚等。
- 以前は色々なサービス毎にAMIを作っていたが破綻した。一部の特殊なサーバについてはバックアップ的にAMIを用いる場合もある。APサーバに関してはデプロイサーバ毎にバックアップを用意し、autosclaing時にそこから起動している。
- 弊社では全部chefにしている。 プロビジョニングでやる部分、AMIでやる部分を分ける。ただ時間が掛かる。chef-soloを完走させないといけない。Packerはその点、救世主に成り得るのではないかと思っている。機械的に作られたAMIを使って立てる事ができそう？
- 一度AMIにしてしまって差分を適用する、というのはバランスが良いのでは。
- AMIからクックブックを生成出来ない？出来ると嬉しい。
- キーの情報、リソース情報どうする？
- とある集まりで議論してみたが、明確な応えは出なかった。data-bagsがキーになる？adminサーバに手動で配置、という点を踏まえるのが妥当なのか。
- 規模感もあり、うちはそこまで管理しなきゃいけないキーってのはそんなにない。cloudwatchの情報とか、キー情報とか。IAMを使うようにしている。CloudHSMを使っていく事等は検討している。
- SOX対応を行なっている。結局のところ、こういう内容を実現する上では、何らかの認証サーバを配置し対処を行う事は必要になって来ると思う。
この後1〜2つテーマが合ったのですがメモを取り切れていたのはここまで。時間の都合で止む無く終わってしまいましたがとても内容の濃いディスカッションでした。
まとめ
最後は会場をご提供頂いた情報科学専門学校様からのAWSへの取り組み等のご紹介(実際授業でAWSを教えているらしいです)や、
2013/09/28に大阪ドームでの開催(！)を予定しているJAWS FESTA Kansai 2013のお知らせなどがありました。
これはやはりというか、ここまでか！というところだと思いますが、全編通して皆さんが伊藤直也さんの『入門Chef Solo - Infrastructure as Code』を猛烈推ししていたのは印象的ではありました。自分も現在写経＆読み進めている所ですが、この書籍は今後もChefを始めるなら必携の1冊！の地位を確固たるものにして行きそうですね。
Kindle向けに『入門Chef Solo - Infrastructure as Code』を出版しました - naoyaのはてなダイアリー
会場ご提供頂いた情報科学専門学校様、発表者の皆様、JAWS-UG横浜の皆様、そして当日ご参加された皆様、ありがとうございました！
35
