この記事では、Web アプリ、モバイル バックエンド、または API アプリの一般的な設定を構成する方法について説明します。 Azure Functions については、「Azure Functions のアプリケーション設定のリファレンス」を参照してください。
アプリの設定を構成する
Azure App Service では、アプリ設定は環境変数としてアプリケーション コードに渡される変数です。 アプリの設定には、次の条件が適用されます。
- アプリ設定名には、文字、数字 (0 ~ 9)、ピリオド (.)、アンダースコア (_) のみを含めることができます。
- アプリ設定の値に含まれる特殊文字は、ターゲットオペレーティングシステムの要件に応じてエスケープする必要があります。
たとえば、 "pa$$w0rd\"
値を使用して App Service for Linux で環境変数を設定するには、アプリ設定の文字列を "pa\$\$w0rd\\"
する必要があります。
Linux アプリとカスタム コンテナーの場合、App Service は、 --env
フラグを使用してコンテナー内の環境変数を設定することで、アプリ設定をコンテナーに渡します。 いずれの場合も、アプリの起動時にアプリ環境に挿入されます。 アプリ設定を追加、削除、または編集する場合、App Service でアプリの起動がトリガーされます。
ASP.NET および ASP.NET Core 開発者の場合、App Service でアプリ設定を構成することは、<appSettings>
またはWeb.config
のappsettings.json
でアプリ設定を構成するのと同じです。 App Service の値は、 Web.config
または appsettings.json
の値よりも優先されます。 ローカル MySQL パスワードなどの開発設定は、 Web.config
または appsettings.json
に保持できます。 App Service では、Azure MySQL データベースパスワードなどの運用シークレットを安全に保持できます。 同じコードは、ローカルでデバッグするときに開発設定を使用します。 Azure にデプロイすると、運用シークレットが使用されます。
他の言語スタックでは、実行時にアプリ設定が環境変数として取得されます。 各言語スタックに固有の手順については、以下を参照してください。
アプリの設定は、格納されるときに常に暗号化されます (保存時に暗号化されます)。
注
アプリ設定にシークレットを格納する場合は、 Azure Key Vault 参照の使用を検討してください。 シークレットがバックエンド リソースへの接続用である場合は、セキュリティが強化され、シークレットを必要としない接続オプションを検討してください。 詳細については、「Azure App Service から Azure サービスとデータベースへのセキュリティで保護された接続」を参照してください。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、 設定>Environment 変数を選択します。 次 に、[アプリの設定] を選択します。
既定では、アプリ設定の値は、セキュリティのためにポータルでは非表示になっています。 アプリ設定の非表示の値を表示するには、[ 値] で [ 値の表示] を選択します。 すべてのアプリ設定の非表示の値を表示するには、[ 値の表示] を選択します。
注
Azure portal でこのセクションを表示するには、ユーザーの読み取り/書き込みアクセス許可が必要です。 十分なアクセス許可を持つ RBAC 組み込みロールは、所有者、共同作成者、および Web サイト共同作成者です。 閲覧者ロールだけでは、このページへのアクセスは許可されません。
新しいアプリ設定を追加するには、[追加] を選択します。 設定を編集するには、設定を選択します。
ダイアログで、設定を現在のスロットに固有として構成することができます。
注
既定の Linux アプリ サービスまたはカスタム Linux コンテナーでは、アプリ設定名内の入れ子になった JSON キー構造は、キー名に対して異なる方法で構成する必要があります。 コロン (
:
) を二重アンダースコア (__
) に置き換えます。 任意のピリオド (.
) を 1 つのアンダースコア (_
) に置き換えます。 たとえば、ApplicationInsights:InstrumentationKey
は、キー名のApplicationInsights__InstrumentationKey
として App Service で構成する必要があります。完了したら、適用 を選択します。 次に、[環境変数] ページで [適用] を選択します。
アプリ設定を一括編集する
- [ 詳細な編集] を選択します。
- テキスト領域の設定を編集します。
- 終了したら、 [OK] を選択します。 次に、[環境変数] ページで [適用] を選択します。
アプリ設定には、次の JSON 形式が含まれています。
[
{
"name": "<key-1>",
"value": "<value-1>",
"slotSetting": false
},
{
"name": "<key-2>",
"value": "<value-2>",
"slotSetting": false
},
...
]
接続文字列を構成する
このセクションでは、接続文字列を構成する方法について説明します。
注
より安全で、接続シークレットを必要としない接続オプションを検討してください。 詳細については、「Azure App Service から Azure サービスとデータベースへのセキュリティで保護された接続」を参照してください。
ASP.NET および ASP.NET Core 開発者にとって、App Service で接続文字列を設定することは、<connectionStrings>
のWeb.config
で接続文字列を設定するのと同じです。 App Service で設定した値は、 Web.config
の値よりも優先されます。 データベース ファイルなどの開発設定は、 Web.config
に保持できます。 App Service では、SQL データベースの資格情報などの運用シークレットを安全に保持できます。 同じコードは、ローカルでデバッグするときに開発設定を使用します。 Azure にデプロイすると、運用シークレットが使用されます。
他の言語スタックの場合は、代わりに アプリ設定 を使用することをお勧めします。 接続文字列では、値にアクセスするために変数キーに特別な書式設定が必要です。
non-.NET 言語のアプリ設定の代わりに接続文字列を使用する場合が 1 つあります。 特定の Azure データベースの種類は、App Service アプリでデータベースの接続文字列を構成した場合 にのみ 、アプリと共にバックアップされます。 詳しくは、カスタム バックアップの作成に関する記事を参照してください。 この自動バックアップが必要ない場合は、アプリ設定を使用します。
実行時に、接続文字列は、前に次の接続の種類が付加された環境変数として使用できます。
- SQL Server:
SQLCONNSTR_
- MySQL:
MYSQLCONNSTR_
- Azure SQL:
SQLAZURECONNSTR_
- カスタム:
CUSTOMCONNSTR_
- PostgreSQL:
POSTGRESQLCONNSTR_
- Azure Notification Hubs:
NOTIFICATIONHUBCONNSTR_
- Azure Service Bus:
SERVICEBUSCONNSTR_
- Azure Event Hubs:
EVENTHUBCONNSTR_
- Azure Cosmos DB:
DOCDBCONNSTR_
- Redis Cache:
REDISCACHECONNSTR_
注
PostgreSQL、Notification Hubs、Service Bus、Event Hubs、Azure Cosmos DB、Redis Cache を対象とする .NET アプリでは、.NET EnvironmentVariablesConfigurationProvider の既知の問題の回避策として、接続文字列を Custom に設定する必要があります。
たとえば、connectionstring1 という名前の MySQL 接続文字列には環境変数 MYSQLCONNSTR_connectionString1
としてアクセスできます。 各言語スタックに固有の手順については、以下を参照してください。
接続文字列は、格納されるときに常に暗号化されます (保存時に暗号化されます)。
注
Key Vaultからの接続文字列をKey Vault 参照を使用して解決することもできます。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、 設定>Environment 変数を選択します。 次に、[接続文字列] を選択 します。
既定では、接続文字列の値は、セキュリティのためにポータルでは非表示になっています。 接続文字列の非表示の値を表示するには、[ 値] で [ 値の表示] を選択します。 すべての接続文字列の非表示の値を表示するには、[ 値の表示] を選択します。
新しい接続文字列を追加するには、[追加] を選択します。 接続文字列を編集するには、その接続文字列を選択します。
ダイアログで、接続文字列を現在のスロットに固有として構成することができます。
完了したら、適用 を選択します。 次に、[環境変数] ページで [適用] を選択します。
接続文字列の一括編集
- [ 詳細な編集] を選択します。
- テキスト領域の接続文字列を編集します。
- 完了したら、適用 を選択します。 [環境変数] ページの [適用] も忘れないでください。
接続文字列には、次の JSON 形式が含まれています。
[
{
"name": "name-1",
"value": "conn-string-1",
"type": "SQLServer",
"slotSetting": false
},
{
"name": "name-2",
"value": "conn-string-2",
"type": "PostgreSQL",
"slotSetting": false
},
...
]
言語スタックの設定を構成する
言語スタック設定を構成するには、次のリソースを参照してください。
全般的な設定を構成する
全般設定を構成するには、お好みのツールの手順に従います。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、[設定]>[構成] を選択します。 次に、[ 全般設定] を選択します。
ここでは、アプリのいくつかの一般的な設定を構成できます。 一部の設定では、より高い価格レベルにスケールアップする必要があります。
スタック設定: 言語や SDK のバージョンなど、アプリを実行するためのソフトウェア スタックの設定を構成します。
Linux アプリの場合は、言語ランタイムのバージョンを選択し、オプションのスタートアップ コマンドを設定できます。
プラットフォームの設定: 次のようなホスティング プラットフォームの設定を構成します。
プラットフォーム: 32 ビットまたは 64 ビットを選択します。 Windows アプリ専用。
FTP 状態: FTPS のみを許可するか、FTP を完全に無効にします。
HTTP バージョン: HTTPS/2 プロトコルのサポートを有効にするには、2.0 に設定します。
注
最新のブラウザーのほとんどは、TLS 経由の HTTP/2 プロトコルのみをサポートしています。 暗号化されていないトラフィックは引き続き HTTP/1.1 を使用します。 クライアント ブラウザーが HTTP/2 でご利用のアプリに確実に接続されるようにするには、カスタム DNS 名をセキュリティで保護します。 詳細については、「 App Service で TLS/SSL バインドを使用してカスタム DNS 名のセキュリティを提供する」を参照してください。
Web ソケット: たとえば 、ASP.NET SignalR または socket.io 用に構成します。
常にオン: トラフィックがない場合でもアプリを読み込み続ける場合はオンにします。
Always On がオフ (既定) の場合、アプリは受信要求なしで 20 分後にアンロードされます。 アンロードされたアプリでは、ウォームアップ時間のために新しい要求の待機時間が長くなる場合があります。
Always On が有効になっている場合、フロントエンド ロード バランサーは 5 分ごとに
GET
要求をアプリケーション ルートに送信します。 継続的 ping により、アプリがアンロードされるのを防ぎます。Always On は、継続的な Web ジョブまたは cron 式によってトリガーされる Web ジョブに必要です。
セッション アフィニティ: 複数インスタンスのデプロイでは、セッションの有効期間中、クライアントが同じインスタンスにルーティングされていることを確認します。 ステートレス アプリケーションの場合は、このオプションを [オフ] に設定できます。
セッション アフィニティ プロキシ: アプリがリバース プロキシ (Azure Application Gateway や Azure Front Door など) の背後にあり、既定のホスト名を使用している場合はオンにします。 セッション アフィニティ Cookie のドメインは、リバース プロキシから転送されたホスト名と一致します。
HTTPS のみ: すべての HTTP トラフィックを HTTPS にリダイレクトする場合に有効にします。
[最小 TLS バージョン]: アプリに必要な TLS 暗号化の最小バージョンを選択します。
[デバッグ] : ASP.NET、ASP.NET Core、または Node.js アプリに対するリモート デバッグを有効にします。 このオプションは、48 時間後に自動的に無効になります。
受信クライアント証明書: 相互認証にクライアント証明書が必要です。
既定のドキュメントを構成する
既定のドキュメントは、App Service アプリのルート URL に表示される Web ページです。 一覧で最初に一致するファイルが使用されます。 アプリが、静的コンテンツの処理ではなく URL に基づいてルーティングされるモジュールを使用している場合、既定のドキュメントは必要ありません。
既定のドキュメントを構成する設定は、Windows アプリ専用です。
- Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
- アプリの左側のメニューで、[ 構成] を選択します。 次に、[ 既定のドキュメント] を選択します。
- 既定のドキュメントを追加するには、[新しいドキュメント] を選択します。 既定のドキュメントを削除するには、その右側にある [削除] を選択します。
URL パスをディレクトリにマップする
既定では、App Service はアプリ コードのルート ディレクトリからアプリを起動します。 しかし、特定の Web フレームワークはルート ディレクトリで開始されません。 たとえば、Laravel は public
サブディレクトリで開始されます。 そのようなアプリには、たとえば http://contoso.com/public
でアクセスできますが、通常は、代わりに http://contoso.com
を public
ディレクトリに送信します。 アプリのスタートアップ ファイルが別のフォルダーにあるか、またはリポジトリに複数のアプリケーションが含まれている場合は、仮想アプリケーションおよびディレクトリを編集または追加できます。
仮想ディレクトリを物理パスにマッピングする機能は、Windows アプリでのみ使用できます。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、[設定]>[構成] を選択します。 次に、[ パス マッピング] を選択します。
[新しい仮想アプリケーションまたはディレクトリ] を選択します。 次に、次のいずれかのアクションを実行します。
- 仮想ディレクトリを物理パスにマップするには、[ ディレクトリ] を 選択したままにします。 仮想ディレクトリと、Web サイト ルート (
D:\home
) への対応する相対 (物理) パスを指定します。 - 仮想ディレクトリを Web アプリケーションとしてマークするには、ディレクトリの選択を解除 します。
- 仮想ディレクトリを物理パスにマップするには、[ ディレクトリ] を 選択したままにします。 仮想ディレクトリと、Web サイト ルート (
OK を選択します。 次に、[構成] ページで [保存] を選択します。
ハンドラー マッピングを構成する
Windows アプリの場合は、IIS ハンドラー マッピングや仮想アプリケーションおよびディレクトリをカスタマイズできます。 ハンドラー マッピングを使用すると、特定のファイル拡張子への要求を処理するためのカスタム スクリプト プロセッサを追加できます。
カスタム ハンドラーを追加するには、次の操作を行います。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、[設定]>[構成] を選択します。 次に、[ パス マッピング] を選択します。
[新しいハンドラー マッピング] を選択します。 次のようにハンドラーを構成します。
-
[拡張子] 。
*.php
やhandler.fcgi
など、処理するファイル拡張子。 -
[Script processor] (スクリプト プロセッサ) 。 スクリプト プロセッサの絶対パス。 スクリプト プロセッサは、ファイル拡張子に一致するファイルへの要求を処理します。 アプリのルート ディレクトリは
D:\home\site\wwwroot
というパスを使って参照します。 - [引数] 。 スクリプト プロセッサの省略可能なコマンド ライン引数。
-
[拡張子] 。
OK を選択します。 次に、[構成] ページで [保存] を選択します。