敏捷與DevOps

在過去帶領 DevOps 團隊的經驗裡，有時會遇到團隊成員對於身為 DevOps 工程師的價值有所疑惑或迷思： 🤔 我們好像只是在做各種工具的整合…是不是要像開發人員一樣寫程式，這樣才比較厲害！？ 🤔 是不是要像開發團隊一樣面對市場客戶的需求，這樣才能產生價值的交付？ 🤔 是不是打造完工具鏈，DevOps 團隊就不需要存在了？ 本文同步刊登於 DZone - Addressing Concerns About Being a DevOps Engineer 認真做好每一樣事物，這才是工程 在工程的世界裡，每個領域絕對都有它專業價值的存在，只是使用的技術、工具及面對的客群不同。雖然各種 IaC 或 XaC 的工具，不像廣為人知的 Java、TypeScript、Python 等程式語言，但在撰寫的過程中，仍然需要基於邏輯地去考量彈性度、模組化等，以及如何透過測試維持品質。有時更因為它是基礎設施或與合規相關，所以相顯之下它所衝擊的範圍也較為龐大，而需更加謹慎。且在五花八門的工具世界裡，選擇一個適合您組織文化、流程、團隊技術線的解決方案，也是個大哉問，不落入貨物崇拜尤為重要。因此，只要保持好奇心、積極的態度，把事情做對，不論背後所採用的技術為何，這就是工程的美妙。

安全的運行環境對於雲端服務來說，是個重要的議題，而對於使用者來說更為重要。 因此，對實體或虛擬主機進行弱點檢查與監測，能為雲端服務提供一個安全的基礎，也能滿足組織對於資安的基本要求。然而，安全威脅多樣，且各式作業系統的組態設定又各有巧妙，要如何才能有效率地完成這個工作，對於維運人員來說是相當令人頭疼的事情。 SCAP2 (Security Content Automation Protocol) 是由美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST3)所維護與制定的協定，主要用意是為主機的組態設定與安全需求提供一個共同交互與發展的基礎。同時也為 NIST 800-53 關於運行主機的安全要求與最佳實踐提供一個自動化的基礎。 OpenScap4 則是基於 SCAP 的具體實作，它主要透過使用 SCAP 裡的 XCCDF5(Extensible Configuration Checklist Description)與 OVAL6(Open Vulnerability and Assessment Language)。XCCDF 透過 XML 形式的描述語言具體地提供評估與檢查一個主機時，應該進行的項目列表。測項可能是一些安全需求下的組態設定的檢查，也可能來自 OVAL 所識別的弱點測試。

作為基礎設施的工具，Pulumi 主要可以採用以下三種方式進行測試，而除了驗證的範疇外，在程式語言的支援上也有所不同，下方的表格總結了三種方式主要的差異： 表格一：Pulumi 測試方法比較 單元測試 屬性測試 整合測試 實際部署基礎設施 否 是* 是 需要 Pulumi CLI 否 是 是 執行時間 毫秒 秒 分 語言 同 Pulumi 支援的程式語言 Node.

開始接觸 Pulumi 後，發現 GCP + Python 可以參考的資料很少，以建置 GCP HTTP Load Balancer 來說，Pulumi 官方提供了 Typescript 的寫法1，若自行對應相同資源的 Python API 範例，則會在執行時遇到一些小錯誤（稍後會提到）。因此本篇將會分享如何透過 Python 建立 GCP HTTP Load Balancer，完整的實作程式碼請至 GitHub 2查看。 架構說明 透過 HTTP Load Balancer，將請求導流至後端的 Nginx 伺服器，由於 VM 在初始化時，會透過 startup script 從外網抓取相關套件並安裝，因此需要為 VM 配置 Public IP 或 NAT proxy，讓 VM 可以與網際網路進行通訊。但為安全考量，我們只允許來自 Load Balancer 的請求，禁止透過 VM 的 Public IP 來存取服務。