เปรียบเทียบ Ansible vs Terraform เลือกใช้อะไรดี

ความแตกต่างระหว่าง Ansible และ Terraform ในประโยคเดียว

การเลือกระหว่าง Ansible และ Terraform ไม่ใช่การเลือกเครื่องมือที่ทำงานเหมือนกัน Terraform ใช้สำหรับประกาศสถานะของโครงสร้างพื้นฐานที่มีอยู่ เช่น เซิร์ฟเวอร์, ดิสก์, เครือข่าย และระเบียน DNS ส่วน Ansible ใช้สำหรับประกาศสถานะภายในเครื่องที่ถูกสร้างขึ้นมาแล้ว เช่น แพ็กเกจ, ผู้ใช้งาน, ไฟล์คอนฟิก และบริการที่กำลังทำงานอยู่ กล่าวคือ Terraform ทำหน้าที่สร้าง VPS ขึ้นมา และ Ansible ทำหน้าที่เปลี่ยน VPS นั้นให้กลายเป็นเว็บเซิร์ฟเวอร์

ทั้งสองเครื่องมือเป็นแบบ declarative และถูกเรียกว่าเป็น Infrastructure as Code (IaC) เหมือนกัน แต่ความแตกต่างที่แท้จริงอยู่ที่สิ่งที่เครื่องมือจดจำ Terraform จะเขียนไฟล์ state เพื่อจับคู่ทรัพยากรทุกอย่างในโค้ดเข้ากับวัตถุจริงที่สร้างผ่าน API ทำให้มันทราบว่าการลบโค้ด 5 บรรทัดหมายถึงการต้องทำลายเซิร์ฟเวอร์ทิ้งหนึ่งเครื่อง ในขณะที่ Ansible ไม่จดจำสถานะใดๆ ระหว่างการรันแต่ละครั้ง มันจะเชื่อมต่อผ่าน SSH ตรวจสอบสถานะของเครื่อง และแก้ไขเฉพาะสิ่งที่ยังไม่ตรงกับ playbook เท่านั้น

ความแตกต่างเพียงข้อเดียวนี้อธิบายเนื้อหาที่เหลือของคู่มือนี้ รวมถึงเหตุผลว่าทำไมการนำงานทั้งสองอย่างมารวมไว้ในเครื่องมือเดียวจึงมักจะเกิดปัญหา

สิ่งที่ Terraform ทำงานจริง

Terraform ติดต่อกับ API ผ่านทาง provider plugin หน้า registry ของ provider จะกำหนดประเภทของ resource ที่คุณสามารถเขียนได้ ดังนั้นเซิร์ฟเวอร์บนโฮสต์หนึ่งกับอีกโฮสต์หนึ่งจึงมีชื่อ resource และ argument ที่แตกต่างกัน

resource "cloud_server" "web" {
  name  = "web1"
  image = "ubuntu-24.04"
  type  = "small"
}

output "web_ip" {
  value = cloud_server.web.ipv4_address
}

ให้แทนที่ cloud_server ด้วยประเภทของ resource ตามที่ provider ของคุณระบุไว้ บล็อก output เป็นส่วนที่สำคัญที่สุดสำหรับคู่มือนี้ เนื่องจากเป็นวิธีที่ที่อยู่ (address) ถูกส่งออกจาก Terraform

terraform init
terraform fmt -check
terraform validate
terraform plan -out=tfplan
terraform apply tfplan

terraform init จะดาวน์โหลด provider และเขียนไฟล์ lock file ส่วน terraform plan จะแสดงความแตกต่างระหว่างโค้ดของคุณกับไฟล์ state โดยจบด้วยบรรทัดที่คล้ายกับ Plan: 1 to add, 0 to change, 0 to destroy. ให้ตรวจสอบบรรทัดนั้นทุกครั้ง argument บางอย่างไม่สามารถเปลี่ยนแปลงได้ทันที (in-place) และแผนการทำงานจะระบุไว้ด้วย # forces replacement ถัดจาก attribute นั้น ตามด้วย 1 to add, 0 to change, 1 to destroy การนำแผนนั้นไปใช้ (apply) จะลบเซิร์ฟเวอร์เดิมทิ้งและสร้างเซิร์ฟเวอร์เปล่าขึ้นมาใหม่ ซึ่งเป็นสาเหตุที่ทำให้ผู้ใช้งานสูญเสียข้อมูลที่คิดว่าปลอดภัยไป

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

