Ansible vs Terraform: எதை எப்போது பயன்படுத்த வேண்டும்?

Ansible மற்றும் Terraform ஆகியவற்றுக்கு இடையேயான வேறுபாடு ஒரே வரியில்

Ansible மற்றும் Terraform ஆகிய இரண்டும் ஒரே வேலையைச் செய்யும் கருவிகள் அல்ல. Terraform என்பது ஏற்கனவே உள்ள உள்கட்டமைப்பை (servers, disks, networks, DNS records) வரையறுக்கிறது. Ansible என்பது ஏற்கனவே இயங்கும் ஒரு machine-க்குள் என்னென்ன இருக்க வேண்டும் (packages, users, config files, running services) என்பதை வரையறுக்கிறது. Terraform ஒரு VPS-ஐ உருவாக்குகிறது; Ansible அந்த VPS-ஐ ஒரு web server-ஆக மாற்றுகிறது.

இவை இரண்டுமே declarative வகையைச் சேர்ந்தவை மற்றும் இவை இரண்டும் infrastructure as code (IaC) என்று அழைக்கப்படுகின்றன. இவற்றின் உண்மையான வேறுபாடு அவை எதை நினைவில் கொள்கின்றன என்பதில் உள்ளது. Terraform ஒரு state file-ஐ உருவாக்குகிறது; இது உங்கள் code-ல் உள்ள ஒவ்வொரு resource-ஐயும் அது API மூலம் உருவாக்கிய உண்மையான object-உடன் இணைக்கிறது. எனவே, ஐந்து வரிகளை நீக்கினால் ஒரு server-ஐ அழிக்க வேண்டும் என்பதை அதனால் புரிந்துகொள்ள முடியும். Ansible இயங்கும் ஒவ்வொரு முறையும் எதையும் நினைவில் கொள்வதில்லை. இது SSH மூலம் இணைந்து, machine-ஐ ஆய்வு செய்து, playbook-உடன் பொருந்தாதவற்றை மட்டும் மாற்றுகிறது.

இந்த ஒரு அடிப்படை வேறுபாடே இந்த வழிகாட்டியின் பிற பகுதிகளை விளக்குகிறது; மேலும், இந்த இரண்டு பணிகளையும் ஒரே கருவியில் இணைப்பது ஏன் தவறானது என்பதையும் இது தெளிவுபடுத்துகிறது.

Terraform உண்மையில் என்ன செய்கிறது

Terraform ஒரு provider plugin வழியாக API-உடன் தொடர்பு கொள்கிறது. நீங்கள் எழுதக்கூடிய resource வகைகளை உங்கள் provider-ன் registry பக்கம் வரையறுக்கிறது. எனவே, ஒரு host-ல் உள்ள server-ம் மற்றொரு host-ல் உள்ள server-ம் வெவ்வேறு arguments-களைக் கொண்ட வெவ்வேறு resource பெயர்களாகும்.

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

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

cloud_server-ஐ உங்கள் provider ஆவணப்படுத்தியுள்ள resource வகையைக் கொண்டு மாற்றவும். இந்த வழிகாட்டிக்கு output தொகுதி மிக முக்கியமானது, ஏனெனில் இதுதான் Terraform-லிருந்து முகவரி வெளியேறும் வழியாகும்.

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

terraform init, provider-ஐத் தரவிறக்கம் செய்து ஒரு lock file-ஐ உருவாக்குகிறது. terraform plan, உங்கள் குறியீட்டிற்கும் state file-க்கும் இடையே உள்ள வித்தியாசத்தைக் காட்டுகிறது, இது Plan: 1 to add, 0 to change, 0 to destroy. போன்ற ஒரு வரியுடன் முடிவடையும். ஒவ்வொரு முறையும் அந்த வரியைப் படிக்கவும். சில arguments-களை அப்படியே மாற்ற முடியாது, இதை plan, attribute-க்கு அருகில் # forces replacement என்றும், அதைத் தொடர்ந்து 1 to add, 0 to change, 1 to destroy என்றும் குறிப்பிடும். அந்த plan-ஐ apply செய்வது server-ஐ நீக்கிவிட்டு புதிய காலி server-ஐ உருவாக்கும்; பாதுகாப்பாக இருப்பதாகக் கருதிய தரவுகளை மக்கள் இழப்பதற்கு இதுவே காரணமாகிறது.

