CircleCI 2.0 を使って Middleman で作ったサイトを AWS S3 + CloudFront にデプロイ

自分の会社のサイトは創立以来 Middleman で管理運用しています。これまでは CircleCI 1.0 の機能を利用して AWS S3 にデプロイし CloudFront のキャッシュをクリアする構成になっていました。

CircleCI 1.0 が 2018 年 8 月末日で利用できなくなるため 2.0 に変更する必要がありました。

CircleCI 1.0 End of Life on August 31, 2018

CircleCI 2.0 対応にやったこと

  1. CircleCI 2.0 のドキュメントの確認
  2. Middleman がビルドできる Docker イメージ作成
  3. circle.yml.circleci/config.yml に変更

CircleCI 2.0 を利用するには Docker イメージが必要です。CircleCI が用意しているイメージを利用する方法もあります。

Pre-Built CircleCI Docker Images - CircleCI

今回は Docker の学習も兼ねて自分で Docker イメージを用意することにしました。

Docker イメージの作り方

できたもの:

今回は Ubuntu 16.04 をベースに Ruby, NodeJS + Yarn が動作するイメージを作成しました。自分でイメージを作成する場合は必須となるパッケージがあるので注意が必要です。Ubuntu 16.04 の場合は例えば ca-certificates は必須です。

必要なパッケージについてはドキュメントに記述があります。Using Custom-Built Docker Images - CircleCI

今回はこれに加え, aws コマンドを追加しています。CloudFront の invalidate 処理に必要になります。問題なくビルドが完了したら Docker Hub に push して完了です。

.circleci/config.yml の記述

.circleci/config.yml

CircleCI 2.0 の設定ファイルは主に次の記述が必要です。

  • job による実行タスクの定義
    • Docker イメージの指定
    • テストやビルドの実行
  • workflow による job の呼び出し
    • job の呼び出し順の指定
    • 動作する branch 条件の指定

静的サイトのビルド&&デプロイであれば, build + deploy 2 つの job を定義, workflow で master ブランチの場合のみ deploy を呼び出しの形になります。

しかし, 今回は middleman-s3_sync を使う都合で master ブランチ専用の job, それ以外の job を定義し呼び出す方法をとっています。s3_sync 前提だと生成したファイルの取り回しが面倒になるためです。

CircleCI 2.0 に移行してどうか

  • メリット
    • 3 分かかっていた処理が 1 分に短縮
    • 1.0 の時は circle.yml で頑張る必要があったが Docker イメージの環境を中心に考えればいい
  • デメリット
    • 自分で Docker イメージを作るのは慣れが必要

全体的には移行するだけのメリットはありました。簡単なものであれば Docker イメージを自作する必要はないので設定方法が理解できれば CircleCI 1.0 と大差ない気がします。