翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ソースコードに基づく App Runner サービス

を使用して AWS App Runner 、ソースコードとソースイメージの 2 つの異なるタイプのサービスソースに基づいてサービスを作成および管理できます。ソースタイプに関係なく、App Runner はサービスの起動、実行、スケーリング、ロードバランシングを処理します。App Runner の CI/CD 機能を使用して、ソースイメージまたはコードの変更を追跡できます。App Runner は変更を検出すると、自動的に (ソースコード用) をビルドし、新しいバージョンを App Runner サービスにデプロイします。

この章では、ソースコードに基づく のサービスについて説明します。ソースイメージに基づくサービスの詳細については、「」を参照してくださいソースイメージに基づく App Runner サービス。

ソースコードは、App Runner が構築およびデプロイするアプリケーションコードです。App Runner をコードリポジトリのソースディレクトリにポイントし、プログラミングプラットフォームのバージョンに対応する適切なランタイムを選択します。App Runner は、ランタイムのベースイメージとアプリケーションコードに基づいてイメージを構築します。次に、このイメージに基づいてコンテナを実行するサービスを開始します。

App Runner は、プラットフォーム固有の便利なマネージドランタイムを提供します。これらの各ランタイムは、ソースコードからコンテナイメージを構築し、言語ランタイムの依存関係をイメージに追加します。Dockerfile などのコンテナ設定やビルド手順を指定する必要はありません。

この章のサブトピックでは、App Runner がサポートするさまざまなプラットフォームについて説明します。これは、さまざまなプログラミング環境とバージョンにマネージドランタイムを提供するマネージドプラットフォームです。

ソースコードリポジトリプロバイダー

App Runner は、ソースコードリポジトリから読み取ってソースコードをデプロイします。App Runner はGitHub と Bitbucket の 2 つのソースコードリポジトリプロバイダーをサポートしています。

ソースコードリポジトリプロバイダーからのデプロイ

ソースコードリポジトリから App Runner サービスにソースコードをデプロイするために、App Runner はそれへの接続を確立します。App Runner コンソールを使用してサービスを作成するときは、App Runner がソースコードをデプロイするための接続の詳細とソースディレクトリを指定します。

Connections

サービス作成手順の一部として接続の詳細を指定します。App Runner API または を使用する場合 AWS CLI、接続は別のリソースです。まず、CreateConnection API アクションを使用して接続を作成します。次に、CreateService API アクションを使用して、サービスの作成時に接続の ARN を指定します。

ソースディレクトリ

サービスを作成するときは、ソースディレクトリも指定します。デフォルトでは、App Runner はリポジトリのルートディレクトリをソースディレクトリとして使用します。ソースディレクトリは、アプリケーションのソースコードと設定ファイルを保存するソースコードリポジトリ内の場所です。ビルドコマンドとスタートコマンドは、ソースディレクトリからも実行されます。App Runner API または を使用してサービス AWS CLI を作成または更新する場合は、CreateService および UpdateService API アクションでソースディレクトリを指定します。詳細については、次の「ソースディレクトリ」セクションを参照してください。

App Runner サービスの作成の詳細については、「」を参照してくださいApp Runner サービスの作成。App Runner 接続の詳細については、「」を参照してくださいApp Runner 接続の管理。

ソースディレクトリ

App Runner サービスを作成するときに、リポジトリとブランチとともにソースディレクトリを指定できます。Source ディレクトリフィールドの値を、アプリケーションのソースコードと設定ファイルを保存するリポジトリディレクトリパスに設定します。App Runner は、指定したソースディレクトリパスからビルドコマンドとスタートコマンドを実行します。

ルートリポジトリディレクトリからソースディレクトリパスの値を絶対として入力します。値を指定しない場合、デフォルトでリポジトリの最上位ディレクトリになります。これはリポジトリルートディレクトリとも呼ばれます。

また、最上位リポジトリディレクトリの他に異なるソースディレクトリパスを指定することもできます。これにより、モノレポリポジトリアーキテクチャがサポートされます。つまり、複数のアプリケーションのソースコードは 1 つのリポジトリに保存されます。単一のモノレポから複数の App Runner サービスを作成してサポートするには、各サービスを作成するときに異なるソースディレクトリを指定します。

apprunner.yaml 設定ファイルを使用してサービスパラメータを定義する場合は、リポジトリのソースディレクトリフォルダに配置します。

デプロイトリガーオプションが自動に設定されている場合、ソースディレクトリでコミットした変更は自動デプロイをトリガーします。ソースディレクトリパスの変更のみが自動デプロイをトリガーします。ソースディレクトリの場所が自動デプロイの範囲にどのように影響するかを理解することが重要です。詳細については、「」の「自動デプロイ」を参照してくださいデプロイ方法。

App Runner マネージドプラットフォーム

App Runner マネージドプラットフォームは、さまざまなプログラミング環境にマネージドランタイムを提供します。各マネージドランタイムを使用すると、プログラミング言語またはランタイム環境のバージョンに基づいてコンテナを簡単に構築して実行できます。マネージドランタイムを使用すると、App Runner はマネージドランタイムイメージで始まります。このイメージは Amazon Linux Docker イメージに基づいており、言語ランタイムパッケージ、いくつかのツール、一般的な依存関係パッケージが含まれています。App Runner はこのマネージドランタイムイメージをベースイメージとして使用し、アプリケーションコードを追加して Docker イメージを構築します。次に、このイメージをデプロイして、コンテナでウェブサービスを実行します。