வெறுமனே terraform apply-ஐ இயக்குவதற்குப் பதிலாக, plan-ஐ ஒரு கோப்பில் சேமித்து அந்த கோப்பை apply செய்வது, நீங்கள் ஆய்வு செய்த அதே விஷயம் தான் இயங்குகிறது என்பதை உறுதிப்படுத்துகிறது. இந்த இரண்டு கட்டளைகளுக்கு இடைப்பட்ட நேரத்தில், வேறொருவர் உள்கட்டமைப்பை மாற்றியிருக்கலாம்.

terraform.tfstate என்பது நினைவகம் (memory) போன்றது. இதை இழந்துவிட்டால், அந்த server-கள் உங்களுடையவை என்பது Terraform-க்குத் தெரியாது, எனவே அடுத்த முறை apply செய்யும்போது அது நகல்களை உருவாக்க முயற்சிக்கும். ஒன்றுக்கும் மேற்பட்ட நபர்கள் கட்டளைகளை இயக்கும்போது, இதை ஒரு remote backend-ல் சேமிக்கவும், ஏனெனில் இருவர் ஒரே நேரத்தில் apply செய்யும்போது இது நிகழும்:

Error: Error acquiring the state lock

OpenTofu என்பது Terraform-ன் ஒரு fork ஆகும், இது அதே கட்டளைகளையும் அதே கோப்பு வடிவத்தையும் கொண்டுள்ளது. ஜூலை 2026 நிலவரப்படி, terraform-க்கு பதிலாக tofu என்று தட்டச்சு செய்தால் இந்த வழிகாட்டியில் உள்ள அனைத்தும் வேலை செய்யும்.

Ansible உண்மையில் என்ன செய்கிறது

Ansible-க்கு agent அல்லது API தேவையில்லை. இது ஒரு SSH இணைப்பைத் திறந்து, ஒரு சிறிய Python module-ஐ இலக்கு server-க்கு நகர்த்தி, அதை இயக்கி, பின் நீக்கிவிடும். SSH மற்றும் sudo கடவுச்சொல் மூலம் நீங்கள் எதை அணுக முடியுமோ, அதை Ansible மூலம் configure செய்ய முடியும்.

- 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

நீங்கள் playbook-ஐ debug செய்யத் தொடங்கும் முன், SSH, Python மற்றும் sudo சரியாக உள்ளதா என்பதை ping module உறுதிப்படுத்துகிறது. சரியான முடிவு web1 | SUCCESS => {"ping": "pong"} என்று வரும். --check --diff இயக்கம் என்பது Ansible-ன் திட்டமிடல் போன்றது: இது எதையும் மாற்றாமல், என்ன மாற்றங்கள் ஏற்படும் என்பதை மட்டும் தெரிவிக்கும். இருப்பினும், முந்தைய பணிகளைச் சார்ந்திருக்கும் பணிகள் check mode-ல் தவறான தகவலைத் தரலாம், ஏனெனில் முந்தைய மாற்றங்கள் உண்மையில் அங்கு நடந்திருக்காது.

ஒவ்வொரு இயக்கமும் ok=6 changed=2 unreachable=0 failed=0 போன்ற ஒரு சுருக்கத்துடன் முடிவடையும். அதே playbook-ஐ இரண்டு முறை இயக்கவும். இரண்டாவது முறை changed=0 என்று காட்ட வேண்டும். ஒவ்வொரு முறையும் changed என்று காட்டும் ஒரு பணி idempotent அல்ல. அது வழக்கமாக ஒரு command அல்லது shell பணியாக இருக்கும், அது ஒரு முறையான module-ஆக இருந்திருக்க வேண்டும். இது உங்களுக்குப் புதியது என்றால், ஒரு VPS-ல் முதல் Ansible playbook-ஐ உருவாக்குதல் என்பதிலிருந்து தொடங்கி, படிப்படியாக முன்னேறுங்கள்.

இரண்டு கருவிகளும் இணையும் இடங்கள் மற்றும் முரண்படும் இடங்கள்

