そうだ、HTTP/2に移行しよう(実践編)
こんにちは、エンジニアの吉田です。 前回そうだ、HTTP/2に移行しよう(OpsWorks編)の記事を執筆しましたが、今回はその続編となります。 (前回から時間が経ってしまい申し訳ないです汗) 前回はHTTP/2に移行する為にAWS OpsWorksを用いたChef12スタックでの シンプルな環境を構築するところまでお伝えしました。 しかし実際はChef12スタックは、Chef11以前のスタックと違い それまでのレシピの運用方法を変えなければなりません。 今回は、現場でのOpsWorks Chef12スタックにおける課題の解決にフォーカスした実践編となります。 実践編 その1. OpsWorksのChef12スタックでコミュニティクックブックを利用したレシピを実行する Chef12スタックで最も注意しなければならない点は、レシピを実行する際に 利用するコミュニティクックブックの参照が自動的に行われなくなったことです。 試しにコミュニティクックブックを利用したレシピをそのまま実行しようとしたら 「コミュニティクックブック?そんなの見つからないよ！」と怒られます。 なので解決方法としてはコミュニティクックブックを含んだクックブックアーカイブを事前に作成し s3にアップロードした場所を参照するようにします。 コミュニティクックブックを含んだクックブックアーカイブを作成 [前提条件] アーカイブ作成にはBerkShelfをインストールしている必要があります。 もし無い方はChefDKをインストールするか、もしくはGemでBerkShelfをインストールしてください。 ChefDK: https://downloads.chef.io/chefdk Gem: gem install berkshelf [手順] 1. ローカルでクックブックのディレクトリに移動する 2. berks packageコマンドを実行してアーカイブを作成する デフォルトだとcookbooks-1506749951.tar.gzといったタイムスタンプ付きのアーカイブが出来上がります。 もしファイル名を指定したい場合はberks package {ファイル名}.tar.gzのようにコマンドを実行します。 3. アーカイブを格納する為のs3バケットを作成する 4. 手順3で作成したバケットにアーカイブをアップロード AWS CLIのS3コマンドが便利です。 aws s3 cp cookbooks.tar.gz s3://{バケット名}...そうだ、HTTP/2に移行しよう(OpsWorks基本編)
こんにちは、チーム活性化サービス「Goalous」のリードエンジニアを務めている吉田です。 今回はGoalousがHTTP/1.1からHTTP/2に移行した経緯と実際にどのように移行したのかをお話します。 なぜ移行したか 僕達は先月までサービス全体の大規模なパフォーマンス改善を1ヶ月半以上かけて行っていました。 Goalousは以前からレスポンスの悪さがかなり目立っていて、「表示速度が遅い」という意見が多く寄せられていました。 開発チームとしてはユーザーのストレスを軽減してサービスの使い心地を向上させたい、 「サクサク動かせるようにしたい」という思いが前々からありましたが ただ機能追加・改善がどうしても優先的になってしまい手をつけることが出来ずにいました。 しかしサービスを有料化する前にはどうしても対応したかったこともあり、 今年5月にチームの総力をあげてサービス全体のパフォーマンス改善に取り組むことが決定しました。 HTTP/2への移行はそのパフォーマンス改善の一つの取り組みです。 HTTP/2のメリットの詳細は今回は省略しますが、詳しく知りたい方はこちらを参照下さい。 HTTP/2への移行を決めたのは、リクエストとレスポンスの多重化等のメリットを享受したかったのと、他にもう一つ僕達にとって重要な理由がありました。 それはAWSの問題です。 GoalousではAWSのOpsWorks(Chefを使用してクラウドエンタープライズでアプリケーションを設定および運用するための設定管理サービス)を使用しています。 OpwsWorksはOpsWorksスタックとOpsWorks for Chef Automateの二種類があり Goalousで使用しているのはOpsWorksスタックです。 OpsWorksのスタックはChefのバージョンが11か12によって明確に区別されます。 僕達はずっとChef11のスタックを使用していましたが、もうそろろそろChef12にバージョンアップしたかったので 今回のHTTP2/移行が良い機会となりました。 あとはロードバランサーがELBではなくALBじゃないとHTTP/2を使用出来ないので思い切って Chef12+ALBの全く新しいスタックを作ることに決めました。 どう移行したか GoalousのChefのレシピは残念ながら公開出来ないので、本記事においてはあくまで OpsworksのChef12スタックとALBをどう構成してHTTP/2を実現するか に焦点を絞り、サンプルのChefレシピを使ってミニマムな構成の手順を説明します。 参考：Use Application Load Balancers with your AWS OpsWorks Chef 12 Stacks Step1.ALB作成 基本的にはAWSの公式ドキュメントに沿って作成します。 ただしステップ 5: ターゲットグループのターゲットを設定するはスキップしてください。 インスタンス作成とターゲットグループへのターゲット登録はOpsWorksで行います。 Step2.OpsWorksスタック作成 OpsWorksのダッシュボードページで、スタック追加ボタンをクリックします。 スタック追加ページに遷移後、まずChef12 Stackを選んだ上で、...勉強会を開催しました！「AWSを使っているならOpsWorksでDevOpsしよう！」、「AWS運用アレコレ」の二本立て
こんにちは、平形です。 先日8/24、弊社で4回目の外部向けの勉強会を開催しましたので、その様子をご報告させていただきます。 今回はAWS関連のトピックを私、平形と同じく弊社エンジニアの赤川がお届けしました。 今回４回目となる勉強会も盛り上がりを増してきた事もあり、弊社代表の中村が自ら挨拶を買って出てくれました。 今回もたくさんの方々にご参加いただき、大変嬉しく思っています。 内容 今回は、 AWSを使っているならOpsWorksでDevOpsしよう！ by 平形 AWS運用アレコレ by 赤川 の２本立てです。 イベントページはこちらのconnpassページにて 弊社では、AWS, GCP, AzureなどクラウドリソースをMSP事業、自社サービスで積極的に活用しております。今回はその中からAWSについてお話ししました。 今回の勉強会のもう一つの特徴は、スピーカーの２人とも今年第一子が誕生した新生育児パパという事です。育児と仕事の両立をして日々業務に精を出しています。 株式会社ISAOは、そんなイクメンエンジニアを応援しています！ AWSを使っているならOpsWorksでDevOpsしよう！ by 平形 AWSのデプロイサービスの一つOpsWorksについて実際の業務で得た知見を発表しました。 AWS運用アレコレ by 赤川 AWSの障害対応など日々1,000台単位のEC2の運用を行なっている中から得られた運用のコツなどを発表しました。 懇親会の様子 秋葉原名物の万世のハンバーグサンドです。 大変美味しく頂きました。 今回も多彩な領域のエンジニアの方々とお話しでき、有意義な交流会となりました。 次回予告 日時：9/29(木曜日)19:00 予定 お題：使った気になるFirebase(仮) 場所：株式会社ISAO おわりに 弊社は今後も社外へ向けた勉強会を引き続き開催していく予定です。 勉強会テーマについても、参加者の皆さんのご意見を反映して幅広いジャンルにしていくつもりです。 connpassのISAO Meetupグループに是非ご参加ください！！ http://isao.connpass.com/ 最後になりますが、ISAOでは一緒にサービスを作ってくれるエンジニアを絶賛募集中です。 ご興味を持っていただけましたら、まずは気軽に弊社に遊びにいらしてください。 https://www.colorkrew.com/recruit/...chefのruby_blockを用いて環境変数を再読み込み
こんにちは。小宮です。 chefでいろいろ自動化していくうちに、途中で変更された値というか変数を使いたい場合が出てくるのかなと思います。 1回目は上手くいかないけど2回目は上手くいくというような冪等にならない怪現象を解決したいと思う時がそのうちきます。 そんなとき、、 ohaiで値がとれる場合はそれを使いなければohaiのプラグインを自作するか、 ruby_blockを書いたり、notifiesで:immediatelyとかつけて呼び出すって感じの対応が必要になったりします。。 何言ってっかわかんねえ！と思うかたは以下のリンク先にchefの実行順序に関して書かれているので見てみるといい気がします。 Chefのレシピは上から下に実行されるという誤解 | Engine Yard Blog JP これだけだと不親切かもしれないので以下ご参考まで。 template "/etc/profile.d/rbenv.sh" do not_if "grep rbenv /etc/profile.d/rbenv.sh" source "rbenv.sh.erb" action :create notifies :create, "ruby_block[initialize_rbenv]", :immediately end ruby_block "initialize_rbenv" do block do ENV['RBENV_ROOT'] = node[:rbenv][:root] ENV['PATH'] = "#{node[:rbenv][:root]}/bin:#{node[:rbenv][:root]}/shims:#{node[:ruby_build][:bin_path]}:#{ENV['PATH']}" end action :nothing end 少し解説しますと、 chefではレシピ中での改変を前提とした処理はくふうがひつようで、 rubyで書かれた処理はconvergeの手前で行われてしまってその時点では途中の改変を認識できないようです。（だから2回目に成功する） ruby_blockリソースはconvergeのタイミングと同じ時に動くようです。 特定のリソースの処理が行われるときだけ実行したい場合にはそのリソースのnotifiesにはタイミングを指定できます。（:immediatelyとか:delayedとかあるらしい） この場合、ruby_blockリソースのactionにはnothingを指定しておき、templateリソースでprofileの設定を置いて:immediatelyをnotifiesに指定することで ただちに変数の再読み込みが実行される、という話になります。（レシピを分けてる場合にnotifiesつかうと-oで個別実行しにくくはなりそう。）...DevOps時代のアジャイルでスケーラブルな開発環境をVagrant, GitHub, Travis, Chef, OpsWorksで構築する
どうも。久しぶりです。 デベロッパーの平形です。 このブログに訪れたすべてのエンジニアの方々。 そして、エンジニア以外の方々。 とても感謝致します。 初めに言っておきますが、この記事ではコード、コマンドラインの一切は登場しません。 はじめに 私が今回お送りする内容は本当にスケーラブルな環境の構築、運用を手助けする事ができます。 連載記事で複数回に渡ってお届けしますが、この連載を読み終えそして実践していただければ、あなたは既にスケーラブルな環境で作業を行っている事でしょう。 この連載記事では、順番に必要なツールのインストール、使い方をハンズオン形式でお送りします。 実際に手を動かして実感していただく事がとても意味がある事だと思っています。 この回では、コード、コマンドラインは一切登場しません。次回以降にどんどん出てきます。 その前に**「伝えたい事があるんだ。君の事が好きだから」by小田和正**と叫ばせてください。 この記事は以下の方には不向きです。 俺は一生一人で生きていくんだ！と1日1回はトイレで意気込んでいる人。 後先の事なんか考えたくない。俺は今を生きているんだ！と週に３回は言っている人。 これらに該当する方。お疲れ様でした。出口はこちらです。 この記事は以下に該当する方に是非読んでいただきたいです。 開発者、インフラ担当者の方。 これから新しいプロジェクトを立ち上げるんだけど、構成どうしようか悩んでる方。 サーバーの台数が多くなったらどうしよう。と悩んでいる方。 開発要員が急に増えたらどうしよう。と悩んでる方。 DevOpsとかスケーラブルな環境とかに興味があって、でも今ひとつ踏み出せない方。 上記を実践してみようとしたけど、挫折してしまった方。 開発環境で動いているコードがなぜか公開環境で動かなくて家に帰れない方。 本番反映が怖くて会社に行きたくない方。 サーバーが落ちる事が不安で夜も眠れない方。 将来の事を考えると不安で不安で仕方なく、「とにかくもう、学校や家には帰りたくない〜。」by尾崎豊と口ずさんでしまう方。 それでは、夢の扉を開きましょう。 レガシーな開発と運用 開発環境、公開環境の構築は、構築手順書を元に手動でインストールしている。 公開環境のサーバー増設は１台ずつ手動でキッティングしている。 パッチの適用、バージョンアップは手動で１台ずつ手順書を元に実行している。 バージョン管理はしないで各自、修正ファイルをFTPでファイルをアップロードしている。 これらをヒューマンエラーなく、ストレスなく運用できるのはスーパーマンです。 そして、開発、運用メンバー全員が自分と同じスーパーマンでなければいけません。 凡人の僕には無理です。 現代の開発と運用 現代のもの凄い勢いで変化するサービス要求に耐えるには、様々なものを効率化しなければいけません。 素早くリリースしてユーザの反応を見ては仕様を変更してすぐに反映しまたリリースする。といった事も必要です。 近頃、開発運用の自動化は様々なメディアの記事で取り上げられ、賑わっています。 しかし、実際にどこまで自動化ができているのでしょうか？ バージョン管理 環境構築 セキュリティパッチの適用 バージョンアップ オートスケール 自動テスト 自動デプロイ 開発環境の配布 なかなか全部はできないですよね？ でもやったほうが絶対に幸せになれます。...redisのソースインストール(chef-solo)
こんにちは。opsのほうの小宮です。 redisのソースインストールをご依頼いただきCHEF-SOLOったのでその記録をのこしておきます。 ★要件 バージョンについては2.8.4でお願いします。（2014/1時点で最新のソース） ★以下作業 ・rpmで入るバージョンの確認(※同環境のサーバでyumで確認) redis.x86_64 0:2.4.10-1.el6 ※要件に合わないためソースインストールする必要がある ・chef-soloの下準備 [shell]$ ssh-copy-id -i ~/.ssh/id_dsa.pub server2 $ ssh-copy-id -i ~/.ssh/id_dsa.pub server1 $ knife solo prepare server1 $ knife solo prepare server2[/shell] ・role作成 [shell]$ vi roles/rankingAPI.json { “name”:“rankingAPI”, “chef_type”: “role”, “json_class”:“Chef::Role”, “default_attributes”:{ “base_setting”: { “swappiness”: “0”, “tcp_tw_reuse”: “0”, “tcp_tw_recycle”: “0”, “tcp_fin_timeout”: “10”, “tcp_max_syn_backlog”: “8192”, “somaxconn”: “8192”, “ntpserver1”: “ntp....cpuコア数に応じたrps_cpusに入れる値の計算方法
こんにちは。OPSのほうの小宮です。 cpuコア数に応じたrps_cpusに入れる値の計算方法です。 ネットワークの割り込み処理を複数コアに分散したいという要望がありまして。(特にキャッシュサーバ) できる人に頼って、ここ↓まで頑張ってもらいました。 [shell]# core=1 # echo “obase=16; ibase=10; $(( 2 ** ${core})) -1” | bc | tr ‘[A-Z]’ ‘[a-z]’ 1 # core=2 # echo “obase=16; ibase=10; $(( 2 ** ${core})) -1” | bc | tr ‘[A-Z]’ ‘[a-z]’ 3 # core=4 # echo “obase=16; ibase=10; $(( 2 ** ${core})) -1” | bc | tr ‘[A-Z]’ ‘[a-z]’ f # core=5 # echo “obase=16; ibase=10; $(( 2 ** ${core})) -1” | bc | tr ‘[A-Z]’ ‘[a-z]’ 1f[/shell]...Chefで書いたレシピをテストする(serverspec)
こんにちは。小宮です。 今回で最終回です。 前回までにご紹介したレシピのテストするところをご紹介します。Serverspecを用います。 なぜServerspecがいいかというのは以下リンクにも書いてますが、以下の点がよいと思います。 ・Chefのテストツールでなく外部のツールなので依存関係がない（puppetでも使える） ・設計思想がシンプル簡単に使えるものということで、手間があんまりなくて簡単につかえた 参考： Serverspec at hbstudy #45 入門Chef Solo落ち穂拾い kayac/newbie-training 「入門Puppet」 resource_typeのマニュアル advanced_tips ncstudy#05 ハンズオン資料 parallel_tests ・セットアップ バージョン0.3と0.6だとテストの書き方が若干違う感じだったので、マニュアルに沿ってる新しいほうを推奨します。 [shell]# yum install rubygems gem install serverspec rake serverspec-init Select a backend type: 1) SSH 2) Exec (local) Select number: 1 Vagrant instance y/n: y Input vagrant instance name: 10....Chefで既存手順のレシピを書く５（munin、zabbix）
おつかれさまです。小宮です。 前回に引き続き、munin,zabbixの手順のレシピをご紹介します。レシピはこの記事でおしまいです。 記事の最後にはレシピの適用方法を記載します。 ・muninのレシピ # cd /opt/src/rpms # mkdir -p /root/chef-repo/site-cookbooks/munin/files/default/rpms # mkdir -p /root/chef-repo/site-cookbooks/munin/files/default/var/www/html/munin # mkdir /root/chef-repo/site-cookbooks/munin/files/default/etc/munin/plugin-conf.d # cp -p /etc/munin/munin.conf /root/chef-repo/site-cookbooks/munin/files/default/etc/munin/ # scp -Cp ｘｘｘ-web01:/etc/munin/munin-node.conf /root/chef-repo/site-cookbooks/munin/files/default/etc/munin/ # cp -p /var/www/html/munin/.htaccess /root/chef-repo/site-cookbooks/munin/files/default/var/www/html/munin/ # cp -p /etc/munin/plugin-conf.d/munin-node /root/chef-repo/site-cookbooks/munin/files/default/etc/munin/plugin-conf.d/ # tar cf /root/chef-repo/site-cookbooks/munin/files/default/rpms/munin-node-rpm.tar ./munin-node-rpm/ # tar tf /root/chef-repo/site-cookbooks/munin/files/default/rpms/munin-node-rpm.tar ./munin-node-rpm/ # tar cf /root/chef-repo/site-cookbooks/munin/files/default/rpms/munin-serv-rpm....Chefで既存手順のレシピを書く４（DBサーバ）
おつかれさまです。小宮です。 前回に引き続きdbserverのレシピについて書いていきます。 のこってるのはmunin、zabbxとserverspecでのテストだけです。もうすこしの辛抱です。 webと同じくバージョン固定インストールなので、外部レシピは基本的に使わない方向とする ・mysqlのインストールと起動と自動起動の有効化 [shell]# cd /root/chef-repo/site-cookbooks/mysqld/recipes mkdir -p /root/chef-repo/site-cookbooks/mysqld/files/default/usr/local/src/rpms mkdir -p ../templates/default/etc/init.d mkdir -p ../files/default/etc/init.d mkdir -p ../files/default/root mkdir -p /root/chef-repo/site-cookbooks/mysqld/files/default/etc/logrotate.d mkdir -p /root/chef-repo/site-cookbooks/mysqld/files/default/opt/{backup,bin} scp -Cp xxx-db02:/opt/bin/mysql-back.sh /root/chef-repo/site-cookbooks/mysqld/files/default/opt/bin/ cp -p /etc/logrotate.d/mysqld /root/chef-repo/site-cookbooks/mysqld/files/default/etc/logrotate.d/ scp -Cp xxx-db01:/etc/init.d/mysqld ../files/default/etc/init.d/ scp -Cp xxx-db02:/etc/my.cnf ../templates/default/etc/ cp -p /root/.path_to_file ../files/default/root/ cd /opt/src/rpms/ tar czf /root/chef-repo/site-cookbooks/mysqld/files/default/usr/local/src/rpms/db-rpm....Chefで既存手順のレシピを書く３（WEBサーバ）
こんにちは。プラットフォームの小宮です。 前回に引き続き既存手順のレシピ化をすすめていきます。あと3回くらいだと思われるので気長におつきあいください。 今回はWEBサーバのレシピになります。 特別なことは特にしていなくて普通のwebサーバだと思いますが、一応何してるか書いておきますと、 apache2.2＋php5.3系で中間コードキャッシュにAPCを使っていてwordpressとそのsshプラグインつかっておりAWSのS3にmountしています。 s3mountに使うfuseが最新版からソースコードで入れる必要があり、バージョン固定のphpのパッケージが18個くらいとかありまして 一つ一つpackageリソース書くのが面倒だったこともありましてscriptつかいました。 scriptつかうときはnot_if忘れるとmakeとか何回も実行されて困るので注意が必要です。 あとcd書き忘れると展開場所が認識してるとこに出ないのでその後の手順でファイルが存在しないエラーがでました。 ・httpdのレシピを書く 設定ファイルの準備をする [shell]# mkdir -p /root/chef-repo/site-cookbooks/httpd/files/default/rpms # tar cf /root/chef-repo/site-cookbooks/httpd/files/default/rpms/web-rpm.tar ./web-rpm/ # tar ｔf /root/chef-repo/site-cookbooks/httpd/files/default/rpms/web-rpm.tar ./web-rpm/ # cd /root/chef-repo/site-cookbooks/httpd/recipes # mkdir -p /root/chef-repo/site-cookbooks/httpd/files/default/etc/httpd/{conf,conf.d} # cp -p /opt/src/config/web/httpd.conf /root/chef-repo/site-cookbooks/httpd/files/default/etc/httpd/conf/ # vi /root/chef-repo/site-cookbooks/httpd/files/default/etc/httpd/conf/httpd.conf # mkdir -p /root/chef-repo/site-cookbooks/httpd/files/default/etc/php.d # cp -p /opt/src/config/php/php.ini /root/chef-repo/site-cookbooks/httpd/files/default/etc/ # cd /root/chef-repo/site-cookbooks/httpd/files/default/rpms # wget http://rpms....Chefで既存手順のレシピを書く２（ユーザ作成）
こんにちは。プラットフォームの小宮です。 前回に引き続きChefの記事で失礼します。 data_bagsでユーザ管理の用意をします。 一応、以前にこちらに書いてるのですが、関連情報がまとまってるほうがいいと思うので部分的に再掲します。 data_bagsとはldapのような機能をもったデータ検索など管理ができるもの。 chef-server使う場合はサーバと通信してデータ取ってきて反映することが可能。 今回はChef-soloなので、ローカルのファイルにデータを用意して反映させる方法をとります。 参考： もしユーザ数が多くて頻繁にアカウントが追加変更される場合、以下リンクのようにdata_bagsで有効無効も管理するのもよさそうです。 chef-data-bag活用法 [shell]# cd ;cd chef-repo/data_bags # mkdir users;cd users # vi xxx-op.json // xxx-op.json { “id” : “xxx-op”, “groups”: [ “xxx-op”,“wheel” ], “uid”: 1000, “username” : “xxx-op”, “home” : “/home/xxx-op”, “shell” : “/bin/bash”, “password” : “$1$Ka.Mw69U$TT5HRfSe7xxxxx” } # vi yyy-op.json // yyy-op....Chef-Soloでレシピを書く前の環境について(Vagrantfile,role,node,data_bags)
こんにちは。小宮です。 いつのまにか今年の前半が終了しました。宇治金時がおいしい季節になってしまったようです。 それはともかく前回の続きです。 今回はChef-Soloのレシピを書く前の環境の定義などまでを書きます。 Chef用語などは軽く解説してる、今日から使い始めるChefを見ていただくか定番の入門Chef Soloを見ていただくのが早いんではないかと思います。 Automated infrastructure is on the menuも英語ですがわかりやすいです。 やりたいこととしては以下のとおりです。 Vagrantfileを書いて仮想インスタンスをたてる chefレポジトリを作る chefクックブックを作る nodeを定義する roleを定義する data_bagsを定義する ★今回はここまで★ レシピを書く レシピをノードに適用する serverspecテストを書く テストを実環境に実行する テストの構成： chef-solo元のadmserver：10.0.0.93 knife-solo適用クライアントwebserver：10.0.0.240 knife-solo適用クライアントdbserver：10.0.0.241 全てCentOS5.8です。 ・AWSの環境変数を定義 AWSのVPC上なので適宜定義しておきます [shell]# cd # vi .ec2 export AWS_ACCESS_KEY_ID=****** export AWS_SECRET_ACCESS_KEY=******* export AWS_KEYPAIR_NAME=xxx-key export AWS_PRIVATE_KEY_PATH=/root/.ssh/xxx-key # source .ec2[/shell] ・VagrantFileを書く vagrant initを実行するとVagrantfileができますのでそれを編集し、...Chef-SoloとVagrantの導入（VPC環境）
こんにちは。プラットフォームの小宮です。 最近chef流行ってますね。 せっかくだからこの波に乗ってプロダクト環境に合わせてやってみよう的な記事を書こうかと思います。 さっさとServerspecまでたどり着きたいんですが、今回は導入のみの記事でレシピなどはまた次回以降に。 やってみよう的なレベルなのでリファクタリングし甲斐のあるレシピになる予感がします。 さて今回Chef化を試みる環境はVPC上に移行する話になってます。(構成はweb2、db2、stg1、nat1です。ELB利用。soloで十分な感じ。) Vagrant-awsでVPCつかう方法が可能なようなので、Vagrantを使用して構成管理を行いつつKnife-soloも使うことにします。 vagrantとsahara連携でOSの状態を保存してロールバックということが可能となります。 knife-soloだと/sbin等の下のrubyを消して入れ替えようとしてしまうことがあるらしいので、アプリケーションにおいてrubyを使用しないことを確認しておきます。 vagrantを入れるのでruby1.8.7より上のバージョンをrbenvで入れます。 (CentOS5系の場合。6系や他のディストリビューションでは別途ruby -vで確認してください） 実は、Chef-Clientを/opt/chefの下に入れた段階で以下のようにPATHを通しておけばrubyのバージョンは気にしなくてもよいかもしれません。 [shell]# curl -L https://www.opscode.com/chef/install.sh | bash # export PATH=$PATH:/opt/chef/embedded/bin/ # vi ~/.bashrc PATHをとおしておく[/shell] gemでchefを入れるのは古いやりかたみたいですね。 ・最初にOracleVirtualBoxを導入 入れる理由はVagrant-awsでインスタンスの起動と管理を行うため。 [shell]cat /etc/redhat-release CentOS release 5.8 (Final) yum install libXmu libXt mesa-libGL qt qt-x11 SDL wget http://download.virtualbox.org/virtualbox/4.2.12/VirtualBox-4.2-4.2.12_84980_el5-1.x86_64.rpm rpm -ivh VirtualBox-4.2-4.2.12_84980_el5-1.x86_64.rpm[/shell] ・ruby-1.8.7より新しいバージョンを導入(必要な場合) [shell]yum -y install zlib-devel readline-devel openssl-devel yum install ruby ruby-devel rdoc irb rubygems yum install git –enablerepo=rpmforge[/shell]...