App Runner コンソールまたは CreateService API オペレーションを使用してサービスを作成するときに、App Runner サービスのランタイムを指定します。ソースコードの一部としてランタイムを指定することもできます。コードリポジトリに含める App Runner 設定ファイルで runtimeキーワードを使用します。マネージドランタイムの命名規則は <language-name><major-version> です。

App Runner は、デプロイまたはサービスの更新ごとに、サービスのランタイムを最新バージョンに更新します。アプリケーションで特定のバージョンのマネージドランタイムが必要な場合は、App Runner 設定ファイルの runtime-versionキーワードを使用して指定できます。メジャーバージョンやマイナーバージョンなど、任意のレベルのバージョンにロックできます。App Runner は、サービスのランタイムに対してのみ低レベルの更新を行います。

マネージドランタイムバージョンのサポート終了

マネージド言語ランタイムの公式プロバイダーまたはコミュニティがバージョンを正式にサポート終了 (EOL) と宣言すると、App Runner はバージョンステータスをサポート終了と宣言します。サポート終了に達したマネージド言語ランタイムバージョンでサービスが実行されている場合、以下のポリシーと推奨事項が適用されます。

言語ランタイムバージョンのサポート終了：

サポート終了ステータスの言語ランタイムバージョンに必要なアクション：

次の表に、サポート終了日が指定されている App Runner マネージドランタイムバージョンを示します。

* App Runner は、アスタリスク (*) が付いたランタイムの新しい言語バージョンをリリースしません。これらのランタイムは、.NET、PHP、Ruby、Go です。これらのランタイム用にコードベースのサービスが設定されている場合は、次のいずれかのアクションをお勧めします。

マネージドランタイムバージョンと App Runner ビルド

App Runner は、最新のメジャーバージョンランタイムで実行されるアプリケーション用に更新されたビルドプロセスを提供します。この改訂されたビルドプロセスは、より高速で効率的です。また、アプリケーションの実行に必要なソースコード、ビルドアーティファクト、ランタイムのみを含む、フットプリントが小さい最終イメージを作成します。

新しいビルドプロセスを改訂された App Runner ビルドと呼び、元のビルドプロセスを元の App Runner ビルドと呼びます。以前のバージョンのランタイムプラットフォームへの重大な変更を避けるために、App Runner は改訂されたビルドを特定のランタイムバージョン、通常は新しくリリースされたメジャーリリースにのみ適用します。

apprunner.yaml 設定ファイルに新しいコンポーネントが導入されました。これは、改訂されたビルドを特定のユースケースに対して下位互換性を持たせ、アプリケーションのビルドをより柔軟に設定できるようにするためです。これはオプションのpre-runパラメータです。このパラメータをいつ使用するか、以下のセクションでビルドに関するその他の有用な情報とともに説明します。

次の表は、特定のマネージドランタイムバージョンに適用される App Runner ビルドのバージョンを示しています。このドキュメントは引き続き更新され、現在のランタイムについてお知らせします。

App Runner のビルドと移行の詳細

改訂されたビルドを使用する新しいランタイムにアプリケーションを移行する場合、ビルド設定を少し変更する必要がある場合があります。

移行に関する考慮事項のコンテキストを提供するために、最初に元の App Runner ビルドと改訂されたビルドの両方の高レベルプロセスについて説明します。次に、設定の更新が必要になる可能性のあるサービスに関する特定の属性を記述するセクションについて説明します。

元の App Runner ビルド

元の App Runner アプリケーションビルドプロセスは、 AWS CodeBuild サービスを活用します。初期ステップは、CodeBuild サービスによってキュレートされたイメージに基づいています。該当する App Runner マネージドランタイムイメージをベースイメージとして使用する Docker ビルドプロセスに従います。

一般的なステップは次のとおりです。

ビルドが完了すると、App Runner はステップ 5 で生成された App Runner マネージドランタイムイメージをデプロイして、コンテナでウェブサービスを実行します。

改訂された App Runner ビルド

改訂されたビルドプロセスは、前のセクションで説明した元のビルドプロセスよりも高速で効率的です。これにより、以前のバージョンビルドで発生するビルドコマンドの重複がなくなります。また、アプリケーションの実行に必要なソースコード、ビルドアーティファクト、ランタイムのみを含む、フットプリントが小さい最終イメージを作成します。

このビルドプロセスでは、Docker マルチステージビルドを使用します。一般的なプロセスステップは次のとおりです。

ビルドが完了すると、App Runner は Run イメージをデプロイして、コンテナでウェブサービスを実行します。

移行に関する考慮事項のサービス要件

アプリケーション環境にこれら 2 つの要件のいずれかがある場合は、 pre-run コマンドを追加してビルド設定を修正する必要があります。

/app ディレクトリ外の変更

build コマンドを 2 回実行する