《基础设施即代码》阅读摘要

读书评价

上个周末读了下这本书，第一部分的基础理论，或者说是指导思想部分，还是蛮有启发性的。DEVOPS已经发展了这多年了，大家多少都已经有一些认识或实践了，读读这本书，一方面可以印证下你的理解是否正确，另一方面也可以帮助你认识得更加全面些。

本书的第2部分讲服务器、服务器模板和服务器更新与变更的管理模式。有一些参考价值吧，不过放在现在这时候看都是些常识罢了，可能在刚刚写这本书时的价值会更大些。

第3部分讲实践，就更加凌乱了，像系统质量、CICD、测试、连续性管理这些，，跟基础设施即代码的主题关系也不大，是不是在凑字数呢。

基础设施即代码这件事儿，确实是说起来简单，没多少内容，但做起来并不容易。

下面我把从书中第一部分摘录的一些指导思想，给大家分享下，这些内容还是很不错的，必竟需要先把一件事儿想对了，才有可能做对（做错的概率仍然会很大）。

动态基础设施的挑战

• 服务器蔓延
• 配置漂移
• 雪花服务器
• 脆弱的基础设施
• 自动化恐惧症
• 侵蚀（熵增）

基础设施即代码的原则

• 系统能够轻松复制
• 系统是用完可扔的（牲口而非宠物）
• 系统是一致的
• 过程是可重复的（幂等）
• 支持设计的经常变更

基础设施即代码的良好实践

• 使用描述式声明定义文件
• 自文档化的系统和流程
• 一切皆版本化
• 持续测试系统和流程
• 小的变更，而不是批量变更
• 让服务持续可用

动态基础设施平台的概念与要求

概念：动态基础设施平台是提供了计算资源，具体包括服务器、存储和网络，并且支持程序化分配和管理这些资源的系统。

这个平台需要具备以下的特征：

• 可编程
• 按需获取
• 自服务

不管使用了多么昂贵、先进的软件，如果服务模型既非动态也非自服务的，那么它就无法支持基础设施即代码。

选择怎样的基础设施即代码工具

• 支持命令行工具和可编程的API，如果同时有开放的源代码无疑会更好了；
• 命令行工具应该支持静默式执行；
• 支持可靠的无人值守式的执行，应该具备一些特征如幂等、事先检查、事后检查、错误可见以及参数化；
• 支持外部化的配置管理模式，工具与配置文件松耦合，使用svn/git等管理配置文件版本；

配置注册表

为什么需要配置注册表？
配置注册表不是CMDB，前者是为支持自动化而共享数据，后者是为了记录与管理资产信息。
对于需要管理和集成基础设施的脚本、工具、应用服务来说，配置注册表提供了一种信息发现的方式。

实现配置注册表的方式有很多种：

• 对于简单的基础设施，使用配置定义文件就足够了。对于复杂的基础设施而言，zookeeper/Consul/etcd都是可选的配置注册表产品。
• 为了能在动态基础设施上工作，配置注册表服务必须支持从注册表中以编程的方式添加、更新和删除条目。

注：提防掉进与配置注册表的紧耦合陷阱，这会让配置注册表成为一个新的服务脆弱性的来源。

自动化服务器管理的目标

• 能够完全按需配置一台新服务器，耗时至多不过几分钟；
• 配置新服务器时完全不需要人工参与或响应某些事件；
• 当有新的服务器配置变更时，可以自动地应用到服务器而不需要人工参与；
• 每个变更都应该被应用到所有相关的服务器上，且在该变更之后再配置的新服务器都自动包含了该变更；
• 配置以及变更服务器的过程具有可重复性、一致性、自文档和透明化等特性；
• 向服务器应用配置或配置变更的流程既容易又安全；
• 每次有服务器配置定义的变更时，都会触发运行自动化测试；
• 配置的变更和处理基础设施任务的流程变更应纳入版本控制，支持应用到不同的环境中以便支持对照性测试和阶段性发布策略；