azure - 强制 azure Fabric 使用更新的版本号更新服务

Question

基本上，我正在寻找一种部署 azure 结构的方法，其中服务仅根据版本号进行更新。

我正在通过 azure devops 部署服务结构应用程序。我编写了一个脚本，用于执行比较并更新 ApplicationManifest.xml 和 ServiceManifest.xml 上的版本号。该脚本已经过测试，它可以正确更新已更改的服务的版本。

现在，当我尝试部署时，收到以下错误消息:

##[error]The content in CodePackage Name:Code and Version:1.0.111 in Service Manifest 'MyMicroServicePkg' has changed, but the versionnumber is the same.

此错误消息不断针对一项又一项服务显示，直到我更新了每个软件包的版本。基本上它迫使我更新每个包。

这是我正在使用的发布配置文件:

<?xml version="1.0" encoding="utf-8"?>
<PublishProfile xmlns="http://schemas.microsoft.com/2015/05/fabrictools">
    <ClusterConnectionParameters .... />
    <ApplicationParameterFile Path="..\ApplicationParameters\PublishProfName.xml" />
    <CopyPackageParameters CompressPackage="true" />
    <UpgradeDeployment Mode="Monitored" Enabled="true">
        <Parameters FailureAction="Rollback" Force="True" />
    </UpgradeDeployment>
</PublishProfile>

这是 yaml 上的 devops 任务:

- task: ServiceFabricDeploy@1
  inputs:
    publishProfilePath: $(publishProfilePath)
    applicationPackagePath: $(applicationPackagePath)
    serviceConnectionName: ${{ parameters.connection }}
    overrideApplicationParameter: true
    
    upgradeMode: Monitored
    FailureAction: Rollback
    # 30 mins timeout
    UpgradeTimeoutSec: 3600 

这个问题我在网上查过。一般来说，人们谈论如何确保所有代码更改的服务都有版本更新。就我而言，我确信版本已针对更改的服务进行了更新。

如何配置部署，使其不进行任何代码比较并仅更新具有更新版本的服务？

Answer 1

根据我的经验，这里答案的要点是，Service Fabric 仅将整个应用程序部署为每个内部包的单一版本集合，但让您可以访问服务部署的具体细节以进行自定义。因此，即使您没有对该应用程序中的单个服务进行更改，最终它仍然会捆绑在部署到集群的应用程序中，并且您仍然必须决定是否部署该服务或不(或使用提供的 Deplooy-FabricInstaller.ps1 脚本来处理此类部署)。

我的建议(基于我自己的管道)是，如果您确实相信您的脚本能够正确检测更改的版本，并且您确实希望避免升级尚未更改的服务(大概是为了减少部署时间) )是改变你的方法，而不是与应用程序部署作斗争，而是优化服务安装。

像平常一样构建解决方案，并利用 ServiceFabricUpdateManifests@2 任务让它自动替换每个服务的所有版本。

在这一点上，我通常偏离标准管道。

• 我有一个脚本，可以从 ApplicationManifest.xml 中删除 DefaultServices 以删除自动服务部署
• 我运行一个单独的脚本来检查应用程序是否已存在(以告知它是全新部署还是升级)
• 基于安装/升级，我采用不同的部署任务路线并捕获有关集群中现有服务的信息

应用程序完全部署后，我编写了一个自定义脚本，该脚本类似于随附的 Deploy-FabricApplication.ps1 脚本，该脚本会迭代每个服务，并根据它们在新部署中的状态自行安装、升级或删除它们利用 ServiceTemplates 填充配置值。

因为我控制了整个实际服务安装过程，所以我可以根据我收集并通过构建管道传递的数据推断出什么应该和不应该独立于应用程序部署而实际部署。

您可能会发现，与您正在采用的方法相比，采用此路线的定制过程要容易一些。