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

1Generator

在系統啟動時，generator會觸發cloud-init。
如果系統存在
 
/etc/cloud/cloud-init.disabled這個檔案，或者核心有設定禁止cloud-init
(/proc/cmdline 中有 cloud-init=disabled) 則不會觸發cloud-init
觸發cloud-init 後按照以下順序執行.

2Local

這個階段所做工作不多，主要是找到資料來源、配置網路等。
關於配置網路
一種是通過元資料配置網路
一種是通過cloud-init 配置“dhcp on eth0”, 這種是雲實例網路配置機制中最多的一種
一種是禁止配置網路，可以在配置檔案/etc/cloud/cloud.cfg中設定network: {config: disabled}
該階段在配置檔案
 
/etc/cloud/cloud.cfg中沒有對應模組

3Network

這個階段主要是配置網路，阿里雲實例中該階段主要配置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。此功能的使用者必須知道，當系統的程式碼執行時，系統正在啟動

4Config

這個階段主要執行配置模組，這個階段執行的模組對其他階段不會產生影響。阿里雲實例中這個階段主要執行
磁碟,掛載分割槽,設定系統密碼，設定repo源，ntp/chrony時間同步設定等。
該階段對應配置檔案/etc/cloud/cloud.cfg 中的這個部分 cloud_config_modules

5Final

這個階段主要是作為引導的最後部分(可以理解為傳統的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將信任現有快取（因此不會清理快取）。