翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ソースコードに基づく 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
ソースコードリポジトリプロバイダーからのデプロイ
ソースコードリポジトリから App Runner サービスにソースコードをデプロイするために、App Runner はそれへの接続を確立します。App Runner コンソールを使用してサービス を作成するときは、App Runner がソースコードをデプロイするための接続の詳細とソースディレクトリを指定します。
接続
サービス作成手順の一部として接続の詳細を指定します。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 サービスを作成するときに、リポジトリとブランチとともにソースディレクトリを指定できます。ソースディレクトリフィールドの値を、アプリケーションのソースコードと設定ファイルを保存するリポジトリディレクトリパスに設定します。App Runner は、指定したソースディレクトリパスからビルドコマンドとスタートコマンドを実行します。
ルートリポジトリディレクトリからソースディレクトリパスの値を絶対として入力します。値を指定しない場合、デフォルトでリポジトリのルートディレクトリとも呼ばれるリポジトリの最上位ディレクトリになります。
また、最上位リポジトリディレクトリの他に異なるソースディレクトリパスを指定することもできます。これにより、モノレポリポジトリアーキテクチャがサポートされます。つまり、複数のアプリケーションのソースコードは 1 つのリポジトリに保存されます。単一のモノレポから複数の App Runner サービスを作成してサポートするには、各サービスを作成するときに異なるソースディレクトリを指定します。
注記
複数の App Runner サービスに同じソースディレクトリを指定すると、両方のサービスが個別にデプロイおよび動作します。
apprunner.yaml
設定ファイルを使用してサービスパラメータを定義する場合は、リポジトリのソースディレクトリフォルダに配置します。
デプロイトリガーオプションが自動 に設定されている場合、ソースディレクトリでコミットした変更によって自動デプロイがトリガーされます。ソースディレクトリパスの変更のみが自動デプロイをトリガーします。ソースディレクトリの場所が自動デプロイの範囲にどのように影響するかを理解することが重要です。詳細については、「 の自動デプロイ」を参照してくださいデプロイ方法。
注記
App Runner サービスが PHP マネージドランタイムを使用していて、デフォルトのルートリポジトリ以外のソースディレクトリを指定する場合は、正しい PHP ランタイムバージョンを使用することが重要です。詳細については、「 PHP プラットフォームを使用する」を参照してください。
App Runner マネージドプラットフォーム
App Runner マネージドプラットフォームは、さまざまなプログラミング環境にマネージドランタイムを提供します。各マネージドランタイムでは、プログラミング言語またはランタイム環境のバージョンに基づいてコンテナを簡単に構築して実行できます。マネージドランタイムを使用すると、App Runner はマネージドランタイムイメージから開始します。このイメージは Amazon Linux Docker イメージ
App Runner コンソールまたは CreateService API オペレーションを使用してサービスを作成するときに、App Runner サービスのランタイムを指定します。ソースコードの一部としてランタイムを指定することもできます。コードリポジトリに含める App Runner 設定ファイルで runtime
キーワードを使用します。マネージドランタイムの命名規則は <language-name><major-version>
です。
App Runner は、デプロイまたはサービスの更新のたびに、サービスのランタイムを最新バージョンに更新します。アプリケーションで特定のバージョンのマネージドランタイムが必要な場合は、App Runner 設定ファイル の runtime-version
キーワードを使用して指定できます。メジャーバージョンやマイナーバージョンなど、任意のレベルのバージョンにロックできます。App Runner は、サービスのランタイムに対して、下位レベルの更新のみを行います。
マネージドランタイムバージョンと App Runner ビルド
App Runner は、アプリケーション用に更新されたビルドプロセスを提供するようになりました。現在、マネージドランタイム Python 3.11 および Node.js 18 で実行されるサービス用の新しいビルドを呼び出します。最終リリース日は 2023 年 12 月 29 日です。この改訂されたビルドプロセスは、より高速で効率的です。また、ソースコード、ビルドアーティファクト、アプリケーションの実行に必要なランタイムのみを含む、フットプリントが小さい最終イメージを作成します。
新しいビルドプロセスを改訂された App Runner ビルドと呼び、元のビルドプロセスを元の App Runner ビルドと呼びます。以前のバージョンのランタイムプラットフォームへの重大な変更を避けるため、App Runner は、改訂されたビルドを、通常は新しくリリースされた特定のランタイムバージョンにのみ適用します。
apprunner.yaml
設定ファイルに新しいコンポーネントを導入し、改訂されたビルドを特定のユースケースに合わせて下位互換性を持たせ、アプリケーションのビルドをより柔軟に設定できるようになりました。これはオプションのpre-runパラメータです。このパラメータをいつ使用するかについては、以下のセクションでビルドに関するその他の有用な情報とともに説明します。
次の表は、特定のマネージドランタイムバージョンに適用される App Runner ビルドのバージョンを示しています。このドキュメントは、現在のランタイムに関する最新情報を得るために、引き続き更新されます。
重要
Python 3.11 – Python 3.11 マネージドランタイムを使用する サービスの構築設定に関する具体的な推奨事項があります。詳細については、Python プラットフォームトピックの特定のランタイムバージョンのコールアウト「」を参照してください。
App Runner のビルドと移行の詳細
改訂されたビルドを使用する新しいランタイムにアプリケーションを移行する場合、ビルド設定を少し変更する必要がある場合があります。
移行に関する考慮事項のコンテキストを提供するために、まず、元の App Runner ビルドと改訂されたビルドの両方の高レベルプロセスについて説明します。続いて、設定の更新が必要になる可能性のあるサービスに関する特定の属性を説明するセクションを示します。
元の App Runner ビルド
元の App Runner アプリケーションビルドプロセスは、 AWS CodeBuild サービスを活用します。最初のステップは、 CodeBuild サービスによってキュレートされたイメージに基づいています。Docker ビルドプロセスでは、該当する App Runner マネージドランタイムイメージをベースイメージとして使用します。
一般的な手順は次のとおりです。
-
CodeBuildキュレーションされたイメージで
pre-build
コマンドを実行します。pre-build
コマンドはオプションです。apprunner.yaml
これらは設定ファイルでのみ指定できます。 -
前のステップと同じイメージ CodeBuild で を使用して
build
コマンドを実行します。build
コマンドは必須です。これらは、App Runner コンソール、App Runner API、またはapprunner.yaml
設定ファイルで指定できます。 -
Docker ビルドを実行して、特定のプラットフォームとランタイムバージョンの App Runner マネージドランタイムイメージに基づいてイメージを生成します。
-
ステップ 2 で生成したイメージから
/app
ディレクトリをコピーします。送信先は、ステップ 3 で生成した App Runner マネージドランタイムイメージに基づくイメージです。 -
生成された App Runner マネージドランタイムイメージで
build
コマンドを再度実行します。ビルドコマンドを再度実行して、ステップ 4 でコピーした/app
ディレクトリのソースコードからビルドアーティファクトを生成します。このイメージは、後で App Runner によってデプロイされ、コンテナでウェブサービスを実行します。build
コマンドは必須です。これらは、App Runner コンソール、App Runner API、またはapprunner.yaml
設定ファイルで指定できます。 -
ステップ 2 の CodeBuild イメージで
post-build
コマンドを実行します。post-build
コマンドはオプションです。apprunner.yaml
これらは設定ファイルでのみ指定できます。
ビルドが完了すると、App Runner はステップ 5 で生成された App Runner マネージドランタイムイメージをデプロイして、コンテナでウェブサービスを実行します。
改訂された App Runner ビルド
改訂されたビルドプロセスは、前のセクションで説明した元のビルドプロセスよりも高速で効率的です。これにより、以前のバージョンビルドで発生するビルドコマンドの重複がなくなります。また、ソースコード、ビルドアーティファクト、アプリケーションの実行に必要なランタイムのみを含む、フットプリントが小さい最終イメージを作成します。
このビルドプロセスでは、Docker マルチステージビルドを使用します。一般的なプロセスステップは次のとおりです。
-
ビルドステージ — App Runner ビルドイメージ上で
pre-build
およびbuild
コマンドを実行する docker ビルドプロセスを開始します。-
アプリケーションのソースコードを
/app
ディレクトリにコピーします。注記
この
/app
ディレクトリは、Docker ビルドのすべてのステージで作業ディレクトリとして指定されます。 -
pre-build
コマンドを実行します。コマンドは
pre-build
オプションです。apprunner.yaml
これらは設定ファイルでのみ指定できます。 -
build
コマンドを実行します。build
コマンドは必須です。これらは、App Runner コンソール、App Runner API、またはapprunner.yaml
設定ファイルで指定できます。
-
-
パッケージングステージ — App Runner 実行イメージにも基づいている、最終的な顧客コンテナイメージを生成します。
-
前のビルドステージから新しい実行イメージに
/app
ディレクトリをコピーします。これには、アプリケーションのソースコードと、前のステージのビルドアーティファクトが含まれます。 -
pre-run
コマンドを実行します。build
コマンドを使用して/app
ディレクトリの外部でランタイムイメージを変更する必要がある場合は、apprunner.yaml
設定ファイルのこのセグメントに同じコマンドまたは必要なコマンドを追加します。これは、改訂された App Runner ビルドをサポートするために導入された新しいパラメータです。
pre-run
コマンドはオプションです。apprunner.yaml
これらは設定ファイルでのみ指定できます。メモ
-
pre-run
コマンドは、改訂されたビルドでのみサポートされます。サービスで元のビルドを使用するランタイムバージョンを使用している場合は、設定ファイルに追加しないでください。 -
build
コマンドを使用して/app
ディレクトリの外部で何も変更する必要がない場合は、pre-run
コマンドを指定する必要はありません。
-
-
-
ビルド後ステージ — このステージはビルドステージから再開され、
post-build
コマンドを実行します。-
/app
ディレクトリ内でpost-build
コマンドを実行します。post-build
コマンドはオプションです。apprunner.yaml
これらは設定ファイルでのみ指定できます。
-
ビルドが完了すると、App Runner は Run イメージをデプロイしてウェブサービスをコンテナで実行します。
注記
ビルドプロセスを設定するapprunner.yaml
ときに、 の「実行」セクションのenv
エントリに誤解しないでください。ステップ 2 (b) で参照される pre-run
コマンドパラメータは Run セクションにありますが、Run セクションの env
パラメータを使用してビルドを設定しないでください。pre-run
コマンドは、設定ファイルのビルドセクションで定義されているenv
変数のみを参照します。詳細については、App Runner 設定ファイルの章実行セクションの「」を参照してください。
移行に関する考慮事項のサービス要件
アプリケーション環境にこれら 2 つの要件のいずれかがある場合は、pre-run
コマンドを追加してビルド設定を修正する必要があります。
build
コマンドを使用して/app
ディレクトリの外部を変更する必要がある場合。-
必要な環境を作成するために
build
コマンドを 2 回実行する必要がある場合。これは非常に異常な要件です。ほとんどのビルドはこれを行いません。
/app
ディレクトリ外の変更
-
改訂された App Runner ビルドは、アプリケーションに
/app
ディレクトリ外の依存関係がないことを前提としています。 -
apprunner.yaml
ファイル、App Runner API、または App Runner コンソールで指定するコマンドは、/app
ディレクトリにビルドアーティファクトを生成する必要があります。 -
pre-build
、、およびpost-build
コマンドを変更してbuild
、すべてのビルドアーティファクトが/app
ディレクトリにあることを確認できます。 -
アプリケーションがビルドでサービス用に生成されたイメージをさらに変更する必要がある場合は、
/app
ディレクトリの外部で、 の新しいpre-run
コマンドを使用できますapprunner.yaml
。詳細については、「設定ファイルを使用した App Runner サービスオプションの設定」を参照してください。
build
コマンドを 2 回実行する
-
元の App Runner ビルドでは、最初にステップ 2 で
build
コマンドを 2 回実行し、次にステップ 5 でコマンドをもう一度実行します。 改訂された App Runner ビルドでは、この冗長性が解消され、build
コマンドは 1 回だけ実行されます。アプリケーションにbuild
コマンドを 2 回実行するための異常な要件がある場合、改訂された App Runner ビルドには、pre-run
パラメータを使用して同じコマンドを再度指定して実行するオプションが用意されています。これにより、同じダブルビルド動作が保持されます。