目次
Target Contents
Azure Data Factory の継続インテグレーションをピックアップした記事となります。本記事は以下を参考に、Azure Data Factory を継続的にデプロイする方法を順序立てて説明致します。
参考: Automated publishing for continuous integration and delivery
OverView The Azure Data Factory
Azure Data Factory は Microsoft Azure の ETLサービスであり、データ統合やデータ変換を行います。
Azure Data Factory インスタンスは Azure Portal 上から構築が可能であり、インスタンス内のデータセット、パイプライン、データフロー等の主要コンポーネントをAzure Data Factory Studio 上で管理します。
Azure Data Factory Studio では、リポジトリ管理として Azure DevOps Git および GitHub を使用する事が可能です。
ここから Azure Data Factory Studio 上で管理されたパラメーターをリポジトリとして管理していくため Azure DevOps について記載していきます。
For Azure DevOps
Azure DevOps は、Azure 上でソフトウェアを共同開発する際に利用されるリポジトリサービスです。 Azure DevOps Services は、クラウド上で管理され、Web ブラウザおよび IDE クライアントからアクセスする事が可能となります。
参考: Azure DevOps とは
VS code 上から操作が出来るよう、AzureDevOps 上でプロジェクトを作成した後、Repos からGit Credentials を発行します。
ここで出力されるパスワードは後々必須となりますので、コピーしておきます。その後、右側にある Clone In VS Code をクリックして VS Code に Git を導入します。
VS Code に遷移すると、パスワードが要求されますので、先ほど取得したパスワードを入力します。
まずは、適当なファイルを作成し、VS Code のソース管理機能を使用して Commit 、Master ブランチへ Push してみます。
Azure DevOps の Repos 上から見ると、作成したファイルが反映されていることが確認できます。
今回の Azure Data Factory の CI/CD では、開発用ブランチが必要です。
通常は個別開発した Feature ブランチから pull request を行いますが、今回は develop ブランチを任意で作成し、ここから pull request を実施します。承認されれば Master ブランチにMerge されます。
For Azure DevOps Pipelines
Azure DevOps Pipelines は、コードを自動的にビルド、テスト、リリースまでを実施する Azure DevOps のサービスとなります。Azure Data Factory の継続インテグレーションにおける手法として Azure DevOps Pipeline が挙げられております。
Azure Resource Manager
Azure DevOps Pipeline では、Azure Resource Manager(ARM) Template を使用します。ARM とは通常 Azure PowerShell / Portal / CLI 経由によりREST APIを受け取り、Resource へ処理を行います。
Azure Resource Manager Template
Azure Resource Manager Template (ARMテンプレート) とは、Azure のインフラストラクチャサービスをコードとして実装するために JSON 形式で記載されたARMのテンプレートです。
Azure Data Factory の新しい CI/CD フローにおいて ARM テンプレートが重要な点は、Azure DevOps Pipeline 上で ビルドした成果物が、リリースで利用される点です。
後述する、リリースに使用される Artifact の前段のパイプラインで生成された成果物をトリガーする事となります。つまり、Master ブランチへのマージ後、自動化されたデプロイまでを行う事が可能です。
Azure DevOps Pipelines では、以下の package.json と yml ファイルを使用してビルドを行います。yml ファイルは任意のファイル名で問題ありません。
package.json には、npm パッケージとして使用される @Microsoft/azure-datadactory-utilities を介してロジックを使用します。
{
"scripts":{
"build":"node node_modules/@microsoft/azure-data-factory-utilities/lib/index"
},
"dependencies":{
"@microsoft/azure-data-factory-utilities":"^1.0.0"
}
}azure-pipelines.yml として ビルドを想定した yml ファイルを作成します。Azure DevOps Pipelines はビルドとテストを実施するためのコードが記載されています。ここに記載する CustomCommand にはDatafactory 名とSubscription IDを適宜入れます。また、後述のDatafactory 上からGit をONとした際にルートディレクトリを / としている場合、Package.json もルート配下に配置します。
# Sample YAML file to validate and export an ARM template into a build artifact
# Requires a package.json file located in the target repository
trigger:
- main #collaboration branch
pool:
vmImage: 'ubuntu-latest'
steps:
# Installs Node and the npm packages saved in your package.json file in the build
- task: NodeTool@0
inputs:
versionSpec: '14.x'
displayName: 'Install Node.js'
- task: Npm@1
inputs:
command: 'install'
workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
verbose: true
displayName: 'Install npm package'
# Validates all of the Data Factory resources in the repository. You'll get the same validation errors as when "Validate All" is selected.
# Enter the appropriate subscription and name for the source factory. Either of the "Validate" or "Validate and Generate ARM temmplate" options are required to perform validation. Running both is unnecessary.
- task: Npm@1
inputs:
command: 'custom'
workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
customCommand: 'run build validate $(Build.Repository.LocalPath)/<Root-folder-from-Git-configuration-settings-in-ADF> /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<Your-ResourceGroup-Name>/providers/Microsoft.DataFactory/factories/<Your-Factory-Name>'
displayName: 'Validate'
# Validate and then generate the ARM template into the destination folder, which is the same as selecting "Publish" from the UX.
# The ARM template generated isn't published to the live version of the factory. Deployment should be done by using a CI/CD pipeline.
- task: Npm@1
inputs:
command: 'custom'
workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
customCommand: 'run build export $(Build.Repository.LocalPath)/<Root-folder-from-Git-configuration-settings-in-ADF> /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<Your-ResourceGroup-Name>/providers/Microsoft.DataFactory/factories/<Your-Factory-Name> "ArmTemplate"'
#For using preview that allows you to only stop/ start triggers that are modified, please comment out the above line and uncomment the below line. Make sure the package.json contains the build-preview command.
# Publish the artifact to be used as a source for a release pipeline.
- task: PublishPipelineArtifact@1
inputs:
targetPath: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>/ArmTemplate' #replace with the package.json folder
artifact: 'ArmTemplates'
publishLocation: 'pipeline'以下は、具体的な設定画面を示しています。
Azure DevOps Pipelines から New Pipelines を選択し、今回使用する Azure Repos Git を選択します。
Starter pipeline を選択し、azure-pipelines.yml を選択して Pipeline を Save ＆ Run します。
azure-pipelines.yml では、以下の処理が行われます。
1. トリガーとして指定するブランチを設定
2. ビルドエージェントの設定
3. ステップの定義
- Node.jsのインストールし、package.json に記載の npm パッケージのインストール
- リソース内の Azure Data Factory の検証、ARMテンプレートの生成
- 生成されたARMテンプレートをビルドアーティファクトとして公開
これらを行った後、リリースを実施します。
Release
Pipeline の設定が完了しますと、Release の設定を行います。
参考: Azure Pipelines リリースのセットアップ
Release では、先ほど Azure DevOps Pipeline で生成された Artifacts をトリガーに Deploy Task を実施します。Release 画面より Artifacts として Source の build Pipeline を選択します。Source alias は任意で問題ありません。
Stage View から Stage Task の追加 (+) を選択し、Task 欄を選択すると、Agent Job という表記があるため、右側の + を選択し、ARM template deployment を選択します。
ARM Template deployment では、Azure の詳細情報を選択していきますが、Template では、以下のような Template 欄と Template parameters 欄が存在します。参考程度ですが、こちらを選択します。
保存後、手動で一度デプロイを実施し、問題がなければ Stages タスク上で Succeeded が表示されます。履歴からこのJob が何をしているかを確認する事が出来ます。
ここで Azure Data Factory 側に話を戻します。
Architecture the Azure Data Factory
Azure Data factory インスタンスは、Microsoft Azure 上に構築可能な PaaS サービスであり、サービス単体で多岐に渡る機能を保有します。
Azure Datafactory インスタンス内部は、以下の主要コンポーネントを含みます。これらは Azure Data Factory Studio 上から操作可能なエンティティであり、今回 CI/CDを行う対象のオブジェクトとなりますので、以下に補足します。
DataSet
参考: Azure Data Factory および Azure Synapse Analytics 内のデータセット
後述する Azure Data Factory の Pipeline はデータに対して処理を実行する論理グループであり、対象データを定義する必要があります。Dataset はこれらを定義するエンティティです。
Azure Data Factory がサポートするデータストアを選択し、データの構造体を具体的に定義する事で処理を行う対象データを指定する事が可能となります
LinkedServices
参考: Azure Data Factory および Azure Synapse Analytics のリンクされたサービス
Azure Data Factory がサポートするデータストアには、１つ１つに LinkedServices を使用します。これは、対象のデータストアとAzure Data Factory Services をリンクさせる機能です。
これらより Dataset はリンクされたデータ ストア内のデータの構造を表すものとなり、LinkedServices はデータ ソースへの接続を定義するものと捉えるイメージとなります。
Pipeline / Activity
参考: Azure Data Factory と Azure Synapse Analytics のパイプラインとアクティビティ
Pipeline は １つ以上の Dataset を使用し、対象データを処理する事が出来ます。この際、データに対してどのような処理を実行するかを定義する事が出来ます。これを Activity と呼びます。
例えば、Azure SQL Database の任意のテーブルから BLOB Storage へファイルを出力するとします。この場合、Copy Activity を使用し、ソースとシンクに事前定義した Azure SQL Database の Dataset と Strage Account の Dataset を入力します。これにより、指定したファイル形式でテーブルデータをコピーする事が可能となります。
上記は、一つの Activity から構成される Pipeline です。Pipeline は、順序定義された複数の Activity を構成し、複数かつ複雑な処理を行ってくれるものとなります。
Pipeline 毎に、スケジュール機能を使用する事が出来ます。これは日次で pipeline を実行する場合などに有効な Pipeline の設定です。
参考: Azure Data Factory または Azure Synapse Analytics でのパイプライン実行とトリガー
Dataflow
参考: Azure Data Factory のマッピング データ フロー
Dataflow はデータ変換処理を個別で行う機能です。入出力に必要な関数を使用して、データを変換します。
なお、Data Flow は上述の Activity の1つとしてPipeline に組み込む事も可能です。
Integration Runtime
参考: Azure Data Factory の統合ランタイム
linkedServices は、Dataset を定義する際に使用され、データ ソースへの接続を定義として作成します。これらは全て Pipeline のActivity 内で使用されます。
Integration Runtime は、Activity とLinkedServices との橋渡しをします。 LinkedServices 内で定義された Integration Runtime は、Activity によって参照、直接実行されるコンピューティング環境を提供します。
Integration Runtime にはAzure Integration Runtime / SelfHosted Integration Runtime / Azure SSIS Integration Runtime の3種類が存在しますが、どの種類をRuntime を使用するかは、 Azure ネットワークと、使用出来るActivity に沿う形となりますので、参照情報を見て判断する必要があります。
参考: Azure 統合ランタイム
参考: セルフホステッド統合ランタイム
これらを含む Azure Data Factory Service 全体をコードとして生成していく事で、CI/CD を行う事が可能です。ここから具体的なステップを見ていきましょう。
First Step
Azure Data factory は、Azure 上の特定のリソースグループ内で管理されるPaaSサービスです。まずは Azure Data Factory インスタンスを構築して、Azure DevOps を有効化しましょう。
なお、コードからDatafactory インスタンスを作成する事も可能です。
{
"name": "datafactory-name",
"location": "japaneast",
"identity": { "type": "SystemAssigned", "principalId": "xxxxx", "tenantId": "xxxxxx"
}
}
今回は順序の説明をする上で Azure Portal から作業を行います。
Azure Data Factory を立ち上げた後、Azure Data factory Studio を起動し、Manage から GIt configuration の構成をセットします。
Azure DevOps Git を選択し、使用するAzure DevOps アカウントやプロジェクト名、リポジトリ名などの構成を設定します。
従来型のCI/CDのデプロイ方法では、コラボレーションブランチと発行ブランチが異なり、発行ブランチにPush されるたびにARM Template をデプロイする方式となっておりました。
参考: 現在の CI/CD フロー
新しいCI/CDフローでは、Azure DevOps パイプラインのビルドが各ブランチからのPull Reqesust によって Merge された Master ブランチの commit によってトリガーされます。ここでPipelineの検証が成功した場合、ARM Template が生成されます。その後、Release でトリガーされた Pipeline から新しいビルド(ARM Template) が利用可能になるたびにデプロイへと向かいます。このケースでは 任意のブランチで問題はありません。
適用すると、Azure Data Factory Studio の画面左上部より、以下の画面が確認する事が出来ます。
Git が有効化されたブランチの各エンティティとライブモード(Git 有効化する前のData Factory UIで設定されたエンティティ) の整合性を合わせる場合は、ライブモードの上書き、あるいは再接続をして、ライブモードのコードが信頼できる情報源として再接続した Repos にインポートする事も可能です。
ここで重要な点は、新しいCI/CDフローにおけるAzure DevOps Pipeline が Data Factory Studio 内にある "発行" の変わりに Data Factory リソースの検証、ARMテンプレートの生成を担う点にあります。
Second Step
続いて、必要なコンポーネントの詳細を見ていきましょう。
Azure Data Factory には主要コンポーネントが複数存在しますが、各コンポーネント単位で、コード管理するための ARM Template を作成していきます。
First Step にて Git の設定を行った際に Repos に ARM Template.json が含まれていると思いますが、Azure Data Factory Studio 上から設定したコードを ARM Template としてエクスポートする事も可能です。
Azure Datafactory リソース以外は未作成の状態かと思いますので、各エンティティ単位でARM Template のJSON を少し見てみます。DataSet.jsonでは、以下を例としてみます。
{
"name": "dataset1",
"properties": {
"linkedServiceName": {
"referenceName": "AzureBlobStorageLinkedService",
"type": "LinkedServiceReference"
},
"type": "AzureBlob",
"typeProperties": {
"fileName": "data.csv",
"folderPath": "container/dataset1",
"format": {
"type": "TextFormat",
"columnDelimiter": ",",
"rowDelimiter": "\n",
"quoteChar": "\""
}
}
}
}続いて、linkedService.json では、以下を例としてみます。
{
"name": "MyAzureBlobStorageLinkedService",
"properties": {
"type": "AzureBlobStorage",
"typeProperties": {
"connectionString": "DefaultEndpointsProtocol=https;AccountName=myblobstorage;AccountKey=myaccountkey;EndpointSuffix=core.windows.net"
}
}
}続いて、Schedule.json では、以下を例としてみます。
{ "name": "trigger1", "properties": { "type": "Schedule", "typeProperties": { "recurrence": { "frequency": "Day", "interval": 1, "startTime": "2022-01-01T00:00:00Z", "timeZone": "UTC" } }, "pipelines": [ { "pipelineReference": { "referenceName": "pipeline1", "type": "PipelineReference" }, "parameters": { "param1": "value1", "param2": "value2" } } ] } }
Third Step
Azure Datafactory Studio 上から作成した保存した Azure Data Factory リソースはAzure DevOps よりコードで管理されています。勿論IDEクライアントから新規コードを発行する事も可能です。想定される IDE クライアントなどから開発ブランチの 同期前の状態のディレクトリ構造を例とします。
/
|- README.md
|- pipelines/
|- pipeline1.json
|- pipeline2.json
|- factory/
|- factory.json
|- dataset/
|- dataset1.json
|- dataset2.json
|- linkedServices/
|- linkedService1.json
|- linkedService2.json
|- triggers/
|- trigger1.json
|- trigger2.json
|- factory-name/
|- globalParameters
|- globalParameters.json
|- linkedTemplates
|- ARMTemplateForFactory.json
|- ARMTemplateParametersForFactory.json
|- azure-pipelines.yml
|- package.jsonAzure DevOps Pipelines でCI/CDを行うためには azure-pipelines.yml で定義されたファイルをReposに追加していますが、Starter Pipeline 選時に yml を定義する事でここに含めずともビルドの実行は可能です。
Azure Data Factory New CI/CD Flow
最後に、ここまで説明した Azure Datafactory における CI/CD のプロセスの一連を見ていきます。
DevOps Repos Pull Requests
開発用ブランチから追加した Datafactory リソースの ARM template を追加、編集します。今回は devloper ブランチの dataset と linkedservice の２ファイル分を更新します。commit 後、main ブランチへ Pull Request を実施します。
Merge to Master Branch Trigger build Pipeline
Merge されたMain ブランチは 事前登録されたビルド処理を実行します。ここでは、Validate が行われるため、妥当性の無い ARM Template は失敗します。リリースに不正確なプログラムが入る事はありません。
DevOps Release
ビルド処理が完了した後は、Release へと向かいます。Artifact の設定を Automatic をトリガーとしておくことで、リリースが自動的に行われます、また、ここで承認プロセスを設けておくことも可能です。
Azure Data Factory Deployment
最後に Azure Datafactory Studio から見ると、反映が確認できます。
以上となります。ここで言及していませんが、Azure Data Factory インスタンスの作成、Gitの有効化を開発環境上で行い、検証・本番のデータ ファクトリには、CI/CD フローの DevOps リリース パイプラインによりデプロイするよう構成する事が推奨されているようです。
実装する際は、Microsoft Azure ドキュメントをご確認の上、お試し頂きますようお願い致します。
この記事をシェアする
