OpsWorksでRailsアプリからAmazon RDSなどの外部DBを利用する方法
前回は、『OpsWorksでRailsをデプロイする際にasset:precompileを実施する方法』というタイトルで、デプロイフックの仕組みについて紹介しました。
今回は、Amazon RDSのようなデータベース・サーバが別インスタンスで稼働している場合を想定して、どのようにしてdatabase.ymlの値を変更すればよいかを紹介します。
まずはOpsworksでRailsアプリケーションを稼働させるためには、アプリケーション全体の設定を定義するStackの設定をしたり、Appサーバ/DBサーバなどのようなインスタンスの役割を定義するLayerの設定をしないといけないのですが、こちらについての解説は割愛します。詳細は細かいところまで丁寧に解説してくれている下記URLを参考にしてください。
http://recipe.kc-cloud.jp/archives/tag/opsworks
では、Layerにて"Rails App Server"を作成し、Appsにてソースコードのリポジトリ設定まで作成できたものとして話を進めます。
Appsにてアプリケーション情報を登録して、デプロイを実行するとOpsWorksが適切な場所にアプリケーションを配備してくれます。
しかし、デプロイに成功したとしても、HTTPでアクセスしてみるとアプリケーションエラーの画面が表示されると思います。
これは、OpsWorksがバックエンドで ${RAILS_ROOT}/config/database.yml をOpsWorksが準備しているテンプレートファイルに置き換えているためです。
ちなみにテンプレートファイルはこちらになります。
参照:https://github.com/aws/opsworks-cookbooks/blob/master-chef-11.4/rails/templates/default/database.yml.erb
見たらわかると思いますが、上記のソースコード内の @database[:設定値] の部分の値を指定してやればよいです。
具体的な設定方法としては、OpsWorksのDeploymentsにて、Run CommandのCustom Chef JSONに設定をすればよいです。
設定画面はこちらのCustom Chef JSONです。
設定する文字列はJSON形式で、以下のようなコードになります。
{ "deploy": { "アプリケーション名": { "database": { "username": "ユーザ名", "password": "パスワード", "host": "データベースサーバのIPもしくはURL", "adapter": "アダプタ名(mysql2 or postgres)", "database": "データベース名", "reconnect": true } } } }
※アプリケーション名については前回の記事を参照してください。また、DBがMysqlでない場合はadapterを設定してください。
上記の設定でdeployを実行すると、前回のブログのデプロイフックと似たような仕組みでデプロイ処理時に database.yml を書き換えてくれるようになります。
これでアプリケーションが正常に動作するようになったはずです。
もし、設定をしてもうまく動作しないという場合は、デプロイ失敗のログを確認するか、Rails App ServerのインスタンスにSSHでログインして、rootかdeployユーザにスイッチした後に、/srv/www/アプリケーション名/current/config/database.yml を確認し、適切な設定が適用されているか確認してみてください。
※RDS等のセキュリティグループで通信を許可することも忘れないでくださいね。
ちなみに、アプリケーションの改修をして再デプロイが必要になった場合は、repeatボタンを活用して上げれば、毎回Custom Chef JSONの値を設定しなくて済むので、こちらも是非利用してみてください。
ただ、今回紹介した方法(deploy時にCustom Chef JSONを指定)を本番環境に適用して運用しようとすると、いつの日かサービスダウンを招いてしまうことになってしまうため、注意が必要です。
今回、その解説をしようとするとブログが長くなってしまうので、次回のブログで本番運用を想定した設定について紹介しようと思います。
-
-
-
- 2014/06 追記
-
-
OpsWorksがRDS連携対応したことで、連携していないRDSを指定している場合にadapterの指定が必須になりました。adapterを指定しないとDeploy時にconfig.ymlが生成できない旨のエラーが表示されますので慌てず設定するようにしましょう。
OpsWorksでRailsをデプロイする際にasset:precompileを実施する方法
OpsWorksでRailsアプリケーションを運用するために知っておくべきことを数回に渡り本ブログで紹介していきます。
今回はOpsWorksのデプロイフックを利用する方法です。
Railsでは、JavaScriptやCSSを結合して圧縮することで、ブラウザがウェブページを描画するために必要となるリクエスト数を削減する仕組み(Asset Pipeline)が用意されています。
この仕組みを利用するには、rake asset:precompile というタスクを実行する必要がありますが、OpsWorksのRailsアプリケーションのデフォルトのデプロイ処理ではこのタスクを実行してくれません。
しかし、OpsWorksにはデプロイフックという仕組みが用意されています。
それではその仕組の利用方法を紹介します。
まず、${RAILS_ROOT}にdeployというディレクトリを作成し、その中にbefore_migrate.rbという名前で以下のようなファイルを作成し、リポジトリに送信しておいてください。
${RAILS_ROOT}/deploy/before_migrate.rb
Chef::Log.info("Running deploy/before_migrate.rb") env = node[:deploy][:アプリケーション名][:rails_env] current_release = release_path execute "rake assets:precompile" do cwd current_release command "bundle exec rake assets:precompile" environment "RAILS_ENV" => env end
上記ソースコード内のアプリケーション名のところは、AppsレイヤのNameにて指定した名前になりますが、その名前にハイフンが含まれている場合は、アンダースコアに変換されるようなので注意が必要です。
例えば、Nameに sonic-garden を指定した場合は、アプリケーション名が sonic_garden になるようです。
これでデプロイリクエストを発行した際に、マイグレーション実行前に rake asset:precompile が実行されるようになります。
今回はアセット機構の使い方でしたが、他の処理も実施可能ですので、ぜひいろいろお試しください。
次回は、アプリケーションからRDSなどのデータベースへの接続するための情報をOpsWorksから渡す方法をご紹介します。
「AWSを活用してる現場リーダーやCIOをお招きしたトークイベント」でパネルディスカッションをさせていただきました。
昨夜、茅場町のコワーキングスペース「Co-Edo」にて、paperboy&co. の梅谷さん(@ume3_)とKDDI webcommunications inc の阿部さん(@yskmerlion)と私の3名で、異なる企業規模のインフラ寄りのエンジニアが、それぞれの立ち位置でチームとして日々どのように仕事を進めているかなどをざっくばらんにお話させていただきました。
企業規模・組織体系によってアプローチが全く異なっていたりし、私としてもいろんなインプットを得ることができる有意義な場でした。
企画してくださいました小山田さん(@h5y1m141)、ありがとうございました。
ちなみに本イベントの概要は、「事業拡大に伴い、リーダーとして業務をすることになった人をイメージし、今後リーダーとして仕事をする上でどんなことを日々意識して業務に取り組むべきかというコンセプトで60分ほどのパネルディスカッション」でした。
なるべく少人数で質問を交えながら話が進められるようにしたいという小山田さんのご意向もあって、ビールを片手にライトな感じで参加者の皆さん15名程度の方々とお話させていただきました。
当日私がお話させていただいた内容を簡単にまとめておこうと思います。
SonicGardenは現在9名の会社です。
そのため、リーダーが必要な状況ではありません。というよりも弊社ではリーダーやマネージャというポジション不要だと思っています。
というのも、セルフマネジメントができないと、自律的に仕事を進めることができないし、誰かに依存した状態となってしまい結果的にお荷物になってしまうと考えているからです。
詳しい内容は代表の倉貫がいくつかブログを書いてますので、それをお読みいただけたらと思います。
- セルフマネジメントのレベルと欠かせないスキル 〜 自己組織化されたチームを作るためには
- 自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ
- どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ
またパネラー3人が共通して言っていたことは、"強みを持つこと"です。
何でも良いので"強み"を持ってそれをアピールすることができれば、その強みに関する仕事が発生したときに、周りとしても頼みやすくなるし、当事者としても必要とされている&貢献できると思えるようになりモチベーションにもつながるはずです。
この辺りについては過去にブログを書いていたので、ぜひお読みいただければ、と。
途中、エンジニアの採用という話題にもなりました。
その時お話した内容が、”SonicGardenでは採用を結婚と同じだと考えています"という内容です。
結婚するまでにデートを重ねて相手のことを知ったり、さらに同棲してみて今後うまくやっていけるかを時間をかけてお互いに考えたりしますよね。
仕事もそれと同じだと考えていて、仕事を進める上で信頼関係は重要になりますし、また価値観や考え方が大きくズレていると仕事を円滑に進めることはできないはずですよね。
仕事をする時間は人生の中でも大きなウェイトを占めるものですので、履歴書と1〜2回の面接で採用を決めるのではなく、真剣にお互いのことを見つめ合って双方の同意のもとに決定したいと全メンバーが思っています。
他にもいろいろなお話をさせていただきましたが、文字に起こすのが大変なのでこれくらいにしておこうと思います。
この記事を読んで、疑問も持たれたり、もっと話を聞いてみたいと思われた方は右下の「メッセージを送る」ボタンよりご連絡いただけ幸いです。
「Developer Migration 2013」で話をしてきたので資料を公開します
「DevOpsが引き金となるインフラエンジニアの進撃 どうする?デベロッパ」というタイトルで、Developer Migration 2013のイベントで登壇の機会をいただいて話をしてきました。
講演内容の概要です。
開発現場のスピードと生産品質を高めるプラクティスとして提唱されるDevOps。
現場にもたらすプラス効果については多く語られますが、「個々のキャリアにどんな変化をもたらすか」について考えてみたことはあるでしょうか?
今、DevOpsが「インフラを管理しアプリケーション開発もするスーパーエンジニア」を生み出そうとしています。
本セッションではDevOpsの概要や現場摘要例を紹介した上で、新しい生産体制がエンジニアのキャリアにどんな変化をもたらすのかを考察します。
発表した時の資料はこちらになります。
内容としては、インフラエンジニアだった私がなぜアプリケーションエンジニアとしての道を開拓したのかの経緯と、今後なぜプログラミングが必要となるのかを個人的意見を交えてお話させていただきました。
講演とは別のセッションで「2013年の開発現場で求められるエンジニアとは?」というテーマでパネルディスカッションをさせていただいたのですが、そのときに講演者の皆さんが、それぞれはっきりとした意見をお持ちで、個人的にはいろんな観点を学ぶ機会となりました。
イベントのことをブログでまとめてくださっている方々もいらっしゃいますので、ぜひ下記のブログもご参照ください。
- 「Developer Migration 2013に参加しました #devmi」
- 「Developer Migration 2013」
- 「パネルディスカッション 2013年の開発現場で求められるエンジニアとは?#devmi」
本資料にてご意見、ご感想等ございましたら、右下に表示されているMessageLeafよりメッセージをいただけますとうれしいです。
※MessageLeafでのやり取りは公開されませんので。
debugger-linecache のbundle に失敗したら
以下のように debugger-linecache のbundle時に失敗したときの対応メモ。
Installing debugger-linecache (1.1.2) with native extensions
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
/Users/interu/.rbenv/versions/1.9.3-p362/bin/ruby extconf.rb
checking for vm_core.h... no
checking for vm_core.h... no
Makefile creation failed
**************************************************************************
No source for ruby-1.9.3-p362 provided with debugger-ruby_core_source gem.
**************************************************************************
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/Users/interu/.rbenv/versions/1.9.3-p362/bin/ruby
--with-ruby-dir
--without-ruby-dir
--with-ruby-include
--without-ruby-include=${ruby-dir}/include
--with-ruby-lib
--without-ruby-lib=${ruby-dir}/lib
Gem files will remain installed in /Users/interu/.rbenv/versions/1.9.3-p362/lib/ruby/gems/1.9.1/gems/debugger-linecache-1.1.2 for inspection.
Results logged to /Users/interu/.rbenv/versions/1.9.3-p362/lib/ruby/gems/1.9.1/gems/debugger-linecache-1.1.2/ext/trace_nums/gem_make.out
An error occurred while installing debugger-linecache (1.1.2), and Bundler cannot continue.
Make sure that `gem install debugger-linecache -v '1.1.2'` succeeds before bundling.
こんなエラーが出たら、debugger-ruby_core_source をインストールしておくと解決します。
$ gem install debugger-ruby_core_source -v1.1.6
いろんな人が関わっている!?ソニックガーデン開発の裏舞台 (SonicGardenアドベントカレンダー5日目)
SonicGardenアドベントカレンダー、5日目までまわってきちゃいました。
今日私が書いているので、残りは副社長と社長の2人ですね。トーク上手な二人なだけに、おもしろい記事が出てくること間違いなしだと思います。
今回は、あまり知られていないソニックガーデンのサービス開発の中で関わっている人たちについてご紹介します。
数ある中でも今回は、Webサービスの「デザイン」と「テスト」の2つに絞って紹介します。
デザイナーとのかかわり
Webサービスの開発はSonicGardenが得意とする領域です。そのためプログラマのみでサービスを作り上げることはできるのですが、スタイリッシュなデザインサイトにしたいということであれば、デザイナーの方のチカラを借りたりします。
実際に自社サービスの「SKIP」や「youRoom」、さらには以下のようなフロントページのデザインを「怖話」で有名なフィヨルドの町田さん(@machida)や、「ズルいデザイン」で有名なフリーランスの赤塚さん(@ken_c_lo)にデザインしてもらったりしています。
ただ、デザイナーさんの方にサイトデザインをお願いするというのは巷でもよく聞くパターンですよね。
では、何か特別かというと、machidaさんや赤塚さんは、インデントや簡略構文によって簡潔な記述を行えるhamlやsass、さらにはソースコードのバージョン管理を行うGitを使いこなしているプログラマスキルを兼ね備えたデザイナーなのです。
そのため、Gitで管理しているソースコードを直接変更してもらうということが可能なのです!
通常は、デザイナーがCSSを書いて、それをプログラマがサービスにせっせと適用するという非効率的な作業をしなければなりませんでしたが、デザイナーさんが直接ソースコードを変更してくれるので、無駄な作業を減らすことができます。
また、以前はデザイン変更中に開発をストップすることを求められることが多々有りましたが、hamlやsassを理解してくれているデザイナーの方はソースコードの変化にも柔軟に対応してくれるため、デザイン変更中であっても機能開発を続けることができるようになりました。
それもこれも、デザイナーの方々がプログラマに求めれられるスキルをオーバーラップしてくれたからですね。プログラマに歩み寄ってくださり、ありがとうございます!
あとはデザイナーの方々が安心してソースコードの変更ができるように、プログラマは、デザイナーさんが変更したソースコードを責任持って確認し、必要に応じてリファクタしてあげましょうね。
続いて、アプリケーションフレームワークのバージョンアップやミドルウェア/OSのリプレース時に行うテストについてです。
オンラインテスティング
アプリケーション単体のテストはCapybaraやRspecなどのようなツールを活用することで実現できますよね。ソニックガーデンでも積極的にテストコードを書いて品質担保をしようとしています。
ですが、テストツールは万能ではありませんので、テストすべてを網羅するのは困難です。
特にフレームワーク自体のバージョンアップでは、テストツールのバージョンアップを同時に求めらることもあり、場合によってはテストコードを改修しないと動かなかったりします。
また、テストツールではアプリケーションを動作させるミドルウェアやOSが変化した際のテストはできません。
そのため、人的なテストも時には必要となります。
そんな時、巷ではテストのアウトソースが利用されるようです。ただ、テストケースを洗い出したドキュメントの作成や入力に対する結果などをまとめたドキュメントを事前作成する必要があるみたいで、アウトソースするのも一苦労のようです。
そこでソニックガーデンでは、より効率的なテストのアウトソースを実現するためにフィヨルドのインターン生のチカラを借りています。
ここ半年以内に、社内SNS「SKIP」と「youRoom」のフレームワークの最新化およびOSディストリビューションの最新化を実施した際に、テスト環境でさまざまなテストの協力をしてもらいました。
このとき工夫した点は以下。
完璧な網羅テストを依頼しようとすると、確かに厳密なドキュメントが必要となりますが、ソニックガーデンではこちらのエントリにあるように、
"SonicGardenのアプリケーション開発は、「どれだけ頑張ってもバグは発生する。0にするよりもどれだけ早く直せるかを考える」"という方針で考えています。
そのため、テストの目的でも、不具合0を目指すのではなく、多くのユーザが利用する機能を重点的にテストし、なるべく不具合を減らすようにしています。
この背景もあり、フィヨルドの優れたインターン生協力のもと、テストのクラウドソーシングを実現してもらうことができました。
インターン生のみなさん、ホントご協力ありがとうございました!
これまでに述べてきたように、SKIPやyouRoomなどのサービスは、さまざまな方々のチカラで成り立っています。これからも多くの方々に協力していただくことになるかもしれませんが、そんなときでもソニックガーデンらくし、既存のやり方のままではなく、何かしらひと工夫したアプローチを心がけていこうと思いますので、ご協力よろしくお願いします。
それでは、次はブログを書かないことで有名な副社長の@pastaonlyにバトンタッチです!エンジニアがこれまで繋いできたバトンをまさか放棄したりしないはず・・・。
最後にお知らせ。
ネット上で年賀状が送れる「Keep in touchグリーティングカード」を使って、例年とはちょっと違う新しいスタイルのウェブ年賀状を送ってみてください。
ビジネスでもネットで年賀状を送ろう!〜もっと手軽に、もっと心を込めて〜Keep in touchグリーティングカード - SonicGarden 株式会社ソニックガーデン
■ あわせて読みたい(Advent Calender編)
3日目:SonicGardenの1プログラマから見た「納品のない受託開発」
4日目:ルールを作るな。習慣化せよ。