次の方法で共有


Azure Synapse Analytics ワークスペースの継続的インテグレーションとデリバリー

継続的インテグレーション (CI) は、チーム メンバーが変更をバージョン コントロールにコミットするたびに行われるコードのビルドとテストを自動化するプロセスです。 継続的デリバリー (CD) は、複数のテスト環境またはステージング環境から運用環境にビルド、テスト、構成、デプロイを行うプロセスです。

Azure Synapse Analytics ワークスペースでは、CI/CD を使用して、すべてのエンティティをある環境 (開発、テスト、運用) から別の環境に移動します。 ワークスペースを別のワークスペースに昇格するプロセスには 2 つの部分があります。 まず、Azure Resource Manager テンプレート (ARM テンプレート) を使用して、ワークスペースのリソース (プールとワークスペース) を作成または更新します。 次に、Azure DevOps または GitHub で Synapse Workspace Deployment ツールを使用して、SQL スクリプトとノートブック、Spark ジョブ定義、パイプライン、データセット、その他成果物のような成果物を移行します。

この記事では、Azure DevOps のリリース パイプラインと GitHub Actions を使用して、複数の環境への Azure Synapse ワークスペースのデプロイを自動化する方法について説明します。

必須コンポーネント

複数の環境への Azure Synapse ワークスペースのデプロイを自動化するには、次の前提条件と構成が満たされている必要があります。 好みや既存のセットアップに従って、Azure DevOps または GitHub のいずれかの使用を選択することができます。

Azure DevOps

Azure DevOps を使用している場合:

GitHub

GitHub を使用している場合:

  • Azure Synapse ワークスペースの成果物とワークスペース テンプレートを含む GitHub リポジトリを作成します。
  • セルフホステッド ランナーを作成したこと、または GitHub ホスト ランナーを使用していることを確認します。

Microsoft Entra ID

  • サービス プリンシパルを使用している場合は、Microsoft Entra ID でデプロイに使用するサービス プリンシパルを作成します。
  • マネージド ID を使用している場合は、Azure の VM でシステム割り当てマネージド ID をエージェントまたはランナーとして有効にし、Synapse 管理者として Azure Synapse Studio に追加する必要があります。
  • Microsoft Entra 管理者ロール使用して、これらのアクションを完了します。

Azure Synapse Analytics

Note

次の前提条件は、同じパイプライン、ARM テンプレート、または Azure CLI を使用して自動化およびデプロイできますが、この記事ではその手順を説明していません。

  • 開発に使用される "ソース" ワークスペースは、Azure Synapse Studio の Git リポジトリを使用して構成する必要があります。 詳細については、「Azure Synapse Studio でのソース管理」を参照してください。

  • デプロイ先の空のワークスペースをセットアップします。

    1. 新しい Azure Synapse ワークスペースを作成します。
    2. サービス プリンシパルに、新しい Synapse ワークスペースに対する次のアクセス許可を付与します。
      • Microsoft.Synapse/workspaces/integrationruntimes/write
      • Microsoft.Synapse/workspaces/operationResults/read
      • Microsoft.Synapse/workspaces/read
    3. このワークスペースでは、Git リポジトリ接続を構成しないでください。
    4. Azure Synapse ワークスペースで、 [Studio]>[管理]>[アクセスの制御] に移動します。 “Synapse Artifact Publisher” をサービス プリンシパルに割り当てます。 デプロイ パイプラインでマネージド プライベート エンドポイントをデプロイする必要がある場合は、代わりに "Synapse 管理者" を割り当てます。
    5. リンクされているサービスを使用するとき、その接続情報が Azure Key Vault に格納されている場合、キー コンテナーを環境別に保持することが推奨されます。 キー コンテナーごとに個別のアクセス許可レベルを構成することもできます。 たとえば、運用環境のシークレットへのアクセス許可をチーム メンバーに持たせたくない場合があります。 このアプローチに従う場合は、すべてのステージで同じシークレット名を保持することをお勧めします。 同じシークレット名を保持する場合、CI/CD 環境全体で各接続文字列をパラメーター化する必要はありません。変わるのは別個のパラメーターであるキー コンテナーの名前だけだからです。

