[wercker] [middleman] [s3]
Werckerを使ってMiddlemanサイトをビルド・デプロイする
はじめに
この記事は foodison advent calendar 2015 の16日目の記事です。
前回の記事では静的サイトで課題となるWebフォームをiframe, javascript, CSS Overrideなしで構築できるサービスFormKeepについて紹介しました。 今回はCIサービスの Wercker 使った Middleman サイトのビルド・デプロイについて紹介します。
CI サービスとは
CI とは Continuous Integration(継続的インテグレーション)の略です。
継続的インテグレーションとは、ソフトウェア開発手法において、プロジェクトメンバーがそれぞれ開発した結果を頻繁に結合し、定期的にビルドやテストを行うことである。問題点を早期に摘出することができ、効率的な開発に役立つ。
不具合は早く見つける方が対策費用が抑えられるため、ソフトウェアのビルドを頻繁に行うのが好ましく、ビルド結果が正しいことを検証するためにすぐにテストを行う。このような手続きは出来る限り自動化するのが好ましい。そのため、継続的インテグレーションを実践するためには、結合のためのビルドとテストの自動化のために「CIサーバー」などと呼ばれる専用コンピュータを用意することが推奨されている。
CIを効率的に行うことができるのが Wercker や CircleCI のような CI サービスです。
Werckerについて
Wercker は CI ツール初めての私でも使えるぐらい敷居が低く、手軽に使うことができると思います。今のところ無料で使えるのも大きな理由です(2015年12月16日現在)。基本的には Middleman の環境を1人で作れるぐらいの知識・経験とAWSの基礎知識があれば Wercker を使って静的サイトをAmazon S3にビルドすることができると思います。
MiddlemanとWerckerの組み合わせは真新しいものでもなく2013年頃からすでにあったようです。
Streamlining your Middleman deploys with wercker and S3
導入することによって実現できること
CI サービスを導入することで、以下のようなことが実現できるようになります。
- githubにpushしただけでビルド・デプロイが行われる
- githubのブランチに合わせてプロダクション・ステージング等デプロイ環境を分けることができる
- ビルド・デプロイ結果をSlackに通知できる
- APIを叩いてビルド・デプロイできる
導入の仕方
大まかな流れは以下の通りです。Werckerのセットアップについては説明をしますが AWS や Git の使い方については長くなってしまうので説明を省きます。不明なところは都度ググれば情報が出てくるはずです。
- Wercker セットアップ
- パイプライン(wercker.yml)の作成
- デプロイターゲットの作成
Wercker セットアップ
Wercker へのサインインが済んだら、新規にアプリケーションを作成します。
セットアップに必要な工程は以下の通りです。
- Gitプロバイダの選択(Choose a Git provider)
- Githubを選択
- リポジトリの選択(Select a repository)
- 対象のリポジトリを選択
- 管理者の選択(Select owner)
- お好みで
- デプロイキーの扱いについて(Configure access)
Add the deploy key to the selected repository for me
を選択
- パイプラインの作成(Setup your wercker.yml)
- リポジトリに
wercker.yml
を用意する
- リポジトリに
- 完了!(Awesome! You are all done!)
パイプライン(wercker.yml)の作成
リポジトリのルートにwecker.yml
を用意します。
WerckerのパイプラインについてはLearn werckerを読むかWerckerの仕組み,独自のboxとstepのつくりかたがわかりやすいと思います。
box: ruby
build:
steps:
- script:
name: Bundler setting
code: bundle config build.nokogiri --use-system-libraries
- bundle-install
- script:
name: Middleman build
code: bundle exec middleman build --verbose
deploy:
steps:
- s3sync:
key_id: $AWS_ACCESS_KEY_ID
key_secret: $AWS_SECRET_ACCESS_KEY
bucket_url: $AWS_BUCKET_URL
source_dir: build/
delete-removed: true
Bowerを使っている場合はsteps:
にNodejs, Bowerのインストールステップを追加します。
- script:
name: Nodejs install
code: |
sudo apt-get update -y
sudo apt-get install nodejs npm -y
sudo update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10
- script:
name: Bower setup
code: sudo npm install bower -g
- script:
name: Bower install
code: bower install --allow-root
変数について
所々$...
から始まる指定があると思いますが、変数のようなもので Wercker 上で定義した変数を呼び出すことができます。これらの変数を次ぎのステップで設定していきます。
変数 | 内容 |
---|---|
$AWS_ACCESS_KEY_ID | AWSのアクセスキーID |
$AWS_SECRET_ACCESS_KEY | AWSのシークレットキー |
$AWS_BUCKET_URL | デプロイ先のS3バケット名 |
デプロイターゲットの作成
Github の master ブランチを対象にターゲットを作成してみます。
Add new variable
からAWS関係の変数を作成します。以下の画像が参考例です。
ステージング環境を作りたいときは、もう一つターゲットを作成します。その際、develop
ブランチを対象に変数を作成すれば、デプロイ先を分けることが可能です。
AWSアクセスキーIDとシークレットキーについて
AWSアクセスキーID と シークレットキー はIAMから新規ユーザーを作成しS3のフルアクセス権限を付与しておきます。
Pushしてみる
諸々の設定ができたら github に push してみてください。ビルド・デプロイに成功すると以下のような画面になります。ビルドやデプロイに失敗した場合、各ステップのログを確認して手直ししていきます。
Slackに通知する
ビルドが成功・失敗したときにSlackに通知することができます。特に外部のサービスを経由させることもないので手軽に利用できます。
パイプラインの設定
ビルドの状況をSlackに通知するには after-steps:
に slack-notifier
を使います。
box: ruby
build:
steps:
- script:
name: Bundler setting
code: bundle config build.nokogiri --use-system-libraries
- bundle-install
- script:
name: Middleman build
code: bundle exec middleman build --verbose
after-steps:
# Slackへの通知
- slack-notifier:
url: $SLACK_API_TOKEN
channel: "#channel_id"
username: wercker
branch: master
deploy:
steps:
- s3sync:
key_id: $AWS_ACCESS_KEY_ID
key_secret: $AWS_SECRET_ACCESS_KEY
bucket_url: $AWS_BUCKET_URL
source_dir: build/
delete-removed: true
利用する変数
変数 | 内容 |
---|---|
$SLACK_API_TOKEN | Slackに通知するためのAPIトークン(URL) |
APIトークンと変数
APIトークンはデプロイターゲットの変数ではなく、環境変数として設定します。APIトークンの生成はSlack上でIncoming WebHooksを新規作成し、Webhook URL https://hooks.slack.com/services/******/******/*********/
をそのままコピーしてきます。Post to Channelで流したいChannelを選択して保存しておきます。
通知
実際にBuildに成功するとこのような通知がChannelに流れます。
まとめ
Wercker を使うことで Github のリポジトリを起点にビルド・デプロイ作業を自動化することができました。Middlemanのような静的サイトの場合はローカルでビルドしてデプロイする手間を省けるので導入効果は非常に大きいです。また、AWS Lambdaのスケジュールイベントから定期的にWerckerのAPIを叩いてビルド・デプロイさせることもでき、Middleman-blogの未来の日付に設定した記事を予約投稿のような形で公開できるようになります。これはそのうち実装してみる予定です。
今回はここまで。
次回はAWS Lambda を使って Amazon S3 にアップロードされた画像のサムネイル画像生成について試したことを紹介したいと思います。