トレーニング
認定資格
Microsoft Certified: Azure Developer Associate - Certifications
Azure Functions の作成、Web アプリの実装と管理、Azure ストレージを利用したソリューションの開発などを行うために、Microsoft Azure でエンド ツー エンドのソリューションを構築します。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
注意
2024 年 6 月 1 日より、新しく作成されたすべての App Service アプリには、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net
を使用して一意の既定のホスト名を生成するオプションが備わります。 既存のアプリ名は変更されません。
例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net
詳細については、「App Service リソースの一意の既定のホスト名」を参照してください。
この記事では、Web アプリ、モバイル バックエンド、または API アプリの一般的な設定を構成する方法について説明します。 Azure Functions については、「Azure Functions のアプリケーション設定のリファレンス」を参照してください。
注意
たとえば、App Service Linux で値 "pa$$w0rd\"
を使用して環境変数を設定するには、アプリ設定の文字列を次のように設定します: "pa\$\$w0rd\\"
App Service では、アプリ設定は、環境変数としてアプリケーション コードに渡される変数です。 Linux アプリとカスタム コンテナーの場合、App Service では、コンテナー内に環境変数を設定するためのアプリ設定が --env
フラグを使用してコンテナーに渡されます。 いずれの場合も、アプリの起動時にアプリ環境に挿入されます。 アプリ設定を追加、削除、または編集する場合、App Service でアプリの起動がトリガーされます。
ASP.NET および ASP.NET Core 開発者の場合、App Service でのアプリ設定の設定は Web.config または appsettings.json での <appSettings>
の設定と同様ですが、App Service の値によって Web.config または appsettings.json でそれらがオーバーライドされます。 Web.config または appsettings.json 内の開発設定 (たとえば、ローカル MySQL パスワード)、および運用シークレット (たとえば、Azure MySQL データベース パスワード) は App Service で安全に保持できます。 ローカルでデバッグするときに開発設定を使用するコードと、Azure にデプロイされたときに運用シークレットを使用するコードは同じです。
同様に、他の言語スタックも実行時に環境変数としてアプリ設定を取得します。 言語スタック固有の手順については、次を参照してください。
アプリの設定は、格納されるときに常に暗号化されます (保存時の暗号化)。
注意
アプリ設定にシークレットを格納する場合は、Key Vault 参照を使用することを検討してください。 シークレットがバックエンド リソースへの接続用の場合は、シークレットをまったく必要としない、より安全な接続オプションを検討してください。 詳細については、「Azure App Service から Azure サービスとデータベースへのセキュリティで保護された接続」を参照してください。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、[環境変数] > [アプリ設定] を選択します。
既定では、アプリ設定の値は、セキュリティのためにポータルでは非表示になっています。 アプリ設定の非表示の値を表示するには、その [値] フィールドを選択します。 すべてのアプリ設定の非表示の値を表示するには、[値の表示] ボタンを選択します。
新しいアプリ設定を追加するには、[追加] を選択します。 設定を編集するには、[設定] を選択します。
ダイアログで、設定を現在のスロットに固有として構成することができます。
注意
既定の Linux App Service またはカスタム Linux コンテナーでは、ApplicationInsights:InstrumentationKey
などの、アプリ設定名の中の入れ子になった JSON キー構造はすべて、App Service ではキー名を ApplicationInsights__InstrumentationKey
として構成する必要があります。 つまり、:
はすべて __
(二重アンダースコア) で置き換える必要があります。 アプリ設定名のピリオドは _
(単一下線) に置換されます。
完了したら、[適用] を選択します。 忘れずに [環境変数] ページに戻って [適用] を選択してください。
[高度な編集] ボタンを選択します。 テキスト領域の設定を編集します。 終わったら、 [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 での接続文字列の設定は Web.config 内の <connectionStrings>
での設定と同様ですが、App Service で設定した値によって Web.config 内の値がオーバーライドされます。Web.config 内の開発設定 (データベース ファイルなど) や運用シークレット (SQL Database の資格情報など) を App Service で安全に保持できます。 ローカルでデバッグするときに開発設定を使用するコードと、Azure にデプロイされたときに運用シークレットを使用するコードは同じです。
他の言語スタックの場合は、値にアクセスするために接続文字列の変数キーに特殊な形式が必要になるため、代わりにアプリ設定を使用することをお勧めします。
注意
.NET 以外の言語のアプリ設定ではなく、接続文字列の使用が必要になる場合があります。 App Service アプリでデータベースの接続文字列を構成した場合のみ、特定の Azure データベースの種類がアプリと一緒にバックアップされます。 詳しくは、カスタム バックアップの作成に関する記事を参照してください。 この自動バックアップが必要ない場合は、アプリ設定を使用してください。
実行時に、接続文字列は、前に次の接続の種類が付加された環境変数として使用できます。
SQLCONNSTR_
MYSQLCONNSTR_
SQLAZURECONNSTR_
CUSTOMCONNSTR_
POSTGRESQLCONNSTR_
NOTIFICATIONHUBCONNSTR_
SERVICEBUSCONNSTR_
EVENTHUBCONNSTR_
DOCDBCONNSTR_
REDISCACHECONNSTR_
注意
PostgreSQL、通知ハブ、Service Bus、イベント ハブ、ドキュメント DB、Redis Cache を対象とする .NET アプリでは、.NET EnvironmentVariablesConfigurationProvider の既知の問題の回避策として、接続文字列を [カスタム] に設定する必要があります
たとえば、connectionstring1 という名前の MySQL 接続文字列には環境変数 MYSQLCONNSTR_connectionString1
としてアクセスできます。 言語スタック固有の手順については、次を参照してください。
接続文字列は、格納されるときに常に暗号化されます (保存時の暗号化)。
注意
接続文字列は、Key Vault 参照を使用して Key Vault から解決することもできます。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、[環境変数] > [接続文字列] を選択します。
既定では、接続文字列の値は、セキュリティのためにポータルでは非表示になっています。 接続文字列の非表示の値を表示するには、その [値] フィールドを選択します。 すべての接続文字列の非表示の値を表示するには、[値の表示] ボタンを選択します。
新しい接続文字列を追加するには、[追加] を選択します。 接続文字列を編集するには、その接続文字列を選択します。
ダイアログで、接続文字列を現在のスロットに固有として構成することができます。
完了したら、[適用] を選択します。 忘れずに [環境変数] ページに戻って [適用] を選択してください。
[高度な編集] ボタンを選択します。 テキスト領域の接続文字列を編集します。 完了したら、[適用] を選択します。 忘れずに [環境変数] ページに戻って [適用] を選択してください。
接続文字列には、次の 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] を探して選択してから、アプリを選択します。 アプリの左側のメニューで、 [構成]>[全般設定] を選択します。
ここでは、アプリのいくつかの一般的な設定を構成できます。 一部の設定では、より高い価格レベルにスケールアップする必要があります。
[Stack settings] (スタックの設定) : アプリを実行するためのソフトウェア スタック (言語や SDK バージョンを含む)。
Linux アプリの場合、言語ランタイム バージョンを選択し、任意のスタートアップ コマンドまたはスタートアップ コマンド ファイルを設定します。
[プラットフォームの設定] : ホスティング プラットフォームの設定を構成できます。次のものが含まれます。
注意
最新のブラウザーのほとんどは、TLS 上でのみ HTTP/2 プロトコルをサポートし、暗号化されていないトラフィックには引き続き HTTP/1.1 を使用しています。 クライアント ブラウザーが HTTP/2 でご利用のアプリに確実に接続されるようにするには、カスタム DNS 名をセキュリティで保護します。 詳細については、「Azure App Service で TLS/SSL バインディングを使用してカスタム DNS 名をセキュリティで保護する」を参照してください。
Web ソケット: ASP.NET SignalR や socket.io など。
[常時接続] : トラフィックがない場合も、アプリを読み込まれたままにします。 [常時接続] がオン (既定) でない場合、アプリは受信要求なしで 20 分後にアンロードされます。 アンロードされたアプリでは、ウォームアップ時間のために新しい要求の待機時間が長くなる場合があります。 [常時接続] がオンの場合、フロントエンド ロード バランサーは 5 分ごとにアプリケーション ルートに GET 要求を送信します。 再イメージング操作が正常に実行されるためには、この要求が 200 OK 応答を受け取っていることを確認することが重要です。 継続的 ping により、アプリがアンロードされるのを防ぎます。
[常時接続] は、継続的な Web ジョブや、CRON 式を使用してトリガーされる Web ジョブに必要です。
セッション アフィニティ: マルチインスタンス デプロイでは、クライアントがセッションの有効期間を通して同じインスタンスにルーティングされることを確認してください。 ステートレス アプリケーションの場合は、このオプションを [オフ] に設定できます。
セッション アフィニティ プロキシ: セッション アフィニティ プロキシを有効にできるのは、アプリがリバース プロキシ (Azure Application Gateway や Azure Front Door など) の背後にあり、既定のホスト名を使用している場合です。 セッション アフィニティ Cookie のドメインは、リバース プロキシから転送されたホスト名と一致します。
HTTPS のみ: 有効にすると、すべての HTTP トラフィックが HTTPS にリダイレクトされます。
最小 TLS バージョン: アプリに必要な最小の TLS 暗号化バージョンを選択してください。
[デバッグ] : ASP.NET、ASP.NET Core、または Node.js アプリに対するリモート デバッグを有効にします。 このオプションは、48 時間後に自動的に無効になります。
[Incoming client certificates] (受信クライアント証明書) : 相互認証でクライアント証明書を必要とします。
この設定は、Windows アプリでのみ使用されます。
既定のドキュメントは、App Service アプリのルート URL に表示される Web ページです。 一覧で最初に一致するファイルが使用されます。 アプリが、静的コンテンツの処理ではなく URL に基づいてルーティングされるモジュールを使用している場合、既定のドキュメントは必要ありません。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、 [構成]>[既定のドキュメント] を選択します。
既定のドキュメントを追加するには、[新しいドキュメント] を選択します。 既定のドキュメントを削除するには、その右側にある [削除] を選択します。
既定では、App Service はアプリ コードのルート ディレクトリからアプリを起動します。 しかし、特定の Web フレームワークはルート ディレクトリで開始されません。 たとえば、Laravel は public
サブディレクトリで開始されます。 そのようなアプリには、たとえば http://contoso.com/public
でアクセスできますが、通常は、代わりに http://contoso.com
を public
ディレクトリに送信します。 アプリのスタートアップ ファイルが別のフォルダーにあるか、またはリポジトリに複数のアプリケーションが含まれている場合は、仮想アプリケーションおよびディレクトリを編集または追加できます。
重要
物理パス機能への仮想ディレクトリは Windows アプリでのみ利用できます。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、[構成]>[Path mappings](パスのマッピング) を選択します。
[新しい仮想アプリケーションまたはディレクトリ] を選択します。
D:\home
) への対応する相対 (物理) パスを指定します。[OK] を選択します。 忘れずに [構成] ページで [保存] を選択してください。
Windows アプリの場合は、IIS ハンドラー マッピングや仮想アプリケーションおよびディレクトリをカスタマイズできます。 ハンドラー マッピングを使用すると、特定のファイル拡張子への要求を処理するためのカスタム スクリプト プロセッサを追加できます。
カスタム ハンドラーを追加するには、次の操作を行います。
Azure portal で、 [App Services] を探して選択してから、アプリを選択します。
アプリの左側のメニューで、 [構成]>[Path mappings](パスのマッピング) を選択します。
[新しいハンドラー マッピング] を選択します。 次のようにハンドラーを構成します。
D:\home\site\wwwroot
というパスを使って参照します。[OK] を選択します。 忘れずに [構成] ページで [保存] を選択してください。
トレーニング
認定資格
Microsoft Certified: Azure Developer Associate - Certifications
Azure Functions の作成、Web アプリの実装と管理、Azure ストレージを利用したソリューションの開発などを行うために、Microsoft Azure でエンド ツー エンドのソリューションを構築します。