その他の前提条件

  • Spark プールとセルフホステッド統合ランタイムは、ワークスペースのデプロイ タスクでは作成されません。 セルフホステッド統合ランタイムを使用するリンク サービスがある場合は、新しいワークスペースにランタイムを手動で作成します。
  • 開発ワークスペースの項目が特定のプールにアタッチされている場合は、パラメーター ファイルでターゲットのワークスペースのプールに同じ名前を作成またはパラメーター化したことを確認します。
  • プロビジョニングされた SQL プールをデプロイしようとしたときに一時停止した場合、デプロイは失敗する可能性があります。

詳細については、Azure Synapse Analytics での CI/CD パート 4 - リリース パイプラインに関するページを参照してください。

Azure DevOps にリリース パイプラインを設定する

このセクションでは、Azure DevOps で Azure Synapse ワークスペースをデプロイする方法について説明します。

  1. Azure DevOps で、リリース用に作成したプロジェクトを開きます。

  2. 左側のメニューで、 [パイプライン]>[リリース] を選択します。

    Azure DevOps のメニューで、[パイプライン]、[リリース] の順に選択したことを示すスクリーンショット。

  3. [新しいパイプライン] を選択します。 既存のパイプラインがある場合は、 [新規]>[新しいリリース パイプライン] を選択します。

  4. [空のジョブ] テンプレートを選択します。

    [空のジョブ] テンプレートを選択したことを示すスクリーンショット。

  5. [ステージ名] に、環境の名前を入力します。

  6. [成果物の追加] を選択し、開発環境の Azure Synapse Studio で構成した Git リポジトリを選択します。 プールとワークスペースの ARM テンプレートを管理する Git リポジトリを選択します。 ソースとして GitHub を使用する場合は、GitHub アカウントとプル リポジトリのサービス接続を作成します。 詳細については、サービスの接続に関する記事を参照してください。

    新しい成果物の発行ブランチを追加するために GitHub を選択したことを示すスクリーンショット。

  7. リソース ARM テンプレート ブランチを選択します。 [既定のバージョン] では [既定のブランチからの最新バージョン] を選択します。

    リソース ARM テンプレート ブランチを設定したことを示すスクリーンショット。

  8. 成果物の [既定のブランチ] では、リポジトリの発行ブランチ、または Synapse 成果物を含む他の発行以外のブランチを選択します。 既定では、発行ブランチは workspace_publish です。 [既定のバージョン] では [既定のブランチからの最新バージョン] を選択します。

    成果物のブランチの設定を示すスクリーンショット。

リソースを作成および更新するための ARM テンプレートのステージ タスクを設定する

Azure Synapse ワークスペース、Spark および SQL プール、キー コンテナーなどのリソースをデプロイするための ARM テンプレートがある場合は、それらのリソースを作成または更新するための Azure Resource Manager デプロイ タスクを追加します。

  1. ステージ ビューで、 [ステージ タスクを表示します] を選択します。

    ステージ ビューの設定を示すスクリーン ショット。

  2. 新しいタスクを作成します。 [ARM テンプレートのデプロイ] を探して [追加] を選択します。

  3. デプロイの [タスク] タブでは、ワークスペースのサブスクリプション、リソース グループ、場所を選択します。 必要であれば資格情報を指定します。

  4. [アクション][リソース グループの作成または更新] を選択します。

  5. [テンプレート] で省略記号 ( [...] ) ボタンを選択します。 ワークスペースの ARM テンプレートに移動します。

  6. [Template parameters](テンプレート パラメーター) については、[…] を選択して、パラメーター ファイルを選択します。

    ワークスペースとプールのデプロイを示すスクリーンショット。

  7. [テンプレート パラメーターのオーバーライド] で、 [...] を選択し、ワークスペースに使用するパラメーター値を入力します。

  8. [配置モード][増分] を選択します。

  9. (省略可能) 付与のために Azure PowerShell を追加して、ワークスペースのロール割り当てを更新します。 リリース パイプラインを使用して Azure Synapse ワークスペースを作成する場合は、パイプラインのサービス プリンシパルが既定のワークスペース管理者として追加されます。PowerShell を実行して、他のアカウントにワークスペースへのアクセスを許可することができます。

    PowerShell スクリプトの実行によるアクセス許可の付与を示すスクリーンショット。

