GitLabとAWS CodePipelineでScalaのCI環境を作る

先日、AWSのCodePipelineというサービスを使ってCI環境をしてみました。
必要な設定が思いの外多かったので備忘も兼ねて構築方法を共有します。

## CodePipelineについて
AWSには以下の開発者向けの3つのサービスがあります。

- CodeCommit gitのホスティング
- CodeBuild ビルドサービス
- CodeDeploy デプロイサービス

CodePipelineはこれらのサービスを組み合わせたワークフローを管理するサービスです。

## CIの構成
以下の図の様に、GitLabにpushしたソースコードをAWSのCodePipeline側でビルドして最終的にECSにデプロイするCIを作ります。
![スクリーンショット 2019-12-28 14.24.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/14415172-53b2-c0ba-b35d-ae848ca42e6d.png)

## 構築の手順
次の流れで構築していきますが、ECSなどが作成済の環境にCIを作る場合は適宜読み飛ばしてください。
ちなみに、Scalaならではの対応が必要なのは1.と8.の手順のみです。

1. Scalaのプロジェクトの作成
2. CodeCommitの作成
3. GitLabでのコードのミラーリングの設定
4. ECRの作成
5. ECSの作成
6. (オプション)ローカルからのデプロイ
7. CodePipelineの作成
8. 設定ファイルの作成
9. 実行


## Scalaプロジェクトの作成

今回は例としてPlay Frameworkで作成したWebアプリケーションをデプロイします。

まず、Dockerイメージを作るためのプラグインを追加します。

```plugins.sbt
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.5.2")
```

build.sbtのプロジェクト名とバージョンが、Dockerイメージの名前とタグになるため適宜修正します。
また、dockerのビルド用の設定も追加しておきます。

```scala:build.sbt
name := """scala-ci-sample"""
organization := "com.example"
version := "1.0.0"

lazy val root = (project in file("."))
  .enablePlugins(PlayScala)
  .settings(
    maintainer in Docker := "sample@example.com",
    dockerBaseImage := "openjdk:8-jdk-alpine",
    dockerCommands ++= Seq(
      Cmd("USER", "root"),
      Cmd("RUN", "apk --update add bash")
    ),
    dockerExposedPorts ++= Seq(9000),
    daemonUserUid in Docker := None,
    daemonUser in Docker := "daemon"
  )
```

CIとは直接関係ありませんが、application.confにデプロイする際に必要な設定も追加しておきます。
本番で利用される場合は適切な値を設定してください。

```:application.conf
play.server.pidfile.path=/dev/null
play.filters.hosts.allowed = ["."]
play.http.secret.key="change_me"
play.http.secret.key=${?APPLICATION_SECRET}
```

各種設定が終わったら、ローカルでDockerイメージが作成できるか確認します。

```
$ sbt docker:publishLocal
$ docker images
REPOSITORY               TAG                 IMAGE ID            CREATED             SIZE
scala-ci-sample          1.0.0               246b9833441a        About a minute ago  149MB
```

問題なくDockerイメージが作成できる事を確認したら、ソースコードはGitLabにpushしておきます。


## CodeCommitの作成

### リポジトリの作成
AWS側でソースコードを管理するCodeCommitのリポジトリを作成します。

AWSコンソールの「リポジトリを作成」ボタンから作成する事ができます。
![スクリーンショット 2019-12-22 21.43.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/e192a8c2-3a45-b02a-35ff-bdcda7227a15.png)

今回はリポジトリ名をscala-ci-sample-repoにします。
![スクリーンショット 2019-12-22 21.45.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/1466e4bb-5a50-150d-d460-ee751c38befa.png)

作成できたら「HTTPSのクローン」からリポジトリのURLを取得しておきます。このURLはGitLabでミラーリングの設定をする際に使用します。（※1）
![スクリーンショット 2019-12-22 22.17.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/1075ad0f-d191-c268-817a-307f1c693b42.png)

「設定」で確認できるリポジトリのARNも控えておきます。このARNはリポジトリへのミラーリング用の権限を作成する際に使用します。（※2）

![スクリーンショット 2019-12-22 21.56.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/31833481-ec45-87dc-a442-8bb47a190b63.png)


### 権限の設定

リポジトリを作っただけでは外部からアクセスできないため、権限の設定を行います。
まずはIAMでポリシーを作成します。

CodeCommitのPullとPushの権限を与えます。
リソースにはリポジトリのARN(※2)を指定します。

![スクリーンショット 2019-12-22 21.58.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/0f610b0a-8681-af23-4933-65de612a6353.png)


次にポリシーをアタッチしたユーザーを作成します。
![スクリーンショット 2019-12-22 22.05.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/9b4a3a51-db91-0931-6181-d7cb9acbcd0f.png)

これだけではまだCodeCommitにhttpで直接アクセスする権限を持たないので、認証情報のタブから権限を追加します。
![スクリーンショット 2019-12-22 22.08.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/ac90f18f-e15a-e0d8-c98d-a3ec391256d3.png)

