[英]configuration transforms in service fabric?
当您通过Visual Studio创建一个空的Service Fabric应用程序时,项目模板将自动为您创建不同的配置文件,如Node1.XML,Node5.XML等。
我们更少关注节点数量而不是我们所针对的环境。
只需1个配置文件并从中创建转换,与Service Fabric建议相反吗?
例如,我们可能会有这样的事情:
<?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理念?
另一个配置示例是:
<?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>
对于上述参数,我们如何维护不同环境的值? 单独的文件是可行的,还是我们可以进行配置转换然后定位不同的构建配置?
只需1个配置文件并从中创建转换,与Service Fabric建议相反吗?
我不知道。 如果它适合您,您的团队很高兴那么这就是最重要的。 稍微不同的是,我通过名为SlowCheetah的第三方工具将App Config转换应用于WPF应用程序(这不是策略,默认情况下在技术上无法实现),并且它运行得相当好。
作为构建过程的一部分,我们希望能够设置配置(调试/发布),并在此基础上更改配置。 是否有可能实现这一目标,还是会违背SF理念?
试试SlowCheetah吧。 说实话,我还没有尝试使用Service Fabric。
Scott Hanselman:
人们希望将他们的app.configs或任何XML文件转换为他们构建的一部分告诉我更多
OP:
对于上述参数,我们如何维护不同环境的值? 单独的文件是可行的,还是我们可以进行配置转换然后定位不同的构建配置?
配置变换 (CT)是一个备受争议的话题。
虽然我发现使用CT开发机器并说测试环境没有问题,但我建议不要将它们用于生产 。
原因是它们是构建过程的产物,而不是SCM管理的静态工件 。
“但Micky” ,我听到你说, “EXE和DLL是构建过程的产物” 。
真正。 但是除了源代码编译结果的二进制文件之外别无选择。 您通常不会在.NET中以最广泛的术语“编译”配置文件,特别是IIS; WCF甚至Service Fabric都不是强制性的。
在构建过程的一部分时,如果您需要生产中当前版本的配置副本,或者对于两个版本之前的某个客户站点,则需要再次运行构建过程以获取生成的文件。
这个问题是:
我的建议是手动维护所有生产节点的配置文件
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.