警告

完全なデプロイ モードでは、新しい ARM テンプレートで指定されていないリソース グループのリソースは "削除されます"。 詳しくは、「Azure Resource Manager のデプロイ モード」を参照してください。

Azure Synapse 成果物のデプロイのステージ タスクを設定する

Synapse ワークスペース デプロイ拡張機能を使用して、Azure Synapse ワークスペース内のその他の項目をデプロイします。 デプロイできる項目には、データセット、SQL スクリプトとノートブック、Spark ジョブ定義、統合ランタイム、データ フロー、資格情報、ワークスペース内のその他の成果物が含まれます。

展開拡張機能をインストールして追加する

  1. Visual Studio Marketplace で拡張機能を探して取得します。

    Visual Studio Marketplace に表示された Synapse ワークスペース デプロイ拡張機能を示すスクリーンショット。

  2. 拡張機能をインストールする Azure DevOps 組織を選択します。

    Synapse ワークスペース デプロイ拡張機能をインストールする組織の選択を示すスクリーンショット。

  3. Azure DevOps パイプラインのサービス プリンシパルにサブスクリプションのアクセス許可が付与され、ワークスペースの Synapse ワークスペース管理者として割り当てられていることを確認します。

  4. 新しいタスクを作成するには、 [Synapse ワークスペースのデプロイ] を探して [追加] を選択します。

    Synapse ワークスペースのデプロイを検索してタスクを作成することを示すスクリーンショット。

展開タスクを構成する

デプロイ タスクでは、3 種類の操作 (検証のみ、デプロイと検証、デプロイ) がサポートされています。

Note

このワークスペース デプロイ拡張機能には下位互換性がありません。 最新バージョンがインストールされ、使用されていることを確認してください。 リリース ノートは、Azure DevOps の概要と GitHub アクションの最新バージョンで読むことができます。

検証は、タスクを使用して発行以外のブランチ内の Synapse 成果物を検証し、ワークスペース テンプレートとパラメーター テンプレート ファイルを生成することです。 検証操作は YAML パイプラインでのみ機能します。 サンプルの YAML ファイルを以下に示します。

   pool:
     vmImage: ubuntu-latest

   resources:
     repositories:
     - repository: <repository name>
       type: git
       name: <name>
       ref: <user/collaboration branch>

   steps:
     - checkout: <name>
     - task: Synapse workspace deployment@2
       continueOnError: true    
       inputs:
         operation: 'validate'
         ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
         TargetWorkspaceName: '<target workspace name>'    

検証とデプロイを使用して、成果物のルート フォルダーを含む発行以外のブランチからワークスペースを直接デプロイできます。

Note

操作の種類で [検証] または [検証とデプロイ] が選ばれている場合、デプロイ タスクではエンドポイント web.azuresynapse.net から依存関係 JS ファイルをダウンロードする必要があります。 VM でネットワーク ポリシーが有効な場合は、エンドポイント web.azuresynapse.net が許可されていることをご確認ください。

検証およびデプロイ操作は、クラシックと YAML の両パイプラインで機能します。 サンプルの YAML ファイルを以下に示します。

   pool:
     vmImage: ubuntu-latest

   resources:
     repositories:
     - repository: <repository name>
       type: git
       name: <name>
       ref: <user/collaboration branch>

   steps:
     - checkout: <name>
     - task: Synapse workspace deployment@2
       continueOnError: true    
       inputs:
         operation: 'validateDeploy'
         ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
         TargetWorkspaceName: 'target workspace name'
         azureSubscription: 'target Azure resource manager connection name'
         ResourceGroupName: 'target workspace resource group'
         DeleteArtifactsNotInTemplate: true
         OverrideArmParameters: >
           -key1 value1
           -key2 value2

