從零導入 Terraform

Infrastructure as Code

Me

Che-Chia Chang

DevOps / Tech Blogger

 

Kubernetes, GCP
 

@Golang Taipei

@CNCF Taiwan

@iThome Summit

@DevOps Taipei

本次演講資源

  • 投影片
  • 講稿
  • Github
  • 導入 SOP

 

文章連載有興趣請 Follow
按讚隨意<3

作者不定期外出取材

諮詢免費，動手收錢XD

以下這段對話很耳熟？

誰改了環境設定？

 環境好像有漏一個設定...嗎？

會動就好，沒壞不要改

關於我們

  • 常常有新專案測試 MVP
  • 越來越多 sites
    • VMs，K8ses(?)，DBs
    • Monitoring，Alerts
    • CI/CD
  • 東西多，但東西多不是問題
  • 問題是什麼？

大量的手動部署漸漸成為問題
對...就算有 SOP

24/7的環境調整是大問題

害怕調整環境的風險

問題整理

  • Infra 不標準
  • 人工太多，慢又易出錯
  • Infra 變動缺乏 review，沒有共識
  • Junior 成員也要操作，權限重新調整
     
  • 程序員，需要用程式工具解決問題

把環境當程式碼寫

Infrastructure as Code

明確需求再找工具

  • 新環境提交標準化
    • 交付自動化
    • 測試環境
  • 環境變更 git-flow
    • 變更 review
    • 變更 commit
  • 快速環境交付
  • Juniors 也能「安全」操作

是否要導入工具

  • DevOps 都知道 IaC 跟 Terraform
    • 沒人有經驗
    • 每個人都怕
    • 但又不知在怕什麼
  • 每個人都知道要做 best practice
    • 不要問為什麼不做，而是你來做
  • 領頭羊有經驗很好，但不是必須
    • 注意安全，逐步嘗試

現在來聊技術

Infrastructure as Code

  • 概念上很單純
  • 不是新東西，但不知多少人在用
  • 宣告式，命令式，或是兩者兼容
    • code 描述結果，tool 產生步驟 (API call)
    • code 描述步驟，tool 執行
    • Terraform vs Ansible
  • code 不會模稜兩可

Terraform

  • https://www.terraform.io/
  • terraform *.tf 檔案
    • 宣告式描述 infra
  • terraform cli
  • providers
    • Public Cloud API
    • GCP，AWS，Azure...
resource "google_compute_instance" "devops-terraform-demo-1" {
  boot_disk {
      size  = 100
  }
  
  machine_type        = "n1-standard-1"
  name                = "devops-terraform-demo-1"
  
  network_interface {
  }

  project = "my-project"

  scheduling {
    automatic_restart   = "true"
    preemptible         = "true"
  }

  lifecycle {
    ignore_changes = [
      metadata_startup_script
    ]
  }
}

Terraform Workflow

  • Write 編寫／更改 tf
  • Plan 計算並呈現變更
  • Apply 應用變更
    • 本地多，上去雲 create
    • 本地少，上去雲 destroy
    • 本地 = 雲，我們要的狀態

Demo

State

  • apply 過的 resource 納入 state
    • state 外的 remte 不會管
  • state 是有序的 snapshot
  • state 跟 remote 手動 sync
  • terraform 允許直接操作 state
    • import / remove
    • 但我不允許XD

Terraform 小結

  • Write -> Plan -> Apply
  • State
  • 更改 state 會有意外 destroy 風險
  • 不要使用 local state

初步心得

  • IaC 公有雲上超，好，用！
    • 彈性，迅速，隨叫隨用
    • 新增很快
    • 每次編輯都基於上次的 infra code
      • code 比 GUI 清楚
    • 刪掉很快
      • 刪錯也很快 XD

Terraform 手起刀落
「啊我的雲勒？」

IaC 的導入

  • 安全第一
    • minimal privilege
    • 足夠的訓練，SOP
  • module 封裝不必要的參數
  • 提供標準 template
  • 「正確」的導入步驟
  • terraform 官方最佳實作

https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html

Terraform 新手雷

  • 多人協作，同時變更 state
    • 盡快導入 Git
  • 推薦使用外部有 lock 的 storage
  • State 可能有敏感資料
  • 仔細 plan 小心 apply
    • 有看到 destroy 請雙手離開鍵盤

導入工具後大家都躺著上班拉

導入工具之後

  • 好的工作流程會降低風險
  • 使用新工具的風險
    • 會 + 不精通 = 炸鍋
  • Junior 操作的風險
    • 過大權限 -> 砍錯東西
    • 工作流程的坑

逐漸導入

  • 不斷檢討修改工作流程
    • 讓成員很難在裡面犯錯
  • 比較官方的最佳實作
  • 分享我們的導入及配套

 https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html

導入三部曲

  • Infrastructure as Code
  • Git-flow
  • CI/CD automation

Infra as Code

  1. import 保存現有架構成 code
  2. diff 舊架構
    • 找出合理的標準架構
    • 新環境依據範本標準化
  3. 環境已經標準化，沒有零碎小錯誤
    • 還有錯誤就是全錯 XD
    • 修範本，永不再犯

Git-flow

  1. Infra code 工作流程
    • protected master
    • new branch commit -> PR
  2. 嚴格 review
    • 夠多的人 approve
    • 加速新人訓練
    • on the same page
  3. 永遠使用 master 部署
    • stable & reviewed

Automation

  1. CI/CD
    • 人工操作降到最低
    • 沒錯都沒錯，有錯就全錯XD
    • 有錯就修 workflow，永不再犯
  2. 自動化測試環境
    • 如果沒有，先求簡單的bash
  3. 移除個人的權限，自動化用公用帳戶
    • 杜絕「我現在上去改一下環境」

Demo 2

工具＋流程

  • Github Repo 供參考
  • SOP
  • 加值服務
    • template
    • terraform module
      • 封裝
      • 隱藏多餘參數

工具很重要
但決定成敗的不只是工具

其他

優點

避免人工操作

infra 標準化

快，真滴快

有膽動 prod 了

新人訓練更有效

 

自動化

可讀性

全域的大局觀

缺點

學習曲線

流程與文化調整

刪錯的風險

要不要 Terraform

  • 看 infra 變動的頻率
  • Infra 造成的困擾（痛點）
  • 我個人是很推

Title Text

Q&A

歡迎透過 fb 私敲

有經驗的求討論！

沒經驗的也歡迎

 

投影片

SOP

範例 Github

 

喜歡按的讚ＸＤ

Made with Slides.com