Ansible กับ Terraform เลือกใช้อะไรดี ต่างกันอย่างไร

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

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

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

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

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

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

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 เป็นส่วนสำคัญสำหรับคู่มือนี้ เพราะเป็นจุดที่แอดเดรสถูกส่งออกจาก Terraform

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

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

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

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

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 สามารถรันคำสั่งบนเซิร์ฟเวอร์ใหม่ได้ด้วย remote-exec provisioner เอกสารของ 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 ครอบ ซึ่งเป็นรูปแบบที่ต้องการสำหรับการทำ shell substitution หากมีเซิร์ฟเวอร์หลายเครื่อง ให้ใช้ terraform output -json เพื่อสร้าง inventory จากข้อมูลนั้น เนื่องจาก -raw รองรับเฉพาะสตริง ตัวเลข หรือค่าบูลีนเพียงค่าเดียวเท่านั้น

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

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

หากคุณไม่ต้องการเขียนไฟล์ inventory เลย cloud.terraform collection สามารถอ่านค่าจาก 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 เพียงหนึ่งเครื่องผ่านแผงควบคุมและตั้งใจจะใช้งานไปอีก 2 ปี 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

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

Host key verification failed.

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

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

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

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

FAQ

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

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

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

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

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

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

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

ประกาศ output ในโค้ด Terraform ของคุณ แล้วอ่านค่าหลังจากสั่ง apply เสร็จสิ้น terraform output -raw web_ip จะแสดงค่าดิบสำหรับนำไปใช้ใน shell substitution และ 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 เพราะเวลาในการบูตขึ้นอยู่กับ image และแผนการใช้งานที่แตกต่างกันไป