展開 操作のデプロイの入力には、Synapse ワークスペース テンプレートとパラメーター テンプレートが含まれます。これは、ワークスペース発行ブランチで発行した後、または検証後に作成できます。 バージョン 1.x と同じです。

ユース ケースに基づいて操作の種類を選択できます。 デプロイの例を次に示します。

  1. このタスクでは、操作の種類として [デプロイ] を選択します。

    デプロイ操作の選択を示すスクリーンショット。

  2. タスクで、[テンプレート] の横にある […] を選択して、テンプレート ファイルを選択します。

  3. [Template parameters](テンプレート パラメーター) の横にある […] を選択して、テンプレート ファイルを選択します。

  4. ワークスペースの接続、リソース グループ、名前を選択します。

  5. [テンプレート パラメーターのオーバーライド] の横にある […] を選択します。 ワークスペースに使用するパラメーター値を入力します (リンク サービスで使用される接続文字列とアカウント キーを含む)。 詳細については、Azure Synapse Analytics の CI/CD に関する記事をご覧ください。

    ワークスペースの Synapse デプロイ タスクの設定を示すスクリーンショット。

  6. マネージド プライベート エンドポイントのデプロイは、バージョン 2.x でのみサポートされています。必ず適切なバージョンを選択し、[マネージド プライベート エンドポイントをテンプレートにデプロイする] をオンにしてください。

    Synapse デプロイ タスクでプライベート エンドポイントをデプロイするためにバージョン 2.x を選択することを示すスクリーンショット。

  7. トリガーを管理するには、トリガー トグルを使用して、デプロイ前にトリガーを停止できます。 また、デプロイ タスクの後にトリガーを再起動するタスクを追加できます。

    デプロイの前後でトリガーを管理することを示すスクリーンショット。

重要

CI/CD のシナリオでは、各環境内の統合ランタイム (IR) の種類は同じである必要があります。 たとえば、開発環境にセルフホステッド統合ランタイムがある場合、テストや運用などの他の環境環境でも、同じ統合ランタイムをセルフホステッドする必要があります。 同様に、複数のステージ間で統合ランタイムを共有している場合は、開発、テスト、運用など、すべての環境で、統合ランタイムをリンクおよびセルフホステッドする必要があります。

デプロイのリリースを作成する

すべての変更を保存したら、 [リリースの作成] を選択してリリースを手動で作成できます。 リリースの作成を自動化する方法の詳細については、Azure DevOps のリリース トリガーに関するページを参照してください。

[新しいリリース パイプライン] ペインが表示されているスクリーンショット。[リリースの作成] が強調表示されています。

GitHub Actions でリリースを設定する

このセクションでは、Azure Synapse ワークスペースのデプロイに GitHub Actions を使用して GitHub ワークフローを作成する方法について説明します。

Azure Resource Manager テンプレートの GitHub Actions を使用して、ワークスペースとコンピューティング プールのための ARM テンプレートの Azure へのデプロイを自動化できます。

ワークフロー ファイル

GitHub Actions ワークフローは、お使いのリポジトリの /.github/workflows/ パスの YAML (.yml) ファイルで定義します。 この定義には、ワークフローを構成するさまざまな手順とパラメーターが含まれます。

この .yml ファイルには 2 つのセクションがあります。

Section タスク
認証 1.サービス プリンシパルを定義します。
2. GitHub シークレットを作成します。
展開 ワークスペースの成果物をデプロイします。

GitHub Actions のシークレットを構成する

GitHub Actions のシークレットは、暗号化された環境変数です。 このリポジトリに対するコラボレーター権限を持つユーザーは、これらのシークレットを使用して、リポジトリ内のアクションを操作できます。

  1. GitHub リポジトリで、 [Settings](設定) タブを選択し、 [Secrets](シークレット)>[New repository secret](新しいリポジトリ シークレット) を選択します。

    新しいリポジトリ シークレットを作成するために選択する GitHub の要素を示すスクリーンショット。

  2. クライアント ID の新しいシークレットを追加し、デプロイにサービス プリンシパルを使用する場合は、新しいクライアント シークレットを追加します。 サブスクリプション ID とテナント ID をシークレットとして保存することもできます。

