تفاوت Terraform و Ansible چیست؟ کی کدام را انتخاب کنیم و چرا اغلب کنار هم می آیند

تفاوت Terraform و Ansible در لایه کارشان است. Terraform زیرساخت را به صورت اعلامی (declarative) می سازد، یعنی ماشین مجازی، شبکه، دیسک و رکورد DNS را در کد توصیف می کنید و وضعیت واقعی آن ها را در یک فایل state ردیابی می کند. Ansible روی ماشین هایی که از قبل وجود دارند، از طریق SSH و بدون نصب agent، نرم افزار نصب و تنظیمات را اعمال می کند. این دو اغلب کنار هم استفاده می شوند: اولی سرور را می سازد، دومی آن را آماده می کند.

مقایسه Terraform و Ansible در یک جدول

مرز این دو دقیق نیست. Ansible هم ماژول هایی برای ساخت ماشین دارد و Terraform هم می تواند با provisioner دستور اجرا کند، ولی هر کدام در کار اصلی خودش تمیزتر است و ترکیبشان کمتر دردسر دارد.

نمونه Terraform: ساخت یک سرور

این بخش یک ماشین مجازی را روی یک ارائه دهنده ابری عمومی توصیف می کند. نام منبع ها و مقدارها نمونه اند.

terraform {
  required_version = ">= 1.10"
  backend "s3" {
    bucket       = "example-tfstate"
    key          = "prod/web.tfstate"
    region       = "eu-central-1"
    encrypt      = true
    use_lockfile = true
  }
}

resource "aws_instance" "web" {
  ami           = "ami-0123456789abcdef0"
  instance_type = "t3.small"
  tags = {
    Name = "web-01"
  }
}

output "web_ip" {
  value = aws_instance.web.private_ip
}

چرخه کار با سه دستور است: terraform init افزونه ها و backend را آماده می کند، terraform plan فهرست تغییرها را بدون اجرا نشان می دهد و terraform apply آن ها را اعمال می کند. plan را همیشه بخوانید. خطی که می گوید یک منبع destroy و دوباره create می شود، یعنی سرور و دیسکش پاک می شود.

نمونه Ansible: پیکربندی همان سرور

وقتی ماشین بالا آمد، playbook زیر nginx را نصب می کند، فایل تنظیمات را می گذارد و سرویس را فعال نگه می دارد:

- name: Configure web servers
  hosts: web
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Deploy site config
      ansible.builtin.template:
        src: site.conf.j2
        dest: /etc/nginx/conf.d/site.conf
        mode: "0644"
      notify: Reload nginx

    - name: Keep nginx running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

اجرا با ansible-playbook -i inventory.ini site.yml است و قبلش می شود با --check --diff فقط تغییرهای احتمالی را دید. فایل inventory فهرست سرورها و گروه هایشان است. خود ansible فقط روی ماشین کنترل نصب می شود و سرورها فقط به SSH و Python نیاز دارند. اتصال Ansible کاملاً روی SSH سوار است، پس کلید SSH و دسترسی sudo باید از قبل آماده باشد.

فایل state در Terraform و چرا remote state مهم است

Terraform برای اینکه بداند چه چیزی را خودش ساخته، نگاشت بین کد و منابع واقعی را در فایل state نگه می دارد. اگر این فایل گم شود، Terraform منبع های موجود را نمی شناسد و می خواهد دوباره بسازدشان. پس چند قاعده دارد:

• state را در Git نگذارید. گاهی شامل رمز و مقدارهای حساس به صورت متن ساده است.
• از remote backend استفاده کنید: bucket سازگار با S3 (مثلاً MinIO روی سرور خودتان)، state مدیریت شده GitLab یا Terraform Cloud. نسخه گذاری را روی bucket روشن کنید تا بشود به state قبلی برگشت.
• قفل (locking) را فعال کنید. بدون آن، دو نفر یا دو پایپ لاین که همزمان apply بزنند، state را خراب می کنند. در مثال بالا use_lockfile این کار را می کند؛ در نسخه های قدیمی تر قفل با جدول DynamoDB انجام می شد.
• دسترسی به state را محدود کنید، چون خواندنش یعنی دیدن اطلاعات زیرساخت.