認証情報を作成のボタンを押すと認証情報が作成され、csvファイルとしてダウンロードできます。この認証情報はGitLab側でのミラーリングの設定に使用します。(※3)
![スクリーンショット 2019-12-22 22.08.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/9bfa7da9-aa85-2d3a-56a4-862f5a2d7f49.png)

## GitLabでのコードのミラーリングの設定

GitLabにコードがコミットされた際に、AWSのCodeCommitに転送するミラーリングの設定を行います。

Settings -> Repository の Mirroring repositories で設定を行います。
![スクリーンショット 2019-12-22 22.13.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/f3d0fba0-e8dc-f394-c840-0a49082a6e1e.png)

設定内容は以下の通りです。
Git repository URL: https://<CodeCommitの認証情報(※3)のUser Name>@<リポジトリのURL(※1)>
Mirror direction: Push
Authentication method: Password
Password: CodeCommitの認証情報(※3)のPassword
![スクリーンショット 2019-12-22 22.34.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/f32220d9-5317-3814-db04-4ee9d3fbfb1e.png)


設定できたらゴミ箱の左のボタンを押すと正しく接続できるか確認できます。

![スクリーンショット 2019-12-22 22.35.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/5ea656c5-fe4b-0fa4-8bde-802d7a0a0f2a.png)

CodeCommit側でもソースコードが表示できれば、ミラーリングの設定は完了です。

![スクリーンショット 2019-12-22 22.36.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/e13123da-7a5b-6246-c020-ea1133efceb4.png)

## ECRの作成

ECRのリポジトリを作成します。

![スクリーンショット 2019-12-27 13.34.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/be0943f1-443e-aec2-15bc-63985f38056e.png)


作成後にリポジトリのURIを控えておきます。(※4)
![スクリーンショット 2019-12-28 15.49.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/58a8e450-a649-2c6b-5960-74a697c3fcd1.png)

## ECSの作成
詳細は割愛しますが、ECSのクラスター、タスク、サービス、ロードバランサーなどを作成します。
タスクを作成する際にコンテナを追加しておきます。イメージの場所にECR(※4)を指定します。まだイメージが登録されていないので仮のタグを指定しておきます。
![スクリーンショット 2019-12-28 15.46.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/f48d3946-23fa-84ca-0981-d384363c9a60.png)


## (オプション) 手動でのデプロイの確認

ここまでで、デプロイ先の環境ができたので、ローカルで作ったDockerイメージをECSにデプロイしてみます。
この手順はスキップできますが、初回のデプロイはセキュリティーグループや環境変数の設定が間違っている事がよくあるので一旦手動でデプロイしてうまく動くか確認するのがおすすめです。

ECRへは以下のコマンドでイメージをpushできます。

```
(aws ecr get-login --no-include-email --region ap-northeast-1)
# 上記のコマンドの実行後に表示されたログインコマンドをコピー＆ペーストで実行する
docker tag scala-ci-sample:1.0.0 <アカウント>.dkr.ecr.ap-northeast-1.amazonaws.com/scala-ci-sample-ecr:1.0.0
docker push <アカウント>.dkr.ecr.ap-northeast-1.amazonaws.com/scala-ci-sample-ecr:1.0.0
```

push後にECSのタスクとサービスを更新して問題なく動く事を確認します。


## CodePipelineの作成

CodePipelineの「パイプラインを作成する」から作成します。
必要事項を入力して順次進んでいくと、ソースステージ、ビルドステージ、デプロイステージが作られます。

![スクリーンショット 2019-12-27 13.37.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/a030c966-f8b5-8b6d-e4b3-2853542a7b8d.png)

![スクリーンショット 2019-12-27 13.37.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/94b3aa60-dc08-f6a3-a680-9e754efb0eaa.png)

### ソースステージの作成
CodeCommitのリポジトリとビルド対象のブランチを指定します。

![スクリーンショット 2019-12-27 13.38.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/dc4520e1-6849-97db-104c-9c22a66224da.png)

### ビルドステージの作成
「プロジェクトを作成する」からビルドプロジェクトを作ります。

![スクリーンショット 2019-12-27 13.38.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/3e4e9a9f-f5fe-e7a4-a7c8-44e2e1d3315d.png)

### CodeBuildの作成
ビルドプロジェクトに適当な名前をつけます。

![スクリーンショット 2019-12-27 13.40.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/dc092ac3-539a-3cfe-d94a-b3c8a48b6cd8.png)

環境ではマネージド型イメージを選択して、OSはAmazon Linuxを選択します。
今回はマネージド型イメージを選択しましたが、sbtなどがインストール済のコンテナを作ってそちらを利用するようにするとビルド時間が短縮できるかと思います。

![スクリーンショット 2019-12-27 13.44.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/50868ffa-f04e-3859-1654-0ccf4fe4243d.png)

