AWS CodeCatalystワークフローのデプロイでAWS CodeDeployを使った話


こんにちは!クラウドソリューション開発部の西谷です。

現在私が参加しているプロジェクトでは、昨年4月に一般公開されたAWS CodeCatalystを利用してCI/CDを実現しています。
今回の記事では、最終的にCodeCatalystのワークフローからAWS CodeDeployを使ってデプロイを実現したことについて紹介させていただこうと思います。

 

CodeCatalystとは

CodeCatalystを一言で表すと、CI/CDを実行するために必要なものが用意されているフルマネージドな統合開発環境サービスです。
ソースリポジトリ機能、クラウドベースの開発環境を構築する機能、CI/CDを実現する機能、テスト結果のレポート出力機能などなど、他にも様々な機能が利用できます。
参考:https://aws.amazon.com/jp/codecatalyst/

 

Workflows

CodeCatalystでCI/CDを実現するうえで重要なのがWorkflowsです。
このWorkflows機能は、ymlファイルに定義した内容に基づいて、一連の作業を自動で実行してくれる機能になります。
例えば、mainブランチにソースがマージされたら、ソースをビルドして、テストを実行して、問題なければデプロイを実行する。
といった作業も、ymlに定義することで自動で実行してくれます。
GitHub Actionsに近いイメージかと思います。

実現したかったこと

ここからが本題です。
私の参加するプロジェクトでも、アプリケーションのデプロイを自動化するにあたっては、Workflowsを使って実現しようと思いました。
デプロイ対象となるアプリケーションはEC2で稼働しており、デプロイするにあたっては、サーバーを停止せず、リポジトリで管理されているソースコードを稼働中のEC2の対象のディレクトリに配置する必要がありました。

問題発生

WorkflowsはCodeCatalyst上から作成することもでき、その際はワークフローのテンプレート(Actions)からワークフローの設定を行うことができます。
上記の条件を加味して、EC2にデプロイのテンプレートを検索してみると、

「おや…1件もヒットしないぞ…」

公式の情報を参照すると、「AWS CloudFormation stack」、「Amazon ECS」、「Kubernetes cluster」、「AWS CDK deploy」の4つが利用可能とのこと…
つまり、既存のEC2にソースコードを配置するだけのデプロイ方法はCodeCatalyst単体だと不可ということがわかりました。
(別プロジェクトではCodeDeployを使ってソースコードを配置していたので、てっきりCodeCatalystでも同じことができると思っていました…)

対応方法

いろいろ調べてみましたが、「CodeDeployでできるならCodeDeploy使えばいいじゃん」となり、CodeCatalystのワークフローからCodeDeployを使うことにしました。
以下の図はその一連のイメージを図示したものです。

このワークフローでミソになるのが、CodeCatalystのワークフローで、S3にzipファイルをアップロードする工程です。
CodeCatalystでは、ワークフローに定義された一連の作業を実行するコンピュートを、AWS LambdaかEC2(現時点ではAmazon Linux 2のみ)から選択できます。
S3にアップロードするためには、EC2のAWS CLIを利用することで実現しました。

AWS CLIの権限

ワークフローを定義しただけでは、ワークフローを実行するインスタンスにS3のアクセス権限がないためファイルをアップロードすることはできません。
権限を付与するには、

  • CI/CDのEnvironmentを設定する
  • CodeCatalystにIAMロールを設定する

の2つが必要になります。以降の説明はCodeCatalystでSpaceとProjectを作成し終えたことを前提に記載しており、各リソースの細かい設定については省略しています。

CI/CDのEnvironmentを設定する

Environmentでは、デプロイが実行される環境を設定します。
設定は簡単で、サイドメニューからCI/CD>Environmentsを選択して「Create environments」を押下した後に、情報を入力して作成します。
下記は開発環境で設定した場合の例です。
AWS account connectionは対象となる環境を指定します。

CodeCatalystにIAMロールを設定する

IAMロールはスペース単位で設定する必要があります。
ヘッダーのSpaceで対象となるスペースを選択し、Settingsを押下します。
AWS accountsタブで対象となるAWSアカウントを選択すると、IAM rolesパネルが表示され、そこに「Manage roles from AWS Management Console」ボタンがあるので、押下してIAMロールを追加します。

ここまで設定で、ワークフローのコンピュートからAWS CLIを使ってS3にファイルを転送する準備ができました。

ワークフロー作成

ワークフローの作成するには、まずサイドメニューのCI/CD>Workflowsに移動します。
「Create workflow」を押下し、対象のリポジトリとブランチを選択することでワークフローを作成することができます。
ワークフローを作成するときにも対象のAWSアカウントとIAMロールを指定する必要があります。
下記の図は実際にAWSアカウントとIAMロールを指定して、hoge.zipをhoge-bucketに転送するコマンドを記載した場合の例です。
(本来であればzip化する前にテストを実行したり、ビルドをしたりといった工程が入ってくると思いますが、説明を簡略化するために省略しています。)

ここまででCodeCatalystで設定する内容については完了となります。

S3イベント設定

S3のイベント設定について、少しハマった部分がありましたので共有します。
初めにイベントタイプを「PUT」のみを選択していたのですが、それだと後続のLambdaが実行されませんでした。
いろいろ設定を見直し、結果「完了したマルチパートアップロード」を選択することで解消されました。
zipファイルが大きいとマルチパートアップロードを実行してくれているようですね。

 

その他のリソースの設定について

その他S3、Lambda、CodeDeploy、EC2の設定については説明が長くなってしまうため省略しますが、CodeCatalystを使うからといって特別な設定は必要ありません。

最後に

いかがでしたでしょうか。こんなやり方もあるんだな~程度に誰かの参考になれば幸いです。
今後はもっとスマートなやり方を見つけて、チームが開発だけに集中できるような環境作りができるように知識を深めていきたいです!