Amazon CodeCatalyst は新規のお客様には提供されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[CodeCatalyst から移行する方法](migration.md)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# コンピューティングイメージとランタイムイメージの構成
CodeCatalyst ワークフローでは、CodeCatalyst でワークフローアクションの実行に使用するコンピューティングとランタイム環境イメージを指定できます。
*コンピューティング*とは、CodeCatalyst がワークフローアクションを実行するために管理および保守するコンピューティングエンジン (CPU、メモリ、およびオペレーティングシステム) を指します。
**注記**
コンピューティングがワークフローのプロパティとして定義されている場合、そのワークフロー内のアクションのプロパティとしてコンピューティングを定義することはできません。同様に、コンピューティングがアクションのプロパティとして定義されている場合、ワークフロー内でコンピューティングを定義することはできません。
*ランタイム環境イメージ*は、CodeCatalyst がワークフローアクションを実行する Docker コンテナです。Docker コンテナは、選択したコンピューティングプラットフォーム上で実行され、オペレーティングシステムと、、Node.js AWS CLI、.tar などのワークフローアクションに必要な追加のツールが含まれています。
**Topics**
+ [コンピューティングタイプ](#compute.types)
+ [コンピューティングフリート](#compute.fleets)
+ [オンデマンドフリートのプロパティ](#compute.on-demand)
+ [プロビジョニングされたフリートのプロパティ](#compute.provisioned-fleets)
+ [プロビジョニングされたフリートの作成](projects-create-compute-resource.md)
+ [プロビジョニングされたフリートの編集](edit-compute-resource.md)
+ [プロビジョニングされたフリートの削除](delete-compute-resource.md)
+ [アクションへのフリートまたはコンピューティングの割り当て](workflows-assign-compute-resource.md)
+ [アクション間でのコンピューティングの共有する](compute-sharing.md)
+ [ランタイム環境イメージの指定](build-images.md)
## コンピューティングタイプ
CodeCatalyst には次のコンピューティングタイプが用意されています。
+ Amazon EC2
+ AWS Lambda
Amazon EC2 はアクションの実行中に最適化された柔軟性を提供し、Lambda はアクションの起動速度を最適化します。Lambda では、起動レイテンシーが低いため、ワークフローアクションの実行速度が速くなります。Lambda では、一般的なランタイムでサーバーレスアプリケーションを構築、テスト、デプロイできる基本的なワークフローを実行できます。これらのランタイムには、Node.js、Python、Java、.NET、Go が含まれます。ただし、Lambda でサポートされていないユースケースもいくつかあります。それによって影響がある場合は Amazon EC2 コンピューティングタイプを使用してください。
+ Lambda では、指定されたレジストリからのランタイム環境イメージをサポートしていません。
+ Lambda では、root 権限を必要とするツールをサポートしていません。`yum` や `rpm` などのツールには、Amazon EC2 コンピューティングタイプや root 権限を必要としないその他のツールを使用してください。
+ Lambda では Docker のビルドや実行をサポートしていません。Docker イメージを使用する以下のアクションはサポートされていません。スタックのデプロイ AWS CloudFormation 、Amazon ECS へのデプロイ、Amazon S3 パブリッシュ、 AWS CDK ブートストラップ、 AWS CDK デプロイ、 AWS Lambda 呼び出し、GitHub Actions。CodeCatalyst GitHub Actions アクション内で実行されている Docker ベースの GitHub Actions も、Lambda コンピューティングではサポートされていません。Podman など、root 権限を必要としない代替手段を使用できます。
+ Lambda では、`/tmp` 外部のファイルへの書き込みがサポートされていません。ワークフローアクションを構成するときは、ツールを再構成して `/tmp` にインストールまたは書き込みできます。`npm` をインストールするビルドアクションがある場合は、必ず `/tmp` にインストールするように構成してください。
+ Lambda では 15 分を超えるランタイムをサポートしていません。
## コンピューティングフリート
CodeCatalyst では、次のコンピューティングフリートが用意されています。
+ オンデマンドフリート
+ プロビジョニングされたフリート
オンデマンドフリートでは、ワークフローアクションが開始されると、ワークフローが必要なリソースをプロビジョニングします。マシンはアクションが終了すると破棄されます。アクションを実行している間のみ、分単位で料金が発生します。オンデマンドフリートはフルマネージド型で、需要の急増にも対応できる自動スケーリング機能を備えています。
CodeCatalyst には、CodeCatalyst によって維持される Amazon EC2 を搭載したマシンを含むプロビジョニングされたフリートも用意されています。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを構成します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートでは、マシンは常に稼働しており、プロビジョニングされている間はコストが発生します。
フリートを作成、更新、または削除するには、**スペース管理者**ロールまたは**プロジェクト管理者**ロールが必要です。
## オンデマンドフリートのプロパティ
CodeCatalyst には以下のオンデマンドフリートがあります。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/workflows-working-compute.html)
**注記**
オンデマンドフリートの仕様は請求階層によって異なります。詳細については、「[料金](https://codecatalyst.aws/explore/pricing)」を参照してください。
フリートが選択されていない場合、CodeCatalyst では `Linux.x86-64.Large` を使用します。
## プロビジョニングされたフリートのプロパティ
プロビジョニングされたフリートには次のプロパティがあります。
**オペレーティングシステム**
オペレーティングシステム。使用できるオペレーションシステムは次のとおりです。
+ Amazon Linux 2
+ Windows Server 2022
**注記**
Windows フリートはビルドアクションでのみサポートされています。その他のアクションでは現在 Windows をサポートしていません。
**アーキテクチャ**
プロセッサアーキテクチャ。以下のアーキテクチャが利用可能です。
+ x86\$164
+ Arm64
**マシンタイプ**
各インスタンスのマシンタイプ。次のマシンタイプを使用できます｡
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/workflows-working-compute.html)
**Capacity**
フリートに割り当てられるマシンの初期数。これにより、並列で実行できるアクションの数が定義されます。
**スケーリングモード**
アクション数がフリート容量を超えたときの動作を定義します。
**オンデマンドで追加の容量をプロビジョニングする**
オンデマンドで追加のマシンを設定すると、新しいアクションの実行に応じて自動的にスケールアップし、アクションが完了するとベース容量までスケールダウンします。実行中のマシンごとに分単位でのお支払いとなるため、追加のコストが発生する可能性があります。
**追加のフリート容量が利用可能になるまで待機する**
アクションの実行は、マシンが使用可能になるまでキューに入れられます。これにより、さらにマシンが割り当てられないため、追加のコストが抑えられます。
# プロビジョニングされたフリートの作成
以下の手順に従って、プロビジョニングされたフリートを作成します。
**注記**
プロビジョニングされたフリートは、アイドル状態が 2 週間続くと、非アクティブ化されます。再度使用すると、自動的に再アクティブ化されますが、この再アクティブ化によりレイテンシーが発生する可能性があります。
**プロビジョニングされたフリートを作成するには**
1. ナビゲーションペインで **[CI/CD]**、**[コンピューティング]** の順に選択します。
1. **[プロビジョニングされたフリートの作成]** を選択します。
1. **[プロビジョニングされたフリート名]** テキストフィールドに、フリートの名前を入力します。
1. **[オペレーティングシステム]** ドロップダウンメニューから、オペレーティングシステムを選択します。
1. **[マシンタイプ]** ドロップダウンメニューから、マシンのマシンタイプを選択します。
1. **[キャパシティ]** テキストフィールドに、フリートのマシンの最大数を入力します。
1. **[スケーリングモード]** ドロップダウンメニューから、目的のオーバーフロー動作を選択します。フィールドの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。
1. **[作成]** を選択します。
プロビジョニングされたフリートを作成したら、アクションに割り当てる準備ができました。詳細については、「[アクションへのフリートまたはコンピューティングの割り当て](workflows-assign-compute-resource.md)」を参照してください。
# プロビジョニングされたフリートの編集
以下の手順に従って、プロビジョニングされたフリートを編集します。
**注記**
プロビジョニングされたフリートは、アイドル状態が 2 週間続くと、非アクティブ化されます。再度使用すると、自動的に再アクティブ化されますが、この再アクティブ化によりレイテンシーが発生する可能性があります。
**プロビジョニングされたフリートを編集するには**
1. ナビゲーションペインで **[CI/CD]**、**[コンピューティング]** の順に選択します。
1. **[プロビジョニングされたフリート]** 一覧で、編集するフリートを選択します。
1. **[編集]** を選択します。
1. **[キャパシティ]** テキストフィールドに、フリートのマシンの最大数を入力します。
1. **[スケーリングモード]** ドロップダウンメニューから、目的のオーバーフロー動作を選択します。フィールドの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。
1. **[保存]** を選択します。
# プロビジョニングされたフリートの削除
プロビジョニングされたフリートを削除するには、以下の手順に従います。
**プロビジョニングされたフリートを削除するには**
**警告**
プロビジョニングされたフリートを削除する前に、アクションの YAML コードから `Fleet` プロパティを削除して、すべてのアクションから削除します。削除後もプロビジョニングされたフリートを参照し続けるアクションは、次回アクションが実行されたときに失敗します。
1. ナビゲーションペインで **[CI/CD]**、**[コンピューティング]** の順に選択します。
1. **[プロビジョニングされたフリート]** 一覧で、削除するフリートを選択します。
1. **[削除]** を選択します。
1. **delete** と入力して削除を確定します。
1. **[削除]** を選択します。
# アクションへのフリートまたはコンピューティングの割り当て
デフォルトでは、ワークフローアクションでは Amazon EC2 コンピューティングタイプの `Linux.x86-64.Large` オンデマンドフリートを使用します。代わりにプロビジョニングされたフリートを使用するか、`Linux.x86-64.2XLarge` などの異なるオンデマンドフリートを使用するには、次の手順に従います。
------
#### [ Visual ]
**[開始する前に]**
+ プロビジョニングされたフリートを割り当てる場合は、まずプロビジョニングされたフリートを作成する必要があります。詳細については、「[プロビジョニングされたフリートの作成](projects-create-compute-resource.md)」を参照してください。
**プロビジョニングされたフリートまたは異なるフリートタイプをアクションに割り当てるには**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。
1. プロジェクトを選択します。
1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。
1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。
1. **[編集]** を選択します。
1. **[ビジュアル]** を選択します。
1. ワークフロー図で、プロビジョニングされたフリートまたは新しいフリートタイプを割り当てるアクションを選択します。
1. **[設定]** タブを選択します。
1. **[コンピューティングフリート]** で以下を実行します。
ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。
プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。
`Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。
1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。
1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
------
#### [ YAML ]
**[開始する前に]**
+ プロビジョニングされたフリートを割り当てる場合は、まずプロビジョニングされたフリートを作成する必要があります。詳細については、「[プロビジョニングされたフリートの作成](projects-create-compute-resource.md)」を参照してください。
**プロビジョニングされたフリートまたは異なるフリートタイプをアクションに割り当てるには**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。
1. プロジェクトを選択します。
1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。
1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。
1. **[編集]** を選択します。
1. **[YAML]** を選択します。
1. プロビジョニングされたフリートまたは新しいフリートタイプを割り当てるアクションを見つけます。
1. アクションで `Compute` プロパティを追加し、`Fleet` をフリートの名前またはオンデマンドフリートタイプに設定します。詳細については、アクションの「[ビルドおよびテストアクション YAML](build-action-ref.md)」の `Fleet` プロパティの説明を参照してください。
1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。
1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
------
# アクション間でのコンピューティングの共有する
デフォルトでは、ワークフロー内のアクションは [[フリート]](workflows-working-compute.md#compute.fleets) 内の個別のインスタンスで実行されます。この動作では、入力の状態を分離し、予測可能なアクションを実行できます。デフォルトの動作では、ファイルや変数などのコンテキストをアクション間で共有するための明示的な設定が必要です。
コンピューティング共有は、同じインスタンスでワークフロー内のすべてのアクションを実行できる機能です。コンピューティング共有を使用すると、インスタンスのプロビジョニングに費やす時間が短縮されるため、ワークフローの実行時間が短縮されます。ワークフロー設定を追加することなく、アクション間でファイル (アーティファクト) を共有することもできます。
ワークフローがコンピューティング共有を使用して実行されると、デフォルトまたは指定されたフリートのインスタンスは、そのワークフロー内のすべてのアクションの期間中予約されます。ワークフローの実行が完了すると、インスタンス予約が解放されます。
**Topics**
+ [共有コンピューティングでの複数のアクションの実行](#how-to-compute-share)
+ [コンピューティング共有に関する考慮事項](#compare-compute-sharing)
+ [コンピューティング共有の有効化](#compute-sharing-steps)
+ [例](#compute-sharing-examples)
## 共有コンピューティングでの複数のアクションの実行
ワークフローレベルで定義 YAML の `Compute` 属性を使用して、アクションのフリート共有プロパティとコンピューティング共有プロパティの両方を指定できます。CodeCatalyst のビジュアルエディタを使用してコンピューティングプロパティを設定することもできます。フリートを指定するには、既存のフリートの名前を設定し、コンピューティングタイプを **[EC2]** に設定し、コンピューティング共有をオンにします。
**注記**
コンピューティング共有は、コンピューティングタイプが **[EC2]** に設定されている場合のみサポートされ、Windows Server 2022 オペレーティングシステムではサポートされていません。コンピューティングフリート、コンピューティングタイプ、プロパティの詳細については、「[コンピューティングイメージとランタイムイメージの構成](workflows-working-compute.md)」を参照してください。
**注記**
無料利用枠にいて、ワークフロー定義 YAML で `Linux.x86-64.XLarge` または `Linux.x86-64.2XLarge` フリートを手動で指定すると、アクションは引き続きデフォルトのフリート (`Linux.x86-64.Large`) で実行されます。コンピューティングの可用性と料金の詳細については、「[階層オプション の表](https://codecatalyst.aws/explore/pricing)」を参照してください。
コンピューティング共有を有効にすると、ワークフローソースを含むフォルダがアクション間で自動的にコピーされます。ワークフロー定義 (YAML ファイル) 全体で出力アーティファクトを設定し、入力アーティファクトとして参照する必要はありません。ワークフロー作成者は、コンピューティング共有を使用しない場合と同様に、入力と出力を使用して環境変数をワイヤアップする必要があります。ワークフローソース外のアクション間でフォルダを共有する場合は、ファイルキャッシュを検討してください。詳細については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」および「[ワークフロー実行間のファイルのキャッシュ](workflows-caching.md)」を参照してください。
ワークフロー定義ファイルが存在するソースリポジトリは、ラベル「`WorkflowSource`」によって識別されます。コンピューティング共有を使用している間、ワークフローソースは、それを参照する最初のアクションでダウンロードされ、ワークフロー実行のその後のアクションで自動的に使用可能になります。ファイルの追加、変更、削除など、アクションによってワークフローソースを含むフォルダに加えられた変更は、ワークフロー内の後続のアクションにも表示されます。コンピューティング共有を使用せずに、任意のワークフローアクションのワークフローソースフォルダにあるファイルを参照できます。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」を参照してください。
**注記**
コンピューティング共有ワークフローでは、並列アクションを設定できないように、アクションの厳密なシーケンスを指定する必要があります。出力アーティファクトはシーケンス内の任意のアクションで設定できますが、入力アーティファクトはサポートされていません。
## コンピューティング共有に関する考慮事項
ワークフローの実行を高速化し、同じインスタンスを使用するワークフロー内のアクション間でコンテキストを共有するために、コンピューティング共有を使用してワークフローを実行できます。コンピューティング共有の使用がシナリオに適しているかどうかを判断するには、以下を考慮してください。
| | コンピューティング共有 | コンピューティング共有なし |
| --- | --- | --- |
| コンピューティングタイプ | Amazon EC2 | Amazon EC2、AWS Lambda |
| インスタンスのプロビジョニング | 同じインスタンスで実行されるアクション | 別のインスタンスで実行されるアクション |
| オペレーティングシステム | Amazon Linux 2 | Amazon Linux 2、Windows Server 2022 (ビルドアクションのみ) |
| ファイルの参照 | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` |
| Workflow 構造 | アクションはシーケンシャルにしか実行できません | アクションは並列で実行できます |
| ワークフローアクション間のデータへのアクセス | キャッシュされたワークフローソースにアクセスする (`WorkflowSource`) | 共有アーティファクトのアクセス出力 (追加の設定が必要) |
## コンピューティング共有の有効化
次の手順に従って、ワークフローのコンピューティング共有を有効にします。
------
#### [ Visual ]
**ビジュアルエディタを使用してコンピューティング共有を有効にするには**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。
1. プロジェクトを選択します。
1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。
1. ワークフローの名前を選択します。
1. **[編集]** を選択します。
1. **[ビジュアル]** を選択します。
1. **[ワークフロー]** プロパティを選択します。
1. **[コンピューティングタイプ]** ドロップダウンメニューから **[EC2]** を選択します。
1. (オプション) **[コンピューティングフリート - オプション]** ドロップダウンメニューから、ワークフローアクションの実行に使用するフリートを選択します。オンデマンドフリートを選択するか、プロビジョニングされたフリートを作成して選択できます。詳細については、「[プロビジョニングされたフリートの作成](projects-create-compute-resource.md)」および「[アクションへのフリートまたはコンピューティングの割り当て](workflows-assign-compute-resource.md)」を参照してください。
1. トグルを切り替えてコンピューティング共有を有効にし、ワークフロー内のアクションを同じフリートで実行します。
1. (オプション) ワークフローの実行モードを選択します。詳細については、「[実行のキュー動作の構成](workflows-configure-runs.md)」を参照してください。
1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
------
#### [ YAML ]
**YAML エディタを使用してコンピューティング共有を有効にするには**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。
1. プロジェクトを選択します。
1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。
1. ワークフローの名前を選択します。
1. **[編集]** を選択します。
1. **[YAML]** を選択します。
1. コンピューティング共有をオンにして、`SharedInstance` フィールドを `TRUE` に、`Type` を `EC2` に設定します。`Fleet` をワークフローアクションの実行に使用するコンピューティングフリートに設定します。オンデマンドフリートを選択するか、プロビジョニングされたフリートを作成して選択できます。詳細については、「[プロビジョニングされたフリートの作成](projects-create-compute-resource.md)」および「[アクションへのフリートまたはコンピューティングの割り当て](workflows-assign-compute-resource.md)」を参照してください。
ワークフロー YAML で、次のようなコードを追加します。
```
Name: MyWorkflow
SchemaVersion: "1.0"
Compute: # Define compute configuration.
Type: EC2
Fleet: MyFleet # Optionally, choose an on-demand or provisioned fleet.
SharedInstance: true # Turn on compute sharing. Default is False.
Actions:
BuildFirst:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: ...
...
```
1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。
1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
------
## 例
**Topics**
+ [例: Amazon S3 Publish](#compute-share-s3)
### 例: Amazon S3 Publish
次のワークフロー例は、Amazon S3 Publish アクションを 2 つの方法で実行する方法を示しています。まず入力アーティファクトを使用し、次にコンピューティング共有を使用します。コンピューティング共有では、キャッシュされた `WorkflowSource` にアクセスできるため、入力アーティファクトは必要ありません。さらに、ビルドアクションの出力アーティファクトが不要になりました。S3 Publish アクションは、明示的 `DependsOn` プロパティを使用してシーケンシャルアクションを維持するように設定されています。S3 Publish アクションを実行するには、ビルドアクションが正常に実行されている必要があります。
+ コンピューティング共有なしでは、入力アーティファクトを使用し、出力を後続のアクションと共有する必要があります。
```
Name: S3PublishUsingInputArtifact
SchemaVersion: "1.0"
Actions:
Build:
Identifier: aws/build@v1
Outputs:
Artifacts:
- Name: ArtifactToPublish
Files: [output.zip]
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: ./build.sh # Build script that generates output.zip
PublishToS3:
Identifier: aws/s3-publish@v1
Inputs:
Artifacts:
- ArtifactToPublish
Environment:
Connections:
- Role: codecatalyst-deployment-role
Name: dev-deployment-role
Name: dev-connection
Configuration:
SourcePath: output.zip
DestinationBucketName: amzn-s3-demo-bucket
```
+ `SharedInstance` を `TRUE` に設定してコンピューティング共有を使用する場合、同じインスタンスで複数のアクションを実行し、単一のワークフローソースを指定してアーティファクトを共有できます。入力アーティファクトは必須ではなく、指定できません。
```
Name: S3PublishUsingComputeSharing
SchemaVersion: "1.0"
Compute:
Type: EC2
Fleet: dev-fleet
SharedInstance: TRUE
Actions:
Build:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: ./build.sh # Build script that generates output.zip
PublishToS3:
Identifier: aws/s3-publish@v1
DependsOn:
- Build
Environment:
Connections:
- Role: codecatalyst-deployment-role
Name: dev-deployment-role
Name: dev-connection
Configuration:
SourcePath: output.zip
DestinationBucketName: amzn-s3-demo-bucket
```
# ランタイム環境イメージの指定
*[ランタイム環境イメージ]* は、CodeCatalyst がワークフローアクションを実行する Docker コンテナです。Docker コンテナは、選択したコンピューティングプラットフォーム上で実行され、オペレーティングシステムと、、Node.js AWS CLI、.tar などのワークフローアクションに必要な追加のツールが含まれています。
デフォルトでは、ワークフローアクションは CodeCatalyst によって提供および保守されている [[アクティブなイメージ]](#build-curated-images) のいずれかで実行されます。ビルドアクションとテストアクションのみがカスタムイメージをサポートします。詳細については、「[カスタムランタイム環境の Docker イメージをアクションに割り当てる](#build-images-specify)」を参照してください。
**Topics**
+ [アクティブなイメージ](#build-curated-images)
+ [アクティブなイメージに必要なツールが含まれていない場合はどうなりますか？](#build-images-more-tools)
+ [カスタムランタイム環境の Docker イメージをアクションに割り当てる](#build-images-specify)
+ [例](#workflows-working-custom-image-ex)
## アクティブなイメージ
*[アクティブなイメージ]* は、CodeCatalyst によって完全にサポートされ、プリインストールされたツールを含むランタイム環境イメージです。現在、アクティブイメージには 2 つのセットがあります。1 つは 2024 年 3 月にリリースされ、もう 1 つは 2022 年 11 月にリリースされます。
アクションが 2024 年 3 月または 2022 年 11 月のイメージを使用するかどうかは、アクションによって異なります。
+ 2024 年 3 月 26 日以降にワークフローに追加されるビルドアクションとテストアクションには、[[2024 年 3 月のイメージ]](#build.default-image) を明示的に指定する `Container` セクションが YAML 定義に含まれます。オプションで `Container` セクションを削除して、[[2022 年 11 月のイメージ]](#build.previous-image) に戻せます。
+ 2024 年 3 月 26 日より前にワークフローに追加されたビルドアクションとテストアクションには、YAML 定義に `Container` セクションが*含まれない*ため、[[2022 年 11 月のイメージ]](#build.previous-image) が使用されます。2022 年 11 月のイメージを保持するか、アップグレードできます。イメージをアップグレードするには、ビジュアルエディタで アクションを開き、**[設定]** タブを選択し、**[Runtime 環境の docker イメージ]** ドロップダウンリストから 2024 年 3 月のイメージを選択します。この選択により、適切な 2024 年 3 月の画像が入力されているアクションの YAML 定義に `Container` セクションが追加されます。
+ 他のすべてのアクションでは、[[2022 年 11 月のイメージ]](#build.previous-image) または [[2024 年 3 月のイメージ]](#build.default-image) が使用されます。詳細については、アクションのドキュメントを参照してください。
**Topics**
+ [2024 年 3 月のイメージ](#build.default-image)
+ [2022 年 11 月のイメージ](#build.previous-image)
### 2024 年 3 月のイメージ
2024 年 3 月のイメージは、CodeCatalyst が提供する最新のイメージです。2024 年 3 月には、コンピューティングタイプとフリートの組み合わせごとに 1 つのイメージがあります。
次の表は、2024 年 3 月の各イメージにインストールされたツールを示しています。
**2024 年 3 月のイメージツール**
| ツール | Linux x86\$164 用 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_x86_64:2024_03` | Linux x86\$164 用 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_x86_64:2024_03` | Linux Arm64 用 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_Arm64:2024_03` | Linux Arm64 用 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_Arm64:2024_03` |
| --- | --- | --- | --- | --- |
| AWS CLI | 2.15.17 | 2.15.17 | 2.15.17 | 2.15.17 |
| AWS Copilot CLI | 1.32.1 | 1.32.1 | 1.32.1 | 1.32.1 |
| Docker | 24.0.9 | 該当なし | 24.0.9 | 該当なし |
| Docker Compose | 2.23.3 | 該当なし | 2.23.3 | 該当なし |
| Git | 2.43.0 | 2.43.0 | 2.43.0 | 2.43.0 |
| Go | 1.21.5 | 1.21.5 | 1.21.5 | 1.21.5 |
| Gradle | 8.5 | 8.5 | 8.5 | 8.5 |
| Java | Corretto17 | Corretto17 | Corretto17 | Corretto17 |
| Maven | 3.9.6 | 3.9.6 | 3.9.6 | 3.9.6 |
| Node.js | 18.19.0 | 18.19.0 | 18.19.0 | 18.19.0 |
| npm | 10.2.3 | 10.2.3 | 10.2.3 | 10.2.3 |
| Python | 3.9.18 | 3.9.18 | 3.9.18 | 3.9.18 |
| Python3 | 3.11.6 | 3.11.6 | 3.11.6 | 3.11.6 |
| pip | 22.3.1 | 22.3.1 | 22.3.1 | 22.3.1 |
| .NET | 8.0.100 | 8.0.100 | 8.0.100 | 8.0.100 |
### 2022 年 11 月のイメージ
2022 年 11 月には、コンピューティングタイプとフリートの組み合わせごとに 1 つのイメージがあります。[[プロビジョニングされたフリート]](workflows-working-compute.md#compute.fleets) を設定している場合、ビルドアクションで 2022 年 11 月の Windows イメージも使用できます。
次の表は、2022 年 11 月の各イメージにインストールされたツールを示しています。
**2022 年 11 月のイメージツール**
| ツール | Linux x86\$164 用 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_x86_64:2022_11` | Linux x86\$164 用 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_x86_64:2022_11` | Linux Arm64 用 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_Arm64:2022_11` | Linux Arm64 用 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_Arm64:2022_11` | Windows x86\$164 用 CodeCatalyst Amazon EC2 - `CodeCatalystWindows_x86_64:2022_11` |
| --- | --- | --- | --- | --- | --- |
| AWS CLI | 2.15.17 | 2.15.17 | 2.15.17 | 2.15.17 | 2.13.19 |
| AWS Copilot CLI | 0.6.0 | 0.6.0 | 該当なし | 該当なし | 1.30.1 |
| Docker | 23.01 | 該当なし | 23.0.1 | 該当なし | 該当なし |
| Docker Compose | 2.16.0 | 該当なし | 2.16.0 | 該当なし | 該当なし |
| Git | 2.40.0 | 2.40.0 | 2.39.2 | 2.39.2 | 2.42.0 |
| Go | 1.20.2 | 1.20.2 | 1.20.1 | 1.20.1 | 1.19 |
| Gradle | 8.0.2 | 8.0.2 | 8.0.1 | 8.0.1 | 8.3 |
| Java | Corretto17 | Corretto17 | Corretto17 | Corretto17 | Corretto17 |
| Maven | 3.9.4 | 3.9.4 | 3.9.0 | 3.9.0 | 3.9.4 |
| Node.js | 16.20.2 | 16.20.2 | 16.19.1 | 16.14.2 | 16.20.0 |
| npm | 8.19.4 | 8.19.4 | 8.19.3 | 8.5.0 | 8.19.4 |
| Python | 3.9.15 | 2.7.18 | 3.11.2 | 2.7.18 | 3.9.13 |
| Python3 | 該当なし | 3.9.15 | 該当なし | 3.11.2 | 該当なし |
| pip | 22.2.2 | 22.2.2 | 23.0.1 | 23.0.1 | 22.0.4 |
| .NET | 6.0.407 | 6.0.407 | 6.0.406 | 6.0.406 | 6.0.414 |
## アクティブなイメージに必要なツールが含まれていない場合はどうなりますか？
CodeCatalyst が提供する [[アクティブなイメージ]](#build-curated-images) に、必要なツールが含まれていない場合は、いくつかのオプションがあります。
+ 必要なツールを含むカスタムランタイム環境の Docker イメージを提供できます。詳細については、「[カスタムランタイム環境の Docker イメージをアクションに割り当てる](#build-images-specify)」を参照してください。
**注記**
カスタムランタイム環境の Docker イメージを提供する場合は、カスタムイメージに Git がインストールされていることを確認してください。
+ ワークフローのビルドまたはテストアクションに必要なツールをインストールできます。
例えば、ビルドアクションまたはテストアクションの YAML コードの `Steps` セクションに以下の手順を含めることができます。
```
Configuration:
Steps:
- Run: ./setup-script
```
*[setup-script]* 命令は、次のスクリプトを実行して Node パッケージマネージャー (npm) をインストールします。
```
#!/usr/bin/env bash
echo "Setting up environment"
touch ~/.bashrc
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash
source ~/.bashrc
nvm install v16.1.0
source ~/.bashrc
```
アクションの使用方法の詳細については、「[ビルドおよびテストアクション YAML](build-action-ref.md)」を参照してください。
## カスタムランタイム環境の Docker イメージをアクションに割り当てる
CodeCatalyst が提供する [[アクティブイメージ]](#build-curated-images) を使用しない場合は、カスタムランタイム環境の Docker イメージを指定できます。カスタムイメージを提供する場合は、そのイメージに Git がインストールされていることを確認してください。イメージは、Docker Hub、Amazon Elastic Container Registry、または任意のパブリックリポジトリに格納できます。
カスタム Docker イメージを作成する方法については、Docker ドキュメントの「[アプリケーションのコンテナ化](https://docs.docker.com/get-started/02_our_app/)」を参照してください。
カスタムランタイム環境の Docker イメージをアクションに割り当てるには、次の手順に従います。イメージを指定すると、CodeCatalyst はアクションの開始時にそのイメージをコンピューティングプラットフォームにデプロイします。
**注記**
次のアクションは、カスタムランタイム環境の Docker イメージをサポートしていません: ** CloudFormation スタックのデプロイ**、**ECS へのデプロイ**、**GitHub Actions**。カスタムランタイム環境の Docker イメージは、**Lambda** コンピューティングタイプもサポートしていません。
------
#### [ Visual ]
**ビジュアルエディタを使用してカスタムランタイム環境の Docker イメージを割り当てるには**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。
1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。
1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。
1. **[編集]** を選択します。
1. **[ビジュアル]** を選択します。
1. ワークフロー図で、カスタムランタイム環境の Docker イメージを使用するアクションを選択します。
1. **[設定]** タブを選択します。
1. 下部の近くで、次のフィールドに入力します。
**ランタイム環境 Docker イメージ - オプション**
イメージが保存されているレジストリを指定します。有効な値を次に示します。
+ `CODECATALYST` (YAML エディタ)
イメージは CodeCatalyst レジストリに保存されます。
+ **[Docker Hub]** (ビジュアルエディタ) または [`DockerHub`] (YAML エディタ)
イメージは Docker Hub イメージレジストリに保存されます。
+ **[その他のレジストリ]** (ビジュアルエディタ) または [`Other`] (YAML エディタ)
イメージはカスタムイメージレジストリに保存されます。公開されているレジストリを使用できます。
+ **[Amazon Elastic Container Registry]** (ビジュアルエディタ) または [`ECR`] (YAML エディタ)
イメージは Amazon Elastic Container Registry イメージリポジトリに保存されます。Amazon ECR リポジトリでイメージを使用するには、このアクションで Amazon ECR にアクセスする必要があります。このアクセスを有効にするには、次のアクセス許可とカスタム信頼ポリシーを含む [[IAM ロール]](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) を作成する必要があります。(既存のロールを変更して、必要に応じてアクセス許可とポリシーを含めることができます。)
IAM ロールのロールポリシーには、次のアクセス許可を含める必要があります。
+ `ecr:BatchCheckLayerAvailability`
+ `ecr:BatchGetImage`
+ `ecr:GetAuthorizationToken`
+ `ecr:GetDownloadUrlForLayer`
IAM ロールには、次のカスタム信頼ポリシーを含める必要があります。
IAM ロールの作成に関する詳細については、「*IAM ユーザーガイド*」の「[ロールの作成とポリシーのアタッチ (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。
ロールを作成したら、環境を介してアクションに割り当てる必要があります。詳細については、「[環境とアクションの関連付け](deploy-environments-add-app-to-environment.md)」を参照してください。
**[ECR イメージ URL]**、**[Docker Hub イメージ]**、または **[イメージ URL]**
次のいずれかを指定します。
+ `CODECATALYST` レジストリを使用している場合は、イメージを次のいずれかの [[アクティブなイメージ]](#build-curated-images) に設定します。
+ `CodeCatalystLinux_x86_64:2024_03`
+ `CodeCatalystLinux_x86_64:2022_11`
+ `CodeCatalystLinux_Arm64:2024_03`
+ `CodeCatalystLinux_Arm64:2022_11`
+ `CodeCatalystLinuxLambda_x86_64:2024_03`
+ `CodeCatalystLinuxLambda_x86_64:2022_11`
+ `CodeCatalystLinuxLambda_Arm64:2024_03`
+ `CodeCatalystLinuxLambda_Arm64:2022_11`
+ `CodeCatalystWindows_x86_64:2022_11`
+ Docker Hub レジストリを使用している場合は、イメージを Docker Hub イメージ名とオプションのタグに設定します。
例: `postgres:latest`
+ Amazon ECR レジストリを使用している場合は、イメージを Amazon ECR レジストリ URI に設定します。
例: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`
+ カスタムレジストリを使用している場合は、イメージをカスタムレジストリで期待される値に設定します。
1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。
1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
------
#### [ YAML ]
**YAML エディタを使用してカスタムランタイム環境の Docker イメージを割り当てるには**
1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。
1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。
1. **[編集]** を選択します。
1. **[YAML]** を選択します。
1. ランタイム環境の Docker イメージを割り当てるアクションを見つけます。
1. アクションで、`Container` セクションと基盤となる `Registry` プロパティと `Image` プロパティを追加します。詳細については、「`Container`」、「`Registry`」、およびアクションの [アクション](workflow-reference.md#actions-reference) の `Image` プロパティの説明を参照してください。
1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。
1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
------
## 例
次の例は、カスタムランタイム環境の Docker イメージをワークフロー定義ファイルのアクションに割り当てる方法を示しています。
**Topics**
+ [例: Amazon ECR でカスタムランタイム環境 Docker イメージを使用して Node.js 18 のサポートを追加する](#workflows-working-custom-image-ex-ecr-node18)
+ [例: カスタムランタイム環境の Docker イメージを使用して、Docker Hub で Node.js 18 のサポートを追加する](#workflows-working-custom-image-ex-docker-node18)
### 例: Amazon ECR でカスタムランタイム環境 Docker イメージを使用して Node.js 18 のサポートを追加する
次の例は、カスタムランタイム環境 Docker イメージを使用して [[Amazon ECR]](https://gallery.ecr.aws/amazonlinux/amazonlinux) で Node.js 18 のサポートを追加する方法を示しています。
```
Configuration:
Container:
Registry: ECR
Image: public.ecr.aws/amazonlinux/amazonlinux:2023
```
### 例: カスタムランタイム環境の Docker イメージを使用して、Docker Hub で Node.js 18 のサポートを追加する
次の例は、カスタムランタイム環境 Docker イメージを使用して [[Docker Hub]](https://hub.docker.com/_/node) で Node.js 18 のサポートを追加する方法を示しています。
```
Configuration:
Container:
Registry: DockerHub
Image: node:18.18.2
```