適用対象: Azure Logic Apps (Standard)
場合によっては、規制コンプライアンス、データのプライバシー、またはネットワーク制限に対する特定のニーズを満たすために、独自のインフラストラクチャを設定および管理する必要があります。 Azure Logic Apps には、オンプレミス、プライベート クラウド、またはパブリック クラウドのシナリオで Standard ロジック アプリ ワークフローをデプロイおよびホストできるように "ハイブリッド デプロイ モデル" が用意されています。 このモデルによって、ローカル処理、データ ストレージ、ネットワーク アクセスを使用する必要があるときに、部分的に接続された環境で統合ソリューションをホストする機能が提供されます。 ハイブリッド オプションを使用すると、ワークフローに最適な環境を自由に、かつ柔軟に選択できます。
ハイブリッド デプロイのしくみ
ハイブリッド デプロイ オプションを使用した Standard ロジック アプリ ワークフローは、Azure Container Apps 拡張機能でホストされている Azure Logic Apps ランタイムを活用します。 ワークフローでは、 組み込みのランタイムネイティブ操作はランタイム でローカルに実行されるため、ローカル データ ソースにアクセスするためのスループットが向上します。 Microsoft Office 365、Microsoft Teams、Salesforce、GitHub、LinkedIn、ServiceNow などのクラウドベースのサービスなど、ローカル以外のデータ リソースにアクセスする必要がある場合は、 Azure でホストされている 1,400 以上のコネクタ から操作を選択してワークフローに含めることができます。 詳細については、マネージド (共有) コネクタに関するページを参照してください。 Azure portal でロジック アプリを管理するにはインターネット接続が必要ですが、このプラットフォームの半接続の性質により、一時的なインターネット接続の問題をすべて吸収できます。
たとえば、オンプレミスのシナリオがある場合は、次のアーキテクチャの概要によって、Standard ロジック アプリ ワークフローがハイブリッド モデル内のどこでホストされ、実行されるかが示されます。 部分的に接続された環境には、Azure Container Apps リソースとしてデプロイされる Standard ロジック アプリをホストして操作するための次のリソースが含まれています。
- Azure Arc 対応 Azure Kubernetes Service (AKS) クラスター
- ワークフロー実行履歴、入力、および出力を処理用にローカルに格納する SQL データベース
- ワークフローで使用される成果物をローカルに格納するサーバー メッセージ ブロック (SMB) ファイル共有
ホスティングの場合は、Azure Local 上の Azure Arc 対応 Kubernetes クラスターまたは Windows Server 上の Azure Arc 対応 Kubernetes クラスターを設定して使用することもできます。
ハイブリッド デプロイ モデルは、オンプレミスとクラウドの機能を組み合わせて、さまざまなニーズに柔軟な統合ソリューションを提供します。 たとえば、ハイブリッド ロジック アプリ リソースは、ワークロードの変化に基づいてリソースを効率的に調整できます。 この動的スケーリングは、ピーク時に容量を増やし、使用量が減少したときにリソースを減らすことで、コンピューティング コストを管理するのに役立ちます。
詳しくは、次のドキュメントをご覧ください。
- Azure Kubernetes Service とは
- Azure Kubernetes Services (AKS) の中心概念
- Azure Arc 対応 Kubernetes クラスターのためのカスタムの場所
- Azure Container Apps とは
- Azure Arc 上の Azure Container Apps
- Kubernetes ベースの Event-Driven 自動スケール (KEDA) の動的スケーリング モデルとアーキテクチャ
このハウツー ガイドでは、ハイブリッド デプロイ モデルを使用して Standard ロジック アプリ ワークフローを作成、デプロイ、ホストできるように、インフラストラクチャ内に必要なオンプレミス リソースを設定する方法を示します。
制限事項
次のセクションでは、ハイブリッド展開オプションの制限事項について説明します。
| 制限事項 | 説明 |
|---|---|
| 切断されたランタイムによるデータログ記録 | 部分的に接続されたモードでは、Azure Logic Apps ランタイムは最大 24 時間切断された状態を維持でき、データ ログは保持されます。 ただし、この期間を過ぎたログ データは失われる可能性があります。 |
| サポート対象の Azure リージョン | ハイブリッド デプロイは現在利用でき、次の Azure リージョンでのみサポートされています。 - 米国中部 -東アジア - 米国東部 - 米国中北部 -東南アジア - スウェーデン中部 - 英国南部 - 西ヨーロッパ - 米国西部 |
| サポートされている Azure Arc 対応 Kubernetes クラスター | - Azure Arc 対応 Kubernetes クラスター - Azure Local 上の Azure Arc 対応 Kubernetes クラスター (旧称 Azure Stack HCI) - Windows Server 上の Azure Arc 対応 Kubernetes クラスター |
| シングルテナントの Azure Logic Apps (Standard) および関連する Azure サービスで使用できるサポートされていない機能 | - デプロイ スロット - Azure Business プロセスの追跡 - Azure portal の [サポートとトラブルシューティング ] のリソース正常性 - コネクタ操作のマネージド ID 認証。 詳細については、「 ハイブリッド展開ワークフローを作成するための制限事項」を参照してください。 |
前提条件
Azure アカウントとサブスクリプション。 サブスクリプションをお持ちでない場合には、無料の Azure アカウントにサインアップしてください。
AKS の中心概念に関する基本的な理解
Azure Arc 対応 Kubernetes 上の Azure Container Apps に関する技術的な要件。Azure Container Registry などのパブリックまたはプライベート コンテナー レジストリへのアクセスが含まれます。
請求書
課金のしくみについては、「 Standard (ハイブリッドデプロイ)」を参照してください。
Kubernetes クラスターを作成する
Standard ロジック アプリを Azure Container Apps 接続環境内の Azure Arc 対応 Kubernetes クラスターにオンプレミス リソースとしてデプロイするには、まず Kubernetes クラスターが必要です。 このクラスターは、後で Azure Arc に接続して Azure Arc 対応 Kubernetes クラスターになるようにします。
Kubernetes クラスターには、ストレージ プロバイダーとして後で作成する SQL データベースと、成果物ストレージのために後で作成するサーバー メッセージ ブロック ファイル共有との受信および送信接続が必要です。 これらのリソースは、同じネットワーク内に存在する必要があります。
注
また、Windows Server 上の Azure Local または Kubernetes クラスターに Kubernetes クラスターを作成し 、 このガイドの手順を適用してクラスターを Azure Arc に接続し、接続環境を設定することもできます。 Windows Server 上の Azure Local と AKS の詳細については、次のリソースを参照してください。
作成する Kubernetes クラスターの次の環境変数を設定します。
SUBSCRIPTION="<Azure-subscription-ID>" AKS_CLUSTER_GROUP_NAME="<aks-cluster-resource-group-name>" AKS_NAME="<aks-cluster-name>" LOCATION="eastus"パラメーター 必須 値 説明 予約 はい < Azure-subscription-ID> Azure サブスクリプションの ID AKS_CLUSTER_GROUP_NAME はい < AKS クラスター リソース グループ名> Kubernetes クラスターで使用する Azure リソース グループの名前。 この名前は、リージョン間で一意である必要があり、文字、数字、ハイフン (-)、アンダースコア (_)、かっこ (())、ピリオド (.) のみを含めることができます。
この例では、Hybrid-RG を使用します。AKS_NAME はい < aks-cluster-name> Kubernetes クラスターの名前。 場所 はい < Azure リージョン> Azure Arc 対応 Kubernetes 上の Azure Container Apps をサポートする Azure リージョン。
この例では、eastus を使います。Azure Cloud Shell の Bash 環境を使用するか、またはコンピューターにインストールされている Azure CLI をローカルで使用して、次のコマンドを実行します。
注
max-count および min-count ノードの値を負荷要件に基づいて必ず変更してください。
az login az account set --subscription $SUBSCRIPTION az provider register --namespace Microsoft.KubernetesConfiguration --wait az provider register --namespace Microsoft.Kubernetes --wait az extension add --name k8s-extension --upgrade --yes az group create \ --name $AKS_CLUSTER_GROUP_NAME \ --___location $LOCATION az aks create \ --resource-group $AKS_CLUSTER_GROUP_NAME \ --name $AKS_NAME \ --enable-aad \ --generate-ssh-keys \ --enable-cluster-autoscaler \ --max-count 6 \ --min-count 1パラメーター 必須 値 説明 max countいいえ < 最大ノード値> enable-cluster-autoscalerオプションを含めるときに、オートスケーラーに使用するノードの最大数。 この値の範囲は 1 から 1000 までです。min countいいえ < min-nodes-value> enable-cluster-autoscalerオプションを含めるときに、オートスケーラーに使用するノードの最小数。 この値の範囲は 1 から 1000 までです。詳細については、次のリソースを参照してください。
Kubernetes クラスターを Azure Arc に接続する
Azure Arc 対応 Kubernetes クラスターを作成するには、Kubernetes クラスターを Azure Arc に接続します。
注
このセクション以降、接続環境の作成までの手順は、Azure/logicapps という名前の GitHub リポジトリにある EnvironmentSetup.ps1 という名前のスクリプトで見つけることができます。 このスクリプトを実際の要件やシナリオを満たすように変更して使用できます。
このスクリプトは署名されていないため、スクリプトを実行する前に、次の Azure PowerShell コマンドを管理者として実行して実行ポリシーを設定してください。
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
詳細については、「Set-ExecutionPolicy」を参照してください。
次の Azure CLI 拡張機能をインストールします。
az extension add --name connectedk8s --upgrade --yes az extension add --name k8s-extension --upgrade --yes az extension add --name customlocation --upgrade --yes az extension add --name containerapp --upgrade --yes詳細については、次のリソースを参照してください。
次の必要な名前空間を登録します。
az provider register --namespace Microsoft.ExtendedLocation --wait az provider register --namespace Microsoft.Kubernetes --wait az provider register --namespace Microsoft.KubernetesConfiguration --wait az provider register --namespace Microsoft.App --wait az provider register --namespace Microsoft.OperationalInsights --wait詳細については、次のリソースを参照してください。
kubectl という名前の Kubernetes コマンド ライン インターフェイス (CLI) をインストールします。
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1')) choco install kubernetes-cli -y詳細については、次のリソースを参照してください。
kubeconfig ファイルを取得して、クラスターへの接続をテストします。
az aks get-credentials \ --resource-group $AKS_CLUSTER_GROUP_NAME \ --name $AKS_NAME \ --admin kubectl get ns既定では、kubeconfig ファイルはパス ~/.kube/config に保存されます。このコマンドは今回の Kubernetes クラスターの例に適用され、他の種類の Kubernetes クラスターでは異なります。
詳細については、次のリソースを参照してください。
Helm という名前の Kubernetes パッケージ マネージャーをインストールします。
choco install kubernetes-helm詳細については、次のリソースを参照してください。
- ヘルム
- choco install kubernetes-helm のコマンドを使用して Kubernetes Helm をインストールします。
次の Helm コマンドを使用して SMB ドライバーをインストールします。
指定されたグラフ リポジトリを追加し、使用可能なグラフに関する最新情報を入手して、指定されたグラフ アーカイブをインストールします。
helm repo add csi-driver-smb https://raw.githubusercontent.com/kubernetes-csi/csi-driver-smb/master/charts helm repo update helm install csi-driver-smb csi-driver-smb/csi-driver-smb --namespace kube-system --version v1.15.0詳細については、次のリソースを参照してください。
- helm repo add（Helmでリポジトリを追加するためのコマンド）
- helm repo update コマンドを使用して、Helm リポジトリを更新します。
- helm install コマンドの実行
次の kubectl コマンドを実行して、SMB ドライバーがインストールされていることを確認します。これにより、smb.csi.k8s.io が一覧表示されるはずです。
kubectl get csidriver詳細については、 kubectl get を参照してください。
Kubernetes クラスターを Azure Arc に接続する
Kubernetes クラスターのデプロイに基づいて、次の環境変数を設定して、Azure Arc 対応クラスターとリソースを含む Azure リソース グループに使用する名前を指定します。
GROUP_NAME="<Azure-Arc-cluster-resource-group-name>"パラメーター 必須 値 説明 GROUP_NAME はい < Azure-Arc-cluster-resource-group-name> Azure Arc 対応クラスターとその他のリソース (Azure Container Apps 拡張機能、カスタムの場所、Azure Container Apps 接続環境など) で使用する Azure リソース グループの名前。 この名前は、リージョン間で一意である必要があり、文字、数字、ハイフン (-)、アンダースコア (_)、かっこ (())、ピリオド (.) のみを含めることができます。
この例では、Hybrid-Arc-RG を使用します。Azure Arc 対応クラスターとリソースのための Azure リソース グループを作成します。
az group create \ --name $GROUP_NAME \ --___location $LOCATION詳細については、次のリソースを参照してください。
Azure Arc 対応 Kubernetes クラスターの名前を指定するには、次の環境変数を設定します。
CONNECTED_CLUSTER_NAME="$GROUP_NAME-cluster"パラメーター 必須 値 説明 接続されたクラスター名 はい < Azure-Arc-cluster-resource-group-name>-cluster Azure Arc 対応クラスターに使用する名前。 この名前は、リージョン間で一意である必要があり、文字、数字、ハイフン (-)、アンダースコア (_)、かっこ (())、ピリオド (.) のみを含めることができます。
この例では、Hybrid-Arc-RG-cluster を使用します。以前に作成された Kubernetes クラスターを Azure Arc に接続します。
az connectedk8s connect \ --resource-group $GROUP_NAME \ --name $CONNECTED_CLUSTER_NAME詳細については、次のリソースを参照してください。
Azure Arc と Kubernetes クラスターの間の接続を検証します。
az connectedk8s show \ --resource-group $GROUP_NAME \ --name $CONNECTED_CLUSTER_NAMEこの出力に provisioningState プロパティ値が Succeeded に設定されていないことが示されている場合は、1 分後に、このコマンドをもう一度実行します。
詳細については、次のリソースを参照してください。
Azure Log Analytics ワークスペースを作成する
Azure Arc 対応 Kubernetes クラスターで実行されるアプリに関するログへのアクセスを提供する、省略可能ではあるが推奨される Azure Log Analytics ワークスペースを作成できます。
Log Analytics ワークスペースの名前を指定するには、次の環境変数を設定します。
WORKSPACE_NAME="$GROUP_NAME-workspace"パラメーター 必須 値 説明 WORKSPACE_NAME はい < Azure-Arc-cluster-resource-group-name>-ワークスペース Log Analytics ワークスペースに使用する名前。 この名前は、リソース グループ内で一意である必要があります。
この例では、Hybrid-Arc-RG-workspace を使用します。Log Analytics ワークスペースを作成します。
az monitor log-analytics workspace create \ --resource-group $GROUP_NAME \ --workspace-name $WORKSPACE_NAME詳細については、次のリソースを参照してください。
Log Analytics ワークスペースの Base64 でエンコードされた ID と共有キーを取得します。 これらの値は後の手順に必要です。
LOG_ANALYTICS_WORKSPACE_ID=$(az monitor log-analytics workspace show \ --resource-group $GROUP_NAME \ --workspace-name $WORKSPACE_NAME \ --query customerId \ --output tsv) LOG_ANALYTICS_WORKSPACE_ID_ENC=[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($LOG_ANALYTICS_WORKSPACE_ID)) LOG_ANALYTICS_KEY=$(az monitor log-analytics workspace get-shared-keys \ --resource-group $GROUP_NAME \ --workspace-name $WORKSPACE_NAME \ --query primarySharedKey \ --output tsv) LOG_ANALYTICS_KEY_ENC=[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($LOG_ANALYTICS_KEY))パラメーター 必須 値 説明 ログ解析作業スペースID はい Log Analytics ワークスペースの ID。 LOG_ANALYTICS_WORKSPACE_ID_ENC はい Log Analytics ワークスペースの Base64 でエンコードされた ID。 LOG_ANALYTICS_KEY はい Log Analytics ワークスペースの共有キー。 LOG_ANALYTICS_ENC はい Log Analytics ワークスペースの Base64 でエンコードされた共有キー。 詳細については、次のリソースを参照してください。
Azure Container Apps 拡張機能を作成してインストールする
次に、Azure Arc 対応 Kubernetes クラスターをオンプレミス リソースとして使用して、Azure Container Apps 拡張機能を作成してインストールします。
重要
Azure Container Apps 拡張機能を作成してインストールする前に、AKS on Azure Local にデプロイする場合は、必ず HAProxy またはカスタム ロード バランサーを設定してください。
次の環境変数を次の値に設定します。
EXTENSION_NAME="logicapps-aca-extension" NAMESPACE="logicapps-aca-ns" CONNECTED_ENVIRONMENT_NAME="<connected-environment-name>"パラメーター 必須 値 説明 EXTENSION_NAME はい logicapps-aca-extension Azure Container Apps 拡張機能の名前。 Namespace はい logicapps-aca-ns リソースをプロビジョニングするクラスター名前空間。 接続された環境名 はい < 接続された環境名> Azure Container Apps 接続環境に使用する一意の名前。 この名前は、Azure Container Apps 接続環境で作成、デプロイ、ホストする Standard ロジック アプリのドメイン名の一部になります。 Azure Arc 対応 Kubernetes クラスターに対して有効になっている Log Analytics で拡張機能を作成してインストールします。 この拡張機能に後で Log Analytics を追加することはできません。
az k8s-extension create \ --resource-group $GROUP_NAME \ --name $EXTENSION_NAME \ --cluster-type connectedClusters \ --cluster-name $CONNECTED_CLUSTER_NAME \ --extension-type 'Microsoft.App.Environment' \ --release-train stable \ --auto-upgrade-minor-version true \ --scope cluster \ --release-namespace $NAMESPACE \ --configuration-settings "Microsoft.CustomLocation.ServiceAccount=default" \ --configuration-settings "appsNamespace=${NAMESPACE}" \ --configuration-settings "keda.enabled=true" \ --configuration-settings "keda.logicAppsScaler.enabled=true" \ --configuration-settings "keda.logicAppsScaler.replicaCount=1" \ --configuration-settings "containerAppController.api.functionsServerEnabled=true" \ --configuration-settings "envoy.externalServiceAzureILB=false" \ --configuration-settings "functionsProxyApiConfig.enabled=true" \ --configuration-settings "clusterName=${CONNECTED_ENVIRONMENT_NAME}" \ --configuration-settings "envoy.annotations.service.beta.kubernetes.io/azure-load-balancer-resource-group=${GROUP_NAME}" \ --configuration-settings "logProcessor.appLogs.destination=log-analytics" \ --configuration-protected-settings "logProcessor.appLogs.logAnalyticsConfig.customerId=${LOG_ANALYTICS_WORKSPACE_ID_ENC}" \ --configuration-protected-settings "logProcessor.appLogs.logAnalyticsConfig.sharedKey=${LOG_ANALYTICS_KEY_ENC}"パラメーター 必須 説明 Microsoft.CustomLocation.ServiceAccount はい カスタムの場所用に作成されたサービス アカウントです。
推奨事項: この値を default に設定します。appsNamespace はい アプリの定義とリビジョンを作成するために使用する名前空間。 この値は、Azure Container Apps 拡張機能のリリース名前空間と一致している必要があります。 clusterName はい 拡張機能のために作成する Azure Container Apps 拡張機能 Kubernetes 環境の名前。 keda.enabled はい Kubernetes イベント ドリブン自動スケーリング (KEDA) を有効にします。 この値は必須であり、true に設定する必要があります。 keda.logicAppsScaler.enabled はい KEDA で Azure Logic Apps スケーラーを有効にします。 この値は必須であり、true に設定する必要があります。 keda.logicAppsScaler.replicaCount はい 起動するロジック アプリ スケーラーの初期数。 この既定値は 1 に設定されています。 環境内にロジック アプリが存在しない場合、この値は 0 にスケールアップまたはスケールダウンします。 containerAppController.api.functionsServerEnabled はい ロジック アプリのワークフロー トリガーを KEDA スケーリング オブジェクトに変換する役割を果たすサービスを有効にします。 この値は必須であり、true に設定する必要があります。 envoy.externalServiceAzureILB（エンボイ・エクスターナルサービス・アジュールILB） はい envoy が内部ロード バランサーまたはパブリック ロード バランサーのどちらとして機能するかを決定します。
- true: envoy は内部ロード バランサーとして機能します。 Azure Logic Apps ランタイムにはプライベート ネットワーク内でしかアクセスできません。
- false: envoy はパブリック ロード バランサーとして機能します。 Azure Logic Apps ランタイムにパブリック ネットワーク経由でアクセスできます。functionsProxyApiConfig.enabled はい Azure portal から Azure Logic Apps ランタイムへの API アクセスを容易にするプロキシ サービスを有効にします。 この値は必須であり、true に設定する必要があります。 envoy.annotations.service.beta.kubernetes.io/azure-load-balancer-resource-group はい。ただし、基になるクラスターが Azure Kubernetes Service である場合のみです。 Kubernetes クラスターが存在するリソース グループの名前。 logProcessor.appLogs.destination いいえ アプリケーション ログに使用する宛先。 この値は、log-analytics または none (これにより、ログ記録が無効になります) のどちらかです。 logProcessor.appLogs.logAnalyticsConfig.customerId はい。ただし、logProcessor.appLogs.destination が log-analytics に設定されている場合のみです。 Log Analytics ワークスペースの Base64 でエンコードされた ID。 このパラメーターは、必ず保護された設定として構成してください。 logProcessor.appLogs.logAnalyticsConfig.sharedKey はい。ただし、logProcessor.appLogs.destination が log-analytics に設定されている場合のみです。 Log Analytics ワークスペースの Base64 でエンコードされた共有キー。 このパラメーターは、必ず保護された設定として構成してください。 詳細については、次のリソースを参照してください。
Azure Container Apps 拡張機能の ID 値を後で使用するために保存します。
EXTENSION_ID=$(az k8s-extension show \ --cluster-type connectedClusters \ --cluster-name $CONNECTED_CLUSTER_NAME \ --resource-group $GROUP_NAME \ --name $EXTENSION_NAME \ --query id \ --output tsv)パラメーター 必須 値 説明 EXTENSION_ID はい < extension-ID> Azure Container Apps 拡張機能の ID。 詳細については、次のリソースを参照してください。
続行する前に、拡張機能が完全にインストールされるまで待ちます。 ターミナル セッションがインストール完了まで待つようにするには、次のコマンドを実行します。
az resource wait \ --ids $EXTENSION_ID \ --custom "properties.provisioningState!='Pending'" \ --api-version "2020-07-01-preview"詳細については、次のリソースを参照してください。
カスタムの場所を作成する
次の環境変数を指定された値に設定します。
CUSTOM_LOCATION_NAME="my-custom-___location" CONNECTED_CLUSTER_ID=$(az connectedk8s show \ --resource-group $GROUP_NAME \ --name $CONNECTED_CLUSTER_NAME \ --query id \ --output tsv)パラメーター 必須 値 説明 CUSTOM_LOCATION_NAME はい my-custom-___location カスタムの場所に使用する名前。 CONNECTED_CLUSTER_ID はい < Azure-Arc-cluster-ID> Azure Arc 対応 Kubernetes クラスターの ID。 詳細については、次のリソースを参照してください。
カスタムの場所を作成する:
az customlocation create \ --resource-group $GROUP_NAME \ --name $CUSTOM_LOCATION_NAME \ --host-resource-id $CONNECTED_CLUSTER_ID \ --namespace $NAMESPACE \ --cluster-extension-ids $EXTENSION_ID \ --___location $LOCATION注
クラスターでのカスタムの場所の作成で問題が発生するときは、クラスターで "カスタムの場所" 機能を有効にすることが必要になる場合があります。 この手順は、サービス プリンシパルを使用して Azure CLI にサインインした場合、またはクラスター リソースに対するアクセス許可が制限された Microsoft Entra ユーザーとしてサインインした場合に必要です。
詳細については、次のリソースを参照してください。
カスタムの場所が正常に作成されたことを確認します。
az customlocation show \ --resource-group $GROUP_NAME \ --name $CUSTOM_LOCATION_NAMEこの出力に provisioningState プロパティ値が Succeeded に設定されていないことが示されている場合は、1 分後に、このコマンドをもう一度実行します。
カスタムの場所 ID を後の手順で使用するために保存します。
CUSTOM_LOCATION_ID=$(az customlocation show \ --resource-group $GROUP_NAME \ --name $CUSTOM_LOCATION_NAME \ --query id \ --output tsv)パラメーター 必須 値 説明 CUSTOM_LOCATION_ID はい < my-custom-___location-ID> カスタムの場所の ID。 詳細については、次のリソースを参照してください。
Azure Container Apps 接続環境を作成する
次に、Standard ロジック アプリで使用する Azure Container Apps 接続環境を作成します。
az containerapp connected-env create \
--resource-group $GROUP_NAME \
--name $CONNECTED_ENVIRONMENT_NAME \
--custom-___location $CUSTOM_LOCATION_ID \
--___location $LOCATION
詳細については、次のリソースを参照してください。
Azure Local での Kubernetes クラスターの CoreDNS の更新
Azure Kubernetes クラスターが Azure Local でホストされている場合は、クラスターの CoreDNS 構成を手動で更新する必要があります。 この手順では、Azure Kubernetes 名前空間に新しい 構成マップ を追加します。 これに対し、Kubernetes クラスターが Azure でホストされている場合、Azure Logic Apps はこの手順を自動的に完了します。 ただし、他の場所でホストされているクラスターの場合は、この手順を手動で完了する必要があります。
詳しくは、次のドキュメントをご覧ください。
- Kubernetes 用 CoreDNS
- Azure Kubernetes Service の CoreDNS をカスタマイズする
- Kubernetes の ConfigMaps
- 名前空間 - Azure Kubernetes Service の主要な概念
CoreDNS 構成を更新するには、シナリオのオプションを使用して次の Azure CLI コマンドを実行します。
az containerapp arc setup-core-dns
| パラメーター | 必須 | 説明 |
|---|---|---|
--distro |
はい | CoreDNS 構成の更新に使用するサポートされるディストリビューション。 許可される値: AksAzureLocal |
--kube-config |
いいえ | Kubernetes クラスターにアクセスするための構成パラメーターを含む (kubeconfig ファイル) へのパス。 |
--kube-context |
いいえ | クラスターのオンプレミス ホストからの kubeconfig コンテキスト。 Kubernetes では、 コンテキスト によって Kubernetes クラスターとの通信方法が定義されます。 |
skip-ssl-verification |
いいえ | クラスター接続の SSL 検証をスキップします。 |
--yes -y |
いいえ | 確認を求めるプロンプトを表示しません。 |
グローバル パラメーターなどの詳細については、 az containerapp arc setup-core-dns を参照してください。
例示
Azure Local の CoreDNS 構成を設定します。
az containerapp arc setup-core-dns --distro AksAzureLocalKubernetes 構成ファイルと Kubernetes コンテキストを使用して、Azure Local の CoreDNS 構成を設定します。
az containerapp arc setup-core-dns --distro AksAzureLocal --kube-config <kubeconfig-file-path> --kube-context <kubeconfig-context-name>
SQL Server ストレージ プロバイダーを作成する
ハイブリッド デプロイ モデルの標準ロジック アプリ ワークフローでは、ワークフローと Azure Logic Apps ランタイムによって使用されるデータのストレージ プロバイダーとして SQL データベースが使用されます (ワークフローの実行履歴、入力、出力など)。
この SQL データベースには Kubernetes クラスターとの受信および送信接続が必要なため、これらのリソースは同じネットワーク内に存在する必要があります。
次のいずれかの SQL Server エディションを設定します。
- オンプレミスの SQL Server
- Azure SQL Database
- Azure SQL Managed Instance
- Azure Arcによって有効化された SQL Server
詳細については、SQL データベース ストレージを Standard ロジック アプリ ワークフロー用に設定する方法に関するページを参照してください。
この SQL データベースが Arc 対応 Kubernetes クラスターおよび SMB ファイル共有と同じネットワーク内にあることを確認します。
作成した SQL データベースの接続文字列を見つけて保存します。
成果物ストレージの SMB ファイル共有を設定する
ロジック アプリ (コンテナー アプリ) リソースのマップ、スキーマ、アセンブリなどの成果物を格納するには、サーバー メッセージ ブロック (SMB) プロトコルを使用するファイル共有が必要です。
SMB ファイル共有を設定するには、管理者アクセスが必要です。
この SMB ファイル共有は、Kubernetes クラスターおよび SQL データベースと同じネットワーク内に存在する必要があります。
この SMB ファイル共有には、Kubernetes クラスターとの受信および送信接続が必要です。 Azure 仮想ネットワークの制限を有効にしている場合は、そのファイル共有が Kubernetes クラスターと同じ仮想ネットワークまたはピアリングされた仮想ネットワーク内に存在することを確認してください。
複数のロジック アプリに同じ正確なファイル共有パスを使用しないでください。
ロジック アプリごとに別の SMB ファイル共有を使用することも、同じ SMB ファイル共有内のフォルダーが入れ子になっていない限り、それらの異なるフォルダーを使用することもできます。 たとえば、あるロジック アプリでルート パスを使用し、その後に別のロジック アプリでサブフォルダーを使用することはしないでください。
Visual Studio Code を使用してロジック アプリをデプロイするには、Visual Studio Code を含むローカル コンピューターがファイル共有にアクセスできることを確認してください。
Windows 上で SMB ファイル共有を設定する
SMB ファイル共有が、そのファイル共有をマウントするクラスターと同じ仮想ネットワーク内に存在することを確認してください。
Windows で、共有するフォルダーに移動し、ショートカット メニューを開いて [プロパティ] を選択します。
[共有] タブで、[共有] を選択します。
開かれたボックスで、ファイル共有にアクセスできるようにしたい人物を選択します。
[共有] を選択し、ネットワーク パスのリンクをコピーします。
ローカル コンピューターがドメインに接続されていない場合は、ネットワーク パス内のコンピューター名を IP アドレスに置き換えます。
その IP アドレスを後でホスト名として使用するために保存します。
SMB ファイル共有として Azure Files を設定する
別の方法として、テストの目的で、SMB ファイル共有として Azure Files を使用できます。 SMB ファイル共有が、そのファイル共有をマウントするクラスターと同じ仮想ネットワーク内に存在することを確認してください。
ストレージ アカウントのメニューの [データ ストレージ] で、[ファイル共有] を選択します。
[ファイル共有] ページのツール バーから、[+ ファイル共有] を選択し、SMB ファイル共有に必要な情報を指定します。
デプロイが完了したら、[リソースに移動] を選択します。
ファイル共有のメニューで、[概要] を選択します (選択されていない場合)。
[概要] ページのツール バーで、[接続] を選択します。 [接続] ペインで、[スクリプトの表示] を選択します。
次の値をコピーし、それらを後で使用するために安全な場所に保存します。
- ファイル共有のホスト名 (mystorage.file.core.windows.net など)
- ファイル共有パス
-
localhost\を含まないユーザー名 - パスワード
[概要] ページのツール バーで、[+ ディレクトリの追加] を選択し、ディレクトリに使用する名前を指定します。 この名前を後で使用するために保存します。
これらの保存された値は、ロジック アプリ リソースをデプロイするときに SMB ファイル共有の情報を指定するために必要です。
詳細については、SMB Azure ファイル共有の作成に関するページを参照してください。
SMB ファイル共有の接続を確認する
Arc 対応 Kubernetes クラスターと SMB ファイル共有の間の接続をテストしたり、ファイル共有が正しく設定されていることを確認したりするには、次の手順に従います。
SMB ファイル共有が同じクラスター上にない場合は、Arc 対応 Kubernetes クラスターから SMB ファイル共有が存在する仮想マシンへの ping 操作が機能することを確認します。 ping 操作が機能することを確認するには、次の手順に従います。
Arc 対応 Kubernetes クラスターで、任意の Linux イメージ (BusyBox や Ubuntu など) を実行するテスト ポッドを作成します。
ポッド内のコンテナーに移動し、次の Linux コマンドを実行して iputils-ping パッケージをインストールします。
apt-get update apt-get install iputils-ping
SMB ファイル共有が正しく設定されていることを確認するには、次の手順に従います。
同じ Linux イメージが含まれているテスト ポッドで、mnt/smb という名前のパスを持つフォルダーを作成します。
mnt フォルダーを含むルートまたはホーム ディレクトリに移動します。
次のコマンドを実行します。
- mount -t cifs //{ip-address-smb-computer}/{file-share-name}/mnt/smb -o username={user-name}, password={password}
成果物が正しくアップロードされることを確認するには、SMB ファイル共有パスに接続し、成果物ファイルがデプロイ中に指定した正しいフォルダー内に存在するかどうかを確認します。
ハイブリッド展開のパフォーマンスを最適化する
ハイブリッドデプロイで Standard ロジック アプリの効率とパフォーマンスを最大化するには、最適化に関する貴重な洞察を得ることができるように、CPU、メモリ割り当て、スケーリング メカニズムなどの主要な側面を分析して評価する方法を理解する必要があります。 その他の重要な要素には、基になる Kubernetes インフラストラクチャ、SQL 構成、スケーリングのセットアップが含まれます。これは、ワークフローの効率と全体的なパフォーマンスに大きな影響を与える可能性があります。 詳細については、「 ハイブリッド 展開のパフォーマンス分析と最適化の推奨事項」を参照してください。