ソースコードに基づく App Runner サービス - AWS App Runner
ソースコードリポジトリプロバイダーソースディレクトリApp Runner マネージドプラットフォームマネージドランタイムバージョンのサポート終了マネージドランタイムバージョンと App Runner ビルド

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

ソースコードに基づく 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 サービスを作成してサポートするには、各サービスを作成するときに異なるソースディレクトリを指定します。

注記

複数の App Runner サービスに同じソースディレクトリを指定すると、両方のサービスが個別にデプロイおよび動作します。

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

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

注記

App Runner サービスが PHP マネージドランタイムを使用していて、デフォルトのルートリポジトリ以外のソースディレクトリを指定する場合は、正しい PHP ランタイムバージョンを使用することが重要です。詳細については、「 PHP プラットフォームを使用する」を参照してください。

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 コンソールでサポートされているランタイムバージョンを選択するか、apprunner.yaml 設定ファイルの runtimeフィールドを更新するか、CreateService/UpdateService API オペレーションまたは IaC ツールを使用して runtimeパラメータを設定します。サポートされているランタイムのリストについては、この章の「特定のランタイムのリリース情報」ページを参照してください。

  • または、App Runner のコンテナイメージソースオプションに切り替えることもできます。詳細については、「イメージベースのサービス」を参照してください。

注記

Node.js 12、14、または 16 から Node.js 22、または Python 3.7 または 3.8 から Python 3.11 に移行する場合は、Node.js 22 および Python 3.11 は、より高速で効率的なビルドを提供する、改訂された App Runner ビルドプロセスを使用することに注意してください。アップグレード前に互換性を確保するために、次のセクションのビルドプロセスガイダンスを確認することをお勧めします。

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

ランタイムバージョン App Runner サポート終了日

Python 3.8 でサポートされているランタイム

2025 年 12 月 1 日

Python 3.7 でサポートされているランタイム

2025 年 12 月 1 日

Node.js 18 でサポートされているランタイム

2025 年 12 月 1 日

Node.js 16 でサポートされているランタイム

2025 年 12 月 1 日

Node.js 14 でサポートされているランタイム

2025 年 12 月 1 日

Node.js 12 でサポートされているランタイム

2025 年 12 月 1 日

.NET 6 *

2025 年 12 月 1 日

PHP 8.1 *

2025 年 12 月 31 日

Ruby 3.1 *

2025 年 12 月 1 日

Go 1 *

2025 年 12 月 1 日

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

  • 該当する場合は、サービス設定をサポートされている別のマネージドランタイムに切り替えます。

  • または、任意のランタイムバージョンでカスタムコンテナイメージを構築し、App Runner イメージベースのサービスのオプションを使用してデプロイします。Amazon ECR でイメージをホストできます。

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

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

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

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

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

プラットフォーム ランタイムバージョン ビルドプロセス App Runner サポート終了日

Python – リリース情報

Python 3.11 (!)

改訂

Python 3.8

元

2025 年 12 月 1 日

Python 3.7

元

2025 年 12 月 1 日

Node.js – リリース情報

Node.js 22

改訂

Node.js 18

改訂

2025 年 12 月 1 日

Node.js 16

元

2025 年 12 月 1 日

Node.js 14

元

2025 年 12 月 1 日

Node.js 12

元

2025 年 12 月 1 日

Corretto – リリース情報

Corretto 11

元

Corretto 8

元

.NET – リリース情報

.NET 6 *

元

2025 年 12 月 1 日

PHP – リリース情報

PHP 8.1 *

元

2025 年 12 月 31 日

Ruby – リリース情報

Ruby 3.1 *

元

2025 年 12 月 1 日

Go – リリース情報

Go 1 *

元

2025 年 12 月 1 日
注記

リストされているランタイムの一部には、サポート終了日が含まれています。詳細については、「マネージドランタイムバージョンのサポート終了」を参照してください。

重要

