最近一直纠结 terraform 和各种云的组织和 IaC 处理问题

[sampeng]

Terraform 是个好东西没错，但我在实际操作中碰到一个让我纠结很久的矛盾。首先云平台不一定所有 console 网页操作一定对应 cli 命令，连 cli 都没有就更提不上什么 terraform 的支持了。这就会产生第一个矛盾，没有支持就不能完整的实现 IaC ，想实现 IaC 要么有绕过去的方法还好说。如果没有只能傻在那？这个矛盾让我郁闷很长时间了

第二个矛盾就是云端的状态是可以靠另外的手段去改的，可能是 cli ，可能是 sdk ，也可能是手动调整。而这个状态是不会 100%同步 IaC 平面的。换句话说，如果只有一个人还好办，没什么矛盾。如果是多人协作，这个状态就比较麻烦，甚至是矛盾。因为又会会出现第一个矛盾。因为为了 IaC ，不允许任何人从其他手段调整配置和脚本。


我现在只敢让一个同事对一件独立的事情实现 IaC 、因为这个问题我实在没想明白，不敢冒然大规模的去实现。

求解惑。

[dayeye2006199]

> 首先云平台不一定所有 console 网页操作一定对应 cli 命令，连 cli 都没有就更提不上什么 terraform 的支持了

需要云平台暴露 API 。但是话说回来，如果某个云平台没有 API 或者 API 功能不全，完全依赖 console UI 来完成配置，估计这个也不是什么正经的云平台。依赖于 API 的脚本化和批量化是很常见的需求，这个和 IaC 没啥太多的关系，在远古时代就是这么弄的了。

> 状态管理

首先状态不要储存在本地，可以使用对象存储或者数据库之类的远程存储，保证大家读到的状态是一份。再者，IaC 不光是技术，也是一种管理方法，理论上所有对 infrastructure 的修改都应该通过 code 的来完成。不同的人需要同时进行修改，这时和使用 git 提交代码一样，大家同时提交 PR ，如果修改之间有冲突，那也和解决代码冲突一样，不同分支进行合并或者 rebase 之后再往主分支上合并。主分支合并之后触发 terraform 的状态调整，根据修改增删查改资源。

[sampeng]

@dayeye2006199 第一个，阿里云和 aws 我都碰到过尚不支持的功能
第二个，并不说状态存在哪。而是并不是时候一样东西会去修改状态，一个简单的例子，terraform 定义一台机器，但是 ansible 定义他定时开关机或者是 update 一些事情。比如调整机器的配置吧，但这个事是放弃掉 ansible 或者其他工具。而是用代码把 tf 文件拉下来，修改再提交上去？怎么想怎么别扭啊。

管理或者团队的问题我能想明白，并不是说不好，只是这两个点我一直没想明白，不敢冒然大规模实施

[dayeye2006199]

@sampeng

API 不支持，这个无解（这类情况比较少，因为 console 本质上也是在调用 API ，可能这个 API 没有公开）。

二 -- 是的，更改需要通过提交代码的形式来完成。这个需要流程和管理方式上的变动。这也是 IaC 的意思。

[xiaket]

@sampeng 放弃 ansible 吧, 机器应该是不可更改的, 所有对机器的更改都应该通过 AMI 来实现.

[sampeng]

@xiaket 对应用的定时调整在某些需求下可能是非常频繁的。比如弹性伸缩场景和多资源类型的动态变动这样的场景下。我现在的业务模式就是在低规模时期调整一批应用的配置。然后逐步变化机器配置甚至是数据库配置。企业云端成本也是基础设施运维一个比较有挑战的话题。所以第二点让我觉得很困扰

[sampeng]

还有人么？

[wandehul]

1, Terraform 说到底，也是走的 api 调用。
2 ，只能强制要求使用 terraform 去变更线上资源，不要手动操作。


最后，前一段时间我在学习 terraform ，terragrunt 的过程中也会遇见一些问题，但是苦于学习这个人太少了，所以，我建了一个小群，好几个月了，也才几个人。
我希望各位能加入。最起码能有个讨论的地方。
@sampeng @dayeye2006199 @xiaket


[sampeng]

@wandehul 我所感到困惑的就是强制要求 terraform 去变更线上资源这一点上，terraform 擅长的是基础资源。但依然无法解释，强制性，带来的收益和损失两者之间的投入产出比是如何的？比如我前面说的弹性伸缩的场景下。再比如很容易 k8s 的资源也纳于 terraform 管理。实际碰到的情况就是，通过 ansible 或者其他工具手段组织的结构，可以比较快的响应业务的快速发展需要，而且给后续的优化提供了空间。但是如果只是用 terraform ，就扼杀了这一部分可能性。最典型的场景就是运维人员堆了成堆的运维任务要变更成 terraform 脚本，堵塞业务的发展流程