あすたぴのブログ

astap(あすたぴ)のブログ

CircleCI2.0 の Workflow を使っているよ

いまいちやる気が出ない時は一度立ち止まってブログを書きます。

Workflow

こちらですね。 ジョブを複数定義し、ジョブごとに依存を定義できる。

今までのCircleCI

いままでのビルドは1フローのみでした。 A-B-C-D というイメージ。 だけど実際はジョブが1つしか定義出来なかった(出来るけど使用するには自分でAPIを呼ぶ必要があった。)ので、A1-A2-A3-A4 みたいな感じだった。

A4はA1に依存してるかもしれないけど、A3には依存していない。とか、 buildとdeployは明確に分けることが出来るんだけど、deployにもいくつかdeploy対象があって、それらは並列でいいとか、あるけど必ず順次実行だった。

具体的にどう使っているか

CIのdeploy対象としては以下の2種類がある。

  • assets(js,css,image)
  • dockerイメージ

dockerイメージも複数種類があったりして、直列に処理をしていると結構な時間がかかる。 以下のような workflow にしている。

workflows:
  version: 2
  build_and_deploy:
    jobs:
      - build
      - app_deploy:
          requires:
            - build
          filters:
            branches:
              only:
                - develop
                - master
      - assets_deploy:
          requires:
            - build
          filters:
            branches:
              only:
                - develop
                - master
      - build_node_app:
          requires:
            - build
          filters:
            branches:
              only:
                - develop
                - master
      - node_app_deploy:
          requires:
            - build_node_app
          filters:
            branches:
              only:
                - develop
                - master

まず build ジョブが走る。実際内容は rspec の実行なんだけど、たぶん buildっていうジョブ名が固定?

それが成功すると、各deployジョブが走る。

app_deploy はRailsのdockerイメージをbuildしてECRにpushしている。

assets_deployは、webpackのbuildを行ってその成果物をS3にアップしている。

build_node_appはexpress用のjsをwebpackでbuildしている。

node_app_deployはbuild_node_appの成果物を受け取って、dockerイメージをbuildしてECRにpushしている。

ここを少し気をつける必要があるのは、各job自体がdockerで動いているということ。 そのdockerイメージは自分で指定するので、自分が行いたいbuild,deployが出来るdockerイメージを用意する必要がある。

app_deployの部分は以前に書いた、multi stage buildなのでdockerではなくmachineビルドになっている。

assets_deployは、webpackのbuildを行うので、nodejs, yarn, そしてS3コマンドを使うため、aws cliが入っているdockerイメージを用意している。

build_node_appは、assets_deployと同じでいい。nodejs, yarnがあるイメージ

node_app_deployは、dockerが入っているdockerが必要になる。そして、ECRにpushするので、aws cliが必要。 あと、build_node_appからartifact経由で成果物を受け取るときにtarコマンドが必要なのでそれも入れておく。

dockerが入っているdockerってなんやねん。って思うかもしれないけど、公式に用意されている。 イカのようなDockerfileからdockerイメージをbuildしてdocker hubとかに置いておく。 何も見られて困るようなものは入ってないので、普通にpublicで良い。

FROM docker:17.05.0-ce

RUN apk update && \
    apk add \
    ca-certificates \
    git \
    openssl \
    zip \
    unzip \
    wget \
    python \
    py-pip \
    py-setuptools \
    groff \
    less \
    tar && \
    pip install awscli

という感じで、色々と準備は必要なものの、CircleCI2.0より前の場合は、 machineビルドで、用意されたVMにその場で色々インストールして、buildしてdeployしていた。 それに比べると、純粋にbuildとdeploy以外は事前に済ませておけるので実行時間は早くなる。

つまり docker は最高。