Terraform বনাম Ansible: আপনার আসলে কোনটি প্রয়োজন?
Terraform এবং Ansible এর একটি ব্যবহারিক বিশ্লেষণ, প্রতিটি টুল আসলে কী জন্য ভালো, এবং একটি বাস্তব IaC পাইপলাইনে সেগুলি কীভাবে একত্রিত করতে হয়।
Infrastructure as Code এ নতুন মানুষ সাধারণত এটি দুটি উপায়ের একটিতে জিজ্ঞাসা করে: "আমার প্রথমে কোন টুলটি শিখতে হবে" বা "দলগুলি কেন উভয়ই ব্যবহার করে।" সংক্ষিপ্ত উত্তর হল যে Terraform এবং Ansible বিভিন্ন সমস্যার সমাধান করে, এবং অধিকাংশ production সেটআপ একটি বেছে নেওয়ার পরিবর্তে সেগুলি একসাথে ব্যবহার করে।
Terraform আসলে কীসের জন্য
Terraform একটি provisioning টুল। এটি ঘোষণা করে কী অবকাঠামো বিদ্যমান থাকা উচিত: একটি VPC, তিনটি EC2 instances, একটি RDS database, একটি S3 bucket একটি নির্দিষ্ট policy সহ। আপনি HCL এ চূড়ান্ত অবস্থা বর্ণনা করেন, terraform plan চালান কী পরিবর্তন হবে তা দেখতে, তারপর terraform apply করেন এটি ঘটানোর জন্য। Terraform একটি state ফাইল রাখে (স্থানীয়ভাবে বা S3 bucket এবং DynamoDB locking সহ একটি backend এ) যা আপনার config কে cloud provider এ বাস্তব resource IDs এর সাথে ম্যাপ করে।
এখানকার শক্তি হল providers জুড়ে dependency resolution। যদি আপনি Terraform কে একটি security group তৈরি করতে এবং তারপর এটি একটি EC2 instance এ attach করতে বলেন, এটি স্বয়ংক্রিয়ভাবে ক্রম বের করে। এটি একই workflow এর মাধ্যমে AWS, Azure, GCP, Cloudflare, Datadog এবং আরও অনেক providers এ কাজ করে, যা গুরুত্বপূর্ণ একবার আপনার অবকাঠামো একাধিক vendor জুড়ে বিস্তৃত হলে।
Terraform মেশিনের ভিতর যা কিছু ঘটে তার জন্য খারাপ একবার এটি বিদ্যমান হয়। এটি প্যাকেজ ইনস্টল করে না, config ফাইল সম্পাদনা করে না, বা কোনো অর্থপূর্ণ চলমান উপায়ে services পুনরায় শুরু করে না। Provisioners যেমন remote-exec বিদ্যমান কিন্তু HashiCorp নিজেই bootstrapping এর বাইরে কিছুর জন্য সেগুলি এড়ানোর সুপারিশ করে।
Ansible আসলে কীসের জন্য
Ansible একটি configuration management টুল। এটি SSH (বা Windows এর জন্য WinRM) এর মাধ্যমে সংযুক্ত হয় এবং ইতিমধ্যে বিদ্যমান মেশিনের বিরুদ্ধে tasks চালায়: nginx ইনস্টল করুন, একটি config ফাইল template করুন, একটি user তৈরি করুন, একটি service পুনরায় শুরু করুন, নিশ্চিত করুন যে একটি cron job উপস্থিত আছে। Playbooks হল YAML, এবং modules ডিজাইনের দ্বারা idempotent, তাই একই playbook দুবার চালানো দ্বিতীয়বার কিছু পরিবর্তন করা উচিত নয় যদি সিস্টেম ইতিমধ্যে desired state এর সাথে মেলে।
Ansible এর প্রয়োজন নেই agents target hosts এ ইনস্টল করা, শুধুমাত্র Python এবং SSH access, যা এটি বিদ্যমান অবকাঠামোতে bolt করা সহজ করে। এটি orchestration tasks এর জন্যও ভালো যা কঠোরভাবে "provisioning" নয় — একটি fleet জুড়ে rolling restarts, blue-green deploy steps, একটি host এ database migration চালান এবং তারপর একটি load balancer আপডেট করুন।
যেখানে তারা overlap করে এবং মানুষ confused হয়
উভয় টুল technically অন্যটির কিছু job করতে পারে। Ansible এর আছে cloud modules (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) যা infrastructure spin করতে পারে। Terraform এর আছে provisioners যা একটি নতুন instance এ shell commands চালাতে পারে। কিন্তু Ansible ব্যবহার করা provisioning এর জন্য মানে Terraform এর state tracking এবং plan/diff workflow ত্যাগ করা, এবং Terraform provisioners ব্যবহার করা configuration এর জন্য মানে idempotent, repeatable config management ত্যাগ করা।
ব্যবহারিক split যা অধিকাংশ দল land করে:
- Terraform অবকাঠামো তৈরি করে: networks, compute instances, load balancers, managed databases, IAM roles।
- Ansible কী তার উপর আছে তা configure করে: software installs, users, config files, service state, application deployment steps।
Handoff এর একটি concrete উদাহরণ
ধরুন আপনি AWS তে একটি load balancer এর পিছনে তিনটি web servers সেটআপ করছেন।
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 instances তৈরি করে এবং তাদের IPs output করে। আপনি যা output করেন তা একটি dynamic Ansible inventory এ feed করতে পারেন (amazon.aws.aws_ec2 inventory plugin সরাসরি EC2 tags পড়ে, কোনো manual copy-paste প্রয়োজন নেই) এবং তারপর চালান:
ansible-playbook -i aws_ec2.yml site.yml
যেখানে site.yml nginx ইনস্টল করে, app config দেয়, এবং service শুরু করে। Terraform কখনো nginx স্পর্শ করে না। Ansible কখনো VPC স্পর্শ করে না। প্রতিটি টুল তার lane এ থাকে, এবং প্রতিটির নিজস্ব state/idempotency model আছে যা অন্যটির সাথে সংঘর্ষ করে না।
এড়ানোর মূল্যবান common mistakes
Terraform state কে git এ store করা সবচেয়ে common প্রাথমিক mistake — state ফাইলগুলি plaintext এ secrets ধারণ করতে পারে এবং merge conflicts সৃষ্টি করতে পারে যা আপনার অবকাঠামো model corrupt করে। দিন এক থেকে একটি remote backend ব্যবহার করুন।
Ansible এর সাথে, mistake হল playbooks লেখা যা actually idempotent নয় — shell বা command modules ব্যবহার করা জিনিসের জন্য যার একটি proper module আছে (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) যা ইতিমধ্যে check-then-act logic সঠিকভাবে পরিচালনা করে।
যদি আপনি সিদ্ধান্ত নিচ্ছেন প্রথমে কী শিখতে হবে: Terraform শিখুন যদি আপনি cloud provisioning এবং multi-environment setups করছেন, Ansible শিখুন যদি আপনি config drift manage করছেন servers এ যা আপনার ইতিমধ্যে আছে। অধিকাংশ DevOps roles expect করে familiarity উভয় সহ প্রথম বছরের মধ্যে।
State management, dynamic inventories, এবং এই tools এর চারপাশে একটি full CI/CD pipeline তৈরি করার বিষয়ে আরও তথ্যের জন্য, Korra Studio এ related DevOps এবং Cloud segments check করুন।
AI সহায়তায় লেখা, পর্যালোচনা ও প্রকাশ করেছেন Michal Pilch (CISSP), Korra Studio।
এটি Korra Studio-র নলেজ বেস থেকে একটি নোট — প্ল্যাটফর্মটি প্রতিটি বিষয়কে ১-এর-সাথে-১ মেন্টরিংয়ের সাথে জুড়ে দেয়।
বিনামূল্যে শুরু করুনarrow_forward