Terraform در مقابل Ansible: کدام یکی را واقعاً نیاز دارید؟

افرادی که برای اولین بار با Infrastructure as Code آشنا می‌شوند معمولاً این سؤال را به یکی از دو صورت می‌پرسند: "کدام ابزار را ابتدا یاد بگیرم" یا "چرا تیم‌ها از هر دو استفاده می‌کنند." پاسخ کوتاه این است که Terraform و Ansible مسائل متفاوتی را حل می‌کنند، و بیشتر راه‌اندازی‌های production آنها را با هم استفاده می‌کنند تا اینکه یکی را انتخاب کنند.

Terraform واقعاً برای چه کار است

Terraform یک ابزار provisioning است. آن چه زیرساخت باید وجود داشته باشد را اعلام می‌کند: یک VPC، سه instance EC2، یک پایگاه داده RDS، یک bucket S3 با یک policy خاص. شما HCL را نوشته‌اید که stateی نهایی را توصیف می‌کند، سپس terraform plan را اجرا می‌کنید تا ببینید چه تغییری خواهد شد، سپس terraform apply را برای انجام آن اجرا می‌کنید. Terraform یک state file (به صورت محلی یا در یک backend مانند S3 bucket با قفل‌گذاری DynamoDB) نگهداری می‌کند که پیکربندی شما را به شناسه‌های منابع واقعی در cloud provider نگاشت می‌کند.

قوت آن در اینجا حل تبعیت کننده‌ها در میان providers است. اگر به Terraform بگویید یک security group ایجاد کند و سپس آن را به یک instance EC2 متصل کند، Terraform ترتیب را خودکار انجام می‌دهد. همچنین از طریق همان workflow در AWS، Azure، GCP، Cloudflare، Datadog و دهها provider دیگر کار می‌کند، که این مهم است زمانی که زیرساخت شما بیش از یک فروشنده را در بر می‌گیرد.

Terraform در هر چیزی که درون ماشین پس از وجود آن اتفاق می‌افتد ضعیف است. بسته‌ها را نصب نمی‌کند، فایل‌های پیکربندی را ویرایش نمی‌کند، یا سرویس‌ها را به هیچ روش معنی‌داری به طور مستمر restart نمی‌کند. Provisioners مانند remote-exec وجود دارند اما خود HashiCorp توصیه می‌کند از آنها برای هر چیزی فراتر از bootstrapping خودداری کنید.

Ansible واقعاً برای چه کار است

Ansible یک ابزار configuration management است. به‌وسیله SSH (یا WinRM برای Windows) متصل می‌شود و tasks را بر روی ماشین‌هایی که از قبل وجود دارند اجرا می‌کند: nginx را نصب کنید، یک فایل پیکربندی را template کنید، کاربری ایجاد کنید، یک سرویس را restart کنید، آن را اعمال کنید که یک cron job موجود است. Playbooks به YAML هستند، و modules طبق design idempotent هستند، بنابراین اجرای همان playbook دوبار نباید دوم بار چیزی را تغییر دهد اگر سیستم قبلاً با stateی مطلوب منطبق باشد.

Ansible نیاز به نصب agents روی میزبان‌های هدف ندارد، فقط به Python و دسترسی SSH نیاز دارد، که آن را آسان می‌کند برای bolt کردن بر روی زیرساخت موجود. همچنین برای tasks orchestration که به طور سختگیرانه "provisioning" نیستند خوب است — rolling restarts در سراسر fleet، blue-green deploy steps، اجرای یک database migration روی یک host و سپس به‌روزرسانی یک load balancer.

جایی که آنها overlapping می‌کنند و جایی که افراد confusion پیدا می‌کنند

هر دو ابزار می‌توانند به طور فنی کمی از کار دیگری را انجام دهند. Ansible دارای cloud modules است (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) که می‌توانند زیرساخت را spin up کنند. Terraform دارای provisioners است که می‌توانند shell commands را روی یک instance جدید اجرا کنند. اما استفاده از Ansible برای provisioning به معنی صرف نظر کردن از state tracking و plan/diff workflow کردن Terraform است، و استفاده از Terraform provisioners برای configuration به معنی صرف نظر کردن از idempotent، repeatable config management است.

Tقسیم عملی که بیشتر تیم‌ها به آن می‌رسند:

• Terraform زیرساخت را ساخت: networks، compute instances، load balancers، managed databases، IAM roles.
• Ansible آنچه روی آن قرار دارد را پیکربندی می‌کند: software installs، users، config files، service state، application deployment steps.

یک مثال مشخص از handoff

فرض کنید شما سه web servers را پشت یک load balancer بر روی AWS راه‌اندازی می‌کنید.

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 کنید (plugin amazon.aws.aws_ec2 inventory به طور مستقیم EC2 tags را می‌خواند، نیاز به copy-paste دستی نیست) و سپس:

ansible-playbook -i aws_ec2.yml site.yml

اجرا کنید که در آن site.yml nginx را نصب می‌کند، app config را drop می‌کند، و سرویس را شروع می‌کند. Terraform هرگز nginx را لمس نمی‌کند. Ansible هرگز VPC را لمس نمی‌کند. هر ابزار در lane خود باقی می‌ماند، و هر کدام دارای state/idempotency model خود است که با دیگری conflict نمی‌کند.

اشتباهات متداول که شایسته اجتناب است

ذخیره state کردن Terraform در git رایج‌ترین اشتباه ابتدایی است — state files می‌توانند secrets را به صورت plaintext داشته باشند و merge conflicts ایجاد کنند که infrastructure model شما را corrupt می‌کنند. از روز اول از یک remote backend استفاده کنید.

با Ansible، اشتباه نوشتن playbooks است که واقعاً idempotent نیستند — استفاده از shell یا command modules برای چیزهایی که module خاصی دارند (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) که از قبل check-then-act logic را به درستی handle می‌کنند.

اگر تصمیم می‌گیریم چه کار را ابتدا یاد بگیریم: Terraform را یاد بگیریم اگر cloud provisioning و multi-environment setups را انجام می‌دهیم، Ansible را یاد بگیریم اگر config drift را بر روی servers مدیریت می‌کنیم که از قبل دارند. بیشتر DevOps roles آشنایی با هر دو را در سال اول انتظار دارند.

برای اطلاعات بیشتر درباره state management، dynamic inventories، و ساخت یک full CI/CD pipeline در اطراف این ابزارها، بخش‌های DevOps و Cloud مرتبط را در Korra Studio بررسی کنید.