ワークフローを追加する

GitHub リポジトリで、 [Actions](アクション) に移動します。

  1. [Set up a workflow yourself](ワークフローを自分でセットアップする) を選択します。

  2. ワークフロー ファイルで、on: セクションの後にあるすべてのものを削除します。 たとえば、残りのワークフローは次の例のようになります。

    name: CI
    
    on:
    push:
        branches: [ master ]
    pull_request:
        branches: [ master ]
    
  3. ワークフローの名前を変更します。 [Marketplace](マーケットプレース) タブで Synapse ワークスペースのデプロイ アクションを検索して、アクションを追加します。

    [Marketplace]\(マーケットプレース\) タブでの Synapse ワークスペースのデプロイ タスクの検索を示すスクリーンショット。

  4. 必要な値とワークスペース テンプレートを設定します。

    name: workspace deployment
    
    on:
        push:
            branches: [ publish_branch ]
    jobs:
        release:
            # You also can use the self-hosted runners.
            runs-on: windows-latest
            steps:
            # Checks out your repository under $GITHUB_WORKSPACE, so your job can access it.
            - uses: actions/checkout@v2
            - uses: azure/synapse-workspace-deployment@release-1.0
            with:
              TargetWorkspaceName: 'target workspace name'
              TemplateFile: './path of the TemplateForWorkspace.json'
              ParametersFile: './path of the TemplateParametersForWorkspace.json'
              OverrideArmParameters: './path of the parameters.yaml'
              environment: 'Azure Public'
              resourceGroup: 'target workspace resource group'
              clientId: ${{secrets.CLIENTID}}
              clientSecret:  ${{secrets.CLIENTSECRET}}
              subscriptionId: 'subscriptionId of the target workspace'
              tenantId: 'tenantId'
              DeleteArtifactsNotInTemplate: 'true'
              managedIdentity: 'False'
    
  5. 変更をコミットする準備ができました。 [Start commit](コミットの開始) を選択し、タイトルを入力して、説明 (省略可能) を追加します。 次に、 [Commit new file](新しいファイルのコミット) を選択します。

    GitHub でのワークフローのコミットを示すスクリーンショット。

    ファイルは、リポジトリの .github/workflows フォルダーに表示されます。

    Note

    マネージド ID は、Azure 上のセルフホステッド VM でのみサポートされています。 ランナーをセルフホステッドに設定してください。 VM に対してシステム割り当てマネージド ID を有効にし、Synapse 管理者として Azure Synapse Studio に追加します。

デプロイを確認する

  1. GitHub リポジトリで、 [Actions](アクション) に移動します。

  2. ワークフローの実行の詳細なログを表示するには、最初の結果を開きます。

    GitHub のリポジトリの [アクション] でワークスペースのデプロイ サインインを選択することを示すスクリーンショット。

ワークスペース テンプレートのカスタム パラメーターを作成する

自動 CI/CD を使用していて、デプロイ時に一部のプロパティを変更するが、既定ではプロパティがパラメーター化されない場合は、既定のパラメーター テンプレートをオーバーライドできます。

既定のパラメーター テンプレートをオーバーライドするには、Git ブランチのルート フォルダーに template-parameters-definition.json という名前のカスタム パラメーター テンプレートを作成します。 このとおりのファイル名を使用する必要があります。 Azure Synapse ワークスペースで、コラボレーション ブランチから発行するか、デプロイ タスクによって他のブランチの成果物が検証されると、このファイルが読み取られ、その構成を使用してパラメーターが生成されます。 Azure Synapse ワークスペースでそのファイルが見つからない場合は、既定のパラメーター テンプレートが使用されます。

カスタムのパラメーター構文

