Infrastructure as Code: خودکارسازی سرورها با Terraform و Ansible

راهنمای Infrastructure as Code

Terraform state را کجا نگه داریم و چرا مهم است؟

Terraform وضعیت منابعی را که ساخته در فایل terraform.tfstate نگه می دارد و این فایل رمزها و مقادیر حساس را به صورت متن ساده در خود دارد. commit کردن آن در گیت یکی از رایج ترین اشتباهات است. اگر دو نفر هم زمان terraform apply اجرا کنند و state قفل نشود، فایل خراب می شود و Terraform دیگر نمی داند چه چیزهایی را مدیریت می کند.

برای تیم های کوچک، backend مدیریت شده GitLab که قفل و نسخه بندی state را دارد، ساده ترین گزینه است. در غیر این صورت backend از نوع S3 روی MinIO داخلی با قفل فعال راه اندازی می کنیم. منابعی که پیش از این با دست ساخته شده اند با terraform import یا بلوک import وارد state می شوند و لازم نیست دوباره ساخته شوند.

Ansible AWX یا اجرای playbook از پایپ لاین GitLab؟

AWX پروژه متن باز پشت Ansible Automation Platform است. رابط وب، کنترل دسترسی برای هر تیم، زمان بندی اجرای playbookها و محل امن نگهداری credentialها را می دهد و تاریخچه هر اجرا را نگه می دارد. در عوض خودش یک سرویس است که با AWX Operator روی کوبرنتیز نصب می شود و نگهداری و به روزرسانی می خواهد.

اگر تیم شما کوچک است و تغییرات همیشه از مسیر merge request می گذرند، اجرای ansible-playbook از GitLab CI کافی است و چیز تازه ای برای نگهداری اضافه نمی کند. AWX وقتی ارزش دارد که افرادی بیرون از تیم فنی، مثل واحد پشتیبانی، باید playbookهای مشخصی را بدون دسترسی مستقیم به سرورها اجرا کنند.

اشتباهات رایج در اتوماسیون کانفیگ سرور

تکیه زیاد بر ماژول های shell و command به جای ماژول های اختصاصی Ansible، playbook را غیر idempotent می کند و اجرای دوم همان تغییر را تکرار می کند یا خطا می دهد. رمزهایی که مستقیم در group_vars نوشته شده اند باید با ansible-vault رمزنگاری شوند یا در Vault بمانند.

نسخه ها هم باید ثابت شوند: نسخه collectionها در requirements.yml و نسخه providerها در فایل .terraform.lock.hcl که باید در گیت بماند. بزرگ ترین مشکل اما انسانی است. اگر بعد از کدنویسی کسی همچنان با SSH تنظیمات را دستی تغییر دهد، کد و سرور دوباره از هم فاصله می گیرند. اجرای زمان بندی شده playbook در حالت check این اختلاف را زود نشان می دهد.

دامنه پروژه Infrastructure as Code به چه عواملی بستگی دارد؟

تعداد نقش های متفاوت سرور از تعداد سرورها مهم تر است. بیست وب سرور یکسان یک role می خواهند و پنج سرور که هر کدام کار متفاوتی می کنند پنج role. تنوع سیستم عامل ها هم اثر دارد، چون پشتیبانی هم زمان از Ubuntu، AlmaLinux و ویندوز کار بیشتری از یک توزیع واحد می برد.

عوامل دیگر در دسترس بودن API برای hypervisor یا ارائه دهنده ابری، وجود پایپ لاین CI و مخزن گیت، مقدار مستندات فعلی و وضعیت مدیریت رمزهاست.