服务结构中的配置转换? [英] configuration transforms in service fabric?

问题描述

通过Visual Studio创建空的Service Fabric应用程序时，项目模板将自动为您创建不同的配置文件，例如Node1.XML，Node5.XML等.

When you create an empty Service Fabric application through Visual Studio, the project template will automatically create different configuration files for you such as Node1.XML, Node5.XML, etc.

与我们要针对的环境相比，我们对节点的数量的关注要少得多.

We are much less concerned with the number of nodes than with which environment we are targeting.

仅具有1个配置文件并从中创建转换与Service Fabric建议背道而驰吗?

Is it contrary to Service Fabric recommendations to have simply 1 configuration file and create transforms from it?

例如，我们可能会有类似的内容:

For example we might have something like this:

<?xml version="1.0" encoding="utf-8"?>
<PublishProfile xmlns="http://schemas.microsoft.com/2015/05/fabrictools">
  <!-- ClusterConnectionParameters allows you to specify the PowerShell parameters to use when connecting to the Service Fabric cluster.
       Valid parameters are any that are accepted by the Connect-ServiceFabricCluster cmdlet.

       For a remote cluster, you would need to specify the appropriate parameters for that specific cluster.
         For example: <ClusterConnectionParameters ConnectionEndpoint="mycluster.westus.cloudapp.azure.com:19000" />

       Example showing parameters for a cluster that uses certificate security:
       <ClusterConnectionParameters ConnectionEndpoint="mycluster.westus.cloudapp.azure.com:19000"
                                    X509Credential="true"
                                    ServerCertThumbprint="0123456789012345678901234567890123456789"
                                    FindType="FindByThumbprint"
                                    FindValue="9876543210987654321098765432109876543210"
                                    StoreLocation="CurrentUser"
                                    StoreName="My" />

       Example showing parameters for a cluster that uses Azure Active Directory (AAD) security:
       <ClusterConnectionParameters ConnectionEndpoint="mycluster.westus.cloudapp.azure.com:19000"
                                    AzureActiveDirectory="true"
                                    ServerCertThumbprint="0123456789012345678901234567890123456789" />
  -->
  <ClusterConnectionParameters ConnectionEndpoint="dzimchuk.westeurope.cloudapp.azure.com:19000" AzureActiveDirectory="true" ServerCertThumbprint="F52285B5F344C8D3C0B7ADDE0B421F08CF38CB1A" />
  <ApplicationParameterFile Path="..\ApplicationParameters\Cloud.xml" />
  <UpgradeDeployment Mode="Monitored" Enabled="true">
    <Parameters FailureAction="Rollback" Force="True" />
  </UpgradeDeployment>
</PublishProfile>

作为构建过程的一部分，我们希望能够设置配置(调试/发布)，并在此基础上更改配置.有可能实现这一目标，还是有悖于SF哲学?

As part of our build process, we would like to be able to set the configuration (Debug/Release) and based on this, the configuration would be changed. Is it possible to achieve this, or would it be contrary to the SF philosophy?

另一个配置示例是这样:

Another configuration example would be this:

<?xml version="1.0" encoding="utf-8" ?>
<Settings xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2011/01/fabric">

  <Section Name="Logging">
    <Parameter Name="IncludeScopes" Value="false" />
    <Parameter Name="LogLevel:Default" Value="Debug" />
    <Parameter Name="LogLevel:System" Value="Information" />
    <Parameter Name="LogLevel:Microsoft" Value="Information" />
  </Section>

  <Section Name="Authentication">
    <Parameter Name="AzureAd:B2C:Instance" Value="e.g https://login.microsoftonline.com/" />
    <Parameter Name="AzureAd:B2C:TenantId" Value="B2C tenant ID" />
    <Parameter Name="AzureAd:B2C:Audience" Value="B2C Application ID" />
    <Parameter Name="AzureAd:B2C:Policy" Value="" />
  </Section>

  <Section Name="ApplicationInsights">
    <Parameter Name="InstrumentationKey" Value="" />
  </Section>

  <Section Name="Redis">
    <Parameter Name="Configuration" Value="" />
    <Parameter Name="InstanceName" Value="BookFast.Booking_" />
  </Section>

  <Section Name="FacilityApi">
    <Parameter Name="ServiceUri" Value="fabric:/BookFast/FacilityService" />
    <Parameter Name="ServiceApiResource" Value="" />
  </Section>

  <Section Name="Test">
    <Parameter Name="FailRandom" Value="false" />
  </Section>

