次の方法で共有

AppServiceでイメージのpullが一時的に失敗する場合の対策について

野本 理裕 20 評価のポイント
2026-06-05T05:10:12.3733333+00:00

Azure App Serviceを再起動した際、Azure Container RegistryからのDockerイメージのpullに失敗して起動しないことがありました。
事象はまだ一度だけであり再発していないものの、今後の自動デプロイやスケールアウト時などに同様のエラーでサービスが停止しないよう、予防策を講じたいと考えております

一時的なネットワークエラー等によるpullの失敗に対して、App Service側で自動リトライさせるような設定、またはベストプラクティスとなる対策はありますでしょうか。

特に、以下の公式ドキュメントに挙げられているヘルスチェックや自動回復などの機能は、コンテナの起動自体が完了していない状況でも有効に機能するのでしょうか。
https://learn.microsoft.com/ja-jp/azure/app-service/routine-maintenance-downtime#strategies-for-startup-consistency

Azure App Service
Azure App Service

zure App Service は、スケーラブルでミッションクリティカルな Web アプリを作成してデプロイするのに使用されます。


質問作成者が受け入れた回答

Praneeth Maddali 10,460 評価のポイント Microsoft 外部スタッフ モデレーター
2026-06-05T06:25:08.17+00:00

こんにちは @野本 理裕

Microsoft Q&Aにご質問を投稿いただき、ありがとうございます。回答は英語から翻訳されているため、文法的な誤りが含まれている可能性があります。あらかじめご了承ください。

ご連絡いただき、また今回の事象について詳細を分かりやすくお知らせくださり、ありがとうございます。再起動やスケールアウトの際に発生する一時的なイメージ取得(pull)の失敗は、頻繁に起こるものではないにせよ、煩わしい問題となり得ます。Azure App Serviceには、Dockerイメージの取得のみを対象とした明示的な「自動再試行」の切り替え設定はありませんが、プラットフォーム自体に組み込まれた回復機能(レジリエンス)が備わっています。また、システムの堅牢性を高めるために実践できる対策もいくつか存在します。

推奨される設定の調整

  1. コンテナの起動時間制限を延長してください。これにより、イメージのプルや初期化に時間がかかる場合でも、プラットフォームに余裕を持たせることができます。
    • アプリ設定 WEBSITES_CONTAINER_START_TIME_LIMIT を追加し、値を 600(最大 1800 秒)に設定してください。これは特に、再起動時やサイズの大きなイメージをプルする際に役立ちます。.
  2. 可用性チェックの失敗時にコンテナーの自動修復を有効にするには、アプリ設定 CONTAINER_AVAILABILITY_CHECK_MODERepair に設定します。これにより、可用性チェックに3回連続で失敗した場合、プラットフォームは自動的にコンテナーを再起動します。この機能は、コンテナーのプロセス開始直後に発生するような一時的な問題に対して有効です。
  3. ACR認証にはマネージドIDを使用してください(強く推奨)。管理者資格情報を使用すると、古いキャッシュに起因する問題が発生する場合があります。代わりに、以下の方法を使用してください。
    • App Service で、システム割り当て(またはユーザー割り当て)のマネージド ID を有効にします。
    • Azure Container Registry で、それに AcrPull ロールを割り当てます。
    • 次のアプリ設定を追加します:acrUseManagedIdentityCreds = true(ユーザー割り当て ID を使用する場合は acrUserManagedIdentityID = <client-id> も追加)。その後、古い資格情報をクリアするためにアプリを再起動してください。
  4. Azure ポータルで、対象の App Service の [監視] > [正常性チェック] に移動して機能を有効にし、アプリ内のシンプルな /health(または同様の)エンドポイントを指定して正常性チェックを構成します。これにより、コンテナーの起動後に正常ではないインスタンスをプラットフォームがより迅速に検出し、置き換えることが可能になります。この機能は主に起動後に動作するものですが、可用性チェックを適切に補完する役割も果たします。

その他のベストプラクティス

  • 可能な限り、ゼロダウンタイムでの更新にデプロイメントスロットを使用してください。
  • デプロイメントセンターで継続的デプロイを有効にし、イメージの更新によって確実に再起動がトリガーされるようにします。
  • 再起動中に Docker ログを監視し(az webapp log tail)、起動失敗時のアラートを設定してください。

これらの変更により、将来同様の停止が発生する可能性は大幅に低減するはずです。

参照:

https://learn.microsoft.com/ja-jp/azure/app-service/routine-maintenance-downtime

https://learn.microsoft.com/ja-jp/troubleshoot/azure/azure-container-registry/pull-image-to-web-app-fail

https://learn.microsoft.com/ja-jp/azure/app-service/monitor-instances-health-check?tabs=dotnet

https://learn.microsoft.com/ja-jp/azure/app-service/configure-custom-container?tabs=debian&pivots=container-linux

もしこの回答が役に立った場合は、「回答を承認する」をクリックしてください。はい、これは他のコミュニティメンバーにも有益です。 もし他に質問があれば、「コメント」で教えてください。喜んでお手伝いします。

この回答は役に立ちましたか?

1 人がこの回答が役に立ったと思いました。
0 件のコメント コメントはありません

0 件の追加の回答

並べ替え方法: 最も役に立つ

お客様の回答

質問作成者は回答に "承認済み"、モデレーターは "おすすめ" とマークできます。これにより、ユーザーは作成者の問題が回答によって解決したことを把握できます。