terraform.tfstate คือหน่วยความจำ หากทำไฟล์นี้หาย Terraform จะไม่ทราบอีกต่อไปว่าเซิร์ฟเวอร์เหล่านั้นเป็นของคุณ ดังนั้นการรัน apply ครั้งถัดไปจะพยายามสร้างเซิร์ฟเวอร์ซ้ำขึ้นมา ให้เก็บไฟล์นี้ไว้ใน remote backend ทันทีที่มีคนมากกว่าหนึ่งคนรันคำสั่งเหล่านี้ เพราะหากสองคนรันคำสั่งพร้อมกันจะเกิดเหตุการณ์นี้:

Error: Error acquiring the state lock

OpenTofu คือ fork ของ Terraform ที่ใช้คำสั่งและรูปแบบไฟล์เดียวกัน ณ เดือนกรกฎาคม 2026 ทุกอย่างในคู่มือนี้สามารถใช้งานได้หากคุณพิมพ์ tofu แทน terraform

สิ่งที่ Ansible ทำงานจริง

Ansible ไม่จำเป็นต้องมี agent หรือ API มันจะเปิดการเชื่อมต่อ SSH คัดลอกโมดูล Python ขนาดเล็กไปยังเป้าหมาย รันโมดูลนั้น แล้วลบออก สิ่งใดก็ตามที่คุณสามารถเข้าถึงได้ด้วย SSH และรหัสผ่าน sudo สิ่งนั้น Ansible ก็สามารถกำหนดค่าได้

- name: Base web server
  hosts: web
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Ensure nginx is running at boot
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

ansible -i inventory.ini web -m ansible.builtin.ping
ansible-playbook -i inventory.ini site.yml --check --diff
ansible-playbook -i inventory.ini site.yml

โมดูล ping ใช้ตรวจสอบ SSH, Python และ sudo ก่อนที่คุณจะเริ่มดีบั๊ก playbook ผลลัพธ์ที่ปกติคือ web1 | SUCCESS => {"ping": "pong"} การรันด้วย --check --diff คือสิ่งที่ใกล้เคียงที่สุดกับแผนการทำงานของ Ansible โดยจะรายงานสิ่งที่อาจเปลี่ยนแปลงโดยที่ยังไม่มีการเปลี่ยนแปลงจริง อย่างไรก็ตาม งานที่ขึ้นอยู่กับงานก่อนหน้าอาจรายงานผลผิดพลาดในโหมดตรวจสอบได้ เนื่องจากงานก่อนหน้าไม่ได้ถูกดำเนินการจริง

การรันทุกครั้งจะจบลงด้วยสรุปผลเช่น ok=6 changed=2 unreachable=0 failed=0 ให้ลองรัน playbook เดิมซ้ำอีกครั้ง การรันครั้งที่สองควรรายงานผลเป็น changed=0 งานใดที่รายงานว่า changed ในทุกครั้งที่รันถือว่าไม่มีความเป็น idempotent ซึ่งมักจะเป็นงานประเภท command หรือ shell ที่ควรจะเปลี่ยนไปใช้โมดูลที่เหมาะสม หากคุณเพิ่งเริ่มต้น ให้เริ่มจาก playbook แรกของ Ansible บน VPS เดียว แล้วค่อยขยายขอบเขตจากจุดนั้น

จุดที่เครื่องมือทั้งสองทำงานซ้อนทับกันและจุดที่เกิดความขัดแย้ง

Terraform สามารถรันคำสั่งบนเซิร์ฟเวอร์ใหม่ได้ด้วย provisioner remote-exec เอกสารของ HashiCorp เองระบุว่า provisioner ควรเป็นทางเลือกสุดท้าย ซึ่งมีเหตุผลรองรับที่ชัดเจน

