翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ソースコードに基づく 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 アクションでソースディレクトリを指定します。 UpdateService 詳細については、次の「ソースディレクトリ」セクションを参照してください。
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 で、アプリケーション用に更新されたビルドプロセスが提供されるようになりました。現在、2023 年 12 月 29 日に最後にリリースされたマネージドランタイム Python 3.11 および Node.js 18 で実行されるサービスの新しいビルドを呼び出します。この改訂されたビルドプロセスは、より迅速で効率的です。また、アプリケーションの実行に必要なソースコード、ビルドアーティファクト、ランタイムのみを含む、フットプリントが小さい最終イメージを作成します。
新しいビルドプロセスを改訂された 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ときに、 の Run セクションのenvエントリに誤解しないでください。ステップ 2 (b) で参照される pre-run コマンドパラメータは Run セクションにありますが、Run セクションの envパラメータを使用してビルドを設定しないでください。pre-run コマンドは、設定ファイルのビルドセクションで定義されたenv変数のみを参照します。詳細については、App Runner 設定ファイルの章実行セクションの「」を参照してください。
移行に関する考慮事項のサービス要件
アプリケーション環境にこれら 2 つの要件のいずれかがある場合は、 pre-run コマンドを追加してビルド設定を修正する必要があります。
buildコマンドを使用して/appディレクトリの外部を変更する必要がある場合。-
コマンドを
build2 回実行して必要な環境を作成する必要がある場合。これは非常に異常な要件です。ほとんどのビルドでは、これを行うことはできません。
/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 でコマンドを 2 回実行します。 改訂された App Runner ビルドは、この冗長性を緩和し、buildコマンドを 1 回だけ実行します。アプリケーションにbuildコマンドを 2 回実行するための異常な要件がある場合、改訂された App Runner ビルドには、pre-runパラメータを使用して同じコマンドを再度指定して実行するオプションが用意されています。これにより、同じダブルビルド動作が保持されます。
