Amazon Web Services ブログ
Amazon CodeCatalyst で GitHub Actions を利用する
訳者注）このブログは CodeCatalyst の代表的な使い方を説明する全 5 回のブログ記事のうち 4 回目にあたります。最初の記事は「Amazon CodeCatalyst を用いたワークフローによるビルド、テスト、デプロイの実現」です。
Amazon CodeCatalyst ワークフローは、継続的インテグレーションおよび継続的デリバリー (CI/CD) システムの一部としてコードをビルド、テスト、デプロイする方法を記述する自動化されたプロシージャです。CodeCatalyst ワークフローでは、GitHub Actions を CodeCatalyst アクションと一緒に使用できます。
イントロダクション
このシリーズの以前の記事「Amazon CodeCatalyst を用いたワークフローによるビルド、テスト、デプロイの実現」では、CodeCatalyst での CI/CD パイプラインの作成と、それが The Unicorn Project の主役である Maxine とどのように関係しているかについて説明しました。CodeCatalyst ワークフローは、高品質のアプリケーションアップデートを頻繁に、迅速かつ安全・確実に配信するのに役立ちます。CodeCatalyst を使用すると、アクションをすばやく組み立てて設定し、CI/CD パイプライン、テストレポート、その他の手動プロセスを自動化するワークフローを作成できます。ワークフローでは、プロビジョニングされたコンピューティング、Lambda コンピューティング、カスタムコンテナイメージ、マネージドビルドインフラストラクチャを使用して、柔軟性を犠牲にすることなく簡単に実行をスケーリングできます。この投稿では、ワークフローに戻り、ネイティブの CodeCatalyst アクションと一緒に GitHub Actions を実行する方法について説明します。
前提
このチュートリアルを進めるには、次のことを行う必要があります。
- CodeCatalyst にサインインするための AWS Builder ID を用意してください。
- スペースに所属し、スペース内で自分にスペース管理者ロールを割り当ててください。詳細については、「CodeCatalyst でのスペースの作成とスペースのメンバーの管理」、および「スペース管理者ロール」を参照してください。
- スペースに AWS アカウントを関連付けて、そのアカウントで IAM ロールを割り当ててください。ロールとロールポリシーの詳細については、「CodeCatalyst サービスロールの作成」を参照してください。
手順
CodeCatalyst シリーズのこれまでの記事と同様に、ここでモダン 3 層 Web アプリケーションのブループリントを使用します。ブループリントにはサンプルコードと CI/CD ワークフローが用意されているため、プログラミング言語とアーキテクチャをさまざまに組み合わせて簡単に始めることができます。手順をたどるには、以前に作成したプロジェクトを再利用することも、3 層 ブループリントを使用してプロジェクトを作成する手順を説明した以前の投稿を参照することもできます。
チームが成長するにつれて、コードの品質が低下していることに気づきました。そのため、新しいプルリクエストが送信されたときにコードの品質を検証するためのツールをいくつか追加したいと思います。さらに、コードでどのコンポーネントが使用されているかがわかるように、プルリクエストごとにソフトウェア部品表 (SBOM) を作成したいと考えています。ワークフローに関する前回の投稿では、デプロイメントワークフローに焦点を当てました。この投稿では、OnPullRequest ワークフローに焦点を当てます。OnPullRequest パイプラインを表示するには、左側のナビゲーションから CI/CD を展開し、[Workflows] を選択します。次に、OnPullRequest を選択すると、次のスクリーンショットに示すワークフローが表示されます。このワークフローは、新しいプルリクエストが送信されたときに実行され、現在 Amazon CodeGuru を使用して自動コードレビューを実行しています。
図 1: CodeGuru code review による OnPullRequest Workflow
CodeGuru はコード品質を向上させるためのインテリジェントなレコメンデーションを提供しますが、スタイルのチェックは行いません。開発者が私たちのコーディング規約に従っていることを確認するために、Linter を追加したいと思います。CodeCatalyst は豊富なネイティブアクションをサポートしていますが、現時点では Linter は含まれていません。幸い、CodeCatalyst は GitHub Actions もサポートしています。GitHub Actions を使ってワークフローに Linter を追加してみましょう。
ワークフロー画面の右上隅にある Edit を選択します。エディターが YAML モードで開いた場合は、コードの上にあるトグルを使用して Visual モードに切り替えます。次に、「+ Actions」を選択してアクションのリストを表示します。次に、ドロップダウンを使用して Amazon CodeCatalyst から GitHub に変更します。このブログが公開された時点で、CodeCatalyst には厳選された GitHub アクションが 12 個ほど含まれています。利用可能な Action はキュレーションされたアクションのリストに限定されないことに注意してください。リストにない GitHub Actions を追加する方法については、この記事の後半で説明します。まずは、Super-Linter を使ってプルリクエストのコーディングスタイルをチェックします。厳選されたリストから Super-Linter を探し、plus アイコンをクリックしてワークフローに追加します。
図 2: Super-Linter の追加画面
これにより、ワークフローに新しいアクションが追加され、設定ダイアログボックスが開きます。これ以上の設定は必要ないため、設定ダイアログボックスを閉じるだけで済みます。これで、ワークフローは次のようになるはずです。
図 3: Super-Linter を追加した後のワークフロー表示
アクションは並行して実行するように設定されていることに注意してください。前回の記事で、デプロイメントワークフローについて説明したとき、手順は直列で実行されていました。各ステップは前のステップに基づいて構築されていたので、これは理にかなっています。プルリクエストのワークフローでは、アクションは独立しているので、アクションを並行して実行できるようにして、より早く完了するようにします。[Validate] を選択し、問題がないと仮定して [Commit] を選択して変更をリポジトリに保存します。
CodeCatalyst はプルリクエストが送信されるとワークフローを開始しますが、送信するプルリクエストはありません。そのため、[Run] を選択してワークフローをテストします。画面上部の通知には、実行内容を表示するためのリンクが含まれています。予想どおり、Super Linter はアプリケーションコードに問題が見つかったため失敗します。Super Linter アクションをクリックしてログを確認します。ここでは、バックエンドアプリケーションで使用される app.py に関して Super Linter から報告された問題をいくつか紹介します。ログは 1 行に収まるように少し変更されていることに注意してください。
Super Linter が動くようになったので、ソフトウェア部品表 (SBOM) の作成に目を向けます。OWASP CycloneDX を使用して SBOM を作成します。CodeCatalyst には多くの開発者に役立つと思われる GitHub Actions の厳選されたリストがあるだけでなく、ほとんどすべての Actions を使用できます。キュレーションリストにないGitHub Actions を追加するには、編集モードに戻り、キュレーションされたアクションのリストで “GitHub Actions” を見つけ、プラスアイコンをクリックしてワークフローに追加します。
図 4: 任意のGitHub Actions追加画面
CodeCatalyst はワークフローに新しいアクションを追加し、設定ダイアログボックスを開きます。[Configuration] タブを選択し、鉛筆アイコンを使用して [Action Name] を「Software-Bill-of-Materials」に変更します。次に、設定セクションまでスクロールして、GitHub Action YAML を変更します。最新バージョン番号を含めて YAML を GitHub Actions マーケットプレイスからコピーできることに注意してください。さらに、CycloneDX アクションでは、入力パラメータとして Python 要件ファイルへのパスを渡す必要があります。
図 5: GitHub Action の設定 YAMLファイル
一般的な GitHub Action を使っているので、そのアクションによって生成されるアーティファクトと実行後に収集すべきアーティファクトを CodeCatalyst に伝える必要があります。CyclonedX は bom.xml という名前の XML ファイルを作成します。これをアーティファクトとして設定します。CodeCatalyst アーティファクトはワークフローアクションの出力であり、通常はフォルダまたはファイルのアーカイブで構成されることに注意してください。アーティファクトを後続のアクションと共有できます。
図 6: Artifacts での bom.xml 生成パス設定
もう一度 [Validate] を選択し、問題がないと仮定して [Commit] を選択して変更をリポジトリに保存します。これで、プルリクエストが送信されると並行して実行されるアクションが 3 つあります。CodeGuru、Super-Linter および Software-Bill-of-Materials です。
図 7: Software-Bill-of-Materials 追加後のワークフロー表示
以前と同様に、[Run] を選択してワークフローをテストし、通知の view リンクをクリックします。予想どおり、Super-Linterはまだ問題を報告しているので、ワークフローは失敗します。ただし、新しいソフトウェア部品表は正常に完了しました。Artifacts タブから SBOM をダウンロードできます。
図 8: Artifact タブでコードレビューと SBOM が表示されます
アーティファクトは、CyclonedDX によって作成された bom.xml を含む zip アーカイブです。xml 以外の情報として、バックエンドアプリケーションで使用されるコンポーネントのリストが含まれます。
<components>
<component type="library" bom-ref="7474f0f6-8aa2-46db-bebf-a7648cff84e1">
<name>Jinja2</name>
<version>3.1.2</version>
<purl>pkg:pypi/jinja2@3.1.2</purl>
</component>
<component type="library" bom-ref="fad0708b-d007-4f98-a80c-056b136015df">
<name>aws-cdk-lib</name>
<version>2.43.0</version>
<purl>pkg:pypi/aws-cdk-lib@2.43.0</purl>
</component>
<component type="library" bom-ref="23e3aaae-b4e1-4f3b-b026-fcd298c9cb9b">
<name>aws-cdk.aws-apigatewayv2-alpha</name>
<version>2.43.0a0</version>
<purl>pkg:pypi/aws-cdk.aws-apigatewayv2-alpha@2.43.0a0</purl>
</component>
<component type="library" bom-ref="d283cf17-9125-422c-b55c-cabb64d18f79">
<name>aws-cdk.aws-apigatewayv2-integrations-alpha</name>
<version>2.43.0a0</version>
<purl>pkg:pypi/aws-cdk.aws-apigatewayv2-integrations-alpha@2.43.0a0</purl>
</component>
<component type="library" bom-ref="0f095c84-c9e9-4d6c-a4ed-c4a6c7605426">
<name>aws-cdk.aws-lambda-python-alpha</name>
<version>2.43.0a0</version>
<purl>pkg:pypi/aws-cdk.aws-lambda-python-alpha@2.43.0a0</purl>
</component>
<component type="library" bom-ref="b248b85b-ba27-4796-bcdf-6bd82ad47295">
<name>constructs</name>
<version>>=10.0.0,<11.0.0</version>
<purl>pkg:pypi/constructs@%3E%3D10.0.0%2C%3C11.0.0</purl>
</component>
<component type="library" bom-ref="72b1da33-19c2-4b5c-bd58-7f719dafc28a">
<name>simplejson</name>
<version>3.17.6</version>
<purl>pkg:pypi/simplejson@3.17.6</purl>
</component>
</components>これで、ワークフローでコードの品質が強化され、希望どおりの SBOM が生成されるようになりました。これは素晴らしいスタートですが、まだ改善の余地があることに注意してください。まず、ワークフロー内のアクションによって生成されたレポートを収集して、コード品質の成功基準を定義できました。次に、ソフトウェア構成分析 (SCA) ソリューションを使用して、既知のセキュリティ脆弱性について SBOM をスキャンできました。これについては、このシリーズの今後の記事で取り上げます。
クリーンアップ
このワークフローに従っている場合は、引き続き料金が発生しないように、デプロイしたリソースを削除する必要があります。まず、ブループリントを起動したときに関連付けた AWS アカウントの AWS CloudFormation コンソールを使用して CDK がデプロイした 2 つのスタックを削除します。これらのスタックには mysfitsXXXXXWebStack や mysfitsXXXXXAppStack などの名前が付けられます。次に、プロジェクト設定に移動し、[プロジェクトの削除] を選択して、CodeCatalyst からプロジェクトを削除します。
まとめ
この投稿では、GitHub Actions を CodeCatalyst ワークフローに追加する方法を学びました。ワークフローでは、ネイティブのCodeCatalyst アクションと一緒に GitHub Actions を使用しました。また、厳選されたアクションリストと、このリストにないアクションの両方から Action を追加することについても説明しました。CodeCatalyst で GitHub Actions を使用する方法の詳細については、ドキュメントをご覧ください。
この記事は Using GitHub Actions with Amazon CodeCatalyst を翻訳したものです。翻訳はソリューションアーキテクトの高柴元が担当致しました。