Azure App Service on Linux の FAQ

これらのコマンドまたはスクリプトは、組み込みの Docker コンテナーが開始されてから、アプリケーション コードが開始されるまでの間に実行されます。

このアクションは Docker の再起動と同じです。

はい、ソース管理 (SCM) サイトからご利用いただけます。

App Service の 予約済み フィールドを true に設定 します。

はい。 Web App for Containers での継続的デプロイに従って、Azure Container Registry または DockerHub の継続的インテグレーション/デプロイを設定します。 プライベート レジストリでは、Web アプリを停止してから起動することでコンテナーを更新できます。 または、ダミー アプリケーション設定を変更または追加して、コンテナーを強制的に更新できます。

はい。

はい。 WEBSITE_WEBDEPLOY_USE_SCM というアプリ設定を false に設定する必要 があります。

Linux Web アプリに対して Git デプロイが失敗する場合は、以下のいずれかのオプションを選択してアプリケーション コードをデプロイします。

• 継続的デリバリー (プレビュー) 機能を使用する: アプリのソース コードを Azure DevOps Git リポジトリまたは GitHub リポジトリに格納して、Azure 継続的デリバリーを使用できます。 詳細については、「 Linux Web アプリの継続的デリバリーを構成する方法」を参照してください。

• ZIP デプロイ API を使用する: この API を使用するには、Web アプリに SSH 接続し、コードをデプロイするフォルダーに移動します。 次のコードを実行します。

  curl -X POST -u <user> --data-binary @<zipfile> https://{your-sitename}.scm.azurewebsites.net/api/zipdeploy
  

  curl コマンドが見つからないというエラーが発生した場合は、前の curl コマンドを実行する前に、apt-get install curlを使用して curl をインストールしてください。

はい、サーバー側の Node.js コードで perMessageDeflate を無効にします。 たとえば、socket.io を使用している場合は、次のコードを使用します。

const io = require('socket.io')(server,{
  perMessageDeflate :false
});

はい。

はい、Git のデプロイ中に、Kudu は (composer.lock ファイルの存在により) PHP アプリケーションをデプロイしていることを検出し、その後 Kudu は Composer のインストールをトリガーします。

はい、この機能は、Azure CLI から使用できます。 システム割り当て ID またはユーザー割り当て ID を使用できます。 この機能は現在、Azure Portal ではサポートされていません。

WEBSITES_ENABLE_APP_SERVICE_STORAGE設定が指定されていないか false に設定されている場合、/home/ ディレクトリはスケール インスタンス間で共有されません。書き込まれたファイルは再起動しても保持されません。 WEBSITES_ENABLE_APP_SERVICE_STORAGEを明示的に true に設定すると、マウントが有効になります。 これが true に設定されたら、マウントを無効にする場合は、 WEBSITES_ENABLE_APP_SERVICE_STORAGE を 明示的に false に設定する必要があります。

App Service on Linux では、次の 2 種類のストレージが使用されます。

• ファイル システム ストレージ: ファイル システム ストレージは、App Service プランのクォータに含まれています。 これは、 /home ディレクトリにルート化された永続ストレージにファイルが保存されるときに使用されます。
• ホスト ディスク領域: ホスト ディスク領域は、コンテナー イメージを格納するために使用されます。 これは、Docker ストレージ ドライバーを介してプラットフォームによって管理されます。

ホスト ディスク領域は、ファイル システムのストレージ クォータとは別です。 展開できず、インスタンスごとに 15 GB の制限があります。 ワーカーにカスタム イメージを格納するために使用されます。 ホスト ディスク領域の正確な可用性によっては、15 GB を超える GB を使用できる場合がありますが、これは保証されません。

コンテナーの書き込み可能レイヤーが、 /home ディレクトリまたは マウントされた Azure ストレージ パスの外部にデータを保存する場合、ホスト ディスク領域も消費されます。

プラットフォームは、ホスト ディスク領域を定期的にクリーンアップして、未使用のコンテナーを削除します。 コンテナーが /home ディレクトリまたは Bring Your Own Storage (BYOS) の外部に大量のデータを書き込む場合、ホスト ディスク領域の上限を超えると、起動エラーまたはランタイム例外が発生します。

Linux App Service で実行する場合は、コンテナー イメージをできるだけ小さくし、永続ストレージまたは BYOS にデータを書き込むことをお勧めします。 可能でない場合は、App Service プランのホスト ディスク領域が固定され、App Service プラン内のすべてのコンテナー間で共有されるため、App Service プランを分割する必要があります。

コンテナーを再起動する前にプラットフォームが待機する時間を構成できます。 これを行うには、WEBSITES_CONTAINER_START_TIME_LIMIT アプリ設定を目的の値に設定します。 既定値は 230 秒であり、最大値は 1800 秒です。

https://を含む完全なレジストリ URL を指定します。

プライベート レジストリ の URL を含む完全なイメージ名を追加します (例: myacr.azurecr.io/dotnet:latest)。 カスタム ポートを使用するイメージ名 は、ポータルから入力できません。 docker-custom-image-nameを設定するには、az コマンドライン ツールを使用します。

複数のポートの公開はサポートされていません。

はい、持ち込みストレージはプレビュー段階です。

SCM サイトは別のコンテナーで実行されています。 アプリ コンテナーのファイル システムや実行中のプロセスをチェックすることはできません。