次のガイドラインを使用して、カスタム パラメーター ファイルを作成できます。

  • 関連するエンティティ型の下にプロパティ パスを入力します。
  • プロパティ名を * に設定すると、そのプロパティの下にあるすべてのプロパティ (再帰的にではなく、最初のレベルまでのみ) をパラメーター化することを指示します。 この構成には例外を設定できます。
  • プロパティの値を文字列として設定すると、プロパティをパラメーター化することを指示します。 「<action>:<name>:<stype>」の形式を使用します。
    • <action> には、次のいずれかの文字を指定できます。
      • = は、パラメーターの既定値として現在の値を保持することを意味します。
      • - は、パラメーターの既定値を保持しないことを意味します。
      • | は、接続文字列またはキーに対する Azure Key Vault からのシークレットの特殊なケースです。
    • <name> は、パラメーターの名前です。 空白の場合は、プロパティの名前になります。 値が - 文字で始まる場合、名前は短縮されます。 たとえば、AzureStorage1_properties_typeProperties_connectionStringAzureStorage1_connectionString に短縮されます。
    • <stype> は、パラメーターの型です。 <stype> が空白の場合、既定の型は string です。 サポートされる値は stringsecurestringintboolobjectsecureobject、および array です。
  • ファイルに配列を指定すると、テンプレート内の一致するプロパティが配列であることを指示します。 Azure Synapse では、指定された定義を使用して、配列内のすべてのオブジェクトを反復処理します。 2 番目のオブジェクトである文字列は、各反復処理のパラメーターの名前として使用されるプロパティ名です。
  • 定義をリソース インスタンスに固有にすることはできません。 定義はその型のすべてのリソースに適用されます。
  • 既定では、(Key Vault シークレットなどの) セキュリティで保護されたすべての文字列と、(接続文字列、キー、トークンなどの) セキュリティで保護された文字列がパラメーター化されます。

パラメーター テンプレート定義の例

ここに、パラメーター テンプレート定義の例を示します。

