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 を使用している場合:
- リリース パイプラインを実行するための Azure DevOps プロジェクトを準備します。
- リポジトリを表示できるようにするため、コードをチェックインするユーザーに組織レベルでの Basic アクセス権を付与します。
- Azure Synapse リポジトリに対する所有者権限を付与します。
- セルフホステッド Azure DevOps VM エージェントを作成したこと、または Azure DevOps ホステッド エージェントを使用していることを確認します。
- リソース グループの Azure Resource Manager サービス接続を作成するためのアクセス許可を付与します。
- Microsoft Entra の管理者は、Azure DevOps 組織に Azure DevOps Synapse Workspace Deployment Agent 拡張機能をインストールする必要があります。
- パイプラインを実行するための既存のサービス アカウントを作成または指名します。 サービス アカウントの代わりに個人用アクセス トークンを使用できますが、そのユーザー アカウントが削除されるとパイプラインが機能しなくなります。
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 でのソース管理」を参照してください。
デプロイ先の空のワークスペースをセットアップします。
- 新しい Azure Synapse ワークスペースを作成します。
- サービス プリンシパルに、新しい Synapse ワークスペースに対する次のアクセス許可を付与します。
- Microsoft.Synapse/workspaces/integrationruntimes/write
- Microsoft.Synapse/workspaces/operationResults/read
- Microsoft.Synapse/workspaces/read
- このワークスペースでは、Git リポジトリ接続を構成しないでください。
- Azure Synapse ワークスペースで、 [Studio]>[管理]>[アクセスの制御] に移動します。 “Synapse Artifact Publisher” をサービス プリンシパルに割り当てます。 デプロイ パイプラインでマネージド プライベート エンドポイントをデプロイする必要がある場合は、代わりに "Synapse 管理者" を割り当てます。
- リンクされているサービスを使用するとき、その接続情報が Azure Key Vault に格納されている場合、キー コンテナーを環境別に保持することが推奨されます。 キー コンテナーごとに個別のアクセス許可レベルを構成することもできます。 たとえば、運用環境のシークレットへのアクセス許可をチーム メンバーに持たせたくない場合があります。 このアプローチに従う場合は、すべてのステージで同じシークレット名を保持することをお勧めします。 同じシークレット名を保持する場合、CI/CD 環境全体で各接続文字列をパラメーター化する必要はありません。変わるのは別個のパラメーターであるキー コンテナーの名前だけだからです。
その他の前提条件
- Spark プールとセルフホステッド統合ランタイムは、ワークスペースのデプロイ タスクでは作成されません。 セルフホステッド統合ランタイムを使用するリンク サービスがある場合は、新しいワークスペースにランタイムを手動で作成します。
- 開発ワークスペースの項目が特定のプールにアタッチされている場合は、パラメーター ファイルでターゲットのワークスペースのプールに同じ名前を作成またはパラメーター化したことを確認します。
- プロビジョニングされた SQL プールをデプロイしようとしたときに一時停止した場合、デプロイは失敗する可能性があります。
詳細については、Azure Synapse Analytics での CI/CD パート 4 - リリース パイプラインに関するページを参照してください。
Azure DevOps にリリース パイプラインを設定する
このセクションでは、Azure DevOps で Azure Synapse ワークスペースをデプロイする方法について説明します。
Azure DevOps で、リリース用に作成したプロジェクトを開きます。
左側のメニューで、 [パイプライン]>[リリース] を選択します。
[新しいパイプライン] を選択します。 既存のパイプラインがある場合は、 [新規]>[新しいリリース パイプライン] を選択します。
[空のジョブ] テンプレートを選択します。
[ステージ名] に、環境の名前を入力します。
[成果物の追加] を選択し、開発環境の Azure Synapse Studio で構成した Git リポジトリを選択します。 プールとワークスペースの ARM テンプレートを管理する Git リポジトリを選択します。 ソースとして GitHub を使用する場合は、GitHub アカウントとプル リポジトリのサービス接続を作成します。 詳細については、サービスの接続に関する記事を参照してください。
リソース ARM テンプレート ブランチを選択します。 [既定のバージョン] では [既定のブランチからの最新バージョン] を選択します。
成果物の [既定のブランチ] では、リポジトリの発行ブランチ、または Synapse 成果物を含む他の発行以外のブランチを選択します。 既定では、発行ブランチは
workspace_publish
です。 [既定のバージョン] では [既定のブランチからの最新バージョン] を選択します。
リソースを作成および更新するための ARM テンプレートのステージ タスクを設定する
Azure Synapse ワークスペース、Spark および SQL プール、キー コンテナーなどのリソースをデプロイするための ARM テンプレートがある場合は、それらのリソースを作成または更新するための Azure Resource Manager デプロイ タスクを追加します。
ステージ ビューで、 [ステージ タスクを表示します] を選択します。
新しいタスクを作成します。 [ARM テンプレートのデプロイ] を探して [追加] を選択します。
デプロイの [タスク] タブでは、ワークスペースのサブスクリプション、リソース グループ、場所を選択します。 必要であれば資格情報を指定します。
[アクション] で [リソース グループの作成または更新] を選択します。
[テンプレート] で省略記号 ( [...] ) ボタンを選択します。 ワークスペースの ARM テンプレートに移動します。
[Template parameters](テンプレート パラメーター) については、[…] を選択して、パラメーター ファイルを選択します。
[テンプレート パラメーターのオーバーライド] で、 [...] を選択し、ワークスペースに使用するパラメーター値を入力します。
[配置モード] で [増分] を選択します。
(省略可能) 付与のために Azure PowerShell を追加して、ワークスペースのロール割り当てを更新します。 リリース パイプラインを使用して Azure Synapse ワークスペースを作成する場合は、パイプラインのサービス プリンシパルが既定のワークスペース管理者として追加されます。PowerShell を実行して、他のアカウントにワークスペースへのアクセスを許可することができます。
警告
完全なデプロイ モードでは、新しい ARM テンプレートで指定されていないリソース グループのリソースは "削除されます"。 詳しくは、「Azure Resource Manager のデプロイ モード」を参照してください。
Azure Synapse 成果物のデプロイのステージ タスクを設定する
Synapse ワークスペース デプロイ拡張機能を使用して、Azure Synapse ワークスペース内のその他の項目をデプロイします。 デプロイできる項目には、データセット、SQL スクリプトとノートブック、Spark ジョブ定義、統合ランタイム、データ フロー、資格情報、ワークスペース内のその他の成果物が含まれます。
展開拡張機能をインストールして追加する
Visual Studio Marketplace で拡張機能を探して取得します。
拡張機能をインストールする Azure DevOps 組織を選択します。
Azure DevOps パイプラインのサービス プリンシパルにサブスクリプションのアクセス許可が付与され、ワークスペースの 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 と同じです。
ユース ケースに基づいて操作の種類を選択できます。 デプロイの例を次に示します。
このタスクでは、操作の種類として [デプロイ] を選択します。
タスクで、[テンプレート] の横にある […] を選択して、テンプレート ファイルを選択します。
[Template parameters](テンプレート パラメーター) の横にある […] を選択して、テンプレート ファイルを選択します。
ワークスペースの接続、リソース グループ、名前を選択します。
[テンプレート パラメーターのオーバーライド] の横にある […] を選択します。 ワークスペースに使用するパラメーター値を入力します (リンク サービスで使用される接続文字列とアカウント キーを含む)。 詳細については、Azure Synapse Analytics の CI/CD に関する記事をご覧ください。
マネージド プライベート エンドポイントのデプロイは、バージョン 2.x でのみサポートされています。必ず適切なバージョンを選択し、[マネージド プライベート エンドポイントをテンプレートにデプロイする] をオンにしてください。
トリガーを管理するには、トリガー トグルを使用して、デプロイ前にトリガーを停止できます。 また、デプロイ タスクの後にトリガーを再起動するタスクを追加できます。
重要
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 のシークレットは、暗号化された環境変数です。 このリポジトリに対するコラボレーター権限を持つユーザーは、これらのシークレットを使用して、リポジトリ内のアクションを操作できます。
GitHub リポジトリで、 [Settings](設定) タブを選択し、 [Secrets](シークレット)>[New repository secret](新しいリポジトリ シークレット) を選択します。
クライアント ID の新しいシークレットを追加し、デプロイにサービス プリンシパルを使用する場合は、新しいクライアント シークレットを追加します。 サブスクリプション ID とテナント ID をシークレットとして保存することもできます。
ワークフローを追加する
GitHub リポジトリで、 [Actions](アクション) に移動します。
[Set up a workflow yourself](ワークフローを自分でセットアップする) を選択します。
ワークフロー ファイルで、
on:
セクションの後にあるすべてのものを削除します。 たとえば、残りのワークフローは次の例のようになります。name: CI on: push: branches: [ master ] pull_request: branches: [ master ]
ワークフローの名前を変更します。 [Marketplace](マーケットプレース) タブで Synapse ワークスペースのデプロイ アクションを検索して、アクションを追加します。
必要な値とワークスペース テンプレートを設定します。
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'
変更をコミットする準備ができました。 [Start commit](コミットの開始) を選択し、タイトルを入力して、説明 (省略可能) を追加します。 次に、 [Commit new file](新しいファイルのコミット) を選択します。
ファイルは、リポジトリの .github/workflows フォルダーに表示されます。
Note
マネージド ID は、Azure 上のセルフホステッド VM でのみサポートされています。 ランナーをセルフホステッドに設定してください。 VM に対してシステム割り当てマネージド ID を有効にし、Synapse 管理者として Azure Synapse Studio に追加します。
デプロイを確認する
ワークスペース テンプレートのカスタム パラメーターを作成する
自動 CI/CD を使用していて、デプロイ時に一部のプロパティを変更するが、既定ではプロパティがパラメーター化されない場合は、既定のパラメーター テンプレートをオーバーライドできます。
既定のパラメーター テンプレートをオーバーライドするには、Git ブランチのルート フォルダーに template-parameters-definition.json という名前のカスタム パラメーター テンプレートを作成します。 このとおりのファイル名を使用する必要があります。 Azure Synapse ワークスペースで、コラボレーション ブランチから発行するか、デプロイ タスクによって他のブランチの成果物が検証されると、このファイルが読み取られ、その構成を使用してパラメーターが生成されます。 Azure Synapse ワークスペースでそのファイルが見つからない場合は、既定のパラメーター テンプレートが使用されます。
カスタムのパラメーター構文
次のガイドラインを使用して、カスタム パラメーター ファイルを作成できます。
- 関連するエンティティ型の下にプロパティ パスを入力します。
- プロパティ名を
*
に設定すると、そのプロパティの下にあるすべてのプロパティ (再帰的にではなく、最初のレベルまでのみ) をパラメーター化することを指示します。 この構成には例外を設定できます。 - プロパティの値を文字列として設定すると、プロパティをパラメーター化することを指示します。 「
<action>:<name>:<stype>
」の形式を使用します。<action>
には、次のいずれかの文字を指定できます。=
は、パラメーターの既定値として現在の値を保持することを意味します。-
は、パラメーターの既定値を保持しないことを意味します。|
は、接続文字列またはキーに対する Azure Key Vault からのシークレットの特殊なケースです。
<name>
は、パラメーターの名前です。 空白の場合は、プロパティの名前になります。 値が-
文字で始まる場合、名前は短縮されます。 たとえば、AzureStorage1_properties_typeProperties_connectionString
はAzureStorage1_connectionString
に短縮されます。<stype>
は、パラメーターの型です。<stype>
が空白の場合、既定の型はstring
です。 サポートされる値はstring
、securestring
、int
、bool
、object
、secureobject
、および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
型のプロパティの下にはcomputeProperties
とssisProperties
という 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 プールにアタッチされますが、デプロイでは、プールはターゲット ワークスペースに存在しません。 プール名をパラメーター化しない場合は、環境間のプールの名前が同じであることを確認してください。