在部署ADF时触发状态更新

Question

我正在使用Azure DevOps管道从DEV实例部署ADF模板。

下面的部署是我遵循的步骤。

​

微软提供的

1. 脚本在部署
2. ARM模板之前停止触发器，由微软提供的启动触发器和删除资源不在JSON文件中。在页面https://learn.microsoft.com/en-us/azure/data-factory/continuous-integration-deployment

中的头示例部署前和部署后脚本下面。

我确实有大约20个触发器，其中15个处于运行状态，5个被暂停一段时间。在我的DEV实例中，为了避免不必要的管道运行，所有触发器都处于停止状态。但是在部署到PROD时，我需要将20个触发器中的15个设置为已启动。

为了实现这一点，我在模板参数化中添加了触发器的runtimeState，现在我可以在ARM模板部署任务中从覆盖参数选项中选择触发器状态，如下所示。

​

现在的问题是在PROD部署之后，所有触发器都处于停止的状态，就像在DEV实例中一样。

尽管runtimeState在部署时被覆盖，但部署后的PROD实例中没有反映它。

根据我的分析，我怀疑问题是来自微软的start触发器脚本引用了DEV中的ARMTemplateForFactory.json文件，其中停止了所有触发器的状态。

​

如何解决这个问题？我必须更新每个触发作业在部署时从DEV到PROD的触发状态。

在要从Microsoft停止/启动触发器的脚本中，它从Json文件中获取要启动的触发器列表，我们通过构建管道从DEV实例中获得这些触发器。将不会将覆盖的管道状态用于启动触发器。

​

我找到的解决方案之一是在ARM部署之后显式地启动触发器。为此，我找到了一个代理工作，如下所示。

​

但是这个工作的问题是我不能一次提供多个触发器的名称。我能够提供单个触发器的名称，如下所示。

​

是否有任何方法在此作业中添加多个触发器名称？

Answer 1

目前，我在ARM模板部署任务之后添加了一个新的任务，以启动所需的触发器。

ResourceGroupName，DataFactoryName，TriggersToStart详细信息作为启动触发器的脚本的参数传递。这样，我们就可以在每次部署期间为添加/删除启用的触发器。

​

下面是我用来获取参数并使用下面的脚本启动触发器的脚本。

param
(
 [parameter(Mandatory = $false)] [String] $ResourceGroupName,
 [parameter(Mandatory = $false)] [String] $DataFactoryName,
 [parameter(Mandatory = $false)] [Array] $triggersToStart
)

 Foreach($trigger_name in $triggersToStart)
 {
  Write-Host "Starting Trigger : " $trigger_name
  Start-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $trigger_name  -Force
 }

Answer 2

正如您所描述的，Microsoft提供了预部署脚本，在部署之前暂停所有活动触发器，然后在部署后将它们还原到ARM模板中指定的状态。(他们建议在部署前暂停触发器以避免出现问题)

一种解决方案可以是创建一个定制的powershell脚本，并在部署ARM模板之后执行该脚本。您可以使用Microsoft提供的脚本中也使用的Start-AzDataFactoryV2Trigger cmdlet。

例如：

$ResourceGroupName = "my-resource-group"
$DataFactoryName = "my-data-factory'
$triggersToStart = @("trigger-1", "trigger-2", "trigger-3")

$triggersToStart | ForEach-Object {
    Start-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_ -Force
}

Answer 3

请查核以下事项：

1. 在您的本地机器上尝试使用相同的脚本，以确定它们是否能按预期工作。

1. 如果脚本也不能从本地机器运行，那么问题应该在ADF或脚本上，而不是Azure DevOps上。检查ADF或脚本中是否有不正确的配置。

如果脚本可以在本地机器上正常工作，请尝试在本地机器上安装一个自托管代理，以运行管道，看看它是否能按预期工作。