この記事で伝えたいこと（ポイント）
- AWSのリポジトリサービス、AWS CodeCommitが廃止された話題について振り返り（紹介記事）
- 代替となるリポジトリサービスとして、GitHubを紹介
- GitHubとAWSを連携する方法について紹介
はじめに
この記事はGitHubとAWSを連携するにはどうすれば良いかについてまとめたものです。
主な内容としては検討内容などを中心に書きます。（思いついたことなど）
誤りなどがあれば書き直していく予定です。
内容につきましては2024年12月1日時点の内容で記載しております。あらかじめご了承ください。
なお、本記事の内容は筆者の見解を多分に含んでおり、加えて何かを断定するものではございません。
前回の続き
前回の記事ではAWS CodeCommitが廃止されることをテーマにAWSにおける新しい開発環境をどうすれば良いかということを取り上げました。（Cloud9も併せて記載）
今回はその続きとして、AWS CodeCommitの代替としてGitHubをうまいことAWSと連携させる方法についてまとめます。
GitHubとAWSの連携にはどのような方法があるか
まずは大前提としてGitHubを企業で利用している場合は
GitHub Enterprise Server（以下、GHES）やGitHub Enterprise Cloud（以下、GHEC）を利用することもあります。
機能の違いや実装の違いはあれど、GitHubであることは変わりありません。
前提を踏まえてGitHubとAWSを連携する方法には以下のような方法があります。（今回は5つ紹介）
- GitHubとCodeBuildの連携
- GitHubとCodeDeployの連携
- GitHubとAmazon CodeCatalystを連携
- GitHubとAWS App Runnerの連携
- GitHubとAWS App Runnerの連携（ECRを利用）
また、構成するうえでGitHub Actionsを利用することもあります。
難しいポイントとしてビルドとテストをGitHub Actionsのみで行うのか、CodeBuildを利用するのかという部分が挙げられます。
どちらを使えば良いのかという答えはありませんが、用途やホストしているアプリケーションによって適切な方法を選択することが重要です。
個人的にはビルドとテストのみをCodeBuuildのみで行う場合はGitHubがリポジトリホスティングの役割を果たすことが多くなってしまい、あまり良い使い方とは思えません。
※ただ、その一方ではCodeBuildでビルドとテストの設定を一元管理できるというメリットもあります。
では、それぞれの連携方法について詳しく見ていきましょう。
補足：GitHub Enterprise Server（GHES）とGitHub Enterprise Cloud（GHEC）の違い
ここでGitHub Enterprise Server（GHES）とGitHub Enterprise Cloud（GHEC）の違いについて簡単に説明しますが
明確な違いとしては以下のような点が挙げられます。
| 機能 | GitHub Enterprise Server | GitHub Enterprise Cloud |
|---|---|---|
| ホスティング | オンプレミス/IaaS | クラウド |
| カスタマイズ性 | 高い | 限定的 |
| セキュリティ | 自社で管理 | GitHubが管理 |
| コスト | ハードウェア、ソフトウェア、運用コスト | サブスクリプション費用 |
| メンテナンス | 自社で実施 | GitHubが実施 |
| スケーラビリティ | 自社リソースに依存 | 高い |
ソースコードがどこに保存されるかという部分にフォーカスするとハッキリとした違いが見えてきます。
GitHubとCodeBuildの連携
まずはAWSのCodeシリーズをよく扱う人によっては一番馴染みがあるであろうCodeBuildとの連携について紹介します。
GitHub および での GitHub Enterprise Server アクセス CodeBuild - 参考
結論から説明すると「GitHubのリポジトリにプッシュされたコードをCodeBuildでビルドする」というものです。
ビルドの際はお馴染みのbuildspec.ymlを利用してビルドの設定を行います。
メリットとしては以下のような点が挙げられます。
- CodeBuildの設定を
buildspec.ymlで一元管理できる - AWSマネジメントコンソールからボタンぽちぽちで設定できる
デメリットとしては以下のような点が挙げられます。
- どのリポジトリがCodeBuildでビルドされているかがわかりにくい/わからない
- IAMロールの設定が必要
なお、Deployについてはさまざまな方法がありますが、CodePipelineでパイプラインを構築している場合はCodeDeployを利用すると良いでしょう。
GitHubとCodeDeployの連携
CodeBuildと同様にAWSのCodeシリーズをよく扱う人にとっては馴染みがある方法だと思います。
参考
- AWS CodeDeploy を使用して GitHub から自動的にデプロイする
- CodeDeploy アプリケーションを GitHub リポジトリに接続する
- AWS CodeDeploy を使用して GitHub から自動的にデプロイする
- CodeDeploy との統合 GitHub
結論から説明すると「GitHubのリポジトリにプッシュされたコードをCodeDeployでデプロイする」というものです。
この方法のメリットとしては以下のような点が挙げられます。
- CodeDeployの設定を
appspec.ymlで一元管理できる - AWSマネジメントコンソールからボタンぽちぽちで設定できる
デメリットとしては以下のような点が挙げられます。
- どのリポジトリがCodeDeployでデプロイされているかがわかりにくい/わからない
- IAMロールの設定が必要
また、この方法ではビルド/テストの工程が存在しないため、GitHub Actionsなどでビルド/テストを行う必要があります。
CircleCIやJenkinsなどのCI/CDツールを利用することもできます。※デプロイ後にテストすることもできます
GitHubとAmazon CodeCatalystを連携
次に比較的新しいサービスであるAmazon CodeCatalystとGitHubを連携する方法について紹介します。
Amazon CodeCatalystは簡単に説明するとソフトウェア統合開発サービスです。
※過去に解説しているので用語はここを参照してください。
※なお、開発環境のDev Environmentについても解説しています。こちら
GitHubリポジトリ拡張機能を利用するとAmazon CodeCatalystとGitHubを連携できます。
この方法のメリットとしては以下のような点が挙げられます。
- CodeCatalystでGitHubのリポジトリを利用できる
- CodeCatalystの機能で開発ができる（Dev Environmentの利用）
デメリットとしては以下のような点が挙げられます。
- CodeCatalystの機能を利用するためには料金がかかる（ユーザ数やMAU単位）
- IAM Identity Centerを使ったログインが必要
- あるいはAWS Builder IDを使う必要
- 参考 - 【AWS】検証！AWS Builder IDを使ってAmazon CodeCatalystをセットアップする
GitHubとAWS App Runnerの連携
GitHubとAWS App Runnerを連携する方法について紹介します。
AWS App Runnerはコンテナイメージやコードからアプリケーションをデプロイするサービスであるため
簡単に説明すると、GitHubのリポジトリにプッシュされたコードをApp Runnerでデプロイするというものです。
参考 - GitHub から AWS App Runner にデプロイする
この方法のメリットとしては以下のような点が挙げられます。
- GitHubのリポジトリがあれば、すぐにデプロイを開始できる
- 責任共有モデルの大半をAWSが管理する
デメリットとしては以下のような点が挙げられます。
- どのリポジトリがApp Runnerでデプロイされているかがわかりにくい/わからない
- ビルドとテストの工程は別途用意する必要がある（GitHub Actionsなど）
なお、App RunnerはWAF対応ができないという問題が昔の名残で質問に挙がりますが、2023年2月24日時点で対応済です。
参考 - AWS App Runner がセキュリティ強化のためのウェブアプリケーションファイアウォール (WAF) サポートを導入
GitHubとAWS App Runnerの連携（ECRを利用）
最後にもうひとつの方法としてECRを使った方法について紹介します。
先ほど、App Runnerはコンテナイメージやコードからアプリケーションをデプロイするサービスであると説明しました。
そのため、GitHubのリポジトリにプッシュされたコードをコンテナイメージとしてビルド
ECRにプッシュしてApp Runnerによるデプロイを実行するという方法があります。
以下の記事はCodeCommitを含むCodeシリーズを使った方法ですが、リポジトリはGitHubにホスティングされているものOKです。
【AWS】手を動かしながら学ぶ AWS App Runner (Codeシリーズを利用)
この方法のメリットとしては以下のような点が挙げられます。
- GitHubのリポジトリがあれば、すぐにデプロイを開始できる
- 責任共有モデルの大半をAWSが管理する
- ECRにプッシュすることで、コンテナイメージを管理できる
- ECRにコンテナイメージをプッシュできれば、ビルドとテストの工程に使うサービスはなんでも良い
デメリットとしては以下のような点が挙げられます。
- コンテナイメージを管理するためにECRが必要
- コンテナイメージのタグをどう管理するかが課題
まとめ
以上、GitHubとAWSを連携する方法について紹介しました。
AWS CodeCommitが廃止された今、リポジトリをAWS上に置くのは難しいです。ですが、GitHubリポジトリとAWSを連携する方法はいくつかあります。
また、社内の事情や利用ツールの種類、導入しているクラウドによっても選択肢は変わってくると思います。
どの方法を選択するかは用途やホストしているアプリケーションによって適切な方法を選択することが重要です。