Terraform ஒரு புதிய server-ல் remote-exec provisioner மூலம் கட்டளைகளை இயக்க முடியும். HashiCorp-ன் சொந்த ஆவணங்களே provisioner-களை ஒரு கடைசி முயற்சியாகவே கருதுகின்றன. இதற்கு வலுவான காரணங்கள் உள்ளன.

ஒரு resource உருவாக்கப்படும்போது மட்டுமே provisioner இயங்கும். நீங்கள் script-ஐ மாற்றினாலும் ஏற்கனவே உள்ள server-ல் எந்த மாற்றமும் நடக்காது, ஏனெனில் Terraform-ன் பார்வையில் அந்த resource ஏற்கனவே code-உடன் ஒத்துப்போகிறது. Provisioner படிகள் terraform plan-ல் ஒருபோதும் தெரிவதில்லை, எனவே உங்கள் review-ல் அவை குறித்த எந்த அறிகுறியும் இருக்காது. அந்த script தோல்வியடைந்தால், Terraform அந்த resource-ஐ tainted எனக் குறிக்கும்; அடுத்தமுறை apply செய்யும்போது, சரியாக இயங்கிக்கொண்டிருந்த server-ஐ அழித்துவிட்டு மீண்டும் உருவாக்கும்.

இந்தத் தோல்வி தவறான நேரத்தில் நிகழ்கிறது. API உறுதி அளித்தவுடன் server உருவாக்கப்பட்டுவிட்டதாக provider தெரிவித்துவிடும், ஆனால் அந்த நேரத்தில் operating system boot ஆகிக்கொண்டிருக்கும், sshd இன்னும் listening நிலையில் இருக்காது.

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

Ansible-ல் இதற்கு நேர்மாறான சிக்கல் உள்ளது. Cloud modules மூலம் server-களை உருவாக்க முடியும், சில machines-க்கு இது வேலை செய்யும். ஆனால் நீங்கள் dependency graph மற்றும் state file-ஐ இழக்கிறீர்கள். Ansible ஒரு resource-ஐ மகிழ்ச்சியுடன் உருவாக்கும், ஆனால் உங்கள் playbook-லிருந்து அந்த task-ஐ நீக்கினால், அந்த resource தொடர்ந்து இயங்கிக்கொண்டிருக்கும் மற்றும் அதற்கான கட்டணமும் வசூலிக்கப்படும், ஏனெனில் அது உங்களுடையது என்பதை எங்கும் பதிவு செய்யவில்லை.

இதிலிருந்து பெறப்படும் விதி இதுதான்: API மூலம் உருவாக்கப்பட்டு அழிக்கப்படும் object-களை Terraform-ன் கட்டுப்பாட்டில் விடுங்கள், அதேபோல் boot ஆன operating system-க்குள் உள்ள அனைத்தையும் Ansible-ன் கட்டுப்பாட்டில் விடுங்கள்.

handoff, வெற்றிகரமாக முடிந்தது

handoff என்பது ஒரு எல்லை, ஒருங்கிணைப்பு அல்ல. Terraform தனது பணியை முடித்து, ஒரு முகவரியை (address) வெளியிட்டுவிட்டு நின்றுவிடுகிறது. அந்த முகவரியிலிருந்து 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, மேற்கோள் குறிகள் (quotes) அல்லது JSON wrapper இல்லாமல் ஒரு மதிப்பை மட்டும் அச்சிடும். shell substitution-க்குள் உங்களுக்குத் தேவைப்படுவது இதுவே. பல server-களுக்கு, terraform output -json-ஐப் பயன்படுத்தி inventory-ஐ உருவாக்கவும், ஏனெனில் -raw ஒரு string, எண் அல்லது boolean-ஐ மட்டுமே கையாளும்.

இந்த இரண்டு கருவிகளுக்கும் இடையே உள்ள ping படியைத் தக்கவைப்பது நல்லது. இது "Terraform தவறான முகவரியைக் கொடுத்துவிட்டது" என்பதையும் "எனது playbook-ல் பிழை உள்ளது" என்பதையும் தனித்தனியாகப் பிரித்துக் காட்டுகிறது. புதிய server-ஐத் தொடும் முதல் கருவியாக playbook இருந்தால், இந்த இரண்டு சிக்கல்களும் ஒரே மாதிரியாகத் தோன்றும்.

