如何在本地/本地托管Azure辅助角色?

Jax*_*ian 6 c# azure azure-worker-roles

一些背景......

我们第一次冒险进入Azure,并试图以婴儿步骤进行.目前,我们的第一个应用程序将成为工作者角色,监视队列以处理请求(例如发送电子邮件或执行一些屏幕抓取),我们只需从我们的内部部署MVC应用程序和WCF服务插入队列.我们稍后会将MVC应用程序和WCF服务移至Azure.

我们的开发工作流程基本上是这样的(稍微修改一些不重要的方式):

  1. 在本地和一些共享服务器上开发.检查源代码管理.
  2. 每15分钟,构建服务器构建并部署到"开发"环境(如果我们需要达到本地以外的"开发"环境,则可以兼作CI和覆盖)
  3. 技术测试人员手动触发构建服务器以将最后成功的"Dev"构建部署到测试环境(或者替代地,先前部署的测试构建,包括/排除数据库).
  4. 技术测试人员和业务测试人员手动触发构建服务器,以将最后成功的"测试"构建(或者,之前部署的测试构建,包括/排除数据库)部署到QA环境.
  5. 在某些时候,我们合并了QA批准部署的变更集.
  6. 之后,我们的生产构建服务器将此版本部署到暂存,然后再部署到我们的生产环境(我们在并行/独立环境中托管N次).

正如您所知,我们有许多内部托管版本的应用程序,供内部支持人员在达到生产之前进行攻击.我希望这些对Azure的依赖程度相当低.我不需要完成服务器依赖性,所以我们将继续使用Azure队列和其他一些机制,因为它们很容易继续使用,但我们不希望我们的构建服务器必须部署到Azure对于这些环境中的每一个(并且支付所有托管费用).

那么,我们如何才能合理地在我们实际测试部署到Azure的代码的方式上部署我们的工作者角色内部部署?

建议的一个选项是我们将worker角色创建为包装器/外观,并在类库中完成所有实际工作,这是我们的计划.但是,允许我们"托管"这一操作的后续操作是创建第二个包装器/外观应用程序,它执行与工作者角色相同的工作,只是以我们可以将其作为计划任务或窗口运行的方式服务器.最终,我不喜欢这个选项,因为整个项目在进入分段之前从未进行过测试.

是否有可能在我们创建第二个包装器/外观应用程序时执行类似的操作,而不是调用它实际引用的类库并调用Run()worker角色中的函数?

Vla*_*mir 5

您认为Azure模拟器可能会对您有所帮助吗?这些是真正的Azure提供程序和模拟器之间的差异.

为你的工人角色设置一个外观似乎是合理的.并使用适配器使任何可能的云(或其他托管)技术适应该外观?只想尝试一些想法.我之前实际上使用过这种方法,但这是一个"个人"项目.

使用PowerShell配置您的角色等等.像这样配置Azure模拟器.