Infrastructure as Code (IaC) با Terraform و Ansible

راهنمای Infrastructure as Code با Terraform، OpenTofu و Ansible

Infrastructure as Code یعنی وضعیت زیرساخت، از ماشین مجازی و شبکه تا کاربران و سرویس‌های داخل سرور، در فایل‌های متنی نوشته شود و هر تغییر از مسیر Git، بازبینی و اجرای خودکار بگذرد. Terraform و OpenTofu اعلانی کار می‌کنند: وضعیت نهایی را توصیف می‌کنید و ابزار تفاوت آن با وضعیت فعلی را اعمال می‌کند. Ansible Taskها را به ترتیب و با ماژول‌های Idempotent اجرا می‌کند، پس اجرای دوباره Playbook روی سروری که درست تنظیم شده تغییری ایجاد نمی‌کند. نتیجه، محیط‌های یکسان، تاریخچه قابل ردیابی تغییرات و بازسازی سریع پس از خرابی است.

از کجا شروع کنیم؟

لازم نیست کل زیرساخت یک‌جا به کد تبدیل شود. کارهایی را انتخاب کنید که بیشترین تکرار یا خطا را دارند، مثل ساخت ماشین مجازی جدید، تنظیمات پایه و سخت‌سازی سرورهای لینوکس یا تعریف کاربران و کلیدهای SSH. منابعی را که از قبل وجود دارند با Import به State اضافه کنید و کد را تا جایی با وضعیت فعلی تطبیق دهید که plan هیچ تغییری نشان ندهد. از آن به بعد تغییرات فقط از مسیر کد انجام می‌شود و تشخیص Drift زمان‌بندی‌شده، تغییری را که کسی مستقیم روی سرور داده نشان می‌دهد.

Terraform یا OpenTofu کنار Ansible

در بیشتر پروژه‌ها Terraform یا OpenTofu ماشین‌ها، شبکه و DNS را از طریق API بستر، مثل Proxmox یا VMware vSphere، می‌سازد و Ansible داخل همان ماشین‌ها را از طریق SSH پیکربندی می‌کند. آدرس ماشین‌هایی که Terraform ساخته می‌تواند Inventory Ansible را بسازد تا فهرست سرورها دو جا نگهداری نشود. ماژول‌ها را برای dev، stage و production یکسان بنویسید و فقط متغیرها را تغییر دهید. Roleهای Ansible را برای سرویس‌های تکراری بسازید و رمزها را در Ansible Vault نگه دارید. سخت‌سازی سرورها در Roleها بر اساس چک‌لیست امن‌سازی سرور نوشته می‌شود و طراحی خود بستر مجازی در خدمات مجازی‌سازی سرور انجام می‌شود.

OpenTofu انشعاب متن‌باز Terraform است که پس از تغییر لایسنس Terraform به BSL زیر نظر بنیاد لینوکس ساخته شد. بیشتر کدهای Terraform بدون تغییر یا با تغییر کم روی آن اجرا می‌شوند. برای پروژه‌های جدید OpenTofu را پیشنهاد می‌کنیم و در پروژه‌هایی که Terraform دارند، مهاجرت را بر اساس Providerهای مورد استفاده بررسی می‌کنیم.

State، رمزها و ساختار مخزن

فایل State نقشه زیرساخت واقعی است. اگر گم شود، Terraform منابع موجود را نمی‌شناسد و اگر دو نفر هم‌زمان apply کنند، State خراب می‌شود. State را روی Remote Backend، مثل MinIO سازگار با S3 یا GitLab، با قفل هم‌زمانی نگه دارید، برای هر محیط State جدا بسازید و از آن بکاپ منظم بگیرید. ساختاری که معمولاً برای مخزن پیشنهاد می‌کنیم این است:

• ماژول‌های مشترک برای ماشین، شبکه و DNS
• پوشه جدا برای هر محیط با متغیرها و State خودش
• Roleهای Ansible برای هر سرویس و Inventory هر محیط
• فایل .terraform.lock.hcl داخل Git و فایل State بیرون از Git
• README با روش اجرای plan، apply و Playbookها

بازبینی تغییرات، GitOps و شرایط ایران

در جریان GitOps هیچ تغییری مستقیم روی سرور اعمال نمی‌شود. تغییر در Merge Request پیشنهاد می‌شود، Pipeline دستور plan را اجرا می‌کند تا بازبین ببیند چه چیزی ساخته، تغییر یا حذف می‌شود و apply فقط پس از تأیید انجام می‌شود؛ ساخت این Pipeline در پیاده‌سازی CI/CD انجام می‌شود. برای Kubernetes همین جریان با Argo CD یا Flux اجرا می‌شود و وضعیت کلاستر با مخزن هماهنگ می‌ماند.

دسترسی از ایران به بخشی از سرویس‌های HashiCorp ممکن است محدود یا ناپایدار باشد، چون HashiCorp طبق قوانین کنترل صادرات آمریکا دسترسی کشورهای تحریم‌شده را محدود می‌کند. به همین دلیل OpenTofu مسیر پیشنهادی ما برای پروژه‌های جدید است. نسخه Providerها را با .terraform.lock.hcl قفل می‌کنیم و Providerهای متن‌باز و Collectionهای Ansible مورد نیاز را در Mirror داخلی نگه می‌داریم تا اجرای کد به دریافت لحظه‌ای از رجیستری خارجی وابسته نباشد.

زمان و هزینه پیاده‌سازی Infrastructure as Code به چه بستگی دارد؟

تعداد و تنوع منابع، بسترهای درگیر، نیاز به Import زیرساخت موجود و اتصال به Pipeline پایه برآورد هستند. Import منابعی که سال‌ها دستی تغییر کرده‌اند معمولاً از نوشتن کد برای محیط جدید زمان بیشتری می‌گیرد، چون هر تفاوت کد با وضعیت واقعی باید بررسی شود. مرور روش اعمال تغییر از مسیر کد با تیم هم بخشی از تحویل است. برای برآورد، بسترها، تعداد سرورها، ابزارهای فعلی و کارهای دستی تکراری تیم را بفرستید تا پس از بررسی اولیه قیمت اعلام شود.

فایل State ممکن است رمزها و مقادیر حساس را به‌صورت متن ساده نگه دارد. آن را داخل Git قرار ندهید و دسترسی به Remote Backend را فقط به Pipeline و افراد مسئول بدهید.