翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ソースコードに基づく 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パラメータを使用して同じコマンドを再度指定して実行するオプションが用意されています。これにより、同じダブルビルド動作が保持されます。