Terraform state-ஐ Ansible inventory-ஆகப் படித்தல்

நீங்கள் inventory file எதையும் எழுத விரும்பவில்லை என்றால், cloud.terraform collection நேரடியாக state-ஐப் படித்துக்கொள்ளும்.

ansible-galaxy collection install cloud.terraform

உங்கள் playbook-க்கு அருகில் terraform.yml-ஐ உருவாக்கவும்:

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

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

இதைப் பயன்படுத்துவதற்கு முன்பு இரண்டு விஷயங்களை அறிந்துகொள்ள வேண்டும். இந்த plugin terraform show-ஐ project_path-க்கு எதிராக இயக்கும், எனவே அந்த directory ஏற்கனவே initialized செய்யப்பட்டிருக்க வேண்டும், இல்லையெனில் plugin இயங்காது. மேலும், இது உங்கள் server resources-லிருந்து தானாகவே hosts-ஐ உருவாக்காது: இது ansible_host மற்றும் ansible_group resources-ஐ மட்டுமே படிக்கும், இவற்றை நீங்கள் Terraform code-ல் Ansible provider-ஐப் பயன்படுத்தி அறிவிக்க வேண்டும். நீங்கள் அவற்றைச் சேர்க்கும் வரை ansible-inventory --graph-ல் எதுவும் தோன்றாது.

சாதாரணமாக உருவாக்கப்பட்ட inventory file-ஐ debug செய்வது எளிது மற்றும் அது எந்த provider-உடனும் வேலை செய்யும். inventory-ல் உள்ள machines-ன் எண்ணிக்கை அதிகரித்து, கையால் திருத்தும்போது பிழைகள் ஏற்படத் தொடங்கும் போது, இந்த plugin பயனுள்ளதாக இருக்கும். அந்த நிலையில்தான் ஒரே control machine-லிருந்து பல Linux servers-ஐ நிர்வகிப்பது ஒரு பழக்கமாக இல்லாமல், முறையான பணிப்பாய்வாக (workflow) மாறுகிறது.

உங்களுக்கு உண்மையில் Terraform தேவையா?

இதைப் படிக்கும் பெரும்பாலானோருக்கு, இப்போதைக்கு இது தேவையில்லை. உள்கட்டமைப்பை (infrastructure) உருவாக்குவதும் அழிப்பதும் மீண்டும் மீண்டும் செய்யப்படும் வேலையாக இருக்கும்போதுதான் Terraform பயனுள்ளதாக இருக்கும். நீங்கள் ஒரு control panel மூலம் ஒரு VPS-ஐ வாங்கி, அதை இரண்டு ஆண்டுகள் அப்படியே வைத்திருக்கப் போகிறீர்கள் என்றால், Terraform என்பது ஒருமுறை மட்டுமே நடக்கும் செயலை விவரிக்கிறது; மேலும் இது நீங்கள் தொலைக்கக்கூடாத ஒரு state file-ஐ உருவாக்குகிறது.

நீங்கள் அடிக்கடி சூழல்களை (environments) மறுசீரமைக்கும்போது, staging சூழல் production சூழலைப் போலவே இருக்க வேண்டியிருக்கும்போது, பல நபர்கள் உள்கட்டமைப்பை மாற்றும்போது மற்றும் எதையும் அழிப்பதற்கு முன்பு சரிபார்க்கக்கூடிய ஒரு திட்டம் (reviewable plan) தேவைப்படும்போது, அல்லது நீங்கள் நிர்வகிக்கும் விஷயங்கள் server-களைத் தாண்டி DNS records, load balancers மற்றும் provider API-ல் உள்ள firewall rules என விரிவடையும்போது Terraform-ஐப் பயன்படுத்துங்கள்.

