株式会社フーディソン エンジニアブログ

blog

[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

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 の使い方については長くなってしまうので説明を省きます。不明なところは都度ググれば情報が出てくるはずです。

  1. Wercker セットアップ
  2. パイプライン（wercker.yml）の作成
  3. デプロイターゲットの作成

Wercker セットアップ

Wercker へのサインインが済んだら、新規にアプリケーションを作成します。

アプリケーション作成画面

セットアップに必要な工程は以下の通りです。

  1. Gitプロバイダの選択（Choose a Git provider）
    • Githubを選択
  2. リポジトリの選択（Select a repository）
    • 対象のリポジトリを選択
  3. 管理者の選択（Select owner）
    • お好みで
  4. デプロイキーの扱いについて（Configure access）
    • Add the deploy key to the selected repository for me を選択
  5. パイプラインの作成（Setup your wercker.yml）
    • リポジトリに wercker.yml を用意する
  6. 完了！（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に流れます。

Slackへの通知

まとめ

Wercker を使うことで Github のリポジトリを起点にビルド・デプロイ作業を自動化することができました。Middlemanのような静的サイトの場合はローカルでビルドしてデプロイする手間を省けるので導入効果は非常に大きいです。また、AWS Lambdaのスケジュールイベントから定期的にWerckerのAPIを叩いてビルド・デプロイさせることもでき、Middleman-blogの未来の日付に設定した記事を予約投稿のような形で公開できるようになります。これはそのうち実装してみる予定です。

今回はここまで。
次回はAWS Lambda を使って Amazon S3 にアップロードされた画像のサムネイル画像生成について試したことを紹介したいと思います。