今回はBuildspecを使用してビルドの定義を行います。
buildspec.ymlはCircleCIで言うところのconfig.ymlに相当するファイルです。ファイルの詳細については後述します。

![スクリーンショット 2019-12-27 13.41.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/ef98b3be-b66c-2150-3d83-7522e1367ad4.png)

ビルド時にECRにアクセスできる権限を付与する必要があるので、ロール名を控えておきます。(※5)

![スクリーンショット 2019-12-27 13.45.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/80657a14-aecc-491a-d28d-6c60e150225e.png)

作成後にビルドステージに戻ってプロジェクトとして設定します。

![スクリーンショット 2019-12-27 13.45.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/800cf766-5a63-295e-2bbc-967d0d389f62.png)

### デプロイステージの作成

デプロイステージではデプロイ対象のECSのクラスターとサービスを指定します。

![スクリーンショット 2019-12-27 14.48.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/42a5e4b9-a589-7b5c-d25e-78f05a44f8f2.png)

### ポリシーの設定

今回はCodeBuild内でイメージを作成してECRにpushする必要があるため、
IAMからCodeBuildが使用するポリシー(※5)にECRにアクセスする権限を付与します。
追加する必要のある権限は以下の通りです。

```
    {
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:CompleteLayerUpload",
        "ecr:GetAuthorizationToken",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
```

![スクリーンショット 2019-12-27 20.34.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82768/5cc5181c-f6ae-3a6f-a137-cedb9a0b4a08.png)


## 設定ファイルの作成

ソースコードのルートディレクトリにbuildspec.ymlを追加します。
installではbuildの環境の指定、pre_buiuldではsbtのインストールなどのビルドの準備、buildでは実際のビルド、post_buildでは次のデプロイステージのための準備を定義します。

```buildspec.yml
version: 0.2

phases:
  install:
    runtime-versions:
      docker: 18
      java: corretto8
  pre_build:
    commands:
      - echo commit hash ${CODEBUILD_RESOLVED_SOURCE_VERSION}
      - $(aws ecr get-login --no-include-email --region ap-northeast-1)
      - yum -y install sbt
  build:
    commands:
      - echo Build started
      - sbt docker:publishLocal
  post_build:
    commands:
      - echo publish ECR
      - docker tag scala-ci-sample:1.0.0 <アカウント>.dkr.ecr.ap-northeast-1.amazonaws.com/scala-ci-sample-ecr:${CODEBUILD_RESOLVED_SOURCE_VERSION}
      - docker push <アカウント>.dkr.ecr.ap-northeast-1.amazonaws.com/scala-ci-sample-ecr:${CODEBUILD_RESOLVED_SOURCE_VERSION}
      - printf '[{"name":"scala-ci-sample-container","imageUri":"%s"}]' <アカウント>.dkr.ecr.ap-northeast-1.amazonaws.com/scala-ci-sample-ecr:${CODEBUILD_RESOLVED_SOURCE_VERSION} > imagedefinitions.json
artifacts:
  files: imagedefinitions.json
```

pre_buiuldやbuildは特に説明は不要だと思いますが、post_buildで何を行っているか解説します。
まず、以下の部分ではビルド結果のイメージにタグ付してECRにpushしています。タグはbuild.sbtで指定されたバージョンではなくコミットハッシュを使用するようにしています。
CloudBuildではコミットハッシュを表す環境変数の CODEBUILD_RESOLVED_SOURCE_VERSION の他にもいくつかの環境変数が用意されています。
参考: https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-env-ref-env-vars.html

```yml
- docker tag scala-ci-sample:1.0.0 <アカウント>.dkr.ecr.ap-northeast-1.amazonaws.com/scala-ci-sample-ecr:${CODEBUILD_RESOLVED_SOURCE_VERSION}
- docker push <アカウント>.dkr.ecr.ap-northeast-1.amazonaws.com/scala-ci-sample-ecr:${CODEBUILD_RESOLVED_SOURCE_VERSION}
```

以下の部分ではビルドステージでECSへデプロイを行う際にデプロイ対象のコンテナ名とイメージのURLを記載した imagedefinitions.json というファイルが必要なのですが、今回はビルドの度にタグが変更されるため、ビルドステージ内で動的に作成しています。

```yml
- printf '[{"name":"scala-ci-sample-container","imageUri":"%s"}]' <アカウント>.dkr.ecr.ap-northeast-1.amazonaws.com/scala-ci-sample-ecr:${CODEBUILD_RESOLVED_SOURCE_VERSION} > imagedefinitions.json
```

## 実行
上記で作成したファイルをGitLabにpushすると以降はmasterブランチに変更が入る度にCIが実行されるようになります。

## 参考
https://dev.classmethod.jp/cloud/aws/gitlab-codecommit-mirroring/
https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-spec-ref.html
https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/file-reference.html