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

> เปรียบเทียบ Ansible vs Terraform ในปี 2026: configuration management vs provisioning, เมื่อไหร่ควรใช้เครื่องมือใด, OpenTofu, และการเตรียมตัวสัมภาษณ์ DevOps

- Published: 2026-08-22
- Updated: 2026-08-22
- Author: Anthony Fillion-Maillet
- Reading time: 5 min

---

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

> **ความแตกต่างหลัก**
>
> Terraform จัดการ state ของโครงสร้างพื้นฐานแบบ declarative (VM, เครือข่าย, ฐานข้อมูล) Ansible กำหนดค่าสิ่งที่รันบนโครงสร้างพื้นฐานนั้นแบบ procedural (packages, services, files) สภาพแวดล้อม production ส่วนใหญ่ใช้ทั้งสองอย่าง

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

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

```hcl
# 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 ปลายทาง

```yaml
# 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](https://developer.hashicorp.com/terraform/language/state) ที่ map คอนฟิกกับทรัพยากรจริง state นี้ติดตาม resource ID, dependencies และ metadata หากไม่มี Terraform ไม่สามารถระบุได้ว่ามีอะไรอยู่หรืออะไรต้องเปลี่ยน

| ด้าน | Terraform | Ansible |
|------|-----------|----------|
| การจัดเก็บ state | จำเป็น (ไฟล์ local หรือ remote backend) | ไม่มีโดย default |
| การตรวจจับ drift | Built-in ผ่าน `terraform plan` | ต้องตรวจสอบอย่างชัดเจน |
| การติดตามทรัพยากร | อัตโนมัติผ่าน state | อ้างอิงจาก inventory |
| Rollback | Destroy และ recreate จาก state | ไม่มี rollback แบบ native |

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) พร้อมการเข้ารหัสและการควบคุมการเข้าถึง

```hcl
# 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](https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax) เพื่อรัน scripts หลังจากสร้างทรัพยากร Ansible สามารถสร้างทรัพยากร cloud ผ่าน modules เช่น `amazon.aws.ec2_instance` แต่การใช้แต่ละเครื่องมือนอกเหนือจากจุดแข็งของมันนำไปสู่ปัญหาการบำรุงรักษา

> **หลีกเลี่ยง Anti-Pattern นี้**
>
> การใช้ provisioners ของ Terraform อย่างกว้างขวางสำหรับ configuration management สร้างโครงสร้างพื้นฐานที่เปราะบาง Provisioners รันเฉพาะตอนสร้างเท่านั้น ไม่ใช่ใน applies ครั้งต่อไป ใช้ Terraform สำหรับโครงสร้างพื้นฐาน แล้วส่งต่อให้ Ansible สำหรับ configuration

## Workflow รวมใน Production

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

```hcl
# 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 กับโครงสร้างพื้นฐานใหม่

```yaml
# 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](https://opentofu.org/) ซึ่งตอนนี้อยู่ภายใต้ 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:

```hcl
# 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](https://terratest.gruntwork.io/) รัน integration tests Ansible: `ansible-lint` ตรวจจับปัญหา, โหมด `--check` ทำ dry runs, และ [Molecule](https://ansible.readthedocs.io/projects/molecule/) ทดสอบ roles กับ containers

สำหรับการเตรียมสัมภาษณ์ Terraform ที่ลึกกว่า ดู [Terraform Interview Questions: Infrastructure as Code Complete Guide](/blog/devops/terraform-interview-questions-infrastructure-as-code) ฝึกปฏิบัติจริงกับ modules [Terraform Basics](/technologies/devops/interview-questions/terraform-basics) และ [Ansible Configuration Management](/technologies/devops/interview-questions/ansible-configuration)

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

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

| เครื่องมือ | เวอร์ชัน | วันที่ออก | ฟีเจอร์หลัก |
|------------|----------|-----------|-------------|
| Ansible | 2.20.5 | เมษายน 2026 | การจัดการ collection ที่ปรับปรุง |
| Terraform | 1.15.8 | กรกฎาคม 2026 | รองรับ Windows ARM64, ฟังก์ชัน convert |
| OpenTofu | 1.11.6 | เมษายน 2026 | การเข้ารหัส state, provider for_each |

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

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

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

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

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

| Use Case | เครื่องมือที่แนะนำ |
|----------|------------------|
| Provision VMs, databases, เครือข่าย | Terraform |
| กำหนดค่า OS, ติดตั้ง packages | Ansible |
| จัดการทรัพยากร Kubernetes | Terraform หรือ kubectl/Helm |
| Deploy application code | Ansible หรือ CI/CD native |
| สร้าง IAM roles และ policies | Terraform |
| จัดการบัญชี user บน servers | Ansible |
| ตั้งค่าโครงสร้างพื้นฐาน monitoring | Terraform (สร้างทรัพยากร) + Ansible (กำหนดค่า agents) |

สำหรับภาพรวมของการที่เครื่องมือเหล่านี้เข้ากับ workflow การ deploy สมัยใหม่ ดู [CI/CD Pipeline Interview Questions](/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins)

## สิ่งที่วิศวกร 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 สำหรับทั้งสอง

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/th/blog/devops/ansible-vs-terraform-2026-infrastructure-as-code-devops-interview