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-உடன் தொடர்பு கொள்கிறது. நீங்கள் பயன்படுத்தும் provider-ன் registry பக்கம், நீங்கள் எழுதக்கூடிய resource வகைகளை வரையறுக்கிறது. எனவே, ஒரு host-ல் உள்ள server-ம் மற்றொரு host-ல் உள்ள server-ம் வெவ்வேறு resource பெயர்களையும், வெவ்வேறு arguments-களையும் கொண்டிருக்கும்.

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 என்று இயக்குவதற்குப் பதிலாக, திட்டத்தை ஒரு கோப்பாகச் சேமித்து, அந்த கோப்பைச் செயல்படுத்துவது, நீங்கள் ஆய்வு செய்த அதே விஷயம் தான் இயங்குகிறது என்பதை உறுதிப்படுத்துகிறது. இந்த இரண்டு கட்டளைகளுக்கு இடைப்பட்ட நேரத்தில், வேறொருவர் உள்கட்டமைப்பை மாற்றியிருக்கலாம்.

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

Error: Error acquiring the state lock

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

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

Ansible-க்கு agent அல்லது API தேவையில்லை. இது ஒரு SSH இணைப்பைத் திறந்து, ஒரு சிறிய Python module-ஐ இலக்கு கணினிக்கு நகலெடுத்து, அதை இயக்கி, பின் நீக்கிவிடும். 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

நீங்கள் playbook-ஐ பிழைத்திருத்தம் (debugging) செய்யத் தொடங்கும் முன், 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, remote-exec provisioner-ஐப் பயன்படுத்தி ஒரு புதிய server-ல் கட்டளைகளை இயக்க முடியும். HashiCorp-ன் சொந்த ஆவணங்களே provisioner-களை ஒரு கடைசி முயற்சியாகவே (last resort) கருதுகின்றன. இதற்கு வலுவான காரணங்கள் உள்ளன.

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

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

ஒப்படைப்பு (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, number அல்லது boolean மதிப்பை மட்டுமே கையாளும்.

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

Terraform state-ஐ Ansible inventory-ஆக வாசித்தல்

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

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

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

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

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

Server-கள் நீண்ட காலம் பயன்பாட்டில் இருக்கும்போதும், அவற்றின் எண்ணிக்கை குறைவாக இருக்கும்போதும் Ansible-ஐ மட்டும் பயன்படுத்தவும். அப்போது அன்றாடக் கேள்வி "இந்த box சரியாக உள்ளமைக்கப்பட்டுள்ளதா?" என்பதாக இருக்குமே தவிர, "இந்த box இருக்கிறதா?" என்பதாக இருக்காது. ஒரு புதிய 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 listening நிலையில் இருப்பதற்கு முன்பே API ஒரு முகவரியை வழங்கியுள்ளது. ஒரு நிலையான sleep-ஐச் சேர்ப்பதற்குப் பதிலாக, port தயாராகும் வரை காத்திருக்கவும். Ansible-ல் இதற்காகவே ansible.builtin.wait_for_connection உள்ளது, இதை play-ன் முதல் task-ஆக இயக்கவும். ஒரே playbook ஒரு புதிய server-க்கு பதிலாக ஒரு குழுவை இலக்காகக் கொள்ளும்போது, ஒரு host அணுக முடியாத நிலையில் என்ன நடக்க வேண்டும் என்பதை முன்கூட்டியே முடிவு செய்யவும். ஏனெனில், Ansible அந்த host-ஐ மீதமுள்ள செயல்பாட்டிலிருந்து நீக்கிவிடும், recap வரியில் மட்டுமே இது குறித்துத் தெரிவிக்கும்.

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 காட்டுகிறது என்றால், உள்கட்டமைப்பு குறியீட்டிலிருந்து விலகிச் சென்றுள்ளது என்று பொருள். பொதுவாக, யாராவது provider-ன் web panel-ல் அமைப்புகளை மாற்றியிருந்தால் இது நடக்கும். அந்த வித்தியாசத்தை மட்டும் பார்க்க terraform plan -refresh-only-ஐ இயக்கவும். பிறகு, குறியீடு தவறா அல்லது நேரடி resource தவறா என்று முடிவு செய்யவும். ஒவ்வொரு வரியையும் உங்களால் விளக்க முடியாத ஒரு destructive plan-ஐ ஒருபோதும் apply செய்யாதீர்கள்.

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

FAQ

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

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

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

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

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

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

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

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

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

API-ல் சர்வர் உருவாக்கப்பட்டதாகத் தகவல் வந்தவுடன் provider அதை உறுதிப்படுத்துகிறது, ஆனால் அப்போதுதான் இயங்குதளம் (OS) boot ஆகிக்கொண்டிருக்கும். எனவே, முதல் சில நொடிகள் SSH இணைப்பு மறுக்கப்படும். இந்தத் தவறு UNREACHABLE! மற்றும் Connection refused என்று காட்டும். boot நேரம் ஒவ்வொரு image மற்றும் plan-க்கு ஏற்ப மாறுபடும் என்பதால், தோராயமாக நேரத்தை நிர்ணயிப்பதற்குப் பதிலாக, ansible.builtin.wait_for_connection-ஐ அந்த play-ன் முதல் task-ஆக வைக்கவும்.