iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 21
0
DevOps

Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*系列 第 21

Day 21 - 從零開始導入Terraform,Infrastructure as Code 導入後的優點,感想與心得

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

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

曬貓


優點

好,跟團隊一步一步溝通改進,花了一兩個月,成功導入。是否有解決當初的問題?

  • 降低人工操作

    • 避免人工失誤
    • infra 交付標準化,沒有奇怪的設定,再也沒有「啊我機器開錯了」這回事
    • 快,真低快。開一個機器就是我剛剛 demo 這樣,而且保證會動。這樣開出來的機器,對她超有信心,要複製完全一模一樣的環境也超有信心。如果再加上自動化測試就更敢保證。
  • 準確

    • 大家都 review 過,比較不會有「啊我當時沒想到」的狀況,infra 出這種萬萬沒想到的問題,很有機率要幹掉重來。菜鳥跟著 review ,試著發 PR,這樣新人訓練才會有效率,他之後才能自己操作,資深工程師只要 review 就好。要給新人足夠的訓練,又要顧慮安全, review 花的時間非常值得。
    • 保證開發、測試、staging、production 環境長的一模一樣。terraform 程式保證的不是我保證的(XD)。但他的保證是有根據的,讓團隊從開發到上限保證相同環境。
    • 「阿在我的機器上會跑怎麼上 production 就壞掉」不好意思沒這回事,壞掉就是你扣寫錯
    • 認真地說,排除一些 infra 的問題,可以大幅增加除錯的效率,只要檢查還沒自動化的地方就好。
    • 自動化測試,扣要測試環境也要測試,這邊直接整進去,環境交出去保證是好的
  • 生產環境變動

    • 因為已經轉成程式碼,要有什麼改動都很精確,大家也比較敢動環境,特別是 production 環境。
    • 再來因為保留所有環境產生的程式碼,要複製環境也很容易,而且有信心保證一樣。
    • 我們就把就架構的 production 複製,然後搬家。安全下庄沒出事。後面就搬上癮,整個公司服務大搬家,搬成團隊理想的架構。
    • 搬家已經上線的服務,這個需要多少信心跟勇氣你們知道嗎,維運真的是愛與勇氣的冒險。新架構我們也很滿意。
  • 自動化

    • 自動化就是讓你用零倍的時間做十倍的事情嘛。聽起來怪怪的蛋是是真的。
    • 因為我們目標是維運躺著上班嘛(XD),我們才能把時間拿去做改進,不然以光是開機器,測試環境可用性,維運就飽了,根本沒時間改進跟提升。這樣對公司長期非常不好。
  • 可讀性

    • GUI 沒辦法打 comment 阿,誰知道這個機器當初為什是這個設定。IaC 後到處都可以寫 comment,怕你不寫而已。然後 code 的表達性還是很強大,比起 GUI,資深工程師可以把握整個公司的架構狀況,比起去雲平台下一堆搜索,手動比對,程式碼的可維護性真的超高。而 GCP 已經是 GUI 做得很好的公有雲了。

降低人工,快速,準確,自動化,有信心

其他: terraform 的命令

  • validate 既然是 code,這邊幫你做 lint、語法檢測、type check,過濾第一層錯誤
  • import 可以把遠端的資源匯入成 state,一個點讚 follow 追蹤的概念(XD),不是所有的遠端資源都需要追蹤到 state,我們只需要在對的 scope 裡面關注需要的機器
  • module 可以自由撰寫,把有相依性的資源打包,依照團隊使用習慣調整使用
  • cloud 可以管理 state,terraform cloud 幫你維護全域同一份 state,有人在使用時會 lock state,避免多人同時修改,打亂 API 造成資源錯誤

注意 state conflicts

  • 如果有多份 state,你電腦上一份 local state,我電腦上一份 local state,其實會造成衝突
  • 更怕同時多人憶起 apply,GCP API 直接被打亂,會有不可預期的錯誤
  • 解法是使用 terraform remote backend,不要用 local state,使用 DB 、storage 或是 terraform cloud,透過一隻 lock 來保證 synchronized state

深入間接理解 GCP API

ex. GCP Load Balancer

這個講下去就太多了,基本上透過爬 terraform google provider 的文件,然後去比對

  • 因為去點 GUI 其實感受不到 GCP API 的調用,但是使用 terraform 轉寫資源時候就很有感,打這個 API 跟打這個 API,tf 檔案上其實看得出來。
  • 進一步去查,才發現 GCP Load Balancer 內網或外網、http 或 tcp、全球或區域,使用的 Load Balancer 行為不一樣,因為底下的實作不一樣。但之前使用 GUI 時其實不會去想為啥設定不一樣,使用 terraform 就會被迫去了解,強迫學習XD。

垃圾話

  • 最佳實踐不是問題 ,如何導入才是問題
  • 可以不用躺著上班,但是不能跪著上班

結論

  • 如果你是使用公有雲,gcp aws azure,那我超級推薦使用
  • 如果你有使用 terraform 支援的 provisioner 的服務,例如 terraform 的 vault module,那我也大推
    • 使用 terraform 來初始化服務的設定
    • 這就進一步帶到可能的下個主題 configuration as code

上一篇
Day 20 - 從零開始導入Terraform,Infrastructure as Code Terraform 與 Gitflow 工作流程整合
下一篇
Day 22 - 從零開始導入Terraform,Infrastructure as Code Github repository 範例帶你手把手操作
系列文
Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言