前言

前面介紹完了註冊 OpsWorks 失敗的解決方案。這篇文章想分享一些在處理過程中值得分享的事情。

Userdata 的挑戰

shell script

第一個就是整個 userdata 的修改。前面有提到，做為一個超級菜鳥，其實筆者一開始連 shell script 都不太會寫，受到了前輩很多的幫忙後，才慢慢做出改善的結果。

而在整個修改過程中，筆者一開始曾寫出以下被揪正的指令：

if [ -z "$INSTANCE_ID" ]; then SET_EC2_UNHEALTHY; exit 0; fi

該指令主要在exit 0這裡不太好，因為該指令應該是用在系統沒有問題的情況下，但顯然這裡是在出錯的情況下結束的。

另外，上面可以看到，筆者下達關機的指令是透過另一個 AWS CLI Command：

aws autoscaling set-instance-health

這個做法是經過前輩建議的。事實上筆者一開始是直接透過 Linux Command，對虛擬機本人下達關機(shut down)的指令。但前輩認為比較理想的做法，應該是透過 ASG 判斷 EC2 健康狀態的方式來進行這個終止機器(terminate)的動作。因此相較於直接下達關機指令，透過設定機器為 unhealthy 的方式則應該會是更好的。

權限

不過，在實驗這個指令的過程中也很意外地遇到另一個權限問題。因為該指令是從 EC2 中下達的，雖然 userdata 的指令都會以虛擬機的最高權限來執行，但一開始開給 EC2 的權限就無法執行該指令的狀況下，這邊也歷經過一輪權限設定的繁鎖流程呢。

最後，由於錯誤處理的指令本身也會有各種預料之外的突發狀況，因此在每個過程中不斷印出相關的訊息，也是事後在排查問題時一件相當重要的事情。比如說，在一個指術的開始或結束後，或在錯誤處理機制觸發的前後，如果能加上一個echo，就很容易能夠在問題出現後找到失敗的指令。以上這些都是在學習過程中所接觸到，筆者認為非常珍貴的經驗，也在此分享給讀者。

架構與歷史的挑戰

第二件事情，在維護模式工具當時也有提到一點，就是能夠在研究的過程中摸到服務的架構，並從架構的演進中看到公司過去的各種歷史，以及，呃，包伏……的部分。比如說，我們可能光部署或架構管理工具，就有 CloudFormation、客製化工具、Terraform，以及甚至還有部分是手動建立的。每一個不同的工具都象徵某個時代的團隊，而我們就是站在巨人的肩膀上，跟據前人的建設再增加上我們自己的東西，或……也許有時候也有負責當拆彈專家的部分。

容器化的趨式

第三件事情，則是在這些過程中，筆者似乎更開始能夠理解容器化或無伺服器作為現在軟體開發趨勢的理由。虛擬機器帶來的環境問題著實非常困擾，而我們大部分在意的是程式面本身，而非底層的機器運作邏輯。因此敝公司目前的新專案，也都全部以容器化的方式來進行，筆者現在是完全可以理解的。

最後，雖然主要問題都已經解決，但我們由於有設定機器啟動失敗的相關警報，因此我們仍然會儘可能避免不要一次大量加開機器，否則相關警報還是非常煩人的。但也因為機器啟動失敗會有各種原因，因此我們也不能直接將該警報關掉。這直到現在，都還或多或少困擾著我們團隊。

後記

關於 OpsWorks 註冊失敗的日常維運主題到此告一個段落。在這整個過程中雖然有許多技術上的挑戰，但溝通上的問題卻相對少上許多。雖然技術上的各種困難也並非簡單解決，但在心情上似乎相較於與人溝通都還是好上非常多。

接下來，讓讀者喘口氣，來會分享一些比較小型的日常維運工作。