Azure创建关联基础结构的最佳实践

时间:2014-08-08 00:47:51

标签: azure cloud

当在azure中工作并利用队列和表格等所有PaaS产品时,我常常面临这样的困境:我是应该按需创建这些资源,还是作为配置的一部分预先创建。

例如,假设我有一个辅助角色从队列接收消息,然后将数据保存到表中。我有两个选择

选项1 - 预先配置 作为我的配置过程的一部分,我可以通过PowerShell脚本创建队列和表。在代码中,在运行时,它会期望这些资源存在,如果它们不存在,则会引发异常。

赞成

  • 该服务不需要管理员权限,因为它不需要创建任何内容
  • 所有提供工作都在一个地方(配置脚本)进行,而不是分散在代码中。

缺点

  • 服务不能“自我修复”。我的意思是,如果所需资源不存在(例如队列或表),或者可能不存在所需形式,则服务无法自动恢复。相反,它需要人工干预。

选项2 - 按需

在运行时,由于需要资源,如果它们不存在,则会创建它们。

赞成

  • 正在运行的服务可以创建它需要的任何东西,因此会更强大,并且需要更少的干预。

缺点

  • 现在,代码具有可能导致某些安全问题的提升权限

我发现自己面临这个问题,主要是在处理队列或主题/订阅时。这个

有两个相互矛盾的原因
  1. 我喜欢为每个队列创建一个共享访问密钥,并且只授予所需的权限。例如,在从队列中读取的上述场景中,我将创建一个具有只读权限的SAK。
  2. 我喜欢在需要时自动创建内容,特别是在开发过程中。这使事情变得如此简单,而且事情才有效。
  3. 我想知道的是,是否有任何建议的方法,无论是来自Azure团队还是来自更广泛的社区,使用哪个选项?任何人都可以给我任何明确的理由来选择一种选择吗?

1 个答案:

答案 0 :(得分:0)

我们曾经创建过存储容器和队列作为配置的一部分。但是在本地工作是一件痛苦的事情:开发人员有时会被代码中不相关部分抛出(并吞没)的随机异常所困扰。在一个例子中,我们浪费了一天才发现存储容器不是在本地创建的。

然后我们切换了"按需创建"并且从不后悔。

如果您正在讨论存储队列和表,而不需要提升访问权限 - 可以使用与应用程序获取存储帐户相同的访问密钥来创建容器/队列/表。

如果您谈论存储帐户和数据库,那么我们会在配置过程中执行此操作 - 创建它们需要管理证书和一些Azure Management API调用。对于从未删除/修改过的内容,这是一项额外的工作。此外,如果你的应用程序突然失去了对blob存储的访问权限,那么就会出现问题,并且尝试自动修复也不会有任何好处。