基础设施即代码的设计原则

基础设施即代码的原则：系统能够轻松复制、系统是用完可扔的、消失的文件服务器、系统是一致的、过程是可重复的、设计经常变更。
　　
　　系统能够轻松复制
　　
　　我们应该能够毫不费力并且可靠地重建基础设施中的任何元素。毫不费力意味着无须对于如何构建元素做出任何重大的决策。在服务器上安装什么软件、安装软件的什么版本以及选择什么主机名等决策都应该包括在置备基础设施元素的脚本和工具中。
　　这种毫不费力地创建和重建基础设施任意部分的能力是非常强大的。在变更的时候，风险会更小，无须过多担心。我们可以有信心地快速处理故障，无须花费什么力气即可置备新的服务或环境。
　　
　　系统是用完可扔的
　　
　　动态基础设施的好处之一是可以轻松创建、销毁、替换、扩容和移动资源。为了利用这一点，设计系统时必须假设基础设施始终在变更。即使服务器消失了、出现了或者大小改变了，软件也应该依然正常运行。
　　这种优雅处理变更的能力让增强和修复正在运行的基础设施变得更容易，也使得服务具有更强的容错性。当共享大规模的云基础设施无法保证底层硬件的可靠性时，这种能力变得尤为重要。
　　
　　牲口，而非宠物
　　有一句流行的话：“将你的服务器视作牲口，而不是宠物。”我很怀念那些为服务器名称指定一个主题，然后为每个新置备的服务器小心选择名称的时光。但我一点也不怀念不得不手动调整每台服务器的时光。
　　铁器时代和云时代的根本差异在于，铁器时代是不可靠的软件运行于可靠的硬件之上，而云时代是软件可靠地运行于不可靠的硬件之上。
　　
　　消失的文件服务器
　　
　　服务器并不是永久存在的，这个理念需要一段时间才能被人们领会。我们曾在一个团队中使用VMware和Chef建立起了自动化的基础设施，并且养成了随意删除和替换VM的习惯。有个开发人员需要一台Web服务器来放置文档并供团队其他成员下载使用，因此在开发环境中的一台服务器上安装了Web服务应用程序并放置了文档。几天后，他吃惊地发现这台服务器上的Web服务应用程序和文档都不见了。
　　这名开发人员有些困惑，随后在Chef配置中加入了针对其文件仓库的配置，利用该工具的优势把数据持久化到SAN中。这个团队最终拥有了一个高度可靠、自动配置的文件共享服务。
　　套用一句陈词滥调：消失的服务器是一个特性，而不是bug。过去，人们临时安装工具并随意进行配置，结果导致了雪花式的、难以触碰的、脆弱的基础设施。尽管这名开发人员刚开始并不适应，但最终学会了使用基础设施即代码来构建可复制的可靠服务，即本例中的文件仓库。
　　
　　系统是一致的
　　
　　假设两个基础设施元素提供相似的服务，例如同一个集群中的两台应用程序服务器，那么这些服务器应该几乎完全相同。它们的系统软件和配置应该是一样的，除了一点点区分彼此的配置，比如IP地址。　
　　基础设施出现不一致会导致人们不相信自动化。如果一台文件服务器拥有80GB的分区，另一台拥有100GB的分区，还有一台有200GB的分区，那么无法信赖相同的操作在这些服务器上都能取得相同的结果。这会促使人们对那些不太一样的服务器做一些特殊处理，从而导致不可靠的自动化。　
　　遵循了可复制性原则的团队可以轻松构建多个完全相同的基础设施元素。如果需要修改其中一个元素（例如一台文件服务器需要更大的磁盘分区），有两种方式可以保持一致性。一是修改对服务器的配置定义，使得所有的文件服务器都拥有足够大的分区。二是添加新的类型或者角色，比如xl-file-server，其硬盘比标准的文件服务器大得多。每种类型的服务器都能被重复构建，而且保持了一致性。　　
　　能够构建和重新构建一致的基础设施，有助于解决配置漂移的问题。但很明显，还需要处理好服务器创建之后所发生的变更。
　　
　　过程是可重复的
　　
　　基于可复制性原则，对基础设施执行的任何操作都应该是可重复的。显而易见，使用脚本和配置管理工具比手动修改更容易实现这一点。不过坚持这样做并不容易，尤其对有经验的系统管理员来说更是如此。
　　假设要实现对硬盘进行分区这样看似一次性的任务，我发现登录机器执行分区比编写并测试脚本更简单。我可以查看系统磁盘，考虑服务器的需求，再结合自己的经验和知识来决定每个分区的大小、使用的文件系统类型等。
　　问题在于，团队中的其他人可能需要对其他机器的磁盘进行分区，并且可能做出了与之前稍有不同的分区决定。可能我给一台文件服务器的/var分区分配了80GB的空间，并采用了ext3文件系统，而Priya给集群中的另一台文件服务器的/var分区分配了100GB的空间，并采用了xfs文件系统。这打破了一致性原则，最终会破坏自动化的能力。
　　高效的基础设施团队有浓厚的脚本文化。如果任务可以由脚本实现，那么就编写脚本。如果任务难以脚本化，那么就深入探讨能否借助于一些技术或工具，或者换种方式来解决该任务面对的问题。
　　
　　设计经常变更
　　
　　在IT的铁器时代，对已有系统的变更很困难而且成本很高。因此，当服务器构建完成之后，限制系统的修改听上去很有道理。这需要全面的预先设计，并且考虑各种需求和情况。
　　由于无法准确预测系统的实际使用情况以及系统的需求会如何变化，因此这种方式自然会产生过度复杂的系统。讽刺的是，这样的复杂度让系统的变更和改进变得更加困难，从而导致系统不太可能长时间运转良好。
　　借助云时代的动态基础设施，对已有系统的变更比较简单，而且成本很低。然而，前提是一切设计都支持变更。软件和基础设施的设计必须在满足当前需求的同时尽可能简单。变更管理必须能安全和快速地交付变更。
　　确保系统能够安全和快速变更的首要指标是频繁地做变更。这迫使人人养成管理变更的良好习惯，开发高效、简练的流程，并采用有助于此的工具