Ansible vs Terraform ในปี 2026: Infrastructure as Code และคำถามสัมภาษณ์ DevOps

Ansible vs Terraform เป็นหนึ่งในคำถามเปรียบเทียบที่พบบ่อยที่สุดในการสัมภาษณ์ DevOps แต่การตั้งคำถามแบบนี้เองก็เผยให้เห็นความเข้าใจผิด: เครื่องมือทั้งสองแก้ปัญหาที่แตกต่างกัน Ansible 2.20 จัดการ configuration management และการ deploy แอปพลิเคชัน ในขณะที่ Terraform 1.15 provision ทรัพยากรโครงสร้างพื้นฐาน การเข้าใจว่าแต่ละตัวเก่งเมื่อไหร่ ตรงไหนที่ทับซ้อนกัน และพวกมันเสริมกันอย่างไร คือสิ่งที่แยกวิศวกร DevOps ระดับ senior ออกจากผู้ที่ยังคงเรียนรู้พื้นฐานอยู่

Declarative vs Procedural: ความแตกต่างพื้นฐาน

Terraform ใช้วิธีการแบบ declarative ไฟล์คอนฟิกอธิบาย state ปลายทางที่ต้องการ และ Terraform คำนวณการเปลี่ยนแปลงที่จำเป็นเพื่อไปถึงจุดนั้น วิธีนี้ทำงานได้ดีสำหรับโครงสร้างพื้นฐานที่ต้องสร้าง แก้ไข หรือลบเป็นหน่วยเดียว

# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

การรัน terraform apply จะสร้างทรัพยากรทั้งสองถ้ายังไม่มี หรืออัปเดตให้ตรงกับคอนฟิก การรันอีกครั้งโดยไม่มีการเปลี่ยนแปลงจะไม่มีการดำเนินการใดๆ: Terraform เปรียบเทียบคอนฟิกกับ state file และไม่พบสิ่งที่ต้องทำ

Ansible ใช้วิธีการแบบ procedural โดย tasks ถูกรันตามลำดับ แม้ว่า modules ของ Ansible มักจะเป็น idempotent (รันสองครั้งได้ผลเหมือนกัน) แต่ playbook เองอธิบายลำดับของการกระทำมากกว่า state ปลายทาง

# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

แต่ละ task รันตามลำดับ รูปแบบ notify/handler ให้พฤติกรรมแบบ declarative บางส่วน: handler รันเพียงครั้งเดียวตอนท้ายโดยไม่คำนึงว่ามี tasks กี่ตัวที่ trigger มัน

การจัดการ State: หัวข้อสัมภาษณ์ที่สำคัญ

Terraform รักษา state file ที่ map คอนฟิกกับทรัพยากรจริง state นี้ติดตาม resource ID, dependencies และ metadata หากไม่มี Terraform ไม่สามารถระบุได้ว่ามีอะไรอยู่หรืออะไรต้องเปลี่ยน

Ansible ไม่มี state file ที่เทียบเท่า มันเชื่อมต่อกับระบบเป้าหมายและรัน tasks โดยอาศัย state ปัจจุบันของระบบและ idempotency ของ module สิ่งนี้ทำให้ Ansible เริ่มต้นง่ายกว่าแต่ยากกว่าในการติดตามการเปลี่ยนแปลงตามเวลา

คำถามสัมภาษณ์ทั่วไปถามเกี่ยวกับความปลอดภัยของ state file State ของ Terraform อาจมีข้อมูลที่ละเอียดอ่อน: รหัสผ่านฐานข้อมูล, API keys, resource identifiers การ deploy ใน production จะจัดเก็บ state แบบ remote (S3, Azure Blob, Terraform Cloud) พร้อมการเข้ารหัสและการควบคุมการเข้าถึง

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

ตาราง DynamoDB ให้ locking ป้องกันวิศวกรสองคนแก้ไข state พร้อมกัน

เมื่อไหร่ควรใช้แต่ละเครื่องมือ

Terraform เก่งในการ provision โครงสร้างพื้นฐาน cloud: virtual machines, managed databases, load balancers, IAM roles, VPCs มันจัดการ dependencies ระหว่างทรัพยากรโดยอัตโนมัติและรองรับ cloud providers หลักทั้งหมดผ่าน syntax HCL ที่สอดคล้องกัน

