Terraform MCP với Gemini CLI

Gemini CLI là agentic coding tool của Google, có context window (cửa sổ ngữ cảnh) rất lớn — một lợi thế đáng kể khi làm việc với Terraform, vì plan output của hạ tầng lớn thường dài hàng nghìn dòng JSON mà các model context window nhỏ dễ bị cắt mất thông tin. Bài này hướng dẫn setup Terraform MCP cho Gemini CLI, cách tận dụng context lớn để tóm tắt plan khổng lồ, một ví dụ thực tế bắt lỗi resource bị replace ngoài ý muốn, và so sánh nhanh với Claude Code để bạn chọn công cụ phù hợp cho từng tình huống.

Cài Đặt Và Kết Nối Terraform MCP Vào Gemini CLI

Gemini CLI đọc cấu hình MCP từ file .gemini/settings.json trong project, hoặc ~/.gemini/settings.json cho cấu hình áp dụng toàn máy.

{
  "mcpServers": {
    "terraform": {
      "command": "terraform-mcp-server",
      "args": ["--workdir", "./infra/prod"],
      "env": {
        "AWS_PROFILE": "terraform-agent-readonly"
      },
      "timeout": 30000
    }
  }
}

Sau khi lưu file, khởi động lại Gemini CLI và kiểm tra bằng slash command:

gemini
> /mcp list

Nếu server hiện terraform: connected (N tools), bạn có thể xác nhận danh sách tool cụ thể bằng /mcp describe terraform. Một điểm khác biệt đáng chú ý so với Claude Code: Gemini CLI có field timeout riêng cho từng MCP server, nên đặt cao hơn mức default (thường 10s) khi làm với Terraform, vì lệnh terraform_plan trên module lớn có thể chạy 20-30 giây thực tế (refresh state từ cloud provider tốn thời gian network).

Mẹo: Nếu bạn thấy lỗi timeout khi gọi terraform_plan trên module lớn, đừng vội nghi ngờ MCP server bị lỗi — tăng field timeout trong settings lên 60000 (60s) trước, vì nguyên nhân phổ biến nhất chỉ là plan cần refresh nhiều resource từ API cloud, tốn thời gian hơn timeout default.

Tóm Tắt Plan Output Khổng Lồ Thành Change Set Dễ Review

Đây là chỗ context window lớn của Gemini CLI phát huy giá trị rõ nhất. Với hạ tầng có vài trăm resource, terraform plan -json có thể sinh ra output vượt 50.000 token — nhiều model khác phải cắt bớt hoặc tóm tắt từng phần rời rạc, dễ bỏ sót resource quan trọng nằm giữa. Gemini CLI với context lớn có thể nạp toàn bộ output một lần và tóm tắt nhất quán.

Prompt thực dụng cho plan lớn:

Chạy terraform_plan cho toàn bộ infra/prod. Output sẽ rất dài,
đừng tóm tắt sơ sài. Trả về đúng theo format sau:

## Change Set Summary
- Tổng số resource: create / update / destroy / replace

## High-Risk Changes (destroy hoặc replace)
Với MỖI resource ở nhóm này, liệt kê: resource address,
lý do force replacement, có phải resource stateful không
(database, storage, queue), mức độ rủi ro (low/medium/high).

## Routine Changes
Liệt kê ngắn các thay đổi update in-place không rủi ro
(ví dụ thêm tag, sửa description).

Với format ép buộc rõ ràng như trên, agent khó "lười" tóm tắt gộp — vì bạn yêu cầu liệt kê từng resource ở nhóm rủi ro cao, không cho phép nói chung "một vài resource sẽ bị replace". Đây là kỹ thuật prompt quan trọng khi làm việc với plan lớn: cấu trúc output ép model phải duyệt qua toàn bộ dữ liệu thay vì chỉ lấy vài dòng đầu làm đại diện.

Mẹo: Với plan trên 100 resource, luôn thêm câu "đừng tóm tắt sơ sài, liệt kê đầy đủ từng resource ở nhóm rủi ro cao" vào prompt — nếu không, ngay cả model context lớn cũng có xu hướng chỉ nêu vài ví dụ tiêu biểu rồi viết "và một số thay đổi khác tương tự", khiến bạn bỏ sót resource nguy hiểm nằm giữa danh sách.

Ví Dụ Thực Tế: Bắt Lỗi Resource Bị Replace Ngoài Ý Muốn Trong Plan

Tình huống thường gặp: một engineer sửa attribute name của một aws_db_instance chỉ để "đặt tên đẹp hơn", không biết rằng đổi identifier của RDS instance sẽ buộc Terraform destroy và tạo lại toàn bộ database — mất hết dữ liệu nếu không có snapshot trước.

Config trước và sau thay đổi:

resource "aws_db_instance" "main" {
  identifier = "acme-prod-db"
  # ...
}

resource "aws_db_instance" "main" {
  identifier = "acme-production-database"
  # ...
}

Prompt kiểm tra trước khi merge PR:

Chạy terraform_plan cho thay đổi trong PR này. Nếu có resource
nào bị destroy hoặc replace, và resource đó là database, storage
volume, hoặc message queue, đánh dấu CẢNH BÁO MẤT DỮ LIỆU và giải
thích chính xác attribute nào gây ra force replacement.

Kết quả agent trả về:

CẢNH BÁO MẤT DỮ LIỆU: aws_db_instance.main sẽ bị destroy và
tạo lại (# forces replacement) do thay đổi attribute "identifier"
từ "acme-prod-db" thành "acme-production-database". Đây là
resource stateful (RDS PostgreSQL). Nếu apply, toàn bộ dữ liệu
trong instance hiện tại sẽ MẤT VĨNH VIỄN trừ khi đã có snapshot
gần nhất được backup riêng.

Khuyến nghị: dùng terraform state mv hoặc lifecycle {
prevent_destroy = true } để chặn thay đổi này, hoặc revert lại
identifier về giá trị cũ nếu việc đổi tên không thật sự cần thiết.

Đây chính xác là giá trị lớn nhất của việc để AI agent review plan trước khi merge: một thay đổi "cosmetic" (đổi tên cho đẹp) suýt gây mất dữ liệu production, được bắt lại ngay ở bước review thay vì phát hiện sau khi đã apply. Thêm lớp bảo vệ cứng ở code:

resource "aws_db_instance" "main" {
  identifier = "acme-production-database"

  lifecycle {
    prevent_destroy = true
  }
}

Mẹo: Với mọi resource stateful quan trọng (RDS, EBS volume, S3 bucket chứa dữ liệu không tái tạo được), luôn thêm lifecycle { prevent_destroy = true } làm lớp bảo vệ cứng ở code — lớp này chặn được cả trường hợp agent review sai hoặc con người bỏ qua cảnh báo, vì Terraform sẽ tự chặn apply với lỗi rõ ràng.

So Sánh Output Terraform MCP Giữa Gemini CLI Và Claude Code

Cả hai đều gọi cùng một Terraform MCP server, cùng bộ tool — sự khác biệt nằm ở cách model xử lý và trình bày kết quả, không nằm ở tool tự thân.

Không có lựa chọn "đúng tuyệt đối" — nhiều team dùng Gemini CLI cho lần review plan lớn đầu tiên khi audit toàn bộ hạ tầng cũ, sau đó chuyển sang Claude Code cho công việc review hàng ngày trong IDE vì trải nghiệm tích hợp mượt hơn. Điểm chung bắt buộc ở cả hai: luôn yêu cầu agent trích dẫn evidence gốc từ plan JSON, không tin tóm tắt suông, bất kể công cụ nào.

Mẹo: Nếu team dùng cả hai công cụ, hãy dùng chung một prompt template (lưu trong file .agent-prompts/plan-review.md trong repo infra) cho cả Gemini CLI và Claude Code — điều này đảm bảo chất lượng review nhất quán, không phụ thuộc vào việc ai đó quen gõ prompt kiểu nào.

Mẹo Khai Thác Tối Đa Gemini CLI Cho Công Việc Terraform

Vài kinh nghiệm bổ sung giúp bạn khai thác đúng thế mạnh context window lớn của Gemini CLI khi làm việc với Terraform MCP, tránh lãng phí lợi thế này hoặc dùng sai chỗ:

• Dùng Gemini CLI cho lần audit toàn bộ hạ tầng đầu tiên khi tiếp nhận một repo infra cũ không có tài liệu — nạp toàn bộ cây module cùng lúc và hỏi "Tổng hợp toàn bộ resource hiện có theo loại, phát hiện resource nào không còn được tham chiếu trong bất kỳ output nào (có thể là orphan)." Việc này tận dụng đúng lợi thế context lớn, việc mà công cụ context nhỏ hơn phải làm nhiều lượt rời rạc mới xong.
• Kết hợp /mcp describe terraform định kỳ sau mỗi lần cập nhật version terraform-mcp-server để xác nhận danh sách tool và tên tool không đổi — các MCP server còn non đôi khi đổi tên tool giữa các bản release, và một prompt viết cứng tên tool cũ sẽ lặng lẽ thất bại nếu bạn không kiểm tra lại.
• Với nhiều môi trường (dev/staging/prod), khai báo nhiều MCP server riêng theo alias rõ ràng (terraform-dev, terraform-prod) thay vì một server chung đổi --workdir qua tay — giảm khả năng gõ nhầm prompt vào môi trường prod khi ý định thực sự là dev.

{
  "mcpServers": {
    "terraform-dev": {
      "command": "terraform-mcp-server",
      "args": ["--workdir", "./infra/dev"]
    },
    "terraform-prod": {
      "command": "terraform-mcp-server",
      "args": ["--workdir", "./infra/prod"]
    }
  }
}

Mẹo: Luôn gọi rõ tên server trong prompt khi có nhiều môi trường được khai báo, ví dụ "dùng terraform-prod, chạy plan cho module network" — đừng chỉ nói "chạy plan" và hy vọng agent chọn đúng server, vì với nhiều server cùng tên tool tương tự, agent có thể chọn sai nếu ngữ cảnh prompt không đủ rõ.