Terraform vs. Ansible: คุณจริงๆ ต้องการแบบไหน?

ผู้คนใหม่กับ Infrastructure as Code มักจะถามสิ่งนี้ในหนึ่งในสองวิธี: "ฉันควรเรียนเครื่องมือไหนก่อน" หรือ "ทำไมทีมจึงใช้ทั้งสองอย่าง" คำตอบสั้นๆ คือ Terraform และ Ansible แก้ปัญหาที่ต่างกัน และการตั้งค่าการผลิตส่วนใหญ่ใช้มันด้วยกันแทนที่จะเลือกเพียงอย่างเดียว

Terraform ทำอะไรได้จริง

Terraform เป็นเครื่องมือสำหรับการ provisioning เมื่อต้องการประกาศว่าโครงสร้างพื้นฐานควรมีอยู่: VPC สามอินสแตนซ์ EC2 ฐานข้อมูล RDS bucket S3 ที่มีนโยบายเฉพาะ คุณเขียน HCL ที่อธิบายสถานะสิ้นสุด เรียกใช้ terraform plan เพื่อดูว่าจะเปลี่ยนแปลงอะไร จากนั้น terraform apply เพื่อให้เกิดขึ้นจริง Terraform รักษาไฟล์สถานะ (ในเครื่องหรือในแบ็กเอนด์เช่น bucket S3 ที่มีการล็อก DynamoDB) ที่แมพการกำหนดค่าของคุณไปยัง ID ทรัพยากรจริงในผู้ให้บริการระบบคลาวด์

จุดแข็งที่นี่คือความสามารถในการแก้ไขการขึ้นต่อกันข้ามผู้ให้บริการ หากคุณบอก Terraform ให้สร้างกลุ่มความปลอดภัยและแนบมันกับอินสแตนซ์ EC2 มันจะหาลำดับดำเนินการโดยอัตโนมัติ นอกจากนี้ยังใช้ได้กับ AWS Azure GCP Cloudflare Datadog และผู้ให้บริการอื่นๆ อีกหลายสิบแห่งผ่านขั้นตอนการทำงานเดียวกัน ซึ่งสำคัญเมื่อโครงสร้างพื้นฐานของคุณใช้ผู้ให้บริการมากกว่าหนึ่งแห่ง

Terraform ไม่เก่งในสิ่งที่เกิดขึ้น ภายใน เครื่องเมื่อมันมีอยู่แล้ว มันไม่ติดตั้งแพคเกจ แก้ไขไฟล์การกำหนดค่า หรือรีสตาร์ทบริการในวิธีที่มีความหมายอย่างต่อเนื่อง Provisioners เช่น remote-exec มีอยู่ แต่ HashiCorp เองแนะนำให้หลีกเลี่ยงพวกมันสำหรับสิ่งที่เกินกว่า bootstrapping

Ansible ทำอะไรได้จริง

Ansible เป็นเครื่องมือสำหรับการจัดการการกำหนดค่า มันเชื่อมต่อผ่าน SSH (หรือ WinRM สำหรับ Windows) และรันงานเทียบกับเครื่องที่มีอยู่แล้ว: ติดตั้ง nginx สร้างเทมเพลตไฟล์การกำหนดค่า สร้างผู้ใช้ รีสตาร์ทบริการ บังคับว่างาน cron มีอยู่ Playbooks เป็น YAML และโมดูลเป็นแบบ idempotent ตามการออกแบบ ดังนั้นการรัน playbook เดียวกันสองครั้งไม่ควรเปลี่ยนแปลงอะไรครั้งที่สองถ้าระบบตรงกับสถานะที่ต้องการแล้ว

Ansible ไม่ต้องติดตั้งเอเจนต์บนโฮสต์เป้าหมาย เพียง Python และการเข้าถึง SSH ซึ่งทำให้ติดได้ง่ายกับโครงสร้างพื้นฐานที่มีอยู่ นอกจากนี้ยังเก่งในงานการประสานงานที่ไม่ใช่ "provisioning" อย่างเคร่งครัด — รีสตาร์ทแบบม้วนข้ามกองกำลัง ขั้นตอนการปรับใช้สีน้ำเงิน-เขียว การเรียกใช้การโยกย้ายฐานข้อมูลบนโฮสต์เดียวแล้วอัปเดตตัวสมดุลโหลด

