よかろうもん!

アプリからインフラまで幅広くこなすいまどきのクラウドエンジニアが記す技術ブログ

SonicGarden Studyという勉強会でHerokuでの運用術について話しました!

SonicGardenが不定期で開催している勉強会イベント「SonicGarden Study」で、Herokuを使ってサービスを運用する際のポイントについて、メンバーの西見さん(@mah_lab)と共に講師としてお話させていただきましたので、その時の資料を公開しておきます。

f:id:interu:20140628130904p:plain

話のポイントとしては、"運用って、アプリが動けばよいというものではないよ!"というところです。


本スライドの解説については @mah_lab がきちんとまとめてくれてますので、「実践DevOps! SonicGarden流Herokuガチ運用術!」というテーマでCIO安達とHerokuでの運用について話しました | mah365 を覗いてみてください。

ちなみに次回の勉強会は、メンバーの伊藤さん(@jnchito)によるコードレビューとのことです。

CodeIQに出題した「カラオケマシン問題」に挑戦してくれた50名の挑戦者の中から、「これは素晴らしい!」という解答例を3つ紹介します!

とのことです。ご興味のある方はぜひご覧ください。
まだイベントは公開されていませんが、http://sonicgarden.doorkeeper.jp/ で申込をしておくとイベント公開時に通知されますので!

JAWS DAYS 2014でOpsWorksの活用事例について発表していきました!

OpsWorksについての概要と、RailsサーバとNodejsサーバを管理するために知っておきたいことなどを発表してきました。

f:id:interu:20140315163731j:plain


OpsWorksを知っている人向けの資料だったので、使ったことがない方には理解しがたい内容になってたかと思いますが、OpsWorksは便利だし、うまく活用すると楽できるよ!っということは使えられたかと思いますので、ぜひ試していただけたらと思います。

リモートワークに特化したチャットサービス「Remotty」についての紹介を含む資料となっています。OpsWorksに関する事例内容は p15からとなっております!

OpsWorksでNodejsアプリを動かすときにNODE_ENVが指定できないのを何とかする件

OpsWorksのRailsアプリケーションではRAILS_EVNが指定できるにもかかわらず、Nodejsアプリケーションでは、NODE_ENVが指定できず、stagingとproductionで振る舞いを変えたりすることができません。

opsworks_custom_envOpsWorksEnvyのenvironment_variables などを参考にレシピを自分で作成するのもよいのですが、レシピの中でなるべく依存関係が無い状態にしたり、デフォルトのMonit監視設定を変更したりしなければなりません。また、opsworksで自動で設定される標準設定を書き換えてしまうと、今後AWS側で標準設定の書き換えが行われた時にその変更も取り込んだりしないといけないので、出来る限り設定ファイルの上書きでなくファイル追加などで対応したいところですね。

なので、今回紹介するやり方は デプロイフックとNodejsのnode-configモジュールを組み合わせるという技です。

node-config の使い方については、

node.jsのいろいろなモジュール13 – node-configで設定ファイルを切り替えたりする | Developers.IO

を参考にするとすぐに理解できるかと思います。環境毎に固有の設定を別ファイルに抜き出しておくことで、自動で環境に応じた設定ファイル読み込めるというものです。

今回はこの仕組みを利用して以下の設定ファイルを作成したものとして話を進めます。

  • config
    • default.js (開発環境の設定)
    • staging.js (ステージング環境の設定)
    • production.js (本番環境の設定)

環境ごとの設定ファイルが出来たことで、デプロイした時に適切なファイルを読み込めるようにすればNODE_ENVを指定できなくても大丈夫ですね。

まずは、StackのCustom JSON環境変数を設定しましょう。

次はDeployフックです。以前、『OpsWorksでRailsをデプロイする際にasset:precompileを実施する方法 - よかろうもん!』の記事にてデプロイフックのやり方をご紹介しましたね。

Nodejsでも同じようにdeployディレクトリ以下にフック処理を記述したファイルを配置しましょう。

今回は deploy/before_restart.rb というファイルを作成し、上記 StackのCustom JSONで指定した値を読み込み、その値の設定ファイルを default.js にコピーしてデフォルト値として読み込ませます。NODE_ENVの指定がない場合は staging.js / production.js よりも優先して default.js が読み込まれるようになっているので、これで大丈夫なんですね。


上記を見ればすぐにわかりますが、node_envを読み込んで、必要となるファイルをコピーしていますね。


これで deploy フックとStackでのCustom JSONの指定だけで、NODE_ENVを指定した時と同じような仕組みを実現できましたね。めでたしメデタシ。

OpsWorksでNodejsアプリを動かす上で知っておきたいこと 〜その壱〜

これまでOpsWorksでRailsアプリケーションを動かす上での注意事項を紹介してきましたが、今日はNodejsアプリケーションをOpsWorksで動かすときのポイントを紹介します。

まずはNodejsを動かす上での最低限の要件がこちらです。

  • メインファイルの名前は server.js
  • expressで動かす場合は package.json が必要
  • 80 or 443 で Listenする必要


