زیرساخت به عنوان کد: راهنمای عملی شروع کار

چرا پیکربندی دستی سرور هنوز یک معضل جدی است؟

اگر تا به حال یک سرور را با دست و به‌صورت مرحله‌به‌مرحله راه‌اندازی کرده باشید، احتمالاً با این سناریو آشنا هستید: ابتدا یک VPS می‌گیرید، SSH می‌زنید، Nginx نصب می‌کنید، PHP را تنظیم می‌کنید، دیتابیس می‌سازید و بعد از چند ساعت کار، سرور بالا می‌آید. همه‌چیز خوب پیش می‌رود تا روزی که سرور از کار می‌افتد و مجبور می‌شوید کل این فرآیند را دوباره تکرار کنید — این بار با این سؤال که «آخرین بار دقیقاً چه تنظیماتی را انجام دادم؟»

پیکربندی دستی چند مشکل بنیادی دارد: عدم تکرارپذیری (هیچ دو سروری دقیقاً مثل هم تنظیم نمی‌شوند)، خطای انسانی (یک فرمان اشتباه می‌تواند کل امنیت را به خطر بیندازد)، و هیچ مستنداتی (تنها منبع حقیقت، حافظه شماست). اینجاست که زیرساخت به عنوان کد (Infrastructure as Code یا IaC) وارد می‌شود و دقیقاً همین مشکلات را حل می‌کند.

زیرساخت به عنوان کد یعنی تعریف تمام اجزای زیرساخت — از سرور و شبکه گرفته تا نرم‌افزارهای نصب‌شده — به شکل فایل‌های متنی و نسخه‌پذیر. به جای اینکه به کنسول مدیریت دیتاسنتر بروید و روی دکمه کلیک کنید، یک فایل main.tf می‌نویسید و اجرا می‌کنید. نتیجه؟ زیرساختی که مثل کد نرم‌افزار، قابل بازبینی، تست و بازتولید است.

مشکل واقعی: «روی سرور من کار می‌کند» دیگر کافی نیست

فرض کنید یک اپلیکیشن وب دارید که روی یک سرور مجازی اجرا می‌شود. یک روز متوجه می‌شوید که نسخه PHP روی سرور 7.4 است، اما روی سیستم توسعه شما 8.2. یا کشف می‌کنید که فایروال روی سرور اصلی باز است، اما روی سرور پشتیبان بسته. این «انحراف پیکربندی» (Configuration Drift) دقیقاً همان چیزی است که باعث باگ‌های مرموز و آسیب‌پذیری‌های امنیتی می‌شود.

با زیرساخت به عنوان کد، زیرساخت شما به یک «ماشین حالت» تبدیل می‌شود. شما حالت مطلوب را در کد تعریف می‌کنید و ابزار IaC وظیفه دارد سیستم را به آن حالت برساند. اگر کسی به‌صورت دستی چیزی را تغییر دهد، در اجرای بعدی یا شناسایی و اصلاح می‌شود، یا حداقل به‌عنوان انحراف گزارش می‌شود.

سه نسل ابزارهای IaC که باید بشناسید

ابزارهای IaC را می‌توان به سه دسته کلی تقسیم کرد:

• ابزارهای Provisioning (ساخت زیرساخت): مانند Terraform و Pulumi که سرورها، شبکه‌ها و منابع ابری را می‌سازند. این ابزارها «زیرساخت فیزیکی» را مدیریت می‌کنند.
• ابزارهای Configuration Management (تنظیم نرم‌افزار): مانند Ansible، Puppet و Chef که روی سرورهای موجود اجرا می‌شوند و نرم‌افزارها را نصب و پیکربندی می‌کنند.
• ابزارهای Immutable Infrastructure: مانند Packer که تصاویر آماده سرور (مثل AMI) می‌سازند. در این رویکرد، سرور هرگز به‌روزرسانی نمی‌شود؛ بلکه با نسخه جدید جایگزین می‌شود.

در عمل، بیشتر تیم‌ها ترکیبی از Terraform (برای ساخت) و Ansible (برای تنظیم) استفاده می‌کنند. در ادامه، تمرکز ما روی Terraform است چون محبوب‌ترین و در عین حال ساده‌ترین نقطه شروع برای زیرساخت به عنوان کد محسوب می‌شود.