server-கள் நீண்ட காலம் பயன்பாட்டில் இருக்கும்போதும், அவற்றின் எண்ணிக்கை குறைவாக இருக்கும்போதும், "இந்த server சரியாக உள்ளமைக்கப்பட்டுள்ளதா" என்ற கேள்விதான் அன்றாடத் தேவையாக இருக்கும்போதும் Ansible-ஐ மட்டும் பயன்படுத்துங்கள். ஒரு புதிய server-ஐப் பாதுகாக்கும் (harden) ஒரு playbook, புதிய VPS-ல் முதல் பத்து நிமிடங்கள் செய்யும் அதே வேலையைச் செய்கிறது. இதன் கூடுதல் நன்மை என்னவென்றால், அடுத்த server-லும் இது அதே முறையில் இயங்கும்.

இதன் அடிப்படையில் கற்றல் வரிசை அமைகிறது. உங்களிடம் உள்ள முதல் server-லேயே Ansible பலன் தருகிறது. நீங்கள் மூன்றாவது முறையாக ஒரு சூழலை மறுசீரமைக்கும்போதுதான் Terraform பலன் தருகிறது.

handoff-ல் என்னென்ன சிக்கல்கள் ஏற்படும்

Server தயாராக இல்லை. 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}

sshd இயங்குவதற்கு முன்பே API ஒரு முகவரியை வழங்கியுள்ளது. நிலையான sleep நேரத்தைச் சேர்ப்பதற்குப் பதிலாக, port தயாராகும் வரை காத்திருக்கவும். Ansible-ல் இதற்கெனவே ansible.builtin.wait_for_connection உள்ளது, இதை play-ன் முதல் task-ஆக இயக்கவும்.

Host key மாறியுள்ளது. நீங்கள் server-ஐ அழித்து மீண்டும் உருவாக்கியுள்ளீர்கள், புதிய server அதே முகவரியில் புதிய key-உடன் பதிலளிக்கிறது.

Host key verification failed.

ssh-keygen -R 203.0.113.10-ஐப் பயன்படுத்தி பழைய entry-ஐ நீக்கவும். Terraform மூலம் rebuild செய்யும்போது இது அடிக்கடி நடக்கும், எனவே தரவுகளைக் கொண்ட இயந்திரங்களில் rebuild செய்வதைத் தவிர்ப்பது நல்லது.

Sudo தோல்வியடைகிறது. fatal: [web1]: FAILED! => {"msg": "Missing sudo password"} என்பது அந்த host-ல் become: true-க்கு கடவுச்சொல் தேவைப்படுவதைக் குறிக்கிறது. deploy user-க்கு passwordless sudo-வை அமைக்கவும் அல்லது --ask-become-pass-ஐப் பயன்படுத்தவும்.

நீங்கள் மாற்றாத ஒன்றை Terraform அழிக்க முயல்கிறது. நீங்கள் எழுதாத மாற்றங்களை plan காட்டுகிறது என்றால், infrastructure-ல் மாற்றம் (drift) ஏற்பட்டுள்ளது என்று அர்த்தம். பொதுவாக, provider-ன் web panel-ல் யாராவது அமைப்புகளை மாற்றியதால் இது நிகழும். அந்த வித்தியாசத்தை மட்டும் பார்க்க terraform plan -refresh-only-ஐ இயக்கவும், பின் code-ல் தவறு உள்ளதா அல்லது live resource-ல் தவறு உள்ளதா என்று முடிவு செய்யவும். வரி வரியாக விளக்க முடியாத எந்தவொரு destructive plan-ஐயும் apply செய்ய வேண்டாம்.

Ansible ஒவ்வொரு முறையும் changed என்று காட்டுகிறது. creates அல்லது when guard இல்லாத shell task நிபந்தனையின்றி இயங்குகிறது. இது வெறும் தோற்றப் பிரச்சனை மட்டுமல்ல; ஒரு server நீங்கள் கேட்ட நிலையில் உள்ளதா என்பதைக் குறிக்கும் சிக்னலாக changed=0-ஐ உங்களால் இனி பயன்படுத்த முடியாது என்பதே இதன் பொருள்.

FAQ

Terraform-ஆல் Ansible-க்கு மாற்றாக இருக்க முடியுமா?

