cloud-init 基本介绍
cloud-init
主要是为了初始化实例信息，用户在购买实例时配置的实例密码，Hostname,user-data等，及实例启动时系统配置，如 repo源，ssh认证密钥等。
cloud-init 在启动时分5个阶段执行，对应于系统中服务分别是
1 Generator
2 Local 对应系统服务 cloud-init-local.service
3 Network 对应系统服务 cloud-init.service
4 Config 对应系统服务 cloud-config.service
5 Final 对应系统服务 cloud-final.service
1 Generator
在系统启动时，generator会触发cloud-init。 如果系统存在/etc/cloud/cloud-init.disabled这个文件，或者内核有设置禁止cloud-init (/proc/cmdline 中有 cloud-init=disabled) 则不会触发cloud-init 触发cloud-init 后按照以下顺序执行.
2 Local
这个阶段所做工作不多，主要是找到数据源、配置网络等。 关于配置网络 一种是通过元数据配置网络 一种是通过cloud-init 配置“dhcp on eth0”, 这种是云实例网络配置机制中最多的一种 一种是禁止配置网络，可以在配置文件/etc/cloud/cloud.cfg中设置network: {config: disabled} 该阶段在配置文件/etc/cloud/cloud.cfg中没有对应模块
3 Network
这个阶段主要是配置网络，阿里云实例中该阶段主要配置pip源,ssh，设置更新hostname等 该阶段对应配置文件/etc/cloud/cloud.cfg 中的这个部分 cloud_init_modules 此阶段运行disk_setup和mounts 模块，这些模块可以分区和格式化磁盘，并配置挂载点（例如/etc/fstab）。
这些模块不能太运行，因为它们可能只通过网络接收来自源的配置输入。例如，用户可能在描述本地装载应如何完成的网络资源中提供了用户数据。
在一些云（如Azure）上，此阶段将创建要装载的文件系统，包括/etc/fstab中具有过时（以前实例）引用的文件系统。因此，在这个阶段之后，不应该完成运行Cloudinit所需的条目/etc/fstab。 在这个阶段，一个part-handler将运行，它将会触发包括bootcmd在内的cloud-config。此功能的用户必须知道，当系统的代码运行时，系统正在启动
4 Config
这个阶段主要运行配置模块，这个阶段运行的模块对其他阶段不会产生影响。阿里云实例中这个阶段主要运行 磁盘,挂载分区,设置系统密码，设置repo源，ntp/chrony时间同步设置等。 该阶段对应配置文件/etc/cloud/cloud.cfg 中的这个部分 cloud_config_modules
5 Final
这个阶段主要是作为引导的最后部分(可以理解为传统的rc.local,系统启动后执行脚本)
该阶段对应配置文件/etc/cloud/cloud.cfg 中的这个部分 cloud_final_modules
此阶段在引导时尽可能晚一些运行，用户在登录系统后习惯于运行的任何脚本都应该在这里正确运行。包括
-软件包的安装
-配置管理插件 (puppet, chef, salt-minion)
-用户脚本，例如被传作 userdata的shell脚本
cloud-init 如何判断 系统是不是第一次启动
Cloud-init必须判断系统是否是第一次启动，当系统是第一次启动时，它会运行所有运行频率为“per-instance” 的系统配置，而在随后的系统引导中，
它应该只执行运行频率为”per-boot”的配置，下面描述cloud-ini如何判断系统是不是第一次启动，
当cloud-init 运行时，存储其内部状态的缓存，以便跨阶段和引导使用，当这个缓存存在时，cloud-init 在此之前已经启动过了，有两种因素会导致这种情况，
- 最常见的情况时，实例已经启动过了，这是第二次/后续的引导。
- 第二是情况就是 文件系统被挂载到新的实例上了，这种状况最明显的场景就是启动这个实例的镜像是从一个已经启动的实例上创建来的。
默认情况下，cloud-init 尝试通过检查缓存中的实例id 和它正在运行时确定的ID 来确定目前是哪种情况，到底是第一次启动还是第二次/后续的引导，
如果他们不匹配，那这就是实例的第一次引导，否则它就是后续的引导。在内部，cloud-init 称之为check
这种机制对于从已启动实例中捕获的镜像来说是必需的，通用的镜像附带的默认行为也是如此。然而，在有些情况下，它会引起问题。
对于这些情况，cloud init支持修改其行为以无条件信任系统中存在的实例ID。这意味着当缓存存在时，cloud init永远不会检测到新实例，
因此，导致cloud init检测到新实例（以及它的第一次引导）的唯一方法是手动删除cloud init的缓存。在内部，这种行为被称为信任。
为了配置要使用的这些行为，cloud init公保留了一个名为manual_cache_clean配置项。
- 当配置为false（默认值）时，如果实例id不匹配cloud init将检查并清理缓存（这是默认值，如上所述）。
- 如果为true，cloud init将信任现有缓存（因此不会清理缓存）。