شروع کار با Terraform: یک مثال واقعی

فرض کنید می‌خواهید یک سرور مجازی (VPS) در دیتاسنتر راه‌اندازی کنید. با روش سنتی، وارد پنل می‌شوید، یک سرور می‌سازید، SSH key تنظیم می‌کنید و بعد دستی نرم‌افزار نصب می‌کنید. با Terraform، کل این فرآیند به یک فایل متنی تبدیل می‌شود.

نصب Terraform و ساختار اولیه

ابتدا Terraform را نصب کنید. در Ubuntu/Debian:

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

سپس یک دایرکتوری پروژه بسازید و اولین فایل را ایجاد کنید:

mkdir my-infra && cd my-infra
nano main.tf

در این فایل، ابتدا provider را تعریف می‌کنیم. اگر با سرویس‌دهنده ایرانی کار می‌کنید، احتمالاً از API سازگار با OpenStack یا یک provider اختصاصی استفاده می‌کنید. برای مثال ساده، فرض کنید از provider استاندارد AWS استفاده می‌کنیم:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "me-south-1"
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "MyFirstIaCServer"
  }
}

حالا سه دستور اصلی را اجرا کنید:

1. terraform init — برای دانلود پلاگین‌های provider
2. terraform plan — برای مشاهده تغییراتی که قرار است اعمال شود (بدون اعمال)
3. terraform apply — برای ساخت واقعی سرور

خروجی terraform plan به شما نشان می‌دهد که دقیقاً چه چیزی ساخته می‌شود. این «پیش‌نمایش» یکی از بزرگ‌ترین مزیت‌های IaC است: قبل از هر تغییری، می‌دانید چه اتفاقی خواهد افتاد.

مدیریت state: قلب تپنده IaC

Terraform یک فایل به نام terraform.tfstate نگه می‌دارد که وضعیت فعلی زیرساخت شما را ثبت می‌کند. این فایل حیاتی است؛ اگر گم شود، Terraform نمی‌داند چه چیزی ساخته شده و چه چیزی نه. در پروژه‌های تیمی، این فایل باید در یک مکان امن و مشترک (مثل S3 یا GitLab) نگهداری شود. هرگز آن را در Git commit نکنید — مگر اینکه از backend رمزنگاری‌شده استفاده کنید.

یک اشتباه رایج: فراموش کردن اجرای terraform plan قبل از apply. همیشه plan را اجرا کنید، مخصوصاً در محیط production. یک تغییر اشتباه در کد می‌تواند کل زیرساخت را از بین ببرد.

نکات عملی برای اجتناب از اشتباهات رایج

زیرساخت به عنوان کد اگر درست استفاده نشود، می‌تواند دردسرساز شود. در اینجا چند اشتباه رایج و راه‌حل آن‌ها را می‌بینید:

اشتباه ۱: استفاده از credentials در کد

هرگز کلیدهای API یا رمز عبور را مستقیم در فایل‌های .tf ننویسید. این فایل‌ها معمولاً در Git ذخیره می‌شوند و هر کسی با دسترسی به repository می‌تواند آن‌ها را ببیند. به جای آن، از متغیرهای محیطی یا ابزارهایی مثل Vault استفاده کنید:

