有一篇名为“十二要素应用程序”(http://www.12factor.net/)的优秀文档,其中作者试图定义设计、构建和部署现代应用程序即服务的完美方法。
该文档非常笼统,在许多情况下,所描述的实践并不是最佳的,不容易实现,或者与Microsoft的最佳实践相冲突。该文档不鼓励使用配置文件,而是使用环境变量进行配置。这在常见的.NET中似乎是不正确的(最好?)练习使用XML配置文件。
在理想的情况下(即忘记预算/技术/技能限制),在一个组织中,所有部署都选择Microsoft平台作为首选平台,选择.NET/TFS作为开发环境/工具,如何遵循十二要素应用程序中的指导?
有没有这样的应用程序的好例子(也许是一个开源的,有一个很好的参考架构的应用程序)?
发布于 2012-06-23 06:05:02
我读过关于配置的部分,作者显然不理解.NET中配置文件的用法,他们表达的问题是我们过去在.ini文件中遇到的问题。.NET不存在这些问题,因为:
发布于 2012-06-29 02:23:39
我想说,.NET配置文件符合其中的一半。
虽然我可以同意他们的要求的意图,但我认为他们关于环境变量的建议是一个糟糕的建议。他们之所以选择环境变量,是因为他们认为环境变量是最小的公分母,并且在所有平台上都可用,但它们实际上并不是在所有平台上都可用。如果您运行的是部分信任的web应用程序(在共享主机平台上很常见),则可能无法获取/设置环境变量。
环境变量是按机器设置的。如果我必须对我的生产环境进行配置更改,我希望在一个地方对所有服务器进行一次更改。环境变量不允许您这样做。
虽然我能理解他们的观点,但你不希望将秘密存储在所有开发人员都可以访问的版本控制中。对配置进行版本控制肯定有好处。当您的生产环境由于配置更改而停机时,很容易就会问。“什么改变了”?某人只是通过ssh连接到一台prod机器并设置了一个环境变量,留下的审计跟踪可能不那么容易跟踪。话虽如此,我通常不会将配置文件存储在与其余代码相同的版本控制部分中。我把它们放在一个有安全限制的文件夹中,这样只有必要的人才能访问。可以想象,您可以更进一步,将它们放在不同的项目中。
例如。他们主页上的第一个要点是“使用声明性格式进行自动化设置,以最大限度地减少加入项目的新开发人员的时间和成本”;我敢打赌,所有那些不应该在任何地方的文件中的配置设置都在厨师的菜谱中。如果有人花了很长时间来获得正确的厨师食谱,而没有将其存储在某个版本控制中,我会感到惊讶。
我认为他们可以以不同的方式编写配置页面,只要求将您的配置与代码分开。将其保存在单独的文件中(不要将其嵌入到代码中),并将其单独存储在某个地方(不要将其放在同一存储库中)。您的部署过程将把这些(代码和配置)重新组合到一个可部署的包中,但在此之前,它们应该是分开的。
我对配置的建议是将配置视为“附加资源”,并将其存储在后备存储(数据库)中。
发布于 2012-06-29 09:55:11
设计中有很多问题,我觉得有点幼稚。
例如,在Backing部分中,他们指出您应该能够在不考虑代码更改的情况下换出数据存储。
问题是,为了利用任何特定数据存储的性能和功能优势,您将自然而然地倾向于利用您开始使用的存储的特定功能。
此外,并不是每个数据存储都支持一组通用的命令,以便您可以轻松地从一个命令移动到另一个命令。您不能只是将表结构直接应用于CouchDB,然后期望向其抛出SQL命令。
这意味着您必须放置一个前端,以便从本质上用一组公开为web服务的命令来包装每个特定的数据存储……imho,这使得开发变得更加困难,而带来的好处却很少(如果有的话)。
现在,如果他们将其限制为将类似的服务器(本地mysql)交换到远程服务器(Amazon RDS),那么通过url访问数据存储资源的要求就无关紧要了。此外,没有必要要求该移动不发生代码更改,因为您不应该仅仅为了支持在不同服务器上运行完全相同的数据库而更改代码。
以上只是我诚实地看过的第一个领域。正如John Saunders所说,config one也显示出对.Net等技术的完全缺乏理解。
https://stackoverflow.com/questions/11086388
复制相似问题