本文同步刊登於個人技術部落格，有興趣關注更多 Kubernetes、DevOps 相關資源的讀者，請務必追蹤從零開始的軟體工程師之旅，喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。

如果有技術問題也可透過粉絲專頁 討論，技術方面諮詢免錢、需要動手做另計 XD。

先簡單講一下 Infrastructure as Code 概念 (Yeah 終於要講技術了)

IaC

上面都講概念跟心法，現在實際講用到的技術。

首先是 Infrastructure as Code，這個概念很久了，但導入的公司好像不是那麼多。所以我今天要來傳教，洗腦大家(XD，跟你推薦這個配方保證快又有效(XD)

• 簡單來說就是用程式來操作 infrastructure，今天主講的 terraform 是 IaC 工具中的一個
• IaC 工具可以是宣告式，或是命令式，或是兩種都支援
  • 一個是我告訴你結果，步驟我不管，請你幫我生出這樣的結果。
  • 一個是我告訴你步驟，你一步一步幫我做完，就會得到我要的結果
  • terraform 是宣告式，說明邏輯跟結果，例如我要 1 2 3 台機器，terraform 自己去幫我打 Google API 這樣，把機器生出來
  • ansible 是命令式，我把步驟寫成一堆命令腳本 playbook ，ansible 幫我照著跑下去，理論上跑完後我的機器也準備好

Terraform

• 官網在這邊，自己看 https://www.terraform.io/
• 宣告式的 Iac 工具
• 單一語法描述各家 API
• 透過 provider 轉換 tf 成為 API call

Terraform Core Workflow

https://www.terraform.io/guides/core-workflow.html

• Write 撰寫期待狀態 tf file
• plan 計畫試算結果
• apply 用期待狀態去更新遠端
  • tf file，就是宣告式的表達 infra ，描述期待的infra長這樣，ex. tf file 裡有這些機器 1 2 3 台這樣
    • resource 一個一個物件描述，後面可能是對映 provider 的 API Endpoint (ex. GCP GKE API)
  • remote resources，是真實存在遠端的機器，例如 GCP 雲端實際上只有 1 2 兩台這樣。
  • terraform diff tf vs remote，算出 plan，少的生出來，多的上去砍掉

State

• terraform 經手(apply) 過的 resource 會納入 state (scope)

• 不在 scope 裡的 resource 不會納入 plan，不會被 destroy，但可能會 create duplicated ID

• terraform 允許直接操作 state

  • import
  • remove
  • 但我不允許XD

• 注意是 diff state 喔，所以每次 plan 時候會自動 refresh state

• state 又是什麼? remote 是一個動態環境，可能會多會少，這樣沒辦法 diff，state 是把我執行當下，遠端相關資源的狀態快照存起來，然後根據這個 snapshop 去 diff

• apply 只是拿你的期待去 diff state，terraform 幫你算出來差多少，例如我們這邊就是遠端少一台。terraform 透過 provider 去知道，喔這一台要去打那些 GCP API，把這台生出來。

State，是 Terraform 核心概念，我當初自己卡觀念是卡這邊，所以我特別拉出來講

• 雲端空蕩蕩，refresh state 也是空的，tf file 多加一個 VM，plan 覺得要 create
• 雲端有東西，refresh state 未必會 refresh 到
  • 相同 ID 的資源之前 import 在 state 中，refresh state，tf file 沒東西，plan 覺得要 destroy
  • 相同 ID 的資源不在 state 中，這些 resource 不在當前 state 的 scopor 中，refresh state 是空的，tf file 沒東西，plan 覺得沒增沒減
  • 相同 ID 的資源不在 state 中，這些 resource 不在當前 state 的 scopor 中，refresh state 是空的，tf file 有相同 ID 的資源，plan 覺得要 create，但實際 apply，API error 遠端已經有相同 ID 的資源存在

小結

• Write -> Plan -> Apply
• State
• 大家都會 terraform 惹XD

初步使用感想

• IaC 地端跟雲端都能做，但雲端做起來效果超級好
  • 完全展現雲端運算的特性，迅速、彈性、隨用隨叫，調度大量的虛擬化資源
  • 新增東西很快，不要的資源，要刪掉也很快
    • 不小心刪錯也很快(大誤)，所以我說新人一個手起刀落公司整個雲弄不見也是有可能的
    • 「啊我的雲勒」「被 terraform 砍了」
    • 不要笑，那個新人就是我，我自己剛學的時候就有把整個 db 變不見過，差點一到職就引咎辭職(XD
    • 用這些技術還是有很多安全要注意，稍後會細講注意的安全事項。

總之，Iac 就是用程式化的語法，精準的描述雲端的狀態或是步驟，完全沒有模糊的地帶。帶來的好處，降低維運的錯誤風險，加快維運效率，最佳化節省成本。

新手 state 的雷

• 多人協作，同時變更 state 會造成不可預期的錯誤
  • 避免直接操作 state
• state 可能有 sensitive 資料
• 推薦使用外部帶有 lock 的 state storage

明天會分享公司導入的經驗，包含針對的需求、是否考慮導入、需要考慮的原因、實際導入的步驟