この要件を満たしておけば、あとはウィザードに従ってアプリケーションをサーバにデプロイするだけで簡単に動かせます。いやー、実にラクチンですね。

ただ、nodejsで https を require して443ポートで動かそうとする際は注意が必要です。

443ポートでListenしていても、プロセス監視のMonitが http://127.0.0.1:80/ を監視しています。



最新のtemplateはこちらをご確認ください


そのため、443番ポートで Listen している場合でも、ヘルスチェック用に80番ポートで HTTP STATUS 200 を返すようにしなければなりません

443ポートでListenしているだけでも Nodejs は動作しますが、定期的に Monit が node のプロセスをリスタートしているため確立したコネクションがその都度リセットされてしまいますので。
定期的にリスタートされていることには気づきにくいので、NodejsをHTTPSで運用する際は一度サーバ内部で確認しておきましょう!


ここからは未検証の話ですが、Appの設定で SSL Settings を有効にした場合でも、Monitの監視設定は変更されず同様の事象が発生する可能性があるかもしれないので、HTTPSで受け付ける際はご注意ください。

また、aws/opsworks-cookbooks · GitHub を眺めていたところ、Appの設定で SSL Settings を有効にしても、JSONパラメータとしてはサーバに渡されますが、NginxやApacheで443で受け取ったり、自動的にserver.js にHTTPS化のための設定が挿入されたりするわけではなさそうです。なので、 SSL Settings を有効にしても実際はSSL化できないのではないかと思われます(未検証です)。この点については本ブログを見て頂いているAWSの中の人教えてください!
もし間違ってたらゴメンナサイ。前もって誤っておきます。。。



現状、OpsWorksのNodejsアプリケーションでは、NODE_ENVが指定できず、stagingとproductionで振る舞いを変えたりすることができないので、明日はそれを簡単に実現するための方法をご紹介しようと思います。

OpsWorksでRailsアプリを動かす際に注意しておきたいデータベース接続の設定

半年くらい前に『OpsWorksでRailsアプリからAmazon RDSなどの外部DBを利用する方法』というブログを書きましたが、その記事の後半で

今回紹介した方法(deploy時にCustom Chef JSONを指定)を本番環境に適用して運用しようとすると、いつの日かサービスダウンを招いてしまうことになってしまうため、注意が必要です

と記載していました。あとで書くと言っておきながら全然書いていなかったので、そろそろその理由と対策方法について紹介します。

こちらの記事では、DeploymentsのCustom Chef JSONにてデータベース接続設定を記載していました。そのため、アプリケーションのデプロイの度に database.yml がアップデートされます。これは想定内の動きですよね。

ですが、ここで同じレイヤのインスタンスを新しく追加して、それを起動してみてください。
新しく立ち上げたインスタンスが起動する頃には、今まで正常にアクセスできていたアプリケーションにアクセスできなくなっているはずです。

これは、スタックの状態変化(新規インスタンスの起動)をトリガーとして、Configureイベントが発動したことで、Railsサーバ全てのシステム設定が整合性のとれた状態に変更され database.yml が削除されてしまったためです。ちなみにこのConfigureイベントは、インスタンスの起動だけでなく停止した場合にも発動します。

詳細はOpsWorksのドキュメントに詳しく書いてあるため是非読んでみてください。


では、database.yml が削除されないようにするにはどうしたらよいでしょうか。

Deployイベント発動時に設定するCustom JSONにデータベース接続情報を入れるのではなく、スタック自体に設定すれば大丈夫です。
スタックに設定すればConfigureイベントが発動した時も、スタックのCustom JSONの情報を参照し、適切な database.yml を配置してくれます。


f:id:interu:20140310205546p:plain


staging環境などではあまり複数台構成にしたりしないため、なかなか気づかないハマりポイントですので、本番稼働をする前に設定を確認しておいてください。

なお、この情報は2013年年末時点で検証した結果ですので、もしかするとすでに改善されているかもしれません。情報をお持ちの方はぜひコメントいただければと思います。

日経SYSTEMS、「DevOpsツールで実現するタイムリー開発」の取材を受けました

ソニックガーデンの自社サービスや納品のない受託開発で取り組んでいるDevOpsについて日経BPさんに取材を受けた記事が発売されました。

f:id:interu:20140225224033p:plain

日経SYSTEMS 2014年3月号 ※最初の数ページを閲覧できます。


DevOpsを実践する上で利用している開発/運用のツール群の紹介や、プロダクトオーナー(お客様)とのコミュニケーションを円滑にするために利用しているツール(youRoom)の紹介について取り上げられていました。

大手企業の取り組みの中に、ソニックガーデンのことも取り上げられており大変恐縮です。
もともとTISの社内ベンチャーとして立ち上がったソニックガーデンですが、そんな生みの親であるTISの取り組みと同じところに掲載されていて、少しホッコリした気持ちになりました。