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

读书评价

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

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

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

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

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

动态基础设施的挑战

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

基础设施即代码的原则

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

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

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

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

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

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

可编程
按需获取
自服务

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

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

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

配置注册表

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

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

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

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

自动化服务器管理的目标

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