Tooling & clouds

สิ่งที่จะสร้าง

ยังไม่มี infrastructure — บทนี้สร้าง workbench ก่อน จบบทนี้คุณจะมี Terraform และ Terragrunt ติดตั้งแล้ว, AWS, GCP, และ Azure CLIs ที่ auth เข้า account จริงเรียบร้อย, และ billing alert บนแต่ละ cloud เพื่อไม่ให้ cluster ที่ลืมไว้ค่อย ๆ ดูดเงินในบัตรคุณ

ส่วนสุดท้ายนั้นสำคัญกว่าในคอร์ส single-cloud มาก CloudDeploy รัน managed Kubernetes cluster สามตัวและ managed database สามตัว จุดประสงค์ทั้งหมดของ Module 1 คือทำให้ต้นทุนมองเห็นได้ ก่อน ที่ Module 5 จะทำให้เกิดขึ้นจริง

ทำไม

Terraform คือ engine ที่แปลงไฟล์ .tf แบบ declarative ให้เป็น API call ยิงไปที่ cloud Terragrunt อยู่ชั้นถัดขึ้นไปหนึ่งชั้น: เก็บ configuration ให้ DRY ข้ามทั้งสาม cloud และต่อสาย remote state กับ locking ไว้ให้ คุณจึงไม่ต้อง copy-paste backend block เดิม ๆ ลงในสิบกว่า directory คุณต้องติดตั้งทั้งคู่ตั้งแต่วันแรก แม้ Terragrunt จะยังไม่คุ้มค่าจนกว่าจะถึง Module 3

cloud CLIs ทั้งสามทำหน้าที่สองอย่าง คุณจะใช้แหย่ดู resource ด้วยมือ (aws s3 ls, gcloud storage ls, az group list) แต่ที่สำคัญกว่าคือ Terraform authenticate ด้วยวิธีเดียวกับที่ CLIs ทำ login AWS CLI เข้า account แล้ว AWS provider ก็หยิบ credential ชุดนั้นไปใช้ รัน gcloud auth application-default login แล้ว Google provider ก็ใช้ตัวนั้น การ authenticate CLIs ก็คือ การ authenticate Terraform

ข้อดีข้อเสีย

IaC toolchain ตัวเดียวข้ามสาม cloud เทียบกับ native tool ของแต่ละ cloud (CloudFormation / Deployment Manager / ARM/Bicep):

Pros: ภาษาเดียว (HCL), workflow เดียว (plan/apply), mental model เดียว การ abstract provider ทำให้ รูปทรง ของโค้ดเหมือนกันไม่ว่าคุณจะคุยกับ AWS หรือ Azure — นั่นคือสิ่งที่ทำให้คอร์สสาม cloud นี้จัดการไหว
Cons: provider ใหม่ได้แค่เท่าที่ maintainer ทำให้เท่านั้น feature ใหม่ล่าสุดของ cloud บางทีก็มาถึง native tool ก่อน และคุณเป็นเจ้าของ toolchain เอง — การติดตั้ง, pin, และ upgrade Terraform กับ providers กลายเป็นงานของคุณแล้ว

CLI auth อายุสั้น (SSO / ADC / az login) เทียบกับ static key อายุยาว:

Pros: ไม่มีอะไรถาวรค้างอยู่บน disk credential หมดอายุได้ laptop ที่หลุดจึงไม่ใช่การรั่วแบบถาวร และคุณไม่เคยต้อง paste access key ลงในไฟล์ที่อาจหลุดเข้า git
Cons: session หมดอายุกลางงานแล้วคุณต้อง auth ใหม่ CI ทำ az login แบบ interactive ไม่ได้ Module 12 จึงเปลี่ยนตรงนี้ไปใช้ OIDC federation — แต่สำหรับ local development แบบอายุสั้นคือ default ที่ถูกต้อง

ติดตั้ง

1. Install Terraform and Terragrunt

บน macOS ด้วย Homebrew:

brew tap hashicorp/tap
brew install hashicorp/tap/terraform
brew install terragrunt

