啟動配置固化 fstab 開機自啟動持久化 - Elastic Compute Service

本文介紹如何為Elastic Compute Service執行個體配置持久化的雲端硬碟掛載和業務進程自啟動，並建立配套的監控警示體系，確保執行個體在非預期重啟後能自動回復服務，提升系統穩定性。

業務情境

Elastic Compute Service執行個體可能因作業系統OOM（Out of Memory）、宿主機宕機等原因出現非預期重啟。執行個體重啟後，作業系統內部的臨時配置，例如手動掛載的雲端硬碟、手動啟動的業務進程等，並不會自動回復。這可能導致依賴資料盤的服務無法啟動，或核心業務長時間中斷，影響業務的連續性和可用性。

方案架構

本方案旨在通過配置固化，將這些臨時操作轉變為永久配置，使執行個體具備在異常重啟後自動回復業務運行狀態的能力。同時，通過組合使用作業系統內建功能與阿里雲監控服務，構建一個具備自動回復和監控警示能力的彈性系統。

雲端硬碟掛載固化：利用 Linux 的 /etc/fstab 檔案，將雲端硬碟的掛載資訊永久記錄。通過使用裝置的 UUID（通用唯一識別碼）而非裝置名稱（如 /dev/vdb）進行配置，避免因裝置名稱在重啟後可能發生變化而導致的掛載失敗。
業務進程固化：採用 systemd 服務管理業務進程。systemd 是現代 Linux 系統的標準初始化系統，能夠實現服務的開機自啟動，並在服務異常退出時自動拉起，確保業務進程的持續運行。
狀態監控與驗證：
- 監控：配置CloudMonitor服務，對雲端硬碟掛載點、核心業務進程以及執行個體重啟事件進行監控。當自動回復失敗或發生異常時，能夠及時發送警示。
- 驗證：使用雲助手的故障演練外掛程式，在非生產環境中類比執行個體宕機，以端到端地驗證配置固化和監控警示的有效性。

實施步驟

以下步驟將引導完成從雲端硬碟掛載、進程自啟動到監控警示和最終驗證的完整配置。

步驟一：配置雲端硬碟開機自動掛載

此步驟的目標是確保資料盤在執行個體重啟後能夠被自動掛載到指定目錄。推薦使用 UUID 來標識雲端硬碟，因為它在執行個體生命週期內保持不變，比裝置名稱（如 /dev/vdb1）更可靠。

備份 fstab 檔案
在修改系統關鍵設定檔 /etc/fstab 之前，務必執行備份，以便在配置錯誤時能夠快速恢複。
```
sudo cp /etc/fstab /etc/fstab.bak
```
擷取雲端硬碟的 UUID
運行 blkid 命令擷取目標資料分割的 UUID。此處以分區 /dev/vdb1 為例。
```
sudo blkid /dev/vdb1
```
命令會返回類似如下的輸出，記錄其中的 UUID 值。
```
/dev/vdb1: UUID="f1645951-134f-4677-b5f4-c65c71f8f86d" TYPE="ext4" PARTUUID="..."
```
將掛載資訊寫入 /etc/fstab
編輯 /etc/fstab 檔案，在檔案末尾添加新的掛載條目。
```
sudo nano /etc/fstab
```
按照以下格式添加新行，將 <Your-UUID>、<掛載點> 和 <檔案系統類型> 替換為實際值。
```
# <裝置>         <掛載點>    <檔案系統類型>    <掛載選項>      <dump> <pass>
UUID=<Your-UUID>  /mnt        ext4        defaults,nofail   0      2
```
關於 nofail 掛載選項：
- 作用：nofail 選項確保即使該雲端硬碟因故無法掛載，執行個體也能正常啟動，而不會卡在啟動過程中等待掛載。
- 適用條件：推薦為所有非系統關鍵的資料盤添加此選項。
- 風險提示：使用此選項後，掛載失敗時，系統不會在啟動時報錯。因此，請在後續步驟中對掛載點進行監控，以便及時發現並處理掛載問題。
驗證自動掛載配置
在不重啟執行個體的情況下驗證 /etc/fstab 配置的正確性。
```
# 卸載當前掛載點，例如 /mnt
sudo umount /mnt

# 重新載入 /etc/fstab 中的所有條目
sudo mount -a

# 檢查掛載是否成功
sudo lsblk -f
```
如果 lsblk -f 命令的輸出顯示目標裝置已正確掛載到指定目錄，則表示配置成功。如果 mount -a 命令報錯，說明 /etc/fstab 檔案配置存在問題。此時，可通過VNC串連執行個體，然後執行 sudo mv /etc/fstab.bak /etc/fstab 命令從備份中恢複，以確保執行個體能夠正常重啟。

