JAWS-UGによる東京でのビックイベントである JAWS DAYS 2015 の DevOpsセッションでスピーカーとして登壇させていただきました。 発表内容はタイトルの通り、 『DevOpsが普及した今だからこそ考えるDevOpsの次の姿』 です。 さっそくですが発表スライドを公開します。 JAWS DAYS 2015 「DevOpsが普及した今だからこそ 考える DevOpsの次の姿」 from interu07 発表風景を代表の倉貫が撮影してくれてました。 発表時間ギリギリになってしまうだろうと思っていたのですが、だいぶ早口で説明していたようで、結果的には15分近く時間が余ってしまうという失態をしてしまいました。 ですが、皆さまの質問のお陰で時間いっぱいセッションを続けることができてホッと一安心でした。 ついでに１年前のJAWS DAYS 2014にて発表した時の資料も公開しておき

OpsWorksについての概要と、RailsサーバとNodejsサーバを管理するために知っておきたいことなどを発表してきました。 OpsWorksを知っている人向けの資料だったので、使ったことがない方には理解しがたい内容になってたかと思いますが、OpsWorksは便利だし、うまく活用すると楽できるよ！っということは使えられたかと思いますので、ぜひ試していただけたらと思います。 リモートワークに特化したチャットサービス「Remotty」についての紹介を含む資料となっています。OpsWorksに関する事例内容は p15からとなっております！ OpsWorks事例紹介！ソニックガーデンのリモートワークを支えるリアルタイムツール”Remotty”の舞台裏（2014/03/15 - JAWS DAYS） from Yoshihito Kuranuki

OpsWorksのRailsアプリケーションではRAILS_EVNが指定できるにもかかわらず、Nodejsアプリケーションでは、NODE_ENVが指定できず、stagingとproductionで振る舞いを変えたりすることができません。 opsworks_custom_env や OpsWorksEnvyのenvironment_variables などを参考にレシピを自分で作成するのもよいのですが、レシピの中でなるべく依存関係が無い状態にしたり、デフォルトのMonit監視設定を変更したりしなければなりません。また、opsworksで自動で設定される標準設定を書き換えてしまうと、今後AWS側で標準設定の書き換えが行われた時にその変更も取り込んだりしないといけないので、出来る限り設定ファイルの上書きでなくファイル追加などで対応したいところですね。 なので、今回紹介するやり方は デプロイフック

これまで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

半年くらい前に『OpsWorksでRailsアプリからAmazon RDSなどの外部DBを利用する方法』というブログを書きましたが、その記事の後半で 今回紹介した方法(deploy時にCustom Chef JSONを指定)を本番環境に適用して運用しようとすると、いつの日かサービスダウンを招いてしまうことになってしまうため、注意が必要です と記載していました。あとで書くと言っておきながら全然書いていなかったので、そろそろその理由と対策方法について紹介します。 こちらの記事では、DeploymentsのCustom Chef JSONにてデータベース接続設定を記載していました。そのため、アプリケーションのデプロイの度に database.yml がアップデートされます。これは想定内の動きですよね。 ですが、ここで同じレイヤのインスタンスを新しく追加して、それを起動してみてください。 新しく立

前回は、『OpsWorksでRailsをデプロイする際にasset:precompileを実施する方法』というタイトルで、デプロイフックの仕組みについて紹介しました。 今回は、Amazon RDSのようなデータベース・サーバが別インスタンスで稼働している場合を想定して、どのようにしてdatabase.ymlの値を変更すればよいかを紹介します。 まずはOpsworksでRailsアプリケーションを稼働させるためには、アプリケーション全体の設定を定義するStackの設定をしたり、Appサーバ／DBサーバなどのようなインスタンスの役割を定義するLayerの設定をしないといけないのですが、こちらについての解説は割愛します。詳細は細かいところまで丁寧に解説してくれている下記URLを参考にしてください。 http://recipe.kc-cloud.jp/archives/tag/opsworks で

OpsWorksでRailsアプリケーションを運用するために知っておくべきことを数回に渡り本ブログで紹介していきます。 今回はOpsWorksのデプロイフックを利用する方法です。 Railsでは、JavaScriptやCSSを結合して圧縮することで、ブラウザがウェブページを描画するために必要となるリクエスト数を削減する仕組み(Asset Pipeline)が用意されています。 この仕組みを利用するには、rake asset:precompile というタスクを実行する必要がありますが、OpsWorksのRailsアプリケーションのデフォルトのデプロイ処理ではこのタスクを実行してくれません。 しかし、OpsWorksにはデプロイフックという仕組みが用意されています。 それではその仕組の利用方法を紹介します。 まず、${RAILS_ROOT}にdeployというディレクトリを作成し、その中にb

昨夜、茅場町のコワーキングスペース「Co-Edo」にて、paperboy&co. の梅谷さん(@ume3_)とKDDI webcommunications inc の阿部さん(@yskmerlion)と私の3名で、異なる企業規模のインフラ寄りのエンジニアが、それぞれの立ち位置でチームとして日々どのように仕事を進めているかなどをざっくばらんにお話させていただきました。 企業規模・組織体系によってアプローチが全く異なっていたりし、私としてもいろんなインプットを得ることができる有意義な場でした。 企画してくださいました小山田さん(@h5y1m141)、ありがとうございました。 ちなみに本イベントの概要は、「事業拡大に伴い、リーダーとして業務をすることになった人をイメージし、今後リーダーとして仕事をする上でどんなことを日々意識して業務に取り組むべきかというコンセプトで60分ほどのパネルディスカッシ