provisioner จะทำงานเฉพาะตอนที่สร้างทรัพยากรเท่านั้น หากคุณแก้ไขสคริปต์ จะไม่มีการเปลี่ยนแปลงใดๆ เกิดขึ้นบนเซิร์ฟเวอร์ที่มีอยู่เดิม เพราะในมุมมองของ Terraform ทรัพยากรนั้นตรงกับโค้ดอยู่แล้ว ขั้นตอนของ provisioner จะไม่ปรากฏใน terraform plan ทำให้การตรวจสอบโค้ดของคุณไม่แสดงร่องรอยการทำงานเหล่านี้ หากสคริปต์ล้มเหลว Terraform จะทำเครื่องหมายทรัพยากรนั้นว่า tainted และการรัน apply ครั้งถัดไปจะทำลายและสร้างเซิร์ฟเวอร์ใหม่ขึ้นมา ทั้งที่เซิร์ฟเวอร์เดิมอาจจะยังใช้งานได้ปกติ

นอกจากนี้ ความล้มเหลวยังเกิดขึ้นในจังหวะที่ไม่เหมาะสม โดย provider จะรายงานว่าเซิร์ฟเวอร์ถูกสร้างขึ้นทันทีที่ API ตอบกลับ ในขณะที่ระบบปฏิบัติการอาจยังอยู่ในระหว่างการบูตและ sshd ยังไม่เปิดรับการเชื่อมต่อ

Error: remote-exec provisioner error
timeout - last error: dial tcp 203.0.113.10:22: connect: connection refused

Ansible มีความเสี่ยงในทางตรงกันข้าม โมดูลสำหรับ Cloud สามารถสร้างเซิร์ฟเวอร์ได้ และวิธีนี้ใช้ได้ผลดีกับเครื่องจำนวนไม่กี่เครื่อง แต่สิ่งที่คุณต้องสูญเสียไปคือ dependency graph และไฟล์ state โดย Ansible จะสร้างทรัพยากรให้คุณอย่างไม่มีปัญหา แต่หากคุณลบทาสก์นั้นออกจาก playbook ทรัพยากรก็จะยังคงทำงานอยู่และถูกเรียกเก็บเงินต่อไป เพราะไม่มีบันทึกใดระบุว่าทรัพยากรนั้นเป็นของคุณ

กฎที่ได้จากเรื่องนี้คือ: ให้ Terraform ดูแลออบเจกต์ที่ต้องสร้างและทำลายผ่าน API และให้ Ansible ดูแลทุกอย่างที่อยู่ภายในระบบปฏิบัติการที่บูตขึ้นมาแล้ว

การส่งต่องานที่สำเร็จแล้ว

การส่งต่องานคือขอบเขต ไม่ใช่การรวมระบบ Terraform ทำงานจนเสร็จสิ้น ประกาศที่อยู่ IP แล้วหยุดทำงาน จากนั้น Ansible จึงเริ่มทำงานต่อจากที่อยู่นั้น

terraform apply -auto-approve
terraform output -raw web_ip
printf '[web]\n%s ansible_user=root\n' "$(terraform output -raw web_ip)" > inventory.ini
ansible -i inventory.ini web -m ansible.builtin.ping
ansible-playbook -i inventory.ini site.yml

terraform output -raw จะพิมพ์ค่าออกมาหนึ่งค่าโดยไม่มีเครื่องหมายคำพูดและไม่มี JSON wrapper ซึ่งเป็นสิ่งที่คุณต้องการเมื่อใช้งานภายใน shell substitution สำหรับเซิร์ฟเวอร์หลายเครื่อง ให้ใช้ terraform output -json แล้วสร้าง inventory จากค่าที่ได้ เนื่องจาก -raw รองรับเฉพาะสตริง ตัวเลข หรือค่าบูลีนเพียงค่าเดียวเท่านั้น

ขั้นตอน ping ระหว่างเครื่องมือทั้งสองนั้นคุ้มค่าที่จะคงไว้ เพราะช่วยแยกปัญหา "Terraform ให้ที่อยู่ผิด" ออกจาก "playbook ของฉันมีบั๊ก" ซึ่งปัญหาทั้งสองอย่างนี้จะดูเหมือนกันทุกประการหาก playbook เป็นสิ่งแรกที่เข้าถึงเซิร์ฟเวอร์เครื่องใหม่

