背景
最近把我的洋垃圾 epyc 搬到学校这边来了，安装的是 esxi 平台。准备安装几台虚拟机，试一下用 kubeadm 搭建集群。
以前一直手动用 iso 装虚拟机，有点烦了，研究一下怎么把虚拟机的初始化配置给代码化，也就是 IaC 的思想，减轻心智负担。
目标
- 快速的新建指定数量的虚拟机
- 虚拟机需要支持自动执行自定义的配置
Cloud-init
Cloud-init 是一个实例初始化工具，用于配置一些基础信息，像是主机名、ip 地址、用户这些的。类似的工具有 ansible chef 等，不过针对点不同，Cloud-init 只会做实例的初始化配置，通过代码来灵活的、快速的提供一个稳定的初始环境。
IaC
我认为 IaC 最大的意义是_稳定_，通过相同的代码，一定能够得到相同的环境。减少了人为因素的干扰，同时也将操作者从重复工作中解放出来。
支持 IaC 之后，同时，也降低了重新搭建的成本，相当于，虚拟机的具体配置变得不那么重要了。因为通过同一段代码跑一遍就又可以得到一份一样的实例了（以前要手动去创建，成本高）。这样，似乎虚拟机就想容器一样，不需要“精细化”管理了。出了问题就直接全部删掉重建，反正拿代码跑一遍就又初始化了。变成了大号的容器
支持 IaC 之后，同时，也降低了重新搭建的成本，相当于，虚拟机的具体配置变得不那么重要了。因为通过同一段代码跑一遍就又可以得到一份一样的实例了（以前要手动去创建，成本高）。这样，似乎虚拟机就想容器一样，不需要“精细化”管理了。出了问题就直接全部删掉重建，反正拿代码跑一遍就又初始化了~~，变成了大号的容器~~。
Cloud Images
首先要介绍Cloud Images。
历史
传统安装操作系统都是用 iso，在 installer 的界面里面配置参数，再进行安装的。但是想想公有云的情景，我们买了一台服务器，好像不需要我们手动输入这些信息，过个一两分钟就可以直接使用了。
这是因为人家用的是Cloud Images，这个相当于是直接安装好的虚拟机的镜像。
再想想，为什么会有安装这一步呢？我们都有镜像了，live server 都能直接运行，为什么我们必须有安装这一步呢？
其实呢，这又是一个轮回了。一开始的操作系统都是专机专用的，所以操作系统一般都是预安装的。
随着硬件的种类越来越多，操作系统需要兼容的硬件也越来越多，空间占用也越来越大。逐渐有了 installer iso，它里面有很多硬件的驱动，在安装的时候只会把需要用到的驱动安装到磁盘上，这样就节约了磁盘的空间，但也多出了安装的这一个步骤。
再随着虚拟化技术的发展，现在大部分安装的平台其实都是虚拟化的硬件，硬件就只有那么几种了，安装这一个步骤好像又没有必要了，所以有了Cloud Images。
总结：虚拟化平台抹平了硬件的区别
问题
然后就遇到了一个问题，我已经安装好了的操作系统，要怎么对其进行配置呢？
以前用 installer 安装的方式，我还可以手动输入信息去配置。这个Cloud Images直接就是安装好了的，我怎么做配置呢。
由此，出现了 Cloud-init 工具。
解决方法
- 在Cloud Images镜像内安装 Cloud-init 工具
- Cloud-init 工具会在系统首次启动时从外界读取配置文件
- Cloud-init 工具根据配置文件，对实例进行初始化配置
这样的解决方案已经在业界被广泛应用了，几乎所有的 cloud image 都预装了 Cloud-init，几乎所有的公有云都是用的 Cloud-init 做的初始化。
Cloud-init 功能分析
再回到 Cloud-init
Cloud-init 做的是实例初始化工作。
实例的基础镜像都是一样的，通过传递不同的配置信息，得到不同的个性化的实例。
- 需要有一种方式向实例传递配置信息
- 对配置信息进行编码
传递配置信息
我真的看了一天的文档，找我想要的那个方式，但是就没有
通过我的不完全阅读，用户使用的配置信息的传递应该至少有这几种方式
- 直接指定：
/etc/cloud/cloud.cfg和/etc/cloud/cloud.cfg.d/*.cfg还有/run/cloud-init/cloud.cfg，这几个路径下的配置文件会被自动加载 - 内核命令行：就，可以通过内核命令行来传递配置
- 加载 iso：可以插入一张带有配置信息的 iso，会自动加载
- 设置 smbios 参数：可以通过设置 SMBIOS serial number 来传入一个 uri，会自动去请求这个地址获取配置文件
（上面这些我没有安装 Cloud-init 的架构展开，而是根据用户的操作方式进行排列）
配置信息格式
我的选型
目标
尽可能减少手工操作的步骤，尽量自动化部署。
因为配置文件都是一样的，所以我要考虑的主要是怎么传递配置文件。
直接指定
这个就意味着要修改镜像文件了，虽然 esxi 不支持链接克隆（克隆要 vCenter），修改完的镜像也只会用于一个实例，但还是觉得能够附加配置文件就先不要直接修改镜像，因为修改比较麻烦，也不方便扩展。
内核命令行
不会搞，pass。😪启动是直接从磁盘启动的，我好像没有机会修改，感觉不太行。
加载 iso
这个搞成功了，但是好麻烦，要给每台机器生成一个 iso，然后手动附加上去。作为备选方案吧。
设置 smbios 参数
这个用 qemu 测试成功了，Cloud-init 会到我起的 http server 上面读取配置文件。
然后我可以自己写一个 server，根据访问的 ip 不同，渲染出不同的配置文件，然后分发出去，这样 esxi 那边都是用同样的参数去启动，但是能得到不同的个性化的实例。简直是完美。🥰
但是，esxi不支持 修改 serial number，vmware 全家都修改不了。🤬🤬🤬
还有一种可能性，就是用 iso 加载 http server 的地址（虽然好像和直接改镜像差不多了），不过还没有试过。
Terraform
最后实在没办法了，去看了下 Terraform。也上 B 站转了圈，看到了 这个视频。
这不就是我想要的效果吗？
一行代码直接部署机器，还自动化配置 ip 地址。
虽然这个视频中用的平台是 pve，但差不多，好像用 Terraform 搞出一个 iso，附带着镜像一起启动就行了。
明天再看看。
感想
不过说到底，我们不是要做专业的运维，所以搞到这里也就差不多了，能用就行了。