自分の会社のサイトは創立以来 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 対応にやったこと
- CircleCI 2.0 のドキュメントの確認
- Middleman がビルドできる Docker イメージ作成
circle.yml
を.circleci/config.yml
に変更
CircleCI 2.0 を利用するには Docker イメージが必要です。CircleCI が用意しているイメージを利用する方法もあります。
Pre-Built CircleCI Docker Images - CircleCI
今回は Docker の学習も兼ねて自分で Docker イメージを用意することにしました。
Docker イメージの作り方
できたもの:
- Docker Hub: yuya-matsushima/middleman
- GitHub
今回は 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 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 と大差ない気がします。