provider "aws" {
  region     = "me-south-1"
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

و مقادیر را در فایل terraform.tfvars (که در .gitignore قرار می‌گیرد) یا به‌صورت environment variable تعریف کنید.

اشتباه ۲: نادیده گرفتن قفل state در کار تیمی

اگر دو نفر همزمان terraform apply اجرا کنند، ممکن است state خراب شود. ابزارهایی مثل Terraform Cloud یا backendهای مبتنی بر S3 با قفل‌گذاری (Locking) این مشکل را حل می‌کنند. در تیم‌های کوچک، حداقل یک قانون بگذارید: فقط یک نفر در هر زمان عملیات apply انجام دهد.

اشتباه ۳: تست نکردن کد زیرساخت

کد IaC هم مثل کد نرم‌افزار باید تست شود. ابزارهایی مثل terraform validate و terraform fmt را در CI/CD خود قرار دهید. برای تست‌های پیشرفته‌تر، از terraform-compliance یا kitchen-terraform استفاده کنید.

زیرساخت به عنوان کد در دنیای واقعی: چرخه حیات کامل

حالا که اصول اولیه را می‌دانید، بیایید یک سناریوی کامل را مرور کنیم. فرض کنید یک اپلیکیشن Node.js دارید که باید روی یک سرور اجرا شود. با زیرساخت به عنوان کد، چرخه کار به این شکل است:

1. تعریف زیرساخت: در main.tf، یک سرور، یک security group (فایروال) و یک Elastic IP تعریف می‌کنید.
2. تنظیم نرم‌افزار: با Ansible یا یک user_data اسکریپت، Node.js و PM2 را نصب می‌کنید.
3. اعمال تغییرات: terraform apply را اجرا می‌کنید. سرور ساخته می‌شود، نرم‌افزار نصب می‌شود و اپلیکیشن بالا می‌آید.
4. به‌روزرسانی: اگر نسخه جدیدی از اپلیکیشن دارید، کد را تغییر می‌دهید و دوباره apply می‌کنید. Terraform فقط تغییرات لازم را اعمال می‌کند.
5. حذف: اگر دیگر به سرور نیاز ندارید، terraform destroy را اجرا می‌کنید و همه‌چیز پاک می‌شود — بدون اینکه چیزی از قلم بیفتد.

این چرخه، دقیقاً همان چیزی است که در شرکت‌های بزرگ به آن «GitOps» می‌گویند: زیرساخت شما در Git زندگی می‌کند، هر تغییری از طریق Pull Request اعمال می‌شود و هیچ‌کس به‌صورت مستقیم به سرور دسترسی ندارد.

چه زمانی باید سراغ IaC بروید؟

اگر فقط یک سرور دارید و آن را برای یک پروژه شخصی مدیریت می‌کنید، شاید زیرساخت به عنوان کد «بیش از حد» به نظر برسد. اما به محض اینکه:

• بیش از دو سرور دارید،
• نیاز به بازتولید محیط staging و production دارید،
• تیم شما بیش از یک نفر است،
• یا نیاز به مستندسازی خودکار زیرساخت دارید،

…زیرساخت به عنوان کد دیگر یک انتخاب نیست؛ یک ضرورت است. هزینه اولیه یادگیری (حدود یک هفته کار با Terraform) در برابر ساعاتی که در هر دیپلوی صرفه‌جویی می‌کنید، ناچیز است.

اگر به دنبال زیرساختی هستید که با API و ابزارهای IaC سازگار باشد، سرویس‌های ابری ServerNet امکان مدیریت منابع را از طریق رابط‌های برنامه‌نویسی فراهم می‌کنند که می‌تواند نقطه شروع خوبی برای پیاده‌سازی این رویکرد باشد.

جمع‌بندی: قدم بعدی شما

زیرساخت به عنوان کد فقط یک ابزار نیست؛ یک تغییر ذهنیت است. به جای اینکه به سرورها به‌عنوان «اشیاء یک‌بارمصرف» نگاه کنید که با دست ساخته می‌شوند، آن‌ها را به‌عنوان «کد» ببینید که قابل بازبینی، تست و بازتولید است. شروع کنید با یک پروژه کوچک: یک سرور آزمایشی را با Terraform بسازید، چند روز با آن کار کنید و ببینید چقدر راحت‌تر از روش قبلی است.

برای شروع، این سه کار را انجام دهید:

1. Terraform را نصب کنید و یک سرور آزمایشی بسازید.
2. فایل‌های .tf خود را در یک repository Git قرار دهید.
3. یک اسکریپت Ansible ساده بنویسید که Nginx را روی همان سرور نصب کند.

بعد از این تمرین، متوجه می‌شوید که چرا زیرساخت به عنوان کد به یکی از مهم‌ترین مهارت‌های DevOps تبدیل شده است. دیگر هیچ بهانه‌ای برای پیکربندی دستی وجود ندارد — مگر اینکه عاشق تکرار کارهای تکراری باشید.