การอ่าน Terraform state เพื่อใช้เป็น Ansible inventory

หากคุณไม่ต้องการเขียนไฟล์ inventory ด้วยตนเอง คุณสามารถใช้คอลเลกชัน cloud.terraform เพื่ออ่านค่าจาก state โดยตรงได้

ansible-galaxy collection install cloud.terraform

ให้สร้างไฟล์ terraform.yml ไว้ข้างๆ playbook ของคุณ:

plugin: cloud.terraform.terraform_provider
project_path: /home/deploy/infra

ansible-inventory -i terraform.yml --graph
ansible-playbook -i terraform.yml site.yml

มีสองสิ่งที่ควรทราบก่อนเริ่มใช้งาน ปลั๊กอินนี้จะรันคำสั่ง terraform show เทียบกับ project_path ดังนั้นไดเรกทอรีดังกล่าวจะต้องถูก initialized ไว้ก่อน มิฉะนั้นปลั๊กอินจะทำงานล้มเหลว นอกจากนี้ ปลั๊กอินจะไม่สร้างรายการโฮสต์จากทรัพยากรเซิร์ฟเวอร์ของคุณโดยอัตโนมัติ แต่จะอ่านจากทรัพยากร ansible_host และ ansible_group ที่คุณประกาศไว้ในโค้ด Terraform โดยใช้ Ansible provider เท่านั้น จะไม่มีข้อมูลใดปรากฏใน ansible-inventory --graph จนกว่าคุณจะเพิ่มทรัพยากรเหล่านั้นเข้าไป

การใช้ไฟล์ inventory แบบปกติที่สร้างขึ้นมานั้นตรวจสอบข้อผิดพลาดได้ง่ายกว่าและรองรับทุก provider แต่ปลั๊กอินนี้จะเริ่มคุ้มค่าเมื่อ inventory ของคุณมีขนาดใหญ่เกินกว่าจำนวนเครื่องเพียงไม่กี่เครื่อง และการแก้ไขด้วยมือเริ่มทำให้เกิดคำผิด ซึ่งเป็นจุดเดียวกับที่ การจัดการเซิร์ฟเวอร์ Linux หลายเครื่องจากเครื่องควบคุมเครื่องเดียว จะกลายเป็นขั้นตอนการทำงานจริงแทนที่จะเป็นเพียงความเคยชิน

คุณจำเป็นต้องใช้ Terraform จริงหรือ

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

ให้เลือกใช้ Terraform เมื่อคุณต้องสร้างสภาพแวดล้อมใหม่บ่อยครั้ง เมื่อสภาพแวดล้อม staging ต้องเหมือนกับ production ทุกประการ เมื่อมีหลายคนร่วมกันเปลี่ยนแปลงโครงสร้างพื้นฐานและคุณต้องการแผนงานที่ตรวจสอบได้ก่อนที่จะมีการลบสิ่งใดออกไป หรือเมื่อสิ่งที่คุณจัดการมีมากกว่าแค่เซิร์ฟเวอร์ เช่น ระเบียน DNS, load balancer และกฎ firewall ที่อยู่บน API ของผู้ให้บริการ

ให้ใช้เพียง Ansible ต่อไปเมื่อเซิร์ฟเวอร์มีอายุการใช้งานยาวนานและมีจำนวนไม่มาก และเมื่อคำถามประจำวันของคุณคือ "เซิร์ฟเวอร์เครื่องนี้ถูกตั้งค่าไว้อย่างถูกต้องหรือไม่" แทนที่จะเป็น "เซิร์ฟเวอร์เครื่องนี้มีอยู่จริงหรือไม่" playbook เพียงชุดเดียวที่ใช้ปรับแต่งเซิร์ฟเวอร์ใหม่ให้มีความปลอดภัย ก็ให้ผลลัพธ์เช่นเดียวกับ สิบนาทีแรกบน VPS เครื่องใหม่ โดยมีข้อดีคือมันสามารถทำงานในลักษณะเดียวกันบนเซิร์ฟเวอร์เครื่องถัดไปได้

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