server-க்குள் உள்ள configuration-க்கு இது பொருந்தாது. Terraform, remote-exec provisioner மூலம் scripts-ஐ இயக்க முடியும், ஆனால் அவை resource உருவாக்கப்படும்போது மட்டுமே இயங்கும். அவை terraform plan-ல் இடம்பெறாது. அவை தோல்வியுற்றால், அந்த resource taint செய்யப்படும்; அடுத்தமுறை apply செய்யும்போது அது அழிக்கப்பட்டு மீண்டும் உருவாக்கப்படும். nginx ஏற்கனவே நிறுவப்பட்டுள்ளதா என்று சரிபார்த்து, இல்லையென்றால் மட்டும் செயல்படும் module வசதி Terraform-ல் இல்லை. எனவே, machine-ஐ உருவாக்க Terraform-ஐப் பயன்படுத்தவும், பிறகு Ansible-க்கு மாற்றவும்.

Ansible-ஆல் Terraform-க்கு மாற்றாக இருக்க முடியுமா?

குறைந்த எண்ணிக்கையிலான, நீண்ட காலம் இயங்கும் servers-க்கு ஆம். Ansible-ல் servers-ஐ உருவாக்கும் cloud modules உள்ளன. நீங்கள் இரண்டு VPS instances-ஐ உருவாக்கி அவற்றை அப்படியே வைத்திருந்தால், அது போதுமானது. ஆனால், இதில் state file மற்றும் dependency graph வசதி இல்லை. playbook-லிருந்து ஒரு task-ஐ நீக்கினால், அந்த resource தொடர்ந்து இயங்கிக்கொண்டே இருக்கும், கட்டணமும் வசூலிக்கப்படும்; ஏனெனில் அதை உருவாக்கியதை Ansible பதிவு செய்யவில்லை. Terraform-ஆக இருந்தால், அதை அழிப்பதற்கான திட்டத்தை (destroy plan) காட்டியிருக்கும்.

நான் முதலில் எதைக் கற்க வேண்டும்?

உங்களிடம் ஏற்கனவே servers இருந்தால், Ansible-ஐக் கற்கவும். இது முதல் machine-லேயே பலனைத் தரும், SSH தவிர வேறு எதுவும் தேவையில்லை. நீங்கள் கைமுறையாக உருவாக்கிய server-க்கும் இந்தத் திறன் பயன்படும். Terraform-ன் பலன் பிற்காலத்தில் தான் தெரியும்; அதாவது, சூழல்களை (environments) மீண்டும் மீண்டும் உருவாக்க வேண்டியிருக்கும்போதோ அல்லது DNS records மற்றும் firewall rules போன்ற provider resources-ஐ நிர்வகிக்கும்போதோ இது பயனுள்ளதாக இருக்கும்.

Terraform-லிருந்து புதிய server IP-ஐ Ansible-க்கு எப்படி அனுப்புவது?

உங்கள் Terraform code-ல் ஒரு output-ஐ அறிவித்து, apply செய்த பிறகு அதை வாசிக்கவும். terraform output -raw web_ip என்பது shell substitution-க்காக அதன் மதிப்பை மட்டும் அச்சிடும். பல hosts இருக்கும்போது, terraform output -json அனைத்து output-களையும் ஒரே நேரத்தில் வழங்கும். அதை ஒரு inventory file-ல் எழுதவும், அல்லது cloud.terraform collection-ஐ நிறுவி, ansible-inventory -i terraform.yml --graph-ஐ அந்த project directory-க்குச் சுட்டிக்காட்டவும்.

Terraform முடிந்தவுடன் என் playbook ஏன் தோல்வியடைகிறது?

API-ல் server உருவாக்கப்பட்டதாகத் தகவல் வந்தவுடன் provider அதை முடிந்துவிட்டதாகக் கருதும். ஆனால், அந்த நேரத்தில் operating system boot ஆகிக்கொண்டிருக்கும், எனவே முதல் சில நொடிகள் SSH இணைப்பு மறுக்கப்படும். இந்தத் தவறு UNREACHABLE! மற்றும் Connection refused மூலம் குறிக்கப்படுகிறது. boot நேரம் image மற்றும் plan-ஐப் பொறுத்து மாறுபடும் என்பதால், sleep duration-ஐ ஊகிப்பதற்குப் பதிலாக, ansible.builtin.wait_for_connection-ஐ அந்த play-ன் முதல் task-ஆக வைக்கவும்.