Sim*_*wsi 7 resources agent azure-devops azure-pipelines
我正在试验多级 Azure 管道,部署到 Windows 虚拟机。由于多级管道不支持部署组,我正在使用环境。尽管向环境添加虚拟机资源与向部署组添加目标非常相似,但我注意到命名约定略有不同。
当 PowerShell 脚本运行以创建作为部署组目标的代理时,创建的 Windows 服务名为vstsagent.{组织名称}.{项目名称}.{目标 VM 名称}。这使得 Windows 服务名称对于每个项目都是唯一的。
当 PowerShell 脚本运行以创建作为环境资源的代理时,默认情况下创建的 Windows 服务名为vstsagent.{组织名称}..{目标 VM 名称} 。这意味着默认情况下,同一组织中部署到同一虚拟机的所有项目都将使用相同的 Windows 服务名称作为代理。
当我已经为项目设置了 VM 代理并想要将资源添加到同一组织中指向同一 VM 的第二个项目时,我经常会遇到问题。
当 PowerShell 脚本在虚拟机上运行以创建第二个代理时,它会识别出服务器上已存在同名服务vstsagent.{组织名称}..{目标虚拟机名称},并尝试替换它。大约 25% 的情况下会失败。在这种情况下,我尝试使用.\config removePowerShell 手动删除现有的 Windows 服务,然后重新运行第二个代理的 PowerShell 脚本。PowerShell 脚本运行时似乎没有错误,并表示它已注册代理。但是,现在如果我尝试在第一个或第二个项目中运行管道,它会失败,并显示“无法部署到虚拟机 '{target VM name}',因为机器处于脱机状态。 ”。所以我最终得到了两个无法再部署的项目。
将多个项目部署到同一个虚拟机上肯定是比较常见的。当 PowerShell 脚本尝试创建第二个代理无法替换现有代理时,处理这种情况的最佳方法是什么?有没有某种方法可以强制脚本仅使用现有代理而不尝试替换它?或者,在 Azure DevOps GUI 中将资源添加到环境时,是否有某种方法可以指定我要重用另一个项目中的资源/代理?
| 归档时间: |
|
| 查看次数: |
2268 次 |
| 最近记录: |