</Settings>

对于上述参数，我们将如何为不同的环境维护值?是否要使用单独的文件，还是可以进行配置转换然后针对不同的构建配置?

How would we maintain values for for different environments for the above parameters? Are separate files the way to go, or can we do config transforms and then target different build configurations?

推荐答案

仅具有1个配置文件并从中创建转换与Service Fabric建议背道而驰吗?

Is it contrary to Service Fabric recommendations to have simply 1 configuration file and create transforms from it?

我不知道.如果它对您有用，并且您的团队很高兴，那么这很重要.稍有不同的是，我通过名为

I'm not aware. If it works for you and your team is happy then that is all that matters. On a slightly different note, I applied App Config transforms to a WPF app (which wasn't a policy and wasn't technically achieveable by default) by a 3rd party tool called SlowCheetah and it worked rather well.

作为构建过程的一部分，我们希望能够设置配置(调试/发布)，并在此基础上更改配置.有可能实现这一目标，还是有悖于SF哲学?

As part of our build process, we would like to be able to set the configuration (Debug/Release) and based on this, the configuration would be changed. Is it possible to achieve this, or would it be contrary to the SF philosophy?

试一试SlowCheetah.老实说，我还没有在Service Fabric中尝试过.

Give SlowCheetah a try. To be honest I have not tried it with Service Fabric.

斯科特·汉瑟曼:

人们希望将其app.config或任何XML文件作为其构建的一部分告诉我更多

Folks want to transform their app.configs, or any XML file as part of their builds Tell me more

OP:

对于上述参数，我们将如何为不同的环境维护值?是否要使用单独的文件，还是我们可以进行配置转换，然后针对不同的构建配置?

How would we maintain values for for different environments for the above parameters? Are separate files the way to go, or can we do config transforms and then target different build configurations?

配置转换(CT)是一个热门话题.

Configuration Transforms (CT) are a bit of hotly-debated topic.

虽然我发现在开发机上使用CT并没有问题，并说测试环境，但是我建议不要将它们用于生产.

Whilst I see no problem using CT for dev machines and say test environments, I would advise not to use them for Production.

原因是它们是构建过程的产物，而不是由SCM管理的静态工件.

但是Micky" ，我听你说，"EXE和DLL是构建过程的产物"..

是的.但是二进制文件是编译源代码的结果，别无选择.通常，您不会在.NET(尤其是IIS)中最广泛地编译" 配置文件. WCF甚至Service Fabric都不是必需的.

True. But there is no alternative to binaries which are the result of compilation of source code. You generally don't "compile" configuration files in the broadest terms in .NET, specifically IIS; WCF and even Service Fabric it is not mandatory.

在构建过程的一部分时，您是否需要生产中当前版本的配置副本，或者说对于两个构建之前的客户站点之一，您需要再次运行构建过程以获取产生的文件.

When part of a build process, should you need a copy of the configuration for the current version in Production, or say for one of your customer's sites from two builds ago, you need to run the build process again in order to obtain the produced file.

与此有关的问题是:

1. 构建过程可能需要相当长的时间
2. 产生的文件与历史版本完全匹配的保证金为零
3. 这种转换后的文件受转换工具的支配，您能证明该工具的未来版本不会出错或损坏文件吗?

1. The build process may take considerable time
2. There is zero guarentee that the produced file exactly matches the historical version
3. Such transformed files are at the mercy of the transform tool, can you prove that future versions of the tool won't fault or mangle your file?

我的建议是为所有生产节点手动维护配置文件

My advice is to manually maintain configuation files for all your production nodes

这篇关于服务结构中的配置转换?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！