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將信任現有緩存（因此不會清理緩存）。