步驟二：配置業務進程開機自啟動與服務保活

此步驟的目標是使用 systemd 將業務進程註冊為系統服務，實現開機自啟動和異常退出後自動重啟。

方法一：systemd（推薦）：提供更強大、透明和可定製的服務管理能力，是生產環境的最佳實務。配置雖稍顯複雜，但提供了對服務依賴、運行使用者、環境變數等方面的精細控制。
方法二：使用雲助手外掛程式進行服務保活：雲助手的 ecs-tool-servicekeepalive 外掛程式能自動產生 systemd 配置，操作簡單。適用於對服務管理細節要求不高的簡單情境。

本教程採用 systemd 手動設定方式。

（可選，推薦）為應用建立專用使用者
為了遵循最小許可權原則，避免使用 root 使用者運行業務進程。
```
sudo groupadd myapp
sudo useradd -r -s /bin/false -g myapp myapp
```

建立 systemd 服務組態檔

在 /etc/systemd/system/ 目錄下建立一個以 .service 結尾的服務檔案，例如 myapp.service。

sudo nano /etc/systemd/system/myapp.service

將以下模板內容粘貼到檔案中，並根據實際情況修改。

[Unit]
Description=My Application Service
# 定義服務在網路和遠程檔案系統掛載就緒後啟動
After=network-online.target remote-fs.target
Wants=network-online.target
# 如果服務依賴於步驟一中掛載的雲端硬碟（例如 /mnt），請取消下一行注釋
# RequiresMountsFor=/mnt

[Service]
# --- 安全配置 ---
# 使用專用使用者和組運行
User=myapp
Group=myapp

# --- 回合組態 ---
# 進程的工作目錄
WorkingDirectory=/opt/myapp
# 啟動命令的絕對路徑及參數
ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.json

# --- 自動重啟策略 ---
# 僅在服務非正常退出（例如崩潰）時重啟
Restart=on-failure
# 兩次重啟之間的間隔時間
RestartSec=5s

[Install]
# 定義服務所屬的 target，multi-user.target 表示在多使用者模式下啟用
WantedBy=multi-user.target

啟用並啟動服務

執行以下命令使 systemd 重新載入配置、啟用服務的開機自啟動，並立即啟動該服務。

# 重新載入 systemd 配置
sudo systemctl daemon-reload
# 啟用開機自啟動
sudo systemctl enable myapp.service
# 立即啟動服務
sudo systemctl start myapp.service

驗證服務狀態
檢查服務的運行狀態，確保其已成功啟動並已啟用開機自啟動。
```
sudo systemctl status myapp.service
```
如果輸出中的 Active 欄位顯示為 active (running)，且 Loaded 行包含 enabled，則表示配置成功。

步驟三：配置監控與警示

配置固化後，建議建立配套的監控體系，以便在自動回復機制失效時第一時間收到警示並介入處理。

掛載點可用性監控
- 目的：確保資料盤掛載點（如 /mnt）始終可用。
- 實現：使用指令碼（df -h）定期檢查關鍵掛載點是否正常，發現掛載丟失及時警示。
關鍵進程存活監控
- 目的：確保核心業務進程（如 myapp）運行。
- 實現：使用CloudMonitor的進程監控功能。
執行個體異常重啟監控
- 目的：感知系統事件。
- 實現：使用CloudMonitor的系統事件警示功能。

更多監控配置資訊，請參見CloudMonitor。

步驟四：驗證配置固化效果（宕機演練）

完成所有配置後，必須通過類比故障來驗證整個自愈和警示體系是否按預期工作。

重要

故障演練會導致執行個體重啟和業務中斷，請務必在非生產環境或可接受的維護視窗內執行。

執行故障注入
使用雲助手外掛程式 ecs-fault-oscrash 類比核心 Panic，觸發執行個體的非預期重啟。
```
sudo acs-plugin-manager --exec --plugin ecs-fault-oscrash --params inject
```
等待執行個體重啟
命令執行後，執行個體將立即崩潰並重啟。等待約3-5分鐘後，重新串連執行個體。
端到端驗證
- 檢查雲端硬碟掛載：執行 lsblk -f，確認資料盤已自動掛載。
- 檢查業務進程：執行 systemctl status myapp.service，確認商務服務已自動啟動並處於 active (running) 狀態。
- 檢查監控警示：登入CloudMonitor控制台，檢查是否收到事件警示。