مدیریت دستی سرورها در پروژه های کوچک ممکن است ساده باشد، اما با افزایش تعداد سرورها و محیط های مختلف، انجام کارهایی مانند نصب نرم افزار، تغییر تنظیمات، به روز رسانی سرویس ها و یکسان نگه داشتن پیکربندی ها زمان بر و مستعد خطا می شود. Ansible ابزاری برای خودکارسازی این فرایندها است و به تیم ها کمک می کند عملیات تکراری مدیریت زیرساخت را به صورت قابل کنترل و تکرارپذیر اجرا کنند.
اگر بخواهیم ساده پاسخ دهیم که Ansible چیست، انسیبل یک ابزار متن باز برای اتوماسیون سرور، مدیریت پیکربندی و استقرار نرم افزار است. مدیران سیستم و تیم های DevOps می توانند به جای اجرای دستی مجموعه ای از دستورات روی هر سرور، مراحل مورد نیاز را تعریف کنند تا Ansible آنها را روی یک یا چند سیستم اجرا کند.
این شیوه با مفهوم مدیریت زیرساخت به صورت کد ارتباط نزدیکی دارد؛ زیرا تنظیمات و فرایندهای زیرساخت به جای وابستگی به عملیات دستی، در فایل های قابل نگهداری و تکرار تعریف می شوند. در ادامه با نحوه کار Ansible، Playbook ها، کاربردهای آن در DevOps و تفاوت آن با ابزارهایی مانند Terraform آشنا می شویم.
خلاصه سریع؛ Ansible چیست؟
Ansible یک ابزار متن باز برای اتوماسیون زیرساخت و مدیریت پیکربندی سرورها است. با استفاده از انسیبل می توان کارهایی مانند نصب نرم افزار، تغییر تنظیمات، استقرار برنامه ها و اجرای عملیات تکراری روی چندین سرور را خودکار کرد. Ansible معمولا بدون نیاز به نصب Agent روی سرورهای مقصد کار می کند و وظایف اتوماسیون در آن می توانند با استفاده از Playbook های نوشته شده با YAML تعریف شوند. به همین دلیل Ansible در مدیریت سرورها، اتوماسیون IT و فرایندهای DevOps کاربرد گسترده ای دارد.
Ansible چیست و چه کاری انجام می دهد؟
Ansible یک ابزار متن باز برای اتوماسیون IT، مدیریت پیکربندی سرورها، استقرار نرم افزار و هماهنگ سازی فرایندهای زیرساخت است. با استفاده از Ansible می توان مجموعه ای از عملیات را یک بار تعریف کرد و سپس همان عملیات را به صورت قابل تکرار روی یک یا چند سرور اجرا کرد.
در روش های سنتی، مدیر سیستم ممکن است برای نصب یک نرم افزار، تغییر فایل های پیکربندی یا راه اندازی یک سرویس مجبور باشد همین مراحل را روی هر سرور به صورت جداگانه انجام دهد. Ansible این فرایند را خودکار می کند و باعث می شود تنظیمات سرورها با ساختار مشخص و قابل کنترل انجام شوند.
کاربردهای اصلی Ansible را می توان در چهار حوزه خلاصه کرد:
- مدیریت پیکربندی یا Configuration Management: تنظیم و یکسان سازی پیکربندی سیستم ها، سرویس ها و نرم افزارها روی سرورهای مختلف.
- اتوماسیون یا Automation: اجرای خودکار کارهای تکراری مانند نصب پکیج ها، ساخت کاربران، تغییر فایل ها یا راه اندازی سرویس ها.
- استقرار نرم افزار یا Deployment: آماده سازی محیط و اجرای مراحل مورد نیاز برای استقرار برنامه روی سرورها.
- هماهنگ سازی یا Orchestration: اجرای چند عملیات مرتبط با ترتیب مشخص روی بخش های مختلف زیرساخت.
برای مثال، اگر یک مجموعه ده ها سرور داشته باشد، می توان با Ansible مشخص کرد که Nginx روی همه سرورها نصب شود، فایل پیکربندی مشخصی روی آنها قرار بگیرد و سپس سرویس Nginx اجرا یا مجددا راه اندازی شود. به جای انجام این مراحل به صورت دستی، Ansible آنها را طبق دستورهای از پیش تعریف شده اجرا می کند.
این رویکرد با مفهوم مدیریت زیرساخت بدون کد ارتباط نزدیکی دارد. در Infrastructure as Code تلاش می شود تنظیمات و تغییرات زیرساخت به جای عملیات دستی، به صورت فایل های قابل نگهداری، نسخه بندی و تکرار تعریف شوند. Ansible یکی از ابزارهایی است که می تواند برای اجرای بخشی از این فرایند، به خصوص مدیریت پیکربندی و اتوماسیون سرورها، استفاده شود.
Ansible چگونه کار می کند؟
Ansible معمولا از یک سیستم مرکزی به نام Control Node برای اجرای دستورات روی سرورهای مقصد استفاده می کند. سرورهای مقصد در Inventory معرفی می شوند و وظایفی که باید روی آنها اجرا شوند می توانند در Playbook ها تعریف شوند. سپس Ansible با استفاده از Module های مورد نیاز عملیات را روی Managed Node ها اجرا می کند.
به زبان ساده، روند کلی کار را می توان این طور نمایش داد:
Control Node → Inventory → Playbook → Module → Managed Nodes
شناخت این اجزا کمک می کند ساختار Ansible و نحوه اجرای اتوماسیون در آن ساده تر درک شود.
Control Node چیست؟
Control Node سیستمی است که Ansible روی آن اجرا می شود و عملیات اتوماسیون از طریق آن مدیریت می شود.
فایل های Inventory، Playbook ها و تنظیمات Ansible معمولا روی همین سیستم قرار دارند. مدیر سیستم یا تیم DevOps دستور اجرای Ansible را از Control Node صادر می کند و این سیستم وظایف مشخص شده را روی سرورهای مقصد اجرا می کند.
در یک ساختار ساده، Control Node می تواند یک سرور مدیریتی یا حتی سیستم کاری مدیر زیرساخت باشد.
Managed Node چیست؟
Managed Node به سرور یا سیستمی گفته می شود که Ansible آن را مدیریت می کند.
برای مثال، وب سرور، سرور دیتابیس یا سرورهای یک برنامه می توانند به عنوان Managed Node در Ansible تعریف شوند. Ansible دستورات و تنظیمات مورد نیاز را از Control Node به این سیستم ها اعمال می کند.
یکی از ویژگی های مهم Ansible این است که در بسیاری از سناریوهای Linux نیازی به نصب Agent اختصاصی روی Managed Node وجود ندارد. ارتباط با این سرورها معمولا از طریق SSH انجام می شود.
Inventory در Ansible چیست؟
در Inventory می توان آدرس سرورها را مشخص کرد و آنها را در گروه های مختلف قرار داد. برای مثال ممکن است سرورها به شکل زیر دسته بندی شوند:
- Web Servers
- Database Servers
- Application Servers
این گروه بندی اجازه می دهد یک Playbook فقط روی گروه مشخصی از سرورها اجرا شود. به عنوان مثال، دستور نصب Nginx می تواند فقط برای Web Servers اجرا شود و تغییری روی سرورهای دیتابیس ایجاد نکند.
Module در Ansible چیست؟
Module ها واحدهای اجرایی Ansible هستند که هر کدام وظیفه مشخصی را انجام می دهند.
برای مثال Module های مختلف می توانند برای نصب نرم افزار، مدیریت فایل ها، ایجاد کاربران، کنترل سرویس ها یا اجرای دستورات روی سیستم استفاده شوند.
در یک Playbook معمولا مشخص می شود که چه Module ای با چه تنظیماتی و روی چه سرورهایی اجرا شود. Ansible سپس عملیات مورد نظر را از طریق همان Module انجام می دهد.
برای نمونه، به جای نوشتن چند دستور جداگانه برای بررسی وضعیت Nginx و اجرای آن، می توان از Module مربوط به مدیریت سرویس ها استفاده کرد و وضعیت مورد نظر را تعریف کرد.
در نتیجه، نحوه کار Ansible را می توان به صورت یک زنجیره ساده در نظر گرفت: Control Node سرورهای مورد نظر را از Inventory شناسایی می کند، وظایف را از Playbook می خواند، Module مناسب را اجرا می کند و تغییرات مورد نیاز روی Managed Node ها اعمال می شوند.
این ساختار باعث می شود اتوماسیون سرور و مدیریت پیکربندی در Ansible قابل تکرار، قابل کنترل و برای تیم های DevOps ساده تر باشد.
Ansible Playbook چیست؟
Ansible Playbook فایلی است که مجموعه ای از وظایف و تنظیمات مورد نیاز برای اتوماسیون سرورها را مشخص می کند. Playbook ها معمولا با زبان YAML نوشته می شوند و به Ansible می گویند چه عملیاتی، روی کدام سرورها و با چه ترتیبی اجرا شوند.
به جای اینکه مدیر سیستم مجموعه ای از دستورات را به صورت دستی روی هر سرور اجرا کند، می تواند وضعیت مورد نظر را در یک Playbook تعریف کند. برای مثال می توان مشخص کرد که Nginx نصب باشد، فایل پیکربندی مشخصی روی سرور قرار بگیرد و سرویس Nginx نیز فعال و در حال اجرا باشد.
یکی از مزایای مهم Ansible Playbook این است که مراحل اتوماسیون به صورت فایل ذخیره می شوند. در نتیجه می توان آنها را نگهداری، ویرایش، نسخه بندی و در محیط های مختلف دوباره اجرا کرد. این ویژگی به تیم های DevOps کمک می کند تغییرات زیرساخت را با ساختار مشخص تری مدیریت کنند.
ساختار Playbook در Ansible چگونه است؟
یک Playbook می تواند شامل یک یا چند Play باشد. هر Play مشخص می کند که عملیات روی چه گروهی از سرورها انجام شود و چه Task هایی باید اجرا شوند.
در یک ساختار ساده معمولا با مفاهیم زیر روبرو هستیم:
- Hosts: مشخص می کند Playbook روی کدام سرورها یا گروه های Inventory اجرا شود.
- Tasks: مجموعه وظایفی که باید اجرا شوند.
- Modules: ماژول هایی که هر Task برای انجام عملیات مشخص از آنها استفاده می کند.
- Variables: مقادیری که می توانند برای قابل استفاده مجدد کردن تنظیمات تعریف شوند.
- Handlers: وظایفی که معمولا پس از ایجاد یک تغییر مشخص اجرا می شوند؛ مانند Restart کردن یک سرویس.
نمونه Playbook برای نصب Nginx
برای مثال، Playbook زیر می تواند Nginx را روی سرورهای گروه webservers نصب و سپس سرویس آن را فعال کند:
# Run this play on all servers defined in the webservers group.
- name: Install and start Nginx
hosts: webservers
become: true
tasks:
# Install the Nginx package using the system package manager.
- name: Install Nginx
ansible.builtin.package:
name: nginx
state: present
# Ensure that the Nginx service is running and starts after a reboot.
- name: Start and enable Nginx
ansible.builtin.service:
name: nginx
state: started
enabled: trueدر این مثال، Ansible ابتدا سرورهای گروه webservers را از Inventory شناسایی می کند، سپس بررسی می کند که Nginx نصب شده باشد و در مرحله بعد وضعیت سرویس را روی حالت فعال و در حال اجرا قرار می دهد.
نکته مهم این است که Playbook فقط برای اجرای یک مجموعه دستور پشت سر هم طراحی نشده است. در بسیاری از موارد Ansible وضعیت فعلی سیستم را بررسی می کند و فقط تغییراتی را انجام می دهد که برای رسیدن به وضعیت تعریف شده لازم باشند. این رفتار باعث می شود اجرای مجدد بسیاری از Playbook ها تغییرات غیر ضروری ایجاد نکند.
به همین دلیل Playbook ها می توانند برای مدیریت پیکربندی، Deployment، Orchestration و اتوماسیون زیرساخت مورد استفاده قرار گیرند.
Ansible چه کاربردهایی دارد؟
کاربرد Ansible فقط به نصب نرم افزار روی چند سرور محدود نمی شود. این ابزار می تواند بخش قابل توجهی از عملیات تکراری زیرساخت و مدیریت سیستم ها را خودکار کند. از مدیریت پیکربندی گرفته تا استقرار برنامه ها، Ansible در سناریوهای مختلف مدیریت سرور و DevOps قابل استفاده است.
مدیریت پیکربندی سرورها
یکی از اصلی ترین کاربردهای Ansible، مدیریت پیکربندی یا Configuration Management است. با استفاده از Playbook ها می توان وضعیت مورد انتظار سرورها را مشخص کرد و همان تنظیمات را روی چند سیستم اعمال کرد.
برای مثال می توان تعیین کرد که نسخه مشخصی از یک نرم افزار نصب باشد، فایل پیکربندی خاصی وجود داشته باشد، یک سرویس فعال باشد یا کاربران و سطح دسترسی آنها طبق ساختار مشخصی تنظیم شوند.
این روش احتمال ایجاد تفاوت ناخواسته بین سرورها را کاهش می دهد و مدیریت محیط های Development، Testing و Production را ساده تر می کند.
نصب و به روز رسانی نرم افزار
Ansible می تواند نصب، حذف یا به روز رسانی Package ها را روی تعداد زیادی سرور خودکار کند.
برای مثال به جای ورود جداگانه به 20 سرور برای نصب یک نرم افزار، می توان سرورهای مورد نظر را در Inventory قرار داد و عملیات نصب را از طریق یک Playbook اجرا کرد.
همین روش برای به روز رسانی نرم افزارها، نصب وابستگی ها و آماده سازی سرورهای جدید نیز قابل استفاده است
استقرار نرم افزار
استقرار نرم افزار یا Deployment یکی دیگر از کاربردهای مهم Ansible است. پس از آماده شدن نسخه جدید یک برنامه، Ansible می تواند بخشی از عملیات مورد نیاز برای انتقال آن به محیط مقصد را انجام دهد.
برای مثال می توان با Ansible فایل های مورد نیاز را منتقل کرد، Dependency ها را نصب کرد، تنظیمات محیط را اعمال کرد و سرویس برنامه را مجددا راه اندازی کرد.
در پروژه هایی که انتشار نرم افزار به صورت خودکار انجام می شود، Ansible می تواند در کنار فرایند CI/CD برای خودکارسازی مراحل مربوط به پیکربندی و Deployment مورد استفاده قرار گیرد.
اتوماسیون وظایف تکراری
بسیاری از وظایف روزمره مدیران سیستم قابل خودکارسازی هستند. ایجاد کاربران، تغییر سطح دسترسی، مدیریت فایل ها، Restart کردن سرویس ها، اجرای Update ها و انجام برخی عملیات نگهداری نمونه هایی از این وظایف هستند.
با تعریف این عملیات در Ansible، تیم زیرساخت مجبور نیست هر بار مراحل مشابه را به صورت دستی تکرار کند. در نتیجه احتمال خطای انسانی کاهش پیدا می کند و انجام تغییرات روی سرورها قابل تکرارتر می شود.
مدیریت چندین سرور به صورت همزمان
یکی از مزیت های مهم Ansible زمانی مشخص می شود که تعداد سرورها افزایش پیدا کند.
سرورها می توانند در Inventory بر اساس نقش یا محیط دسته بندی شوند؛ برای مثال:
webservers، databases و production
سپس می توان یک Playbook را روی یک گروه مشخص اجرا کرد. به این ترتیب تغییرات مورد نیاز بدون ورود دستی به تک تک سرورها اعمال می شوند.
این قابلیت برای زیرساخت هایی که شامل تعداد زیادی ماشین مجازی، سرور فیزیکی یا سرویس ابری هستند اهمیت بیشتری پیدا می کند.
استفاده از Ansible در DevOps
Ansible می تواند بخشی از زنجیره اتوماسیون DevOps باشد. تیم ها می توانند از آن برای آماده سازی محیط، مدیریت پیکربندی، Deployment و استانداردسازی تنظیمات سرورها استفاده کنند.
برای مثال یک Pipeline می تواند ابتدا کد را Build و Test کند و پس از تایید نسخه جدید، Ansible مراحل مورد نیاز برای پیکربندی محیط یا استقرار برنامه روی سرورهای مقصد را انجام دهد.
بنابراین Ansible جایگزین تمام ابزارهای DevOps نیست؛ بلکه یکی از ابزارهایی است که می تواند بخش مدیریت پیکربندی و اتوماسیون عملیات زیرساخت را بر عهده بگیرد.
در پروژه هایی که تعداد سرورها، محیط های اجرایی یا مراحل استقرار افزایش پیدا کرده است، طراحی صحیح پیاده سازی و اتوماسیون فرایندهای DevOps می تواند به کاهش عملیات دستی و ایجاد یک فرایند قابل کنترل تر برای مدیریت زیرساخت کمک کند.
مزایای Ansible چیست؟
یکی از دلایل استفاده گسترده از Ansible در تیم های DevOps، سادگی نسبی آن در کنار قابلیت خودکارسازی طیف وسیعی از وظایف زیرساخت است. مزایای Ansible فقط به اتوماسیون سرور محدود نمی شود؛ این ابزار می تواند مدیریت پیکربندی، استقرار نرم افزار و اجرای تغییرات روی تعداد زیادی سیستم را با ساختاری قابل تکرار انجام دهد.
معماری Agentless
یکی از مهم ترین ویژگی های Ansible، معماری Agentless آن است. در بسیاری از سناریوها نیازی نیست نرم افزار یا Agent اختصاصی Ansible روی سرورهای مقصد نصب شود.
برای مدیریت سیستم های Linux معمولا ارتباط با سرور از طریق SSH انجام می شود. این موضوع راه اندازی اولیه Ansible را ساده تر می کند و نیاز به نگهداری Agent روی تک تک سرورها را کاهش می دهد.
Agentless بودن به این معنا نیست که Ansible بدون هیچ پیش نیاز یا ارتباطی با سرور مقصد کار می کند؛ Control Node همچنان باید بتواند از طریق روش مناسب با Managed Node ها ارتباط برقرار کند.
استفاده از YAML و خوانایی Playbook ها
Playbook های Ansible معمولا با YAML نوشته می شوند. ساختار YAML در مقایسه با بسیاری از زبان های برنامه نویسی ساده تر و خواناتر است و همین موضوع باعث می شود اعضای تیم بتوانند وظایف تعریف شده در Playbook را راحت تر بررسی کنند.
برای مثال، در یک Playbook می توان به شکل مشخص تعریف کرد که یک Package نصب شود، فایل پیکربندی در مسیر خاصی قرار بگیرد و سپس یک سرویس اجرا شود.
این خوانایی در پروژه هایی که چند نفر روی مدیریت زیرساخت کار می کنند اهمیت بیشتری دارد، زیرا منطق اتوماسیون فقط در ذهن یک مدیر سیستم باقی نمی ماند و در قالب فایل های قابل بررسی ثبت می شود.
Idempotency در Ansible
Idempotency یکی از مفاهیم مهم در مدیریت پیکربندی با Ansible است. به زبان ساده، اجرای چندباره یک عملیات Idempotent نباید هر بار تغییر غیر ضروری جدیدی روی سیستم ایجاد کند.
فرض کنیم در یک Playbook مشخص شده باشد که Nginx باید نصب باشد. اگر Nginx قبلا روی سرور نصب شده باشد، Module مناسب Ansible وضعیت سیستم را بررسی می کند و معمولا نیازی به نصب مجدد آن وجود نخواهد داشت.
این رفتار در اتوماسیون زیرساخت اهمیت زیادی دارد، زیرا Playbook ها ممکن است بارها روی یک محیط اجرا شوند. هدف این است که سیستم به وضعیت مطلوب یا Desired State برسد، نه اینکه هر بار مجموعه ای از تغییرات بدون توجه به وضعیت فعلی اجرا شود.
البته Idempotency به Module و روشی که Playbook نوشته شده است نیز بستگی دارد و همه دستورات یا سناریوهای Ansible به صورت خودکار Idempotent نیستند.
کاهش خطاهای ناشی از عملیات دستی
وقتی یک تنظیم باید روی تعداد زیادی سرور اعمال شود، انجام دستی آن احتمال تفاوت بین سرورها و خطای انسانی را افزایش می دهد.
با استفاده از Ansible می توان مراحل مورد نیاز را یک بار تعریف و سپس همان ساختار را روی سیستم های مختلف اجرا کرد. در نتیجه احتمال اینکه یک مرحله روی بعضی سرورها فراموش شود یا تنظیمات متفاوتی اعمال شود کاهش پیدا می کند.
این ویژگی در محیط هایی مانند Development، Testing و Production که باید تنظیمات مشخص و قابل کنترل داشته باشند اهمیت بیشتری دارد.
مدیریت تعداد زیادی سیستم
Ansible امکان گروه بندی سرورها در Inventory و اجرای عملیات روی گروه های مشخص را فراهم می کند. به همین دلیل همان Playbook می تواند برای مدیریت چند سرور یا تعداد بیشتری از سیستم ها مورد استفاده قرار گیرد.
البته مقیاس پذیری Ansible به طراحی Inventory، Playbook ها، نحوه اجرای Task ها، ساختار شبکه و منابع Control Node نیز وابسته است و صرف استفاده از Ansible به معنای مقیاس پذیری نامحدود نیست.
پشتیبانی از محیط های مختلف
کاربرد Ansible فقط به مدیریت یک نوع سرور محدود نمی شود. بسته به Module ها و Collection های مورد استفاده، می توان از آن در محیط های مختلف از جمله Linux، Windows، سرویس های Cloud و برخی تجهیزات شبکه استفاده کرد.
این قابلیت باعث می شود تیم ها بتوانند بخش های مختلف زیرساخت را با یک رویکرد اتوماسیون مشترک مدیریت کنند.
محدودیت ها و معایب Ansible چیست؟
با وجود مزایای متعدد، Ansible برای همه پروژه ها و همه انواع عملیات زیرساخت بهترین انتخاب نیست. انتخاب این ابزار باید بر اساس تعداد سیستم ها، نوع زیرساخت، پیچیدگی فرایندهای اتوماسیون و ابزارهای دیگری که در پروژه استفاده می شوند انجام شود.
چالش عملکرد در مقیاس های بسیار بزرگ
Ansible برای مدیریت تعداد زیادی سرور قابل استفاده است، اما با افزایش شدید تعداد Managed Node ها، طراحی نحوه اجرای Task ها اهمیت بیشتری پیدا می کند.
اجرای همزمان عملیات روی تعداد بسیار زیادی سیستم می تواند باعث افزایش مصرف منابع Control Node، زمان اجرا و فشار روی شبکه شود. در چنین محیط هایی معمولا باید تنظیمات مربوط به Parallel Execution، ساختار Inventory و روش اجرای Playbook ها با دقت بیشتری طراحی شوند.
بنابراین Ansible می تواند در زیرساخت های بزرگ استفاده شود، اما مقیاس بزرگ نیازمند معماری و تنظیمات مناسب است.
وابستگی به ارتباط شبکه
Control Node برای اجرای بسیاری از عملیات باید بتواند با Managed Node ها ارتباط برقرار کند. در سیستم های Linux این ارتباط اغلب از طریق SSH انجام می شود.
اگر ارتباط شبکه پایدار نباشد، دسترسی های لازم وجود نداشته باشند یا Firewall ارتباط مورد نیاز را مسدود کند، اجرای Playbook ممکن است با مشکل مواجه شود.
به همین دلیل مدیریت دسترسی ها، شبکه و Credential ها بخشی مهم از طراحی یک زیرساخت Ansible است.
پیچیده شدن Playbook های بزرگ
Playbook های ساده معمولا خوانایی بالایی دارند، اما با رشد پروژه ممکن است تعداد Task ها، Variable ها، Condition ها و Dependency ها افزایش پیدا کند.
قرار دادن همه این موارد در چند فایل بزرگ می تواند نگهداری Ansible را دشوار کند. در پروژه های پیچیده معمولا باید از ساختارهایی مانند Roles، Variables، Templates و Collection ها استفاده کرد تا بخش های مختلف اتوماسیون از یکدیگر جدا شوند.
بنابراین سادگی YAML به تنهایی تضمین نمی کند که یک پروژه Ansible همیشه ساده باقی بماند؛ معماری Playbook ها نیز اهمیت زیادی دارد.
نیاز به طراحی درست Roles و ساختار پروژه
در پروژه های کوچک ممکن است چند Playbook ساده کافی باشد، اما با افزایش تعداد سرورها و فرایندها، ساختار پروژه اهمیت بیشتری پیدا می کند.
اگر Role ها، Inventory ها و Variable ها بدون الگوی مشخص ایجاد شوند، بعد از مدتی تغییر و نگهداری Playbook ها دشوار خواهد شد. به همین دلیل استفاده حرفه ای از Ansible نیازمند تعریف استاندارد برای نام گذاری، ساختار فایل ها و مدیریت Environment های مختلف است.
Ansible همیشه بهترین ابزار برای Provisioning نیست
Ansible می تواند برای انجام برخی عملیات Provisioning نیز استفاده شود، اما تمرکز اصلی آن بیشتر روی اتوماسیون، مدیریت پیکربندی و Orchestration است.
اگر هدف اصلی پروژه تعریف و ایجاد منابع زیرساختی مانند ماشین مجازی، شبکه، Load Balancer یا سایر منابع Cloud باشد، ابزارهایی که به صورت تخصصی برای Infrastructure Provisioning طراحی شده اند ممکن است انتخاب مناسب تری باشند.
به همین دلیل در بسیاری از پروژه ها Ansible به جای جایگزین شدن با سایر ابزارها، در کنار آنها استفاده می شود. برای مثال ممکن است یک ابزار زیرساخت مورد نیاز را ایجاد کند و Ansible پس از آن پیکربندی سیستم عامل، نصب نرم افزار و آماده سازی سرورها را انجام دهد.
تفاوت Ansible و Terraform چیست؟
تفاوت Ansible و Terraform در هدف اصلی آنها است. Terraform بیشتر برای ایجاد و مدیریت منابع زیرساختی استفاده می شود، در حالی که Ansible بیشتر روی مدیریت پیکربندی، نصب نرم افزار و اتوماسیون عملیات روی سیستم ها تمرکز دارد. به همین دلیل این دو ابزار در بسیاری از پروژه های DevOps به جای رقابت مستقیم، در کنار یکدیگر استفاده می شوند.
Terraform یک ابزار Infrastructure as Code است که می تواند منابعی مانند ماشین مجازی، شبکه، Load Balancer، دیتابیس و سایر سرویس های Cloud را تعریف و ایجاد کند. زیرساخت در Terraform معمولا با زبان HCL تعریف می شود و Terraform وضعیت منابع را نیز مدیریت می کند.
در مقابل، Ansible بیشتر برای Configuration Management و Automation کاربرد دارد. پس از ایجاد سرور، Ansible می تواند نرم افزارهای مورد نیاز را نصب کند، فایل های پیکربندی را تغییر دهد، سرویس ها را راه اندازی کند و تنظیمات یکسانی را روی چندین سیستم اعمال کند.
برای مثال، در یک پروژه می توان ابتدا با Terraform چند ماشین مجازی و شبکه مورد نیاز را ایجاد کرد و سپس با Ansible روی همان سرورها Nginx، Docker یا سایر سرویس های مورد نیاز را نصب و پیکربندی کرد.
مقایسه Ansible و Terraform
اگر هدف اصلی پروژه ایجاد و مدیریت منابع Cloud و زیرساخت باشد، Terraform معمولا گزینه تخصصی تری است. اگر زیرساخت از قبل وجود داشته باشد و هدف نصب نرم افزار، مدیریت تنظیمات و خودکارسازی عملیات روی سرورها باشد، Ansible معمولا کاربرد مستقیم تری دارد.
برای آشنایی کامل تر با نحوه ایجاد زیرساخت با کد، می توانید مقاله Terraform چیست؟ را مطالعه کنید.
Ansible چه تفاوتی با Puppet و Chef دارد؟
Ansible، Puppet و Chef هر سه برای اتوماسیون IT و مدیریت پیکربندی استفاده می شوند، اما معماری و روش کار آنها با یکدیگر متفاوت است. یکی از تفاوت های مهم Ansible این است که در بسیاری از سناریوها به Agent اختصاصی روی سرورهای مقصد نیاز ندارد، در حالی که Puppet و Chef در معماری های کلاسیک خود معمولا از Agent یا Client روی سیستم های مدیریت شده استفاده می کنند.
Ansible از Playbook های YAML استفاده می کند که معمولا خوانایی بالایی دارند و برای تعریف Task های اتوماسیون مناسب هستند. این موضوع باعث می شود شروع کار با Ansible برای بسیاری از مدیران سیستم و تیم های DevOps ساده تر باشد.
Puppet بیشتر بر تعریف وضعیت مطلوب سیستم با یک مدل Declarative تمرکز دارد. مدیر زیرساخت مشخص می کند سیستم باید در چه وضعیتی قرار داشته باشد و Puppet تلاش می کند آن وضعیت را حفظ کند.
Chef نیز ابزار قدرتمندی برای Configuration Management است، اما در بسیاری از سناریوها تنظیمات آن با DSL مبتنی بر Ruby تعریف می شوند. به همین دلیل استفاده حرفه ای از Chef می تواند نسبت به Playbook های ساده Ansible نیازمند آشنایی بیشتری با ساختار برنامه نویسی باشد.
Ansible، Puppet یا Chef؛ کدام مناسب تر است؟
انتخاب میان این ابزارها به معماری زیرساخت، تجربه تیم و پیچیدگی پروژه بستگی دارد. Ansible معمولا زمانی انتخاب مناسبی است که سادگی، معماری Agentless و اتوماسیون سریع سرورها اهمیت داشته باشد. Puppet می تواند برای محیط هایی مناسب باشد که حفظ مداوم وضعیت پیکربندی سیستم ها اهمیت بالایی دارد و Chef نیز در زیرساخت هایی که تیم تجربه کافی با ساختار و اکوسیستم آن دارد همچنان قابل استفاده است.
بنابراین نمی توان یکی از این ابزارها را برای همه پروژه ها بهترین گزینه دانست. در عمل، برای انتخاب ابزار مدیریت پیکربندی باید عواملی مانند تعداد سرورها، سیستم عامل ها، مدل استقرار، مهارت تیم و نیازهای اتوماسیون بررسی شوند.
نقش Ansible در DevOps و CI/CD چیست؟
Ansible در DevOps برای خودکارسازی مدیریت پیکربندی، آماده سازی محیط و استقرار نرم افزار استفاده می شود و می تواند بخشی از فرایند CI/CD را تکمیل کند. در یک Pipeline، ابزارهای CI/CD معمولا وظایفی مانند دریافت کد، Build، اجرای Test و آماده سازی نسخه جدید را انجام می دهند و Ansible می تواند پس از آن برای پیکربندی سرورها و Deployment مورد استفاده قرار گیرد.
به عنوان مثال، بعد از اینکه نسخه جدید یک برنامه مراحل Build و Test را با موفقیت پشت سر گذاشت، Ansible می تواند مجموعه ای از عملیات را روی سرور مقصد انجام دهد؛ مانند:
- نصب یا به روز رسانی Package های مورد نیاز
- اعمال تنظیمات محیط Production
- انتقال یا آماده سازی فایل های برنامه
- مدیریت متغیرها و فایل های پیکربندی
- راه اندازی یا Restart سرویس ها
- اجرای مراحل استقرار روی چند سرور
به این ترتیب، بخشی از عملیات دستی که معمولا بعد از آماده شدن نسخه جدید انجام می شود نیز قابل خودکارسازی خواهد بود.
Ansible چگونه وارد Pipeline CI/CD می شود؟
در یک ساختار ساده، فرایند می تواند به شکل زیر باشد:
تغییر کد ← Build ← Test ← تایید نسخه ← اجرای Ansible ← Deployment و Configuration
ابزار CI/CD پس از موفقیت مراحل اولیه می تواند اجرای یک Ansible Playbook را فراخوانی کند. Playbook نیز مشخص می کند چه تغییراتی باید روی سرورهای مقصد اعمال شوند.
برای مثال، Pipeline می تواند بعد از موفقیت Test ها یک Playbook را اجرا کند که نسخه جدید برنامه را روی سرورهای Production قرار دهد، تنظیمات مورد نیاز را اعمال کند و سرویس برنامه را مجددا راه اندازی کند.
اگر با ساختار Pipeline آشنایی ندارید، مقاله CI/CD چیست؟ مفهوم Continuous Integration، Continuous Delivery و مراحل خودکار انتشار نرم افزار را به صورت کامل تر توضیح می دهد.
آیا Ansible جایگزین ابزارهای CI/CD است؟
ابزارهایی مانند GitLab CI یا GitHub Actions برای تعریف و اجرای Pipeline، Build، Test و Workflow های انتشار طراحی شده اند. Ansible در این ساختار بیشتر وظایف مرتبط با Configuration Management، آماده سازی سرور و Deployment را بر عهده می گیرد.
در نتیجه هر ابزار مسئول بخش متفاوتی از زنجیره اتوماسیون است و استفاده ترکیبی از آنها می تواند فرایند انتشار نرم افزار را منظم تر و قابل تکرارتر کند.
Terraform و Ansible چگونه در کنار هم استفاده می شوند؟
Terraform و Ansible می توانند دو مرحله متفاوت از مدیریت زیرساخت را پوشش دهند: Terraform منابع زیرساختی را ایجاد می کند و Ansible سیستم های ایجاد شده را پیکربندی و برای اجرای نرم افزار آماده می کند.
این ترکیب در پروژه های DevOps و Infrastructure as Code رایج است، زیرا ایجاد یک سرور تنها بخشی از فرایند آماده سازی زیرساخت محسوب می شود. پس از ایجاد سرور معمولا باید سیستم عامل پیکربندی شود، نرم افزارهای مورد نیاز نصب شوند و سرویس ها با تنظیمات مشخص اجرا شوند.
به صورت ساده:
Terraform ← ایجاد زیرساخت ← Ansible ← پیکربندی و آماده سازی سرورها
Terraform چه بخشی از کار را انجام می دهد؟
Terraform بیشتر برای Infrastructure Provisioning استفاده می شود. برای مثال می توان با آن منابعی مانند موارد زیر را تعریف و ایجاد کرد:
- ماشین مجازی
- شبکه و Subnet
- Load Balancer
- Storage
- Database
- منابع Cloud
Terraform وضعیت این منابع را مدیریت می کند و تلاش می کند زیرساخت واقعی با ساختاری که در فایل های Terraform تعریف شده است هماهنگ باشد.
Ansible بعد از Terraform چه کاری انجام می دهد؟
پس از ایجاد منابع، Ansible می تواند تنظیمات داخل سیستم ها را انجام دهد.
برای مثال بعد از اینکه Terraform سه ماشین مجازی ایجاد کرد، Ansible می تواند:
- Nginx را روی سرورها نصب کند.
- Docker یا سایر Package های مورد نیاز را نصب کند.
- فایل های Configuration را روی سیستم قرار دهد.
- کاربران و سطح دسترسی را تنظیم کند.
- سرویس برنامه را راه اندازی کند.
در این مدل، Terraform بیشتر مسئول ساخت زیرساخت و Ansible مسئول پیکربندی زیرساخت است.
یک سناریوی واقعی استفاده از Terraform و Ansible
فرض کنیم یک تیم قصد دارد چند وب سرور جدید در یک Cloud Provider راه اندازی کند.
ابتدا Terraform می تواند ماشین های مجازی، شبکه، Security Rule و Load Balancer مورد نیاز را ایجاد کند. بعد از آماده شدن منابع، اطلاعات سرورها در اختیار Ansible قرار می گیرد.
Ansible سپس Playbook مربوط به وب سرورها را اجرا می کند و مواردی مانند Nginx، Runtime برنامه، تنظیمات امنیتی و فایل های Configuration را روی آنها اعمال می کند.
در نتیجه کل فرایند از ایجاد منابع تا آماده شدن محیط اجرا می تواند تا حد زیادی خودکار و قابل تکرار شود.
آیا همیشه باید Terraform و Ansible را با هم استفاده کرد؟
خیر. استفاده همزمان از Terraform و Ansible زمانی منطقی است که پروژه هم به Provisioning زیرساخت و هم به Configuration Management نیاز داشته باشد.
اگر سرورها و زیرساخت از قبل وجود داشته باشند و فقط هدف مدیریت تنظیمات و اتوماسیون عملیات آنها باشد، ممکن است Ansible به تنهایی کافی باشد. از طرف دیگر، اگر هدف اصلی ایجاد و مدیریت منابع Cloud باشد و پیکربندی داخل سیستم ها نیاز پیچیده ای نداشته باشد، Terraform می تواند بخش عمده نیاز پروژه را پوشش دهد.
بنابراین انتخاب Ansible، Terraform یا ترکیب هر دو باید بر اساس نوع زیرساخت، مراحل استقرار و نیاز واقعی پروژه انجام شود.
Ansible برای چه پروژه هایی مناسب است؟
Ansible برای پروژه هایی مناسب است که در آنها مدیریت چند سرور، تکرار تنظیمات، استقرار نرم افزار یا انجام عملیات دستی زیرساخت به یک مشکل زمان بر تبدیل شده باشد. این ابزار به تیم ها اجازه می دهد وظایف تکراری را در قالب Playbook تعریف کنند و همان فرایند را به صورت قابل تکرار روی سیستم های مختلف اجرا کنند.
انتخاب Ansible فقط به تعداد سرورها بستگی ندارد. نوع عملیات، میزان تکرار تغییرات، ساختار محیط های Development و Production و نیاز تیم به اتوماسیون سرور و مدیریت پیکربندی نیز در این تصمیم تاثیر دارند.
Ansible مناسب است اگر چندین سرور را مدیریت می کنید
وقتی تعداد سرورها افزایش پیدا می کند، ورود جداگانه به هر سیستم برای نصب نرم افزار، تغییر تنظیمات یا راه اندازی سرویس ها هم زمان بیشتری نیاز دارد و هم احتمال ایجاد تفاوت بین سرورها را افزایش می دهد.
با استفاده از Inventory در Ansible می توان سرورها را گروه بندی کرد و یک عملیات مشخص را روی چند سیستم اجرا کرد. برای مثال می توان تمام Web Server ها را در یک گروه قرار داد و یک Playbook مشخص را روی همه آنها اجرا کرد. مستندات رسمی Ansible نیز Inventory را روشی برای سازماندهی Managed Node ها و اجرای عملیات روی گروه های مختلف معرفی می کند.
Ansible مناسب است اگر تنظیمات تکراری دارید
اگر تیم شما به طور مرتب کارهایی مانند نصب Package، مدیریت فایل های Configuration، ایجاد User، تغییر Permission یا راه اندازی سرویس ها را انجام می دهد، Ansible می تواند بخش قابل توجهی از این عملیات را خودکار کند.
در این شرایط به جای ثبت مراحل در یک فایل راهنما و اجرای دستی آنها، می توان مراحل را در Playbook تعریف کرد. در نتیجه فرایند قابل تکرارتر می شود و احتمال فراموش شدن یکی از مراحل کاهش پیدا می کند.
Ansible مناسب است اگر Deployment هنوز دستی انجام می شود
اگر انتشار نسخه جدید برنامه نیازمند ورود به سرور، نصب Dependency ها، تغییر Configuration و Restart کردن سرویس باشد، بخشی از Deployment را می توان با Ansible خودکار کرد.
این موضوع به خصوص زمانی اهمیت دارد که برنامه روی چند سرور اجرا می شود یا انتشارهای جدید به صورت مرتب انجام می شوند. Ansible از Deployment مداوم نرم افزار نیز به عنوان یکی از کاربردهای اصلی خود پشتیبانی می کند.
Ansible مناسب است اگر چند محیط مشابه دارید
بسیاری از پروژه ها دارای محیط هایی مانند Development، Testing، Staging و Production هستند. اگر تنظیمات این محیط ها به صورت دستی انجام شوند، به مرور ممکن است تفاوت هایی میان آنها ایجاد شود که عیب یابی و استقرار نرم افزار را دشوار کند.
Ansible می تواند بخش های مشترک Configuration را در قالب Playbook و Role تعریف کند و مقادیر مخصوص هر Environment را از طریق Variable ها مدیریت کند. به این ترتیب حفظ ساختار مشابه میان محیط های مختلف ساده تر می شود.
Ansible مناسب است اگر Configuration قابل تکرار می خواهید
یکی از مهم ترین کاربردهای Ansible، تعریف وضعیت مورد انتظار سیستم ها است. اگر یک Playbook مشخص کند Nginx باید نصب و سرویس آن فعال باشد، اجرای دوباره Playbook در حالت عادی نباید تغییر غیر ضروری ایجاد کند، به شرط آنکه Module و Task مورد استفاده رفتار Idempotent داشته باشند. این قابلیت یکی از اصول اصلی طراحی Ansible است.
به همین دلیل Ansible برای پروژه هایی که Configuration Management قابل تکرار و قابل کنترل می خواهند گزینه مناسبی است.
چه زمانی Ansible احتمالا اولویت اول نیست؟
Ansible ابزار قدرتمندی است، اما استفاده از آن برای هر پروژه ای ضروری نیست.
ممکن است Ansible اولویت اول شما نباشد اگر:
- فقط یک سرور ساده دارید و تغییرات آن بسیار محدود است.
- عملیات مدیریتی به ندرت انجام می شود و اتوماسیون آن ارزش عملی زیادی ایجاد نمی کند.
- هدف اصلی شما فقط ایجاد منابع Cloud و Infrastructure Provisioning است.
- نیاز پروژه با یک Script ساده و قابل نگهداری به شکل مناسب تری برطرف می شود.
- تیم شما در حال حاضر ابزار اتوماسیون دیگری دارد که نیازهای پروژه را به خوبی پوشش می دهد.
در نتیجه پاسخ به سوال «آیا Ansible برای پروژه من مناسب است؟» به این بستگی دارد که چه مقدار عملیات تکراری، Configuration و Deployment در زیرساخت وجود دارد. هرچه تعداد سیستم ها و میزان تکرار عملیات بیشتر شود، ارزش استفاده از اتوماسیون نیز معمولا بیشتر خواهد شد.
جمع بندی؛ آیا Ansible ابزار مناسبی برای شماست؟
Ansible یک ابزار متن باز برای اتوماسیون IT، مدیریت پیکربندی، استقرار نرم افزار و مدیریت سیستم های مختلف است. Playbook های YAML، معماری Agentless در بسیاری از سناریوها و امکان مدیریت گروهی از سرورها باعث شده اند Ansible به یکی از ابزارهای شناخته شده در اتوماسیون زیرساخت و DevOps تبدیل شود.
اگر تیم شما هنوز تنظیمات سرورها، نصب نرم افزار یا بخش هایی از Deployment را به صورت دستی انجام می دهد، استفاده از Ansible می تواند این فرایندها را قابل تکرارتر و مدیریت آنها را ساده تر کند. در پروژه های بزرگ تر نیز می توان Ansible را در کنار ابزارهایی مانند Terraform و سیستم های CI/CD به عنوان بخشی از زنجیره اتوماسیون DevOps استفاده کرد.
با این حال، انتخاب Ansible باید بر اساس نیاز واقعی پروژه انجام شود. اگر هدف اصلی مدیریت Configuration، اتوماسیون سرورها و اجرای عملیات مشابه روی چند سیستم باشد، Ansible می تواند انتخاب مناسبی باشد؛ اما اگر فقط قصد ایجاد منابع زیرساختی را دارید، ابزارهای تخصصی Infrastructure Provisioning ممکن است نقش اصلی تری داشته باشند.
اتوماسیون زیرساخت و فرایندهای DevOps
اگر برای مدیریت سرورها، خودکارسازی تنظیمات، استقرار نرم افزار یا پیاده سازی فرایندهای DevOps به یک ساختار پایدار و قابل مدیریت نیاز دارید، تیم سربروس می تواند متناسب با زیرساخت و نیاز پروژه شما راهکار مناسب را طراحی و پیاده سازی کند.
سوالات متداول درباره Ansible
Ansible چیست؟
Ansible یک ابزار متن باز برای اتوماسیون IT و مدیریت سیستم ها است. با استفاده از آن می توان کارهایی مانند مدیریت پیکربندی، نصب نرم افزار، Deployment و اجرای عملیات تکراری روی یک یا چند سرور را خودکار کرد. وظایف در Ansible معمولا در قالب Playbook های YAML تعریف می شوند.
آیا Ansible رایگان است؟
بله. Ansible و ansible-core پروژه های متن باز هستند و می توان از نسخه Community آنها استفاده کرد. در کنار پروژه متن باز Ansible، Red Hat محصولات تجاری مانند Ansible Automation Platform را نیز برای نیازهای سازمانی ارائه می کند.
آیا برای استفاده از Ansible باید Python بلد باشیم؟
برای شروع کار با Ansible معمولا نیازی به برنامه نویسی Python ندارید. Playbook ها با YAML نوشته می شوند و بسیاری از عملیات معمول را می توان با Module های آماده انجام داد.
با این حال، Ansible روی Control Node به Python وابسته است و بسیاری از Managed Node های مبتنی بر سیستم های POSIX نیز برای اجرای Module های معمول به Python نیاز دارند. یادگیری Python برای توسعه Module های اختصاصی یا انجام اتوماسیون های پیشرفته می تواند مفید باشد، اما پیش نیاز یادگیری Playbook نویسی نیست.
تفاوت Ansible و Terraform چیست؟
Terraform بیشتر برای ایجاد و مدیریت منابع زیرساختی استفاده می شود، در حالی که Ansible بیشتر روی مدیریت پیکربندی و اتوماسیون سیستم ها تمرکز دارد.
برای مثال Terraform می تواند ماشین مجازی و شبکه مورد نیاز را ایجاد کند و Ansible پس از آن نرم افزارها و تنظیمات مورد نیاز را روی سرورها اعمال کند. به همین دلیل این دو ابزار می توانند در یک پروژه DevOps در کنار یکدیگر استفاده شوند.
آیا Ansible روی Windows هم قابل استفاده است؟
بله. Ansible می تواند Windows را به عنوان Managed Node مدیریت کند. برای ارتباط با سیستم های Windows می توان از روش هایی مانند WinRM، PSRP یا SSH استفاده کرد و مجموعه ای از Module های مخصوص Windows نیز در دسترس است. بسیاری از این Module ها به جای Python با PowerShell کار می کنند.
