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

Question

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

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

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

赞成

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

缺点

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

选项2 - 按需

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

赞成

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

缺点

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

---

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

有两个相互矛盾的原因

1. 我喜欢为每个队列创建一个共享访问密钥，并且只授予所需的权限。例如，在从队列中读取的上述场景中，我将创建一个具有只读权限的SAK。
2. 我喜欢在需要时自动创建内容，特别是在开发过程中。这使事情变得如此简单，而且事情才有效。

我想知道的是，是否有任何建议的方法，无论是来自Azure团队还是来自更广泛的社区，使用哪个选项？任何人都可以给我任何明确的理由来选择一种选择吗？

Answer 1

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

然后我们切换了＆＃34;按需创建＆＃34;并且从不后悔。

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

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