Python 3.11 – Python 3.11 マネージドランタイムを使用するサービスのビルド設定に関する特定の推奨事項があります。詳細については、Python プラットフォームトピック特定のランタイムバージョンのコールアウトの「」を参照してください。

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

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

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

元の App Runner ビルド

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

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

  1. CodeBuild でキュレートされたイメージでpre-buildコマンドを実行します。

    pre-build コマンドはオプションです。apprunner.yaml これらは設定ファイルでのみ指定できます。

  2. 前のステップと同じイメージで CodeBuild を使用してbuildコマンドを実行します。

    build コマンドは必須です。これらは、App Runner コンソール、App Runner API、またはapprunner.yaml設定ファイルで指定できます。

  3. Docker ビルドを実行して、特定のプラットフォームとランタイムバージョンの App Runner マネージドランタイムイメージに基づいてイメージを生成します。

  4. ステップ 2 で生成したイメージから /app ディレクトリをコピーします。送信先は、ステップ 3 で生成した App Runner マネージドランタイムイメージに基づくイメージです。

  5. 生成された App Runner マネージドランタイムイメージでbuildコマンドを再度実行します。ビルドコマンドを再度実行して、ステップ 4 でコピーした/appディレクトリのソースコードからビルドアーティファクトを生成します。このイメージは、後で App Runner によってデプロイされ、コンテナでウェブサービスを実行します。

    build コマンドは必須です。これらは、App Runner コンソール、App Runner API、またはapprunner.yaml設定ファイルで指定できます。

  6. ステップ 2 の CodeBuild イメージでpost-buildコマンドを実行します。

    post-build コマンドはオプションです。apprunner.yaml これらは設定ファイルでのみ指定できます。

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

改訂された App Runner ビルド

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

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

  1. ビルドステージ — App Runner ビルドイメージ上で pre-buildおよび build コマンドを実行する docker ビルドプロセスを開始します。

    1. アプリケーションのソースコードを /app ディレクトリにコピーします。

      注記

      この/appディレクトリは、Docker ビルドのすべてのステージで作業ディレクトリとして指定されます。

    2. pre-build コマンドを実行します。

      コマンドはpre-buildオプションです。apprunner.yaml これらは設定ファイルでのみ指定できます。

    3. build コマンドを実行します。

      build コマンドは必須です。これらは、App Runner コンソール、App Runner API、またはapprunner.yaml設定ファイルで指定できます。

  2. パッケージングステージ — App Runner 実行イメージにも基づいている、最終的な顧客コンテナイメージを生成します。

    1. ディレクトリを以前のビルドステージ/appから新しい実行イメージにコピーします。これには、アプリケーションのソースコードと前のステージのビルドアーティファクトが含まれます。

    2. pre-run コマンドを実行します。build コマンドを使用して/appディレクトリの外部でランタイムイメージを変更する必要がある場合は、apprunner.yaml設定ファイルのこのセグメントに同じコマンドまたは必要なコマンドを追加します。

      これは、改訂された App Runner ビルドをサポートするために導入された新しいパラメータです。

      pre-run コマンドはオプションです。apprunner.yaml これらは設定ファイルでのみ指定できます。

      メモ

      • pre-run コマンドは、改訂されたビルドでのみサポートされます。サービスが元のビルドを使用するランタイムバージョンを使用している場合は、設定ファイルに追加しないでください。

      • build コマンドを使用して/appディレクトリの外部を変更する必要がない場合は、pre-runコマンドを指定する必要はありません。

  3. ビルド後ステージ — このステージはビルドステージから再開し、post-buildコマンドを実行します。

    1. /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ディレクトリの外部を変更する必要がある場合。

  • コマンドを 2 build回実行して必要な環境を作成する必要がある場合。これは非常にまれな要件です。ほとんどのビルドはこれを行いません。

/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パラメータを使用して同じコマンドを再度指定して実行するオプションが用意されています。これにより、同じダブルビルド動作が保持されます。