ที่ไหนที่พวกมันทับซ้อนกันและที่ไหนที่ผู้คนสับสน

ทั้งสองเครื่องมือสามารถทำได้เป็นเทคนิคของงานของอีกฝ่ายหนึ่ง Ansible มีโมดูลระบบคลาวด์ (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) ที่สามารถสปินอินฟราโครงสร้าง Terraform มี provisioners ที่สามารถรันคำสั่ง shell บนอินสแตนซ์ใหม่ แต่การใช้ Ansible สำหรับ provisioning หมายถึงการสละการติดตามสถานะของ Terraform และขั้นตอนการทำงาน plan/diff และการใช้ provisioners ของ Terraform สำหรับการกำหนดค่าหมายถึงการสละการจัดการการกำหนดค่าที่ idempotent และสามารถทำซ้ำได้

การแยกส่วนที่ใช้ได้จริงที่ทีมส่วนใหญ่ลงจอด:

• Terraform สร้างโครงสร้างพื้นฐาน: เครือข่าย อินสแตนซ์คอมพิวต์ ตัวสมดุลโหลด ฐานข้อมูลที่มีการจัดการ บทบาท IAM
• Ansible กำหนดค่าสิ่งที่อยู่ด้านบน: การติดตั้งซอฟต์แวร์ ผู้ใช้ ไฟล์การกำหนดค่า สถานะบริการ ขั้นตอนการปรับใช้แอปพลิเคชัน

ตัวอย่างที่เป็นรูปธรรมของการส่ง

สมมติว่าคุณกำลังตั้ง web servers สามเซิร์ฟเวอร์อยู่ด้านหลังตัวสมดุลโหลดบน AWS

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform สร้างอินสแตนซ์และส่งออก IP ของพวกมัน คุณสามารถป้อนผลลัพธ์นั้นไปยัง Ansible inventory แบบไดนามิก (plugin amazon.aws.aws_ec2 อ่านแท็ก EC2 โดยตรง ไม่ต้องคัดลอกแล้ววางด้วยตนเอง) จากนั้นเรียกใช้:

ansible-playbook -i aws_ec2.yml site.yml

โดยที่ site.yml ติดตั้ง nginx หยิบใส่การกำหนดค่าแอปพลิเคชัน และเริ่มบริการ Terraform ไม่เคยสัมผัส nginx Ansible ไม่เคยสัมผัส VPC เครื่องมือแต่ละอันอยู่ในเลนของตัวเอง และเครื่องมือแต่ละอันมีโมเดลสถานะ/idempotency ของตัวเองที่ไม่ขัดแย้งกับของอีกฝ่ายหนึ่ง

ความผิดพลาดทั่วไปที่ควรหลีกเลี่ยง

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

กับ Ansible ความผิดพลาดคือการเขียน playbooks ที่ไม่ใช่ idempotent จริง — ใช้โมดูล shell หรือ command สำหรับสิ่งที่มีโมดูลที่เหมาะสม (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) ที่จัดการตรรกะ check-then-act อย่างถูกต้องแล้ว

หากคุณตัดสินใจว่าจะเรียนก่อน: เรียน Terraform หากคุณกำลังทำ cloud provisioning และการตั้งค่าหลายสภาพแวดล้อม เรียน Ansible หากคุณกำลังจัดการการล่องลอยของการกำหนดค่าบนเซิร์ฟเวอร์ที่คุณมีอยู่แล้ว บทบาท DevOps ส่วนใหญ่คาดว่าคุณจะคุ้นเคยกับทั้งสองภายในปีแรก

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการจัดการสถานะ inventories แบบไดนามิก และการสร้างไปป์ไลน์ CI/CD แบบเต็มรอบด้วยเครื่องมือเหล่านี้ โปรดตรวจสอบส่วนที่เกี่ยวข้องกับ DevOps และ Cloud บน Korra Studio