Azure存储：暂存与生产环境
在使用Azure存储时，有时候需要区分是在staging环境还是production环境下运行。下面是一些解决方法：
1. 首先，需要安装Microsoft.Samples.WindowsAzure.ServiceManagement库。可以通过nuGet包“Windows Azure Service Management Library”来获取。
2. 其次，需要创建一个X509Certificate2证书，并按照指示上传到订阅证书存储库。同时，还需要将带有私钥的.PFX文件上传到实际云服务证书存储库。可以参考以下链接的指南：创建和上传Windows Azure管理证书。
3. 然后，需要在app.config文件中定义服务端点。可以使用以下代码：
4. 接着，创建一个名为“GetServerInstance”的静态类。以下是代码示例：
public static class GetServerInstance
{
const string SubId = "your azuresubscriptionid";
public static bool IsProductionEnvironment()
{
var currentInstance = RoleEnvironment.DeploymentId;
var mgmtChannnel = ServiceManagementHelper.CreateServiceManagementChannel("WindowsAzureEndPoint",GetCertifcate());
var serviceDetails = mgmtChannnel.GetHostedServiceWithDetails(SubId, "your-cloud-service-name", true);
var currentDeploymentSlot = serviceDetails.Deployments.First(p => p.PrivateID == currentInstance).DeploymentSlot;
if (currentDeploymentSlot == DeploymentSlotType.Staging)
return false; //staging server
if (currentDeploymentSlot == DeploymentSlotType.Production)
return true; //production server
}
private static X509Certificate2 GetCertifcate()
{
string certificateThumbprint = RoleEnvironment.GetConfigurationSettingValue("CertificateThumbprint");
if (String.IsNullOrEmpty(certificateThumbprint))
{
return null;
}
var certificateStore = new X509Store(StoreName.My, StoreLocation.LocalMachine);
certificateStore.Open(OpenFlags.ReadOnly);
var certs = certificateStore.Certificates.Find(X509FindType.FindByThumbprint, certificateThumbprint, false);
if (certs.Count != 1)
{
return null;
}
return certs[0];
}
}
5. 最后，在worker role中调用IsProductionEnvironment方法来确定当前环境是否为production环境。以下是示例代码：
if (GetServerInstance.IsProductionEnvironment())
{
//Do work! I'm in production
};
需要注意的是，需要根据部署情况将证书的存储位置更改为LocalMachine或CurrentUser。此外，由于SDK模拟器的部署ID与云中的部署ID不同，因此无法在本地完全测试该代码。
问题出现的原因：根据作者的描述，他在生产/验收/测试环境中管理应用程序时，为每个环境创建了云服务、存储账户、SQL Azure服务器和数据库、AppFabric命名空间和虚拟机等组件。作者提到，他只在需要对生产环境进行VIP交换时才使用暂存部署插槽，而其他环境都将应用程序的版本运行在生产部署插槽中。这种做法有一些优点，如可以轻松测试新版本、每个环境可以有不同的安全性设置、可以使用真实的URL和SSL测试应用程序的集成性能等。另外，Windows Azure Storage的可扩展性目标适用于存储账户级别，如果在所有环境中使用单个存储账户，可能会降低生产环境中应用程序的性能。
解决方法：根据作者的描述，解决方法包括使用不同的存储账户来避免测试环境对生产环境的影响，使用Visual Studio可以方便地管理每个环境的设置，以及脚本化创建这些服务的过程。
以下是整理后的文章：
在管理生产/验收/测试环境时，我使用以下方式（注意我没有使用"staging"这个词）。对于每个环境，我会创建以下组件（根据项目的需要）：
- 云服务
- 存储账户
- SQL Azure服务器 + 数据库
- AppFabric（ACS等）命名空间
- 虚拟机
假设我有一个名为"myapp"的应用程序，那么我的环境如下：
生产环境：
- 云服务：myapp-prod.cloudapp.net
- 存储账户：myapp-prod
- 包含一个数据库的SQL Azure服务器：MyApp
验收环境：
- 云服务：myapp-acce.cloudapp.net
- 存储账户：myapp-acce
- 包含一个数据库的SQL Azure服务器：MyAppAcce
测试环境：
- ...
因此，所有环境都有一个运行在生产部署插槽中的应用程序版本。我只在需要对生产环境进行VIP交换时才使用暂存部署插槽（注意生产部署插槽和生产环境之间的区别）。
这种每个环境都有专用组件（如存储账户）的做法有一些优点：
- 可以轻松测试新版本而不影响实际应用程序。
- 每个环境可以有不同的安全设置（例如，所有开发人员都可以访问测试存储账户的密钥）。
- 如果正在测试应用程序，可以使用真实的URL和SSL而不是冗长且丑陋的暂存URL。
- 可以轻松测试与ACS的集成，因为每个环境都有自己的命名空间。
- 使用Visual Studio可以轻松管理每个环境的设置。
- 最后但并非最不重要的是，需要知道Windows Azure Storage的可扩展性目标适用于存储账户级别。这意味着如果在所有环境中使用单个存储账户，可能会降低生产环境中应用程序的性能，因为在暂存环境中对应用程序进行了压力测试。如果为每个环境使用一个存储账户，就不会在执行某些操作时影响其他环境。
这些就是我得出的结论...只是设置所有这些服务有点麻烦。我需要研究如何脚本化创建这些服务的过程。
Azure存储：暂存与生产环境
在使用Azure存储的过程中，有一个问题需要解决：如何在部署代码时根据配置文件选择合适的存储账户和数据库，因为代码可能会部署在暂存或生产环境中。然而，RoleInstance类没有提供区分暂存和生产环境的方法。
解决这个问题的唯一选择是调用Service Management API，并根据新环境选择相应的存储账户和数据库。另外，当进行VIP交换时，暂存环境会变成生产环境（反之亦然），这会给问题增加一些复杂性，因为现在您需要根据新环境切换存储账户和数据库的连接字符串。
我很想了解其他人是如何解决这个问题的。
我自己的解决方案是创建两个云服务，一个用于生产环境，一个用于测试环境，而不是使用单个云服务的暂存和生产环境。