สิ่งที่ทำให้การส่งต่องานล้มเหลว

เซิร์ฟเวอร์ยังไม่พร้อมใช้งาน Terraform ทำงานสำเร็จ แต่ Ansible ล้มเหลวในทันที

fatal: [web1]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host 203.0.113.10 port 22: Connection refused", "unreachable": true}

API ส่งคืนที่อยู่ IP มาก่อนที่ sshd จะเริ่มฟังพอร์ต ให้รอจนกว่าพอร์ตจะพร้อมแทนการใช้คำสั่ง sleep แบบกำหนดเวลาตายตัว Ansible มีโมดูล ansible.builtin.wait_for_connection สำหรับจัดการเรื่องนี้โดยเฉพาะ ให้เรียกใช้เป็นงานแรกของ play เมื่อ playbook เดียวกันต้องจัดการกับกลุ่มโฮสต์แทนที่จะเป็นเครื่องใหม่เพียงเครื่องเดียว ให้ตัดสินใจล่วงหน้าว่า ควรทำอย่างไรเมื่อโฮสต์หนึ่งไม่สามารถติดต่อได้ เพราะ Ansible จะตัดโฮสต์นั้นออกจากการทำงานที่เหลือ และบรรทัดสรุปผล (recap) จะเป็นที่เดียวที่แจ้งเตือนคุณ

Host key เปลี่ยนแปลง คุณทำลายและสร้างเซิร์ฟเวอร์ขึ้นใหม่ และเครื่องใหม่ตอบสนองบนที่อยู่เดิมด้วย key ใหม่

Host key verification failed.

ลบรายการที่ล้าสมัยออกด้วย ssh-keygen -R 203.0.113.10 ปัญหานี้เกิดขึ้นบ่อยครั้งเมื่อ Terraform ทำการสร้างใหม่ ซึ่งเป็นเหตุผลที่ดีในการจำกัดการสร้างใหม่บนเครื่องที่มีข้อมูลสำคัญ

Sudo ล้มเหลว fatal: [web1]: FAILED! => {"msg": "Missing sudo password"} หมายความว่า become: true ต้องการรหัสผ่านบนโฮสต์นั้น ให้กำหนดค่า sudo แบบไม่ต้องใช้รหัสผ่านสำหรับผู้ใช้ที่ใช้ deploy หรือส่งผ่าน --ask-become-pass

Terraform ต้องการทำลายสิ่งที่ไม่ได้แก้ไข แผนการทำงาน (plan) แสดงการเปลี่ยนแปลงที่คุณไม่ได้เขียนไว้ ซึ่งหมายความว่าโครงสร้างพื้นฐานจริงเบี่ยงเบนไปจากโค้ด มักเกิดจากการที่มีคนไปเปลี่ยนการตั้งค่าในแผงควบคุมบนเว็บของผู้ให้บริการ ให้รัน terraform plan -refresh-only เพื่อดูความแตกต่างนั้นโดยเฉพาะ แล้วตัดสินใจว่าโค้ดหรือทรัพยากรที่มีอยู่จริงเป็นฝ่ายที่ผิด ห้ามใช้แผนการทำงานที่ทำลายทรัพยากรหากคุณไม่สามารถอธิบายได้ทีละบรรทัด

Ansible รายงานว่ามีการเปลี่ยนแปลงทุกครั้งที่รัน งาน shell ที่ไม่มีเงื่อนไข creates หรือ when จะทำงานโดยไม่มีเงื่อนไข นี่ไม่ใช่แค่ปัญหาเรื่องความสวยงาม เพราะนั่นหมายความว่าคุณไม่สามารถใช้ changed=0 เป็นสัญญาณบ่งชี้ว่าเซิร์ฟเวอร์อยู่ในสถานะที่คุณต้องการได้อีกต่อไป

FAQ

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

