Devops

声明式基础设施描述期望结果，再由工具计算变更。命令式脚本同样可以查询已有资源、实现幂等性；重复创建不是脚本天生无法避免的命运。Terraform 的价值，在于把配置、资源身份、依赖关系和拟执行操作放进一个共同模型，让评审者能够一起检查。 需要把配置与拟执行操作放在一起评审：改变地址可能改变身份关系，而外部修改也可能让完全没动过的配置产生计划。文件可追踪，并不自动等于所有操作都安全。 计划是提案，不是事务保证 普通 plan 通过 provider 读取受管理对象，把刷新后的观察结果与配置比较，再提出创建、更新、替换或删除操作。未知值、provider 的实现、执行权限，以及计划到执行之间发生的变化，都使它无法保证成功，也不能把输出理解成未来所有 API 调用的完整逐条清单。 保存计划可以让 apply 使用被评审的那份提案，而不是自动重算另一份，但并不会冻结远端系统。状态发生变化可能使保存的计划失效，执行也可能在完成部分操作后报错。计划文件和状态可能包含敏感信息，应作为受控产物保存，不要为了排错就把完整内容贴到公开日志里。 成功 apply 之后，如果输入、配置和外部环境稳定，通常应当不再出现新的变更。若持续有差异，就要检查外部控制器、计算属性、provider 缺陷和不断变化的输入。一个干净的计划只说明此次受管理范围内没有拟执行差异，不能证明云账户里所有资源都已被纳入清单，也不能保证业务服务健康。 状态保存的是身份关系 状态把配置地址绑定到真实对象，并保存 Terraform 需要的其他信息。丢失映射不会立刻删除远端资源；之后的计划可能提议创建新对象，而 apply 究竟会建出重复资源，还是遇到名称冲突，取决于 provider 和服务本身。不能把某一次 already exists 错误推广成所有资源的必然结果。 恢复时应先检查后端历史版本与可用快照。当恢复快照不适合或不可行时，import 可以把受支持的既有对象重新关联到配置地址。除了命令行方式，也有配置驱动的导入流程，并不一定要逐个手工敲命令。导入之后仍需核对资源配置和执行计划，身份绑定完成不意味着下一次 apply 一定没有变化。 共享状态需要访问控制、可恢复的历史，以及具备合适锁定能力的后端。并非所有后端都支持锁；获取锁失败会使操作停止，是否等待、等待多久还取决于锁超时等命令选项。不要为了绕过另一个合法运行而禁用锁，也不要把状态版本历史等同于完整基础设施审计。后端保存了什么记录、能恢复到哪里，都需要独立确认。 漂移与重构是两种决定 已经被状态追踪的资源在外部被修改后，需要决定保留新值还是恢复配置值。保留通常意味着更新配置，普通属性漂移不需要重新 import。refresh-only apply 会更新 Terraform 的记录，而不按照配置去改远端对象；它不会替你编辑配置，因此下一次普通计划仍可能提议把外部改动撤回。 ...