OpenTofu، فورک متن باز Terraform، با همین فایل ها و روش کار می کند، پس آنچه اینجا آمده برای آن هم صدق می کند. اجرای plan و apply در پایپ لاین هم رایج است؛ چارچوبش در CI/CD چیست آمده است.

Idempotency یعنی چه

یک عملیات idempotent را هر چند بار اجرا کنید، نتیجه همان است. ماژول های Ansible مثل apt و template را وضعیت مطلوب تعریف می کنند: اگر nginx نصب است، اجرای دوم تغییری نمی دهد و گزارش changed=0 می بینید. همین ویژگی اجازه می دهد playbook را هر شب یا بعد از هر تغییر اجرا کنید. مرز آن ماژول های shell و command است؛ این ها هر بار دستور را اجرا می کنند، مگر اینکه شرط creates یا when بگذارید. Terraform هم idempotent است، چون plan بعد از apply موفق باید خالی باشد. اگر خالی نیست، یعنی کسی چیزی را دستی تغییر داده (drift) یا تعریف منبع ناقص است.

کدام را انتخاب کنیم؟ برای چند سرور کوچک

صادقانه بگویم: برای دو یا سه سرور ثابت که خودتان خریده یا اجاره کرده اید، Ansible به تنهایی معمولاً کافی است. سرور را از پنل یا از نصب لینوکس دستی می سازید، یک بار، و Ansible نصب بسته ها، کاربرها، فایروال و سرویس ها را تکرارپذیر می کند. اضافه کردن Terraform در این اندازه بیشتر کار می آورد (state، backend، قفل) تا ارزش.

Terraform وقتی می ارزد که منابع زیاد یا زود به زود ساخته و حذف شوند: چند محیط staging و production، ده ها ماشین، شبکه و load balancer روی cloud، یا ماشین های مجازی روی پروکسمکس و VMware که می خواهید با کد ساخته شوند. اگر هنوز مرز مدل های سرویس را نمی دانید، IaaS چیست کمک می کند.

• دو تا سه سرور ثابت: Ansible، با inventory و چند role.
• محیط های تکراری یا موقت، یا زیرساخت ابری: Terraform برای ساخت و Ansible برای پیکربندی.
• برنامه کانتینری روی یک سرور: Ansible برای آماده سازی میزبان و نصب داکر، بعد خود برنامه با Compose. نصب داکر در آموزش نصب داکر است.

اشتباه های رایج

• نگه داشتن state روی لپ تاپ یک نفر. وقتی او نباشد، تیم دیگر نمی تواند زیرساخت را تغییر دهد.
• تغییر دستی منبع ها بعد از ساخت با Terraform. اجرای بعدی تغییر شما را برمی گرداند یا با خطا می ایستد.
• گذاشتن رمز و کلید داخل کد یا tfvars در Git. از متغیرهای محافظت شده پایپ لاین یا ansible-vault استفاده کنید.
• استفاده از shell در Ansible برای کارهایی که ماژول دارند، و از دست دادن idempotency.
• apply بدون خواندن plan، به خصوص روی production.
• نصب بدون تعیین نسخه provider و collection. یک به روزرسانی ناخواسته می تواند رفتار را عوض کند. نسخه ها را پین کنید.
• خاموش نگذاشتن حساب های دسترسی اضافه روی سرورهای ساخته شده. سخت سازی را هم کد کنید؛ فهرست کارها در سخت سازی سرور آمده است.

منابع و مستندات رسمی

• معرفی رسمی Terraform
• مستندات رسمی Terraform درباره فایل state

برای ساخت کلاستر Kubernetes روی چند نود، مراحل را در نصب کلاستر کوبرنتیز روی اوبونتو ببینید.

طراحی ساختار کد زیرساخت، نوشتن role و ماژول ها، راه اندازی remote state با قفل و اجرای خودکار plan و apply در پایپ لاین از کارهای زیرساخت به عنوان کد (IaC) است. اگر فقط چند سرور دارید، با همین سرویس می شود از یک playbook ساده شروع کرد.

نحوه تهیه مقاله ها