Service Connector の既知の制限事項
この記事では、Service Connector の既存の制限事項とそれらの軽減方法について説明します。
コードとしてのインフラストラクチャ (IaC) の制限事項
Service Connector は、可能な限り多くの Azure サービスに対して、簡単で安全な一貫性のあるバッキング サービス接続の利点を提供するように設計されています。 それを行うために、Service Connector は拡張リソース プロバイダーとして開発されました。
残念ながら、Service Connector によりユーザーに代わってインフラストラクチャが変更されるため、IaC のサポートにはいくつかの制限があります。 このシナリオでは、ユーザーは始めに Azure Resource Manager (ARM)、Bicep、Terraform、またはその他の IaC テンプレートを使用してリソースを作成します。 その後、Service Connector を使用してリソース接続を設定します。 この手順の間に、Service Connector によりユーザーに代わってリソース構成が変更されます。 ユーザーが後で IaC テンプレートを再実行すると、Service Connector によって行われた変更は、元の IaC テンプレートに反映されていないため、消失します。 この動作の例として、ARM テンプレートを使用してデプロイされた Azure Container Apps では、通常既定でマネージド ID (MI) が無効になっていますが、Service Connector によってユーザーに代わって接続が設定される際に MI が有効にされます。 ユーザーが MI 設定を更新せずに同じ ARM テンプレートをトリガーすると、再デプロイされたコンテナー アプリで MI が再び無効にされます。
Service Connector の使用時に何らかの問題が発生した場合は、問題を報告してください。
ソリューション
次の解決策をお勧めします。
- インフラストラクチャを構築したり、既存のインフラストラクチャを IaC テンプレートに変換したりするには、IaC ツールで接続を構築する方法に関するページを参照してください。
- CI/CD パイプラインにソース コンピューティングまたはバッキング サービスのテンプレートが含まれている場合、推奨されるフローは、テンプレートの再適用、アプリケーションが稼働していることを確認するためのサニティ チェックまたはスモーク テストの追加、アプリケーションへのライブ トラフィックの許可です。 フローでは、ライブ トラフィックを許可する前に検証手順を追加します。
- Service Connector を使用して Azure Container App コードのデプロイを自動化する場合は、Service Connector によって接続が再適用される前に、一時的に機能しないアプリにトラフィックがルーティングされないように、複数リビジョン モードを使用することをお勧めします。
- 自動化操作の実行順序は非常に重要です。 接続自体が作成される前に、接続エンドポイントがあることを確認します。 理想的には、バッキング サービス、次にコンピューティング サービス、次に両者間の接続を作成します。 この方法で、Service Connector では、コンピューティング サービスとバッキング サービスの両方を適切に構成できます。