ไม่ได้สำหรับการตั้งค่าภายในเซิร์ฟเวอร์ Terraform สามารถเรียกใช้สคริปต์ด้วย provisioner remote-exec ได้ แต่สคริปต์เหล่านั้นจะทำงานเฉพาะตอนสร้างทรัพยากรเท่านั้น ไม่ปรากฏใน terraform plan และจะทำให้ทรัพยากรนั้นติดสถานะ taint เมื่อทำงานล้มเหลว ซึ่งจะส่งผลให้เกิดการสั่งทำลายและสร้างใหม่ในการรันคำสั่ง apply ครั้งถัดไป Terraform ไม่มีโมดูลที่เทียบเท่ากับการตรวจสอบว่า nginx ถูกติดตั้งไว้แล้วหรือไม่และไม่ทำอะไรหากติดตั้งอยู่แล้ว ให้ใช้ Terraform เพื่อสร้างเครื่อง แล้วจึงส่งต่องานให้ Ansible

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

สำหรับเซิร์ฟเวอร์จำนวนน้อยที่มีอายุการใช้งานยาวนาน สามารถทำได้ Ansible มีโมดูลสำหรับระบบคลาวด์ที่ใช้สร้างเซิร์ฟเวอร์ หากคุณสั่งซื้อ VPS สองสามเครื่องและใช้งานไปเรื่อยๆ วิธีนี้ก็เพียงพอแล้ว สิ่งที่คุณจะสูญเสียไปคือไฟล์สถานะ (state file) และกราฟความสัมพันธ์ (dependency graph) หากคุณลบทาสก์ออกจาก playbook ทรัพยากรนั้นจะยังคงทำงานและถูกเรียกเก็บเงินต่อไป เพราะ Ansible ไม่ได้บันทึกไว้ว่ามันเป็นผู้สร้างทรัพยากรนั้นขึ้นมา ในขณะที่ Terraform จะวางแผนการทำลายทรัพยากรนั้นให้

ควรเรียนรู้อะไรก่อน?

ควรเริ่มที่ Ansible หากคุณมีเซิร์ฟเวอร์ใช้งานอยู่แล้ว มันให้ผลตอบแทนตั้งแต่เครื่องแรก ไม่ต้องการอะไรนอกจาก SSH และทักษะนี้สามารถนำไปใช้กับเซิร์ฟเวอร์ที่คุณสั่งซื้อด้วยตนเองได้ ส่วน Terraform จะให้ผลตอบแทนในภายหลัง เมื่อคุณต้องสร้างสภาพแวดล้อมซ้ำๆ หรือจัดการทรัพยากรของผู้ให้บริการที่นอกเหนือจากเซิร์ฟเวอร์ เช่น ระเบียน DNS และกฎของไฟร์วอลล์

ฉันจะส่ง IP ของเซิร์ฟเวอร์ใหม่จาก Terraform ไปยัง Ansible ได้อย่างไร?

ให้ประกาศ output ไว้ในโค้ด Terraform ของคุณ แล้วอ่านค่าหลังจากรัน apply คำสั่ง terraform output -raw web_ip จะแสดงค่าดิบสำหรับการแทนที่ในเชลล์ และ terraform output -json จะแสดงผลลัพธ์ทั้งหมดพร้อมกันในกรณีที่มีหลายโฮสต์ คุณสามารถเขียนค่าเหล่านั้นลงในไฟล์ inventory หรือติดตั้งคอลเลกชัน cloud.terraform แล้วชี้ ansible-inventory -i terraform.yml --graph ไปที่ไดเรกทอรีของโปรเจกต์

ทำไม playbook ของฉันถึงล้มเหลวทันทีหลังจาก Terraform ทำงานเสร็จ?

ผู้ให้บริการจะรายงานว่าเซิร์ฟเวอร์ถูกสร้างขึ้นทันทีที่ API ตอบรับ แต่ในขณะนั้นระบบปฏิบัติการอาจยังอยู่ในระหว่างการบูต ทำให้การเชื่อมต่อ SSH ถูกปฏิเสธในช่วงวินาทีแรก ข้อผิดพลาดที่พบคือ UNREACHABLE! พร้อมกับ Connection refused ให้กำหนดให้ ansible.builtin.wait_for_connection เป็นทาสก์แรกใน play แทนการคาดเดาระยะเวลา sleep เพราะเวลาในการบูตขึ้นอยู่กับอิมเมจและแผนการใช้งานที่แตกต่างกันไป