Azure App Service on Linux の FAQ

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

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

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

アプリ サービスの予約済みフィールドを true に設定します。

はい、Azure Container Registry または DockerHub の継続的インテグレーションと継続的デプロイをセットアップするには、「Azure Web App for Containers での継続的デプロイ」をご覧ください。 プライベート レジストリでは、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 を使用できます。 この機能は現在、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 秒です。

http:// または https:// を含む完全なレジストリ URL を入力します。

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

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

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

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

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

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

はい、.NET Core アプリを起動する前に環境変数を上書きしてください。 例: init.sh スクリプト: export ASPNETCORE_URLS={値}

複数コンテナーで 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 からのスタートアップとシャットダウンの制御の推奨事項のとおり、Azure 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 によってコンテナーが始動すると、ウォームアップ要求によって HTTP 要求がアプリケーションの /robots933456.txt エンドポイントに送信されます。 これはただのダミー エンドポイントですが、お使いのアプリケーションでは、非 5XX 状態コードで応答する必要があります。 お使いのアプリケーションのロジックでは存在しないエンドポイントに HTTP 状態コードで応答しない場合、ウォームアップ要求では応答を受け取れず、コンテナーが繰り返し再起動されます。 ウォームアップ要求はまた、ポートの誤構成によって失敗することがあります。

Azure App Services でポートが正しく構成されるようにするには、「Linux コンテナー内でポートを指定するための操作方法を教えてください」という質問を参照してください。

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

アプリケーションのファイル システムは、マウントされたネットワーク共有です。 これにより、コードを複数のホストにわたって実行する必要があるスケール アウト シナリオが可能になります。 残念ながら、これでは、データベース ファイルに対する排他ロックを取得できないため、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 Apps と Linux
• 環境変数とアプリ設定のリファレンス

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

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