使用定义文件 基础设施即代码的基础实践是使用定义文件（definitionfile）。定义指定了基础设施元素以及应该如何配置它们。定义文件作为输入，供置备或配置这些元素实例的工具使用。例1-1就是一份数据库服务器节点的定义文件。
例1-1 使用DSL的定义文件样例
server: dbnode
base_image: centos72
chef_role: dbnode
network_segment: prod_db
allowed_inbound:
from_segment: prod_app
port: 1521 allowed_inbound:
from_segment: admin
port: 22
基础设施元素可以是一台服务器、服务器的一部分（比如用户账号）、网络配置（比如负载均衡规则），等等。不同的工具对此有不同的术语，例如playbook（Ansible）、recipe（Chef）或者manifest（Puppet）。本书使用“配置定义文件”作为这些术语的统称。
定义文件以文本文件的形式进行管理。它们可能会使用标准的格式，如JSON、YAML或者XML，也可能会定义自己的领域特定语言（domain-specific language，DSL）。
将规格和配置放在文本文件中，比将它们存储在工具的内部数据库中有更好的可访问性。这些文件也可以被当成软件源代码，适用于很多成熟的开发工具。
自文档化的系统和流程
IT团队通常要尽全力保持文档的相关性、实用性和准确性。有人可能为一个新的流程起草了一份详尽的文档，但是随着流程的执行方式发生变更和改进，这样的文档很难保持更新。此外，文档也经常存在不足。不同的人会走不同的捷径，也会做出不同的改进。有些人会实现自己的脚本来让部分流程变得更容易一些。
因此，即使文档通常被视为增强一致性和标准化甚至遵守法规的方式，这在实践中却只是对事实的虚幻构想。
有了基础设施即代码，执行流程的步骤会保存在脚本、定义文件以及实现这个过程的工具中。人们只需要添加极少量的文档，就可以开始工作了。已经存在的文档应当离源代码很近，保证这些文档在人们做出变更时触手可及、触目可见。
自动生成文档
在某个项目中，我的同事Tom Duckering发现负责部署软件到产品环境的团队坚持采用手动方式。虽然Tom用ApacheAnt实现了自动化部署，但是产品团队仍然希望有一份手写的文档来指导人工操作。
因此，Tom写了一个自定义的Ant task，可以打印出自动化部署的每个步骤。这样能生成一份包含具体步骤的文档，细致到要敲入的命令行。他所在团队的持续集成工具为每一次构建都生成了文档，这样可以保证文档的准确性和时效性。对部署脚本的任何修改都会自动包含在文档中，没有任何额外的成本。
