有人在控制台上改过了
一句话总结
漂移是指代码宣布的状态和实际状态发生变化。 引入IaC的组织实际上面临的大部分问题都在这里。
为什么需要这个？
周五晚上出现了故障。有人进入控制台，在安全组中设置了规则。 加了一个，就关掉了急火。是正确的判断。
问题是星期一。想做与别人无关的变更。plan转过身来，
显示“将删除周五添加的那个规则”。代码中包含那个规则。
因为没有。不知道apply这样做就会复发障碍。
这就是漂移。而且这不是工具的缺陷，而是理所当然的动作 是。声明型工具把代码当成真理，把现实放在那里。
产生漂移的路径
| 路线 | 例 | 对应 |
|---|---|---|
| 紧急手动变更 | 应对故障中操作控制台 | 将事后代码反映纳入程序 |
| 其他团队的变更 | 保安团队调整政策 | 明确所有权界限 |
| 自动缩放 | 实例数量不断变化 | ignore_changes除外 |
| 云基本值 | 生成时自动赋予的标签 | 反映在代码中或忽略 |
| 其他代码库 | 两个存储库管理相同的资源 | 绝对禁止 — 所有者只有一个 |
最后一个项目是最危险的。如果两个状态文件管理同一资源的话 继续互相倒退。每个资源的所有者必须只有一个。
检测——plan是诊断工具
plan不是只有在分发前才会旋转。定期旋转
检测漂移是很好的运营。
# 아무 변경도 안 했는데 plan 에 diff 가 있다 = 드리프트
plan → 변경 없음 ✅ 코드와 실제가 일치
plan → 변경 있음 ⚠️ 조사 필요
在CI每天plan如果打开后结果没有空，会发送通知。
这样做的话，周五的变更不是在周一而是周六早上知道。
解决——三个选择
发现漂移时，答案是三个中之一。
1. 吸收到代码中 — 如果那个变更是正确的，就会反映到代码中。 这是最常见且通常正确的选择。
2. 撤销 — 如果那个变更是错误的apply强制码状态为。
但是，首先要确认为什么会有这样的变更。
3.从管理对象中删除—如果是像自动缩放一样原来的变动值的话
ignore_changes所以只排除那个属性。不是把整个资源都排除在外
关键是用属性单位进行筛选。
导入——把已经有的东西放入代码中
IaC的引入一般不会从白纸开始。已经手动制作好的资源 有数百个，需要用代码转移。
绝对不能在这里做的事情：删除后重新创建。如果是正在运行的资源的话 是停机时间，如果有数据的话会丢失。
请写入导入。将实际资源注册到状态文件中，工具“这个是 让他们认识到“是我管理的”。
1. 자원의 실제 설정을 조사한다
2. 그와 똑같은 코드를 작성한다
3. import 로 상태에 등록한다
4. plan 을 돌려 '변경 없음' 이 나올 때까지 코드를 다듬는다
4号是核心。plan是空的导入结束。diff还剩 保持原样继续的话，下次apply时那个资源会变。
处理状态文件时
状态文件包含资源的实际ID、属性、依赖关系。认证信息 也有用平文进入的情况。
- 放在远程后台，打开锁定。两个人同时apply的话 状态被打破。
- 打开版本管理。这是恢复错误apply的唯一手段。
- 不会提交到git上。可能会包含秘密。
- 不手动编辑。如果绝对必要，请写工具提供的状态命令。
在现场相遇的样子
- 新入职者第一次
apply做了后删除了别人的手动更改→没有读plan。 - 自动缩放组大小每次都以diff的形式出现→
ignore_changes没有。 - 状态文件在本地，两人互相覆盖→远程后台和锁定缺失。
在下面的理论中看到的东西
在接下来的阅读中，在复制漂移对应到多个环境时，模块边界在哪里 看看是否应该保留。吸收、反馈、排除中，将哪些决定放入共同模块，哪些 请尝试将决定留存在呼叫环境中，看看是否可以减少变更爆炸半径。