翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ソースコードに基づく 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 がソースコードをデプロイするための接続の詳細とソースディレクトリを指定します。
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 サービスを作成してサポートするには、各サービスを作成するときに異なるソースディレクトリを指定します。
注記
複数の 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 は、最新のメジャーバージョンランタイムで実行されるアプリケーション向けに更新されたビルドプロセスを提供します。この改訂されたビルドプロセスは、より高速で効率的です。また、アプリケーションの実行に必要なソースコード、ビルドアーティファクト、ランタイムのみを含む、フットプリントが小さい最終イメージを作成します。
新しいビルドプロセスを改訂された 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、次にステップ 5 で
buildコマンドを 2 回実行します。 改訂された App Runner ビルドは、この冗長性を修復し、buildコマンドを 1 回だけ実行します。アプリケーションにbuildコマンドを 2 回実行するための異常な要件がある場合、改訂された App Runner ビルドには、pre-runパラメータを使用して同じコマンドを再度指定して実行するオプションが用意されています。これにより、同じダブルビルド動作が保持されます。