いいえ、共有フロントエンドでの HTTPS の終了はプラットフォームが処理します。

はい、これはカスタム コンテナーに必要です。 カスタム ポートを手動で構成するには、Dockerfile の EXPOSE 命令とアプリの設定 WEBSITES_PORT を使用して、コンテナーにバインドするポート値を指定します。

はい、.NET Core アプリを起動する前に環境変数を上書きしてください。 たとえば、init.sh スクリプトでは、ASPNETCORE_URLS={Your value} をエクスポートします。

マルチコンテナーで ACR を使用するには、 すべてのコンテナー イメージ を同じ ACR レジストリ サーバーでホストする必要があります。 同じレジストリ サーバー上に配置されたら、アプリケーション設定を作成し、Docker Compose 構成ファイルを更新して ACR イメージ名を含める必要があります。

次のアプリケーション設定を作成します。

• DOCKER_REGISTRY_SERVER_USERNAME
• DOCKER_REGISTRY_SERVER_URL (完全な URL、例: https://<server-name>.azurecr.io)
• DOCKER_REGISTRY_SERVER_PASSWORD (ACR 設定で管理者アクセスを有効にする)

次の例のように、構成ファイル内で ACR イメージを参照します。

image: <server-name>.azurecr.io/<image-name>:<tag>

• アクセスできるコンテナーは 1 つのみ
• ポート 80 および 8080 のみがアクセス可能 (公開ポート)

アクセス可能なコンテナーを判断するためのルールを次に示します (優先順)。

• コンテナー名に設定されるアプリケーション設定 WEBSITES_WEB_CONTAINER_NAME
• ポート 80 または 8080 を定義する最初のコンテナー
• 上記のいずれにも当てはまらない場合、ファイルで定義されている最初のコンテナーがアクセス可能 (公開) になります

depends_on オプションは App Service ではサポートされておらず、無視されます。 Docker からの制御の起動とシャットダウンの推奨事項と同様に、App Service マルチコンテナー アプリでは、起動時と切断時の両方で、アプリケーション コードを使用して依存関係を確認する必要があります。 次のコード例は、Redis コンテナーが実行されているかどうかを確認する Python アプリを示しています。

import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
    retries = 5
    while True:
        try:
            return cache.incr('hits')
        except redis.exceptions.ConnectionError as exc:
            if retries == 0:
                raise exc
            retries -= 1
            time.sleep(0.5)
@app.route('/')
def hello():
    count = get_hit_count()
    return 'Hello from Azure App Service team! I have been seen {} times.\n'.format(count)
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=80, debug=True)

Web ソケット

Web Sockets は Linux アプリでサポートされています。 Web ソケットは常に Linux に対して有効になっているため、 webSocketsEnabled ARM 設定は Linux アプリには適用されません。

価格は SKU とリージョンによって異なりますが、価格の詳細については、 App Service の価格に関するページを参照してください。

Azure App Services によってコンテナーが開始されると、ウォームアップ要求はアプリケーションの /robots933456.txt エンドポイントに HTTP 要求を送信します。 これは単なるダミー エンドポイントですが、アプリケーションは状態コード (5xx を含む) を返して応答する必要があります。 存在しないエンドポイントに HTTP 状態コードを送信してアプリケーション ロジックが応答しない場合、ウォームアップ要求は応答を受信できません。 そのため、コンテナーは永続的に再起動されます。

既定の動作から変更するには、ウォームアップ エンドポイントのパスと、サイトをウォームアップすると見なす状態コードをカスタマイズできます。 これを行うには、 WEBSITE_WARMUP_PATH と WEBSITE_WARMUP_STATUSES アプリケーションの設定を設定します。

また、ポートの構成ミスが原因でウォームアップ要求が失敗する可能性もあります。

Azure App Services でポートが正しく構成されていることを確認するには、Linux コンテナーでポートを指定する方法に関する質問を参照してください。

ウォームアップ要求は既定で、コンテナーからの応答を 240 秒待ち、応答がなければ失敗となります。 240 ~ 1800 秒の値を持つ WEBSITES_CONTAINER_START_TIME_LIMIT アプリケーション設定を追加することで、コンテナーウォームアップ要求のタイムアウトを増やします。

アプリケーションのファイル システムは、マウントされたネットワーク共有です。 これにより、コードを複数のホストにわたって実行する必要があるスケール アウト シナリオが可能になります。 残念ながら、これでは、データベース ファイルに対する排他ロックを取得できないため、SQLite のようなファイル ベースのデータベース プロバイダーの使用がブロックされます。 マネージド データベース サービスをお勧めします。 Azure SQL、 Azure Database for MySQL 、 または Azure Database for PostgreSQL

アプリケーション設定では、英字 (A ～ Z、a ～ z)、数字 (0 ～ 9)、およびアンダースコア (_) のみご利用いただけます。

アイデアは、Web Apps フィードバック フォーラムで送信できます。 アイデアのタイトルに "[Linux]" を追加してください。

次のステップ

• Azure App Service on Linux とは
• Azure App Service でステージング環境を設定する
• Web App for Containers を使用した継続的なデプロイ
• 知っておくべきこと: Web アプリと Linux
• 環境変数とアプリ設定のリファレンス

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、 サポートリクエストを作成するか、 Azure コミュニティ サポートに問い合わせてください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。