(1)はこちら 、( 2)はこちら から。
GitHub Actions── ビルドとデプロイプロセスの自動化
(3)では、先ほど作成したECS環境に、GitHub Actionsを用いて自動的にアプリケーションをビルドしてデプロイするしくみを構築します。
GitHub Actionsとは、GitHubがgithub.com
に統合した形で提供するCI(Continuous Integration 、継続的インテグレーション)/CD(Continuous Delivery 、継続的デリバリ)環境です。GitHub Actionsには、ソースコードのpullやPull Requestのアサインといった豊富な機能(アクション)が用意されています。ユーザーは、アクションと実行タイミングや実行環境などを組み合わせ、ワークフローと呼ばれるYAML(YAML Ain't Markup Language )ファイルにまとめます。リポジトリの所定の位置にこのYAMLファイルを配置すると、GitHubがそのとおりにワークフローを実行してくれます。
今回はブランチモデルとして、git-flow方式に似た構成を採用します。すなわち、デプロイ用のブランチとしてmaster
を使い、デプロイの前段階としての開発用ブランチにdevel
ブランチを使います。
cpanfile.snapshotを自動で生成しよう
cpanfile.snapshot
は、carton install
を実行する環境によっては異なるものが生成されます。そのため、各開発者の手もとでcpanfile
とともにcpanfile.snapshot
をコミットする方法で開発している場合、cpafile.snapshot
が頻繁に変化してしまうことがあります。これを防ぐために、GitHub Actionsを使ってcpanfile.snapshot
を集中的に生成しましょう。
ワークフローの定義
では、.github/workflows/perl.yml
にワークフローを定義しましょう。
on:
push:
branches:
- devel
pull_request:
branches:
- devel
jobs:
cpan:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- uses: actions/checkout@v2
- name: Generate cpanfile.snapshot
working-directory: ./application
run: |
./generate-cpanfile-snapshot.sh
- uses: stefanzweifel/git-auto-commit-action@v3.0.0
with:
commit_message: Updated cpanfile.snapshot
file_pattern: application/cpanfile.snapshot
前半のon
ブロックでは、ワークフローの実行条件を指定します。今回は、devel
ブランチにpushされたときと、devel
宛てのPull Requestで変更を検知したときを指定しています。
後半のjobs
ブロックが、実際の処理を記述する部分です。ワークフローは複数のジョブから成り立っており、ジョブはさらに複数のステップから成り立っています。個々のアクションはステップで実行されます。今回は、1つのジョブを作成しています。そのジョブの中で、まずcheckout
アクションを使ってソースコードをGitHub Actions上の仮想環境にチェックアウトしたあと、cpanfile.snapshot
を生成するgeneratecpanfile-snapshot.sh
というシェルスクリプトを呼び出します。そして、git-auto-commit-action
アクションによって、cpanfile.snapshot
が変更されていればコミットし、pushしています。
cpanfile.snapshotを生成するシェルスクリプトの作成
前述したgenerate-cpanfile-snapshot.sh
では、cpanmやCartonをインストールし、carton install
を実行してcpanfile.snapshot
を生成しています。簡潔なコードなのでここでは割愛します。WEB+DB PRESS Vol.116のサポートサイト のサンプルコードを参照してください。
いざ生成
これで、自動的にcpanfile.snapshot
を生成する準備ができました。perl.yml
とgenerate-cpanfilesnapshot.sh
をコミットしてpushすると、ワークフローが起動してcpanfile.snapshot
が生成されます。
Amazon ECSへデプロイしよう
GitHubには、ECSにアプリケーションをデプロイする公式アクションが用意されています。これにより、「 特定のブランチにコミットがpushされたとき」といったタイミングでECSにイメージをデプロイできます。
ワークフローの定義
GitHubのテンプレートを使ってワークフローを作成しましょう。GitHubでリポジトリを開き、「 Actions」タブの「New workflow」ボタンをクリックすると、「 Deploy to Amazon ECS」という項目が表示されるので、これを選択します。すると、あらかじめ項目が埋められたYAMLファイルを編集する画面が現れます。
編集を行う前に、あらかじめ、次のリソースを用意しておきましょう。それぞれについて詳しくは、YAMLファイルのコメント(英語)をご覧ください。
アプリケーションのイメージが格納されるECRリポジトリ(URIではなく名前を記入する)
リポジトリのリージョン名
ECSクラスタ
YAMLファイルの各項目を次のように埋め、.github/workflows/aws.yml
として保存します。
(省略)
- name: Build, tag, and push image to Amazon ECR
id: build-image
env:
ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
ECR_REPOSITORY: ECRリポジトリ
IMAGE_TAG: ${{ github.sha }}
run: |
docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_T
AG ./application/
docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPO
SITORY:$IMAGE_TAG"
- name: Fill in the new image ID in the Amazon ECS task de
finition
id: task-def
uses: aws-actions/amazon-ecs-render-task-definition@v1
with:
task-definition: task-definition.json
container-name: app # ここではコンテナ名をappとする
image: ${{ steps.build-image.outputs.image }}
- name: Deploy Amazon ECS task definition
uses: aws-actions/amazon-ecs-deploy-task-definition@v1
with:
task-definition: ${{ steps.task-def.outputs.task-defin
ition }}
service: サービス名
cluster: クラスタ名
wait-for-service-stability: true
(省略)
今回は、master
ブランチにマージなどの変更が発生したときにデプロイしたいので、master
ブランチへのpushかマージがあったときにワークフローを起動するよう、デフォルトのまま指定しました。
Amazon ECSタスク定義の作成
GitHub Actionsを使ってデプロイする場合、タスク定義としてtask-definition.json
を用意する必要があります。手動で作成することもできますが、あらかじめブラウザ上のGUI(Graphical User Interface )でひな型を作成しておき、編集画面からコピーできるJSONを保存すると簡単です。
Amazon ECSのトップ画面から「タスク定義」タブを開き、「 新しいタスク定義の作成」をクリックし、ウィザードにしたがってタスク定義を設定します。「 起動タイプ」は「FARGATE」を選択し、「 コンテナの追加」をクリックしてコンテナ定義を1つ作成します。ここではコンテナ名やイメージを、ecs-cli
コマンドを使ったときと同じに設定しておきます。こうして作成したタスク定義を「タスク定義」タブから開くと、JSONをコピーできます。JSONにはrequiresAttributes
といったプロパティが自動で追加されていますが、これは不要なので削除します。そのほかにもデプロイ時に不要なパラメータを指摘されることがあるため、その場合は該当するプロパティを都度削除しましょう。
IAMユーザーのクレデンシャルの登録
イメージのpushやデプロイにはIAM(Identity and Access Management )ユーザーが必要です。IAMユーザーを作成して、各種権限を割り当てましょう。ここでは割愛しますが、ECSのサービスを更新する権限と、ECRにアップロードする権限などを設定します。
そして、GitHubがこのIAMユーザーとして振る舞えるようにするために、作成したIAMユーザーのアクセスキーIDとシークレットアクセスキーをGitHubに登録します。これはYAMLファイルにではなく、GitHub Actions Secretsとして別画面から保存します。リポジトリの「Settings」➡「Secrets」を開くとクレデンシャルを追加できますので、アクセスキーIDはAWS_ACCESS_KEY_ID
という名前で、シークレットアクセスキーはAWS_SECRET_ACCESS_KEY
という名前で保存しましょう。
いざデプロイ
これで準備ができました。devel
ブランチからのPullRequestをmaster
ブランチにマージすると、ECSクラスタにPerlアプリケーションが自動的にデプロイされます。
まとめ
今回は、ECSとGitHub Actionsを用いて、Dockerアプリケーションをすばやくビルド、デプロイする方法を解説しました。
さて、次回の執筆者は清水隆博さんで、テーマは「Perl歴史散策」です。お楽しみに。
特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現!
特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう
特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、NFT