{
    "Microsoft.Synapse/workspaces/notebooks": {
        "properties": {
            "bigDataPool": {
                "referenceName": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/sqlscripts": {
        "properties": {
            "content": {
                "currentConnection": {
                    "*": "-"
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/pipelines": {
        "properties": {
            "activities": [{
                "typeProperties": {
                    "waitTimeInSeconds": "-::int",
                    "headers": "=::object",
                    "activities": [
                        {
                            "typeProperties": {
                                "url": "-:-webUrl:string"
                            }
                        }
                    ]
                }
            }]
        }
    },
    "Microsoft.Synapse/workspaces/integrationRuntimes": {
        "properties": {
            "typeProperties": {
                "*": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/triggers": {
        "properties": {
            "typeProperties": {
                "recurrence": {
                    "*": "=",
                    "interval": "=:triggerSuffix:int",
                    "frequency": "=:-freq"
                },
                "maxConcurrency": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/linkedServices": {
        "*": {
            "properties": {
                "typeProperties": {
                    "accountName": "=",
                    "username": "=",
                    "connectionString": "|:-connectionString:secureString",
                    "secretAccessKey": "|"
                }
            }
        },
        "AzureDataLakeStore": {
            "properties": {
                "typeProperties": {
                    "dataLakeStoreUri": "="
                }
            }
        },
        "AzureKeyVault": {
            "properties": {
                "typeProperties": {
                    "baseUrl": "|:baseUrl:secureString"
                },
                "parameters": {
                    "KeyVaultURL": {
                        "type": "=",
                        "defaultValue": "|:defaultValue:secureString"
                    }
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/datasets": {
        "*": {
            "properties": {
                "typeProperties": {
                    "folderPath": "=",
                    "fileName": "="
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/credentials" : {
        "properties": {
            "typeProperties": {
                "resourceId": "="
            }
        }
    }
}

ここでは、前のテンプレートの記述方法について、リソースの種類別に説明します。

notebooks

  • パス properties/bigDataPool/referenceName 内のすべてのプロパティは、既定値を使用してパラメーター化されます。 各ノートブック ファイルに対して、アタッチされた Spark プールをパラメーター化できます。

sqlscripts

  • パス properties/content/currentConnection で、poolName および databaseName プロパティは、テンプレートに既定値を指定せずに文字列としてパラメーター化されます。

pipelines

  • パス activities/typeProperties/waitTimeInSeconds 内のすべてのプロパティがパラメーター化されます。 waitTimeInSeconds という名前のコードレベルのプロパティを持つパイプライン内のアクティビティ (たとえば、Wait アクティビティ) はすべて、既定の名前を使用して数値としてパラメーター化されます。 このプロパティには、Resource Manager テンプレートの既定値は設定されません。 代わりに、Resource Manager のデプロイ時にプロパティを入力する必要があります。
  • (たとえば Web アクティビティ内の) headers プロパティは、object 型 (オブジェクト) でパラメーター化されます。 headers プロパティには、ソース ファクトリと同じ値である既定値があります。

integrationRuntimes

  • パス typeProperties のすべてのプロパティは、それぞれの既定値を使用してパラメーター化されます。 たとえば、IntegrationRuntimes 型のプロパティの下には computePropertiesssisProperties という 2 つのプロパティがあります。 両方のプロパティの型は、それぞれの既定の値と型 (Object) で作成されます。

triggers

  • typeProperties の下では、2 つのプロパティがパラメーター化されます。

    • maxConcurrency プロパティには既定値があり、string 型です。 maxConcurrency プロパティの既定のパラメーター名は <entityName>_properties_typeProperties_maxConcurrency です。
    • recurrence プロパティもパラメーター化されます。 recurrence プロパティの下にあるすべてのプロパティは、既定の値とパラメーター名を持つ文字列としてパラメーター化するように設定されます。 例外は、int 型としてパラメーター化される interval プロパティです。 パラメーター名の末尾には <entityName>_properties_typeProperties_recurrence_triggerSuffix が付きます。 同様に、freq プロパティは文字列であり、文字列としてパラメーター化されます。 ただし、freq プロパティは既定値なしでパラメーター化されます。 名前は短縮され、<entityName>_freq などのサフィックスが付けられます。

    Note

    現在、最大 50個のトリガーがサポートされています。

linkedServices

  • リンクされたサービスは一意です。 リンクされたサービスとデータセットにはさまざまな型があるため、型固有のカスタマイズを行うことができます。 前の例では、AzureDataLakeStore 型のすべてのリンク サービスに対して、特定のテンプレートが適用されます。 他のすべて (* 文字を使用して識別される) には、別のテンプレートが適用されます。
  • connectionString プロパティは、securestring 値としてパラメーター化されます。 既定値はありません。 パラメーター名は短縮され、末尾に connectionString が付けられます。
  • secretAccessKey プロパティは (たとえば、Amazon S3 のリンク サービスでは) AzureKeyVaultSecret 値としてパラメーター化されます。 このプロパティは、Azure Key Vault シークレットとして自動的にパラメーター化され、構成済みのキー コンテナーからフェッチされます。 キー コンテナー自体もパラメーター化できます。

datasets

  • データセット内の型をカスタマイズすることもできますが、明示的な * レベルの構成は必要ありません。 前の例では、typeProperties の下にあるすべてのデータセット プロパティがパラメーター化されます。

CI/CD のベスト プラクティス

Azure Synapse ワークスペースで Git 統合を使用していて、変更を開発からテストを経て運用環境に移行する CI/CD パイプラインがある場合は、次のベスト プラクティスをお勧めします。

  • 開発ワークスペースのみを Git と統合します。 Git 統合を使用する場合は、"開発" Azure Synapse ワークスペースのみを Git と統合します。 テスト ワークスペースと運用ワークスペースへの変更は CI/CD を介してデプロイされるので、Git 統合は必要ありません。
  • 成果物を移行する前にプールを準備します。 SQL スクリプトまたはノートブックが開発ワークスペース内のプールにアタッチされている場合は、他の環境のプールに同じ名前を使用します。
  • コードとしてのインフラストラクチャのシナリオでバージョン管理を同期する。 インフラストラクチャ (ネットワーク、仮想マシン、ロード バランサー、接続トポロジ) を記述型モデルで管理するには、DevOps チームがソース コードに使用するものと同じバージョン管理を使用します。
  • Azure Data Factory のベスト プラクティスを確認してください。 Data Factory を使用する場合は、Data Factory の成果物のベスト プラクティスに関するページを参照してください。

成果物のデプロイに関するトラブルシューティング

Synapse ワークスペースのデプロイ タスクを使用して Synapse 成果物をデプロイする

Azure Synapse では、Data Factory とは異なり、成果物は Resource Manager リソースではありません。 ARM テンプレート デプロイ タスクを使用して Azure Synapse の成果物をデプロイすることはできません。 代わりに、Synapse ワークスペースのデプロイ タスクを使用して成果物をデプロイし、ARM リソース (プールとワークスペース) のデプロイに ARM デプロイ タスクを使用します。 一方、このタスクでは、リソースの種類が Microsoft.Synapse である Synapse テンプレートのみがサポートされます。 このタスクを使用すると、ユーザーは Synapse Studio で発行を手動でクリックすることなく、任意のブランチからの変更を自動的にデプロイできます。 次に、頻繁に発生する問題をいくつか紹介します。

1.発行の失敗: ワークスペースの arm ファイルが 20 MB を超えている

git プロバイダーにはファイル サイズの制限があります。たとえば、Azure DevOps では最大ファイル サイズは 20 MB です。 ワークスペース テンプレート ファイルのサイズが 20 MB を超えると、Synapse Studio で変更を発行するときにこのエラーが発生します。この場合、ワークスペース テンプレート ファイルが生成されて git に同期されます。 この問題を解決するには、検証または検証とデプロイ操作を使って Synapse デプロイ タスクを使用し、ワークスペース テンプレート ファイルをパイプライン エージェントに直接保存します。Synapse Studio での手動による発行は必要ありません。

2. リリースにおける予期しないトークン エラー

パラメーター ファイルにエスケープされていないパラメーター値がある場合、リリース パイプラインでファイルの解析に失敗し、unexpected token エラーが生成 されます。 パラメーターをオーバーライドすること、または Key Vault を使用してパラメーター値を取得することをお勧めします。 また、二重エスケープ文字を使用して問題を解決することもできます。

3. 統合ランタイムのデプロイの失敗

マネージド仮想ネットワーク対応ワークスペースから生成されたワークスペース テンプレートがあり、通常のワークスペースにデプロイしようとした場合、またはその逆の場合、このエラーが発生します。

4. 値の解析中での予期しない文字の検出

テンプレート ファイルでテンプレートは解析できません。 バック スラッシュをエスケープしてみます (例: \\Test01\Test)

5. ワークスペース情報が見つからず取得できない

ターゲット ワークスペース情報が正しく構成されていません。 作成したサービス接続のスコープが、ワークスペースを持つリソース グループに設定されていることを確認してください。

6. 成果物の削除の失敗

拡張機能では、発行ブランチにある成果物がテンプレートと比較され、その違いに基づいて削除されます。 発行ブランチにある成果物を削除しようとしていないこと、およびそれを参照している、またはそれと依存関係のある成果物が他にないことを確認してください。

7.デプロイがエラー json position 0 で失敗する

テンプレートを手動で更新しようとすると、このエラーが発生します。 テンプレートを手動で編集していないことを確認してください。

8.参照が無効なため、ドキュメントの作成または更新に失敗

Synapse の成果物は、別の成果物から参照できます。 成果物で参照される属性をパラメーター化した場合は、null 値以外の正しい値を指定してください

9.ノートブックのデプロイでデプロイの状態をフェッチできない

デプロイしようとしているノートブックは、ワークスペース テンプレート ファイル内の Spark プールにアタッチされますが、デプロイでは、プールはターゲット ワークスペースに存在しません。 プール名をパラメーター化しない場合は、環境間のプールの名前が同じであることを確認してください。