Terraform จัดการ engine version ตัวจริง ถ้าคุณสลับหลายโปรเจกต์ tfenv จะ pin version ต่อ repo ให้ Terragrunt เกาะ Terraform ใกล้มาก — เก็บทั้งคู่ให้ค่อนข้างใหม่ไว้ เพราะ command surface ใหม่ของ Terragrunt (ด้านล่าง) สมมติว่าคุณใช้ Terraform รุ่นล่าสุด

2. Install the three cloud CLIs

brew install awscli                       # AWS
brew install --cask google-cloud-sdk      # GCP (gcloud)
brew install azure-cli                    # Azure (az)

3. Authenticate to each cloud

# AWS — SSO is preferred; `aws configure` with an access key also works
aws configure sso

# GCP — log in AND set application-default credentials (what Terraform reads)
gcloud auth login
gcloud auth application-default login
gcloud config set project YOUR_GCP_PROJECT_ID

# Azure — interactive login, then pick the subscription you'll deploy into
az login
az account set --subscription "YOUR_SUBSCRIPTION_NAME_OR_ID"

Google provider อ่าน credential แบบ application-default ไม่ใช่ตัวที่ gcloud auth login ตั้งให้ CLI — นั่นคือเหตุผลที่คุณต้องรันทั้งสองคำสั่ง สำหรับ Azure จดค่า subscription ID ไว้ azurerm provider ต้องใช้ค่านี้ (Module 2 จะต่อสายเข้าไป)

4. Set a billing alert on each cloud

cluster สามตัวบวก database สามตัวคือเงินจริง จำกัดความเซอร์ไพรส์ไว้ก่อนจ่ายสักบาท:

# GCP — create a budget with a threshold (via the console or gcloud billing)
gcloud billing budgets create \
  --billing-account=YOUR_BILLING_ACCOUNT_ID \
  --display-name="clouddeploy-budget" \
  --budget-amount=50USD \
  --threshold-rule=percent=0.9

AWS Budgets (Billing console → Budgets → Create budget) และ Azure Cost Management (Cost Management → Budgets) ตั้งเร็วสุดผ่าน console ของแต่ละเจ้า — monthly cost budget พร้อม email alert ที่ 80–90% ก็เพียงพอ ทำให้ครบทั้งสามเลยตอนนี้

ตรวจสอบผล

ยืนยันว่าทุก tool ทำงานและทุก identity resolve ได้:

terraform -version      # Terraform vX.Y.Z
terragrunt -version     # terragrunt version vX.Y.Z

aws sts get-caller-identity     # → your AWS account + ARN
gcloud auth list                # → your active GCP account (marked *)
az account show                 # → your Azure subscription JSON

คำสั่ง identity ทั้งสามควร return ตัวคุณ ในสถานะ authenticated:

// aws sts get-caller-identity
{
  "UserId": "AIDA...",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/you"
}

คุณเสร็จเมื่อทั้งห้าคำสั่งสำเร็จและคุณเห็น billing alert ตั้งค่าไว้ใน console ของแต่ละ cloud ยังไม่มีอะไรให้ plan — เริ่มบทหน้า — แต่ถ้าคำสั่ง identity ทั้งสาม resolve ได้ Terraform ก็จะ authenticate ได้เช่นกัน

ตรวจสอบความเข้าใจ:

ทำไมการ authenticate cloud CLIs ถึง authenticate Terraform ไปด้วย — provider หยิบ credential มาจากไหน?
gcloud auth login กับ gcloud auth application-default login ต่างกันอย่างไร และทำไมคอร์สนี้ต้องใช้ทั้งคู่?
ทำไม CLI auth อายุสั้นถึงเป็นตัวเลือกที่ถูกสำหรับ local แต่ผิดสำหรับ CI pipeline ใน Module 12?
สิ่งเดียวที่คุณควรตั้งค่าบนทั้งสาม cloud ก่อน provision อะไรคืออะไร และทำไมจึงสำคัญกว่าในโปรเจกต์ single-cloud?

สรุป

คุณมี Terraform และ Terragrunt ติดตั้งแล้ว, สาม cloud ที่ auth แล้ว, และ billing alert คุ้มกันแต่ละตัว engine กับ credential พร้อม — แต่กองของ tool ยังไม่ใช่โปรเจกต์ ต่อไปเราจะวาง layout ของ repository เพื่อให้ทุก module และ configuration ของทุก cloud มีที่อยู่

Next: The repo layout →