Blog

GitHub Actions で開発環境デプロイをしよう

この記事は、リレーブログ企画「CI/CD」の記事です。

はじめに

おはようございます。IWSです。

今回は「CI/CDリレーブログ」ということで私のチームで使われている GitHub Actions を使った開発環境へのCDを紹介しようと思います。

イメージ

この構成のWebアプリに対してCDする GitHub Actions WF を作成します。ECR にあるイメージを使ってECS タスクが動いているよくある構成ですね。

この構成に対して、developブランチにmergeされたときやGitHub Actionsのページから好きなブランチを指定して開発環境にデプロイできるようになるのがゴールです。

IAM Role の用意

WFを作成する前に、まずはAWSのリソースを操作するための権限周りの準備をします。

IAM Userでアクセスキーを取得して使う方法もありますが、IAM Role を使えば一時的なクレデンシャルを発行することができセキュリティ的にも管理のしやすさ的にも楽になるのでこちらがおすすめです。

ID プロバイダの作成

IAM の IDプロバイダ のページから作成していきます。

設定内容については GitHub Docs にも書かれていますが以下のように設定していけばOKです。

  • プロバイダのタイプ
    • OpenID Connect
  • プロバイダのURL
    • https://token.actions.githubusercontent.com
  • 対象者
    • sts.amazonaws.com

IAM Role と Policy の作成

Policyを準備します。

操作したいリソースに合わせてActionの内容は変更してください。 今回はECSの更新やECRへのPushなどをするのでそのあたりを追加しています。

"sts:AssumeRoleWithWebIdentity" がないとWFが認証情報を受け取れないのでそこだけ注意。

Roleも作っていきましょう。

  • 信頼されたエンティティタイプ
    • ウェブアイデンティティ
  • アイデンティティプロバイダー
    • token.actions.githubusercontent.com
  • Audience
    • sts.amazonaws.com
  • GitHub 組織、GitHub リポジトリ、GitHub ブランチ
    • 自分のものを設定
    • ここで設定したリポジトリにあるWFにのみ認証情報を渡せるようになります。

次へ進んで先ほど作成した Policy を設定すればRoleの完成です。

ウェブアイデンティティで設定した内容は信頼ポリシーに反映されています。
Condition の StringLike の部分で Policy を渡してもいい相手を設定しています。↓の場合は test-repository 内の WF に対しては渡していいよ。という感じです。

間違っても "repo:*" みたいな設定はしないようにしましょう!どのリポジトリに対しても権限を渡してしまうゆるゆる設定になります!

ここまででIAM Roleを使ってWFがリソースの操作をできるようにする準備が終わりました!

あとはWF側でこのRoleを受け取るだけですが

公式のActionがあるのでこれだけで受け取ることができます🥳

WF の作成

ここからはWFを作成します。

以下の通りに処理を行っていきます。

  1. IAM Role の取得など初期準備
  2. DockerfileのBuild, ECRへのPush
  3. ECSの更新
  4. Slackへの通知

コード全体

先にコード全体を貼っておきます。

トリガー、初期準備

トリガーにはdevelopブランチにpushされた時と手動実行を入れています。inputsについてはのちほど……。
envにはECRやECS指定のための値やIAM RoleのARNを、steps部分については初期準備として actions/checkout やECRにログインするための aws-actions/amazon-ecr-login などをしています。

imageのBuildとECRへのPush

BuildとPushは docker/build-push-action を使ってやっています。このactionを使うだけでDockerfileのBuild、Push、キャッシュ保存までやってくれるためとりあえずこれを使っておけばいいと思います。

開発環境ですと確認のために何回もデプロイする……ということもあるのでキャッシュを使ってBuildにかかる時間を減らせるのはかなり助かります。そして面倒くさいキャッシュ設定がcache-from , cache-to だけで済むのもありがたいところですね。

キャッシュの使用は no-cache に bool で選べます。なので手動実行の際は inputs でチェックボックスを用意してチェックされたら使用しない。というふうにしています。

ECS の更新

開発環境用のWFなのでECSの更新も行っています。難しいことはしておらず AWS CLI で aws ecs update-service --force-new-deployment をして強制更新をかけているだけです。

使用するイメージについてはタスク定義で latest を使うようにしているため、更新をかけるだけで切り替わるようになっています。

Slack通知

最後に action-slack-notify というactionを使ってWFが成功したかどうかを通知しています。GitHub Actionsは if: ${{ success() }} とするだけで 成功時/失敗時 の分岐ができるのが楽で好きです。

ちなみにここは Slack の GitHub App を使っても同じことができるのでやらなくても大丈夫です。お好きなやり方で通知してみてください。

まとめ

GitHub ActionsでのCDについて書かせていただきました。

いままでは、いちいちAWSのコンソールから CodePipeline や CodeBuild などの設定を変更してから CodePipelineを実行、というふうにしていたのでこのWFが完成してからは格段に楽にデプロイできるようになりました。AWSにログインして設定をいじって実行なんて面倒くさいこと、いままでよくやっていたなと思います……

いまでも充分便利だなとは感じてはいますが、今度はGitHubのページを開くのが面倒くさいと思ってきたためSlackから発火できるようにできないかなと考えています。 もし完成したらこちらもまたブログにできたらと思っているので、その時はよろしくお願いします。

次回は、ブログ運営チームの投稿です。
おたのしみに!

ニフティでは、
さまざまなプロダクトへ挑戦する
エンジニアを絶賛募集中です!
ご興味のある方は以下の採用サイトより
お気軽にご連絡ください!

ニフティに興味をお持ちの方は
キャリア登録をぜひお願いいたします!

connpassでニフティグループに
参加いただくと
イベントの
お知らせが届きます!