Ansible เก่งในการกำหนดค่าระบบที่มีอยู่: ติดตั้ง packages, จัดการ users, deploy application code, orchestrate การ deploy หลายขั้นตอน มันเชื่อมต่อผ่าน SSH (หรือ WinRM สำหรับ Windows) โดยไม่ต้องมี agents บนเครื่องเป้าหมาย

โซนที่ทับซ้อนกันทำให้เกิดความสับสน ทั้งสองสามารถติดตั้งซอฟต์แวร์บน VM ได้ Terraform สามารถใช้ provisioners เพื่อรัน scripts หลังจากสร้างทรัพยากร Ansible สามารถสร้างทรัพยากร cloud ผ่าน modules เช่น amazon.aws.ec2_instance แต่การใช้แต่ละเครื่องมือนอกเหนือจากจุดแข็งของมันนำไปสู่ปัญหาการบำรุงรักษา

Workflow รวมใน Production

องค์กรส่วนใหญ่ใช้ทั้งสองเครื่องมือร่วมกัน Terraform provision โครงสร้างพื้นฐานและ outputs รายละเอียดการเชื่อมต่อ Ansible ใช้ outputs เหล่านั้นเพื่อกำหนดค่าระบบ

# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}

Pipeline CI/CD รัน Terraform ก่อน, capture outputs, สร้าง Ansible inventory แบบ dynamic, แล้วรัน playbooks กับโครงสร้างพื้นฐานใหม่

# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"

Inventory แบบ dynamic นี้ query AWS โดยตรง จัดกลุ่ม instances ตาม tags ของพวกมัน ไม่ต้องจัดการ IP ด้วยตนเอง

OpenTofu: Fork ที่เปลี่ยนภูมิทัศน์

HashiCorp ได้เปลี่ยนสัญญาอนุญาตของ Terraform เป็น Business Source License (BSL) ในเดือนสิงหาคม 2023 ชุมชนตอบสนองด้วยการ fork Terraform 1.5 เป็น OpenTofu ซึ่งตอนนี้อยู่ภายใต้ Linux Foundation

ณ เดือนสิงหาคม 2026 OpenTofu 1.11.6 ยังคงเป็นตัวแทนแบบ drop-in สำหรับ workflow Terraform ส่วนใหญ่ syntax HCL เดียวกัน, ecosystem ของ providers เดียวกัน, รูปแบบ state เดียวกัน OpenTofu ได้เพิ่มฟีเจอร์ที่ไม่มีใน binary open-source ของ Terraform: การเข้ารหัส state, provider for_each, และการประเมินตัวแปรแบบ early

สำหรับการเตรียมสัมภาษณ์ ให้เข้าใจความแตกต่างด้านสัญญาอนุญาต BSL อนุญาตการใช้งานภายในแต่จำกัดการสร้างผลิตภัณฑ์คู่แข่ง องค์กรที่กังวลเกี่ยวกับ vendor lock-in หรือมีข้อกำหนด compliance เฉพาะอาจเลือกสัญญาอนุญาต MPL 2.0 ของ OpenTofu การที่ IBM เข้าซื้อ HashiCorp ในเดือนธันวาคม 2024 เพิ่มตัวแปรอีกตัวในการสนทนาเรื่องความสัมพันธ์กับ vendor

คำถามสัมภาษณ์ DevOps ที่พบบ่อย

Q: Ansible สามารถแทนที่ Terraform ได้หรือไม่?

ไม่ได้อย่างมีประสิทธิภาพ Ansible สามารถสร้างทรัพยากร cloud ได้ แต่ขาดการจัดการ state การรัน playbook เดียวกันสองครั้งอาจสร้างทรัพยากรซ้ำ State file ของ Terraform ติดตามสิ่งที่มีอยู่และคำนวณการเปลี่ยนแปลงที่น้อยที่สุด ใช้ Ansible สำหรับสิ่งที่มันทำได้ดีที่สุด: configuration management

Q: จะจัดการ secrets ใน Terraform อย่างไร?

อย่า commit secrets ไปยัง version control ใช้ environment variables, การรวม Vault, หรือ secret managers ของ cloud provider ทำเครื่องหมายตัวแปรว่า sensitive เพื่อป้องกันไม่ให้ปรากฏใน logs:

# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}

Q: Idempotency ของ Ansible คืออะไร?

การดำเนินการแบบ idempotent ให้ผลลัพธ์เหมือนกันไม่ว่าจะรันครั้งเดียวหรือหลายครั้ง Module apt ที่มี state: present ติดตั้ง package ถ้าไม่มีและไม่ทำอะไรถ้ามีอยู่แล้ว การเขียน playbooks ที่เป็น idempotent ป้องกันการเปลี่ยนแปลงที่ไม่ตั้งใจในการรันครั้งต่อไป

Q: จะทดสอบ infrastructure code อย่างไร?

Terraform: terraform validate ตรวจสอบ syntax, terraform plan แสดงตัวอย่างการเปลี่ยนแปลง, และเครื่องมืออย่าง Terratest รัน integration tests Ansible: ansible-lint ตรวจจับปัญหา, โหมด --check ทำ dry runs, และ Molecule ทดสอบ roles กับ containers

สำหรับการเตรียมสัมภาษณ์ Terraform ที่ลึกกว่า ดู Terraform Interview Questions: Infrastructure as Code Complete Guide ฝึกปฏิบัติจริงกับ modules Terraform Basics และ Ansible Configuration Management

ความเข้ากันได้ของเวอร์ชันและ Ecosystem

เวอร์ชันเสถียรปัจจุบัน ณ เดือนสิงหาคม 2026:

สถาปัตยกรรม collection ของ Ansible แยกฟังก์ชันหลักจาก modules เฉพาะ provider Collection amazon.aws รับอัปเดตอิสระจาก Ansible core สิ่งนี้สำคัญสำหรับการ pin version ใน pipelines CI/CD

การกำหนดเวอร์ชัน provider ของ Terraform ปฏิบัติตามหลักการเดียวกัน Lock files (terraform.lock.hcl) รับประกันเวอร์ชัน provider ที่สอดคล้องกันระหว่างสมาชิกทีมและระบบ CI

# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

การเลือกระหว่างสองเครื่องมือ: กรอบการตัดสินใจ

คำถามไม่ค่อยเป็น Ansible หรือ Terraform คำถามคือเครื่องมือไหนรับผิดชอบความรับผิดชอบไหน

สำหรับภาพรวมของการที่เครื่องมือเหล่านี้เข้ากับ workflow การ deploy สมัยใหม่ ดู CI/CD Pipeline Interview Questions

สิ่งที่วิศวกร Senior ควรรู้เกี่ยวกับ Ansible และ Terraform

• Terraform จัดการ state โครงสร้างพื้นฐานแบบ declarative; Ansible กำหนดค่าระบบแบบ procedural การใช้ทั้งสองร่วมกันสร้างโครงสร้างพื้นฐานที่บำรุงรักษาได้
• ความปลอดภัยของ state file สำคัญ จัดเก็บ state ของ Terraform แบบ remote พร้อมเปิดใช้การเข้ารหัสและ locking
• OpenTofu มอบทางเลือกที่มีสัญญาอนุญาต MPL แทน Terraform พร้อมฟีเจอร์เพิ่มเติม การย้ายตรงไปตรงมาสำหรับ workflows ส่วนใหญ่
• Idempotency ไม่ได้เกิดขึ้นอัตโนมัติ เขียน playbooks ที่ให้ผลลัพธ์สอดคล้องกันในการรันซ้ำ
• Inventory แบบ dynamic กำจัดการจัดการ host ด้วยตนเอง Query cloud providers โดยตรงสำหรับโครงสร้างพื้นฐานปัจจุบัน
• การ pin version ป้องกันความประหลาดใจ Lock เวอร์ชัน provider ใน Terraform; pin เวอร์ชัน collection ใน Ansible
• การทดสอบ infrastructure code ต้องการวิธีการที่แตกต่าง: terraform plan สำหรับ preview การเปลี่ยนแปลง, โหมด --check สำหรับ Ansible dry runs, frameworks integration test สำหรับทั้งสอง