開発の平形です。

今日は、GitHubでpush時にAWS OpsWorksで自動デプロイする方法をお教えします。

OpsWorksはAWSで提供されているデプロイのサービスです。

＊OpsWorksについては、こちらのサイトが詳しいです。

この話は、OpsWorksにスタックとレイヤとインスタンスが存在する前提です。

OpsWorks自体、最近触ったばかりですが、
デプロイがすごく簡単にできるという事はよくわかりました。

でも、欲張りな僕は、もっと自動化できないのかな？と思ったのです。

普段、ソースはGitHubでバージョン管理しているので、
GitHubにpushしたら同時にデプロイできないのかな？と。

そしたら、ビックリするほど簡単に実現できました。

GitHub側で設定が可能です。
アプリケーションのリポジトリのページの「Settings」

「Service Hooks」

AWS OpsWorks

以下の項目は全て必須なので、全部入力します。

ここで、OpsWorks側の情報が必要になります。

まずは、Stack Idですが、一見これがわかるところが、AWS Managed Consoleの画面上にはありません。
手っ取り早くこれを確認する方法はStackの画面のURLをみる事です。

次にApp Idですが、同じくOpsWorksの画面で、「Apps」=>「アプリケーション名」をクリック

OpsWorks IDがApp Idです。

Branch Nameはリポジトリのデプロイしたいブランチ名を指定。

AWSのアクセスキーとシークレットキーを入力し、Update settingsをポチっとします。

あとは、該当ブランチにpushするだけ！

これで自動的にOpsWorksのデプロイが走ります。

僕はこれに感動しました！

ただ、欲張りな僕はまたまた思ったのですね。

OpsWorksではスタックを本番環境とステージング環境と分けて運用してるとします。

そうすると、

• releaseブランチはステージング
• masterブランチは本番

にそれぞれ自動デプロイできたらいいなー、と。

しかし、一つのリポジトリにつき、一つのスタックの設定しかできないんですよね。

という事で「できない」という事がわかり、取り乱しました。

まあ実際の運用で、masterのpushしただけでいきなりデプロイするのもトラブルの元になりそうだし、
そういうもんなんだ。って自分に言い聞かせて落ち着きを取り戻しました。

それでも便利には変わりないですけど。

あなたのデプロイライフがもっと充実しますように。

以上、平形がお届けしました。