راهاندازی یک سرور معمولا کار دشواری نیست. اما وقتی تعداد سرورها از یکی به ده، صد یا حتی هزار سرور میرسد، اجرای دستی یک دستور ساده هم میتواند به کاری زمانبر و مستعد خطا تبدیل شود. نصب یک نرمافزار، ایجاد کاربر جدید، بهروزرسانی تنظیمات یا راهاندازی یک سرویس، اگر قرار باشد روی هر سرور جداگانه انجام شود، بهسرعت به یک چالش مدیریتی تبدیل خواهد شد.
اینجاست که مفهوم اتوماسیون اهمیت پیدا میکند. بهجای تکرار یک مجموعه دستور روی تکتک سرورها، کافی است یک بار آن را تعریف کنید تا همه سیستمها بهصورت خودکار همان مراحل را اجرا کنند. Ansible دقیقا با همین هدف طراحی شده است، ابزاری که مدیریت و پیکربندی سرورها را به فرآیندی قابل تکرار، سریع و قابل اعتماد تبدیل میکند.
در این مطلب با Ansible آشنا میشویم، نحوه عملکرد آن را بررسی میکنیم و یاد میگیریم چگونه میتوان با استفاده از Playbookها، بسیاری از وظایف تکراری مدیریت سرورها را تنها با چند دستور خودکار کرد.
Ansible چیست؟
انسیبل یک ابزار متنباز برای اتوماسیون زیرساخت، مدیریت پیکربندی (Configuration Management) و استقرار نرمافزار (Application Deployment) است. این ابزار به مدیران سیستم و تیمهای DevOps کمک میکند تا وظایف تکراری را بهجای اجرای دستی، بهصورت خودکار روی یک یا چندین سرور انجام دهند.
برای مثال، اگر بخواهید روی ۵۰ سرور وب، Nginx را نصب کنید، کاربر جدیدی ایجاد کنید یا فایلهای پیکربندی را بهروزرسانی کنید، نیازی نیست به هر سرور جداگانه متصل شوید. کافی است این عملیات را یک بار در Ansible تعریف کنید تا همان دستورها بهصورت خودکار روی همه سرورها اجرا شوند.
یکی از مهمترین ویژگیهای انسیبل، Agentless بودن آن است. بسیاری از ابزارهای مشابه نیاز دارند که روی تمام سرورهای مقصد یک Agent نصب شود، اما Ansible بدون نصب هیچ نرمافزار اضافی روی سرورها کار میکند. این ابزار معمولا از طریق SSH به سرورهای لینوکسی متصل میشود و دستورهای موردنظر را اجرا میکند. همین موضوع راهاندازی و نگهداری آن را سادهتر کرده است.
علاوه بر این، Ansible از فایلهایی با فرمت YAML برای تعریف وظایف استفاده میکند. این فایلها که Playbook نام دارند، خوانایی بالایی دارند و حتی افرادی که تجربه برنامهنویسی زیادی ندارند نیز میتوانند ساختار آنها را درک کنند.
بهدلیل همین سادگی، Ansible امروزه در بسیاری از پروژههای DevOps برای مدیریت سرورها، استقرار برنامهها، پیکربندی سرویسها، راهاندازی زیرساخت ابری و پیادهسازی Infrastructure as Code (IaC) مورد استفاده قرار میگیرد.
Ansible چگونه کار میکند؟
یکی از دلایل محبوبیت انسیبل، معماری ساده آن است. برخلاف بسیاری از ابزارهای مدیریت زیرساخت، برای استفاده از Ansible به اجزای پیچیده یا نصب نرمافزار روی تمام سرورها نیاز نیست. کافی است Ansible روی یک سیستم نصب شود تا بتواند سایر سرورها را مدیریت کند.

در این معماری، چند مفهوم اصلی وجود دارد که آشنایی با آنها درک نحوه عملکرد Ansible را بسیار سادهتر میکند.
۱. Control Node
نود کنترل سیستمی است که Ansible روی آن نصب میشود. تمام دستورها، Playbookها و فرآیندهای اتوماسیون از این ماشین اجرا میشوند. این سیستم میتواند لپتاپ توسعهدهنده، یک سرور مدیریتی یا ماشین اختصاصی تیم DevOps باشد.
۲. Managed Node
نود مدیریتشده به سرورها یا ماشینهایی گفته میشود که قرار است توسط انسیبل مدیریت شوند. این سرورها از طریق SSH در لینوکس یا WinRM در ویندوز در دسترس هستند. یکی از مزیتهای مهم Ansible این است که روی Managed Nodeها نیازی به نصب Agent وجود ندارد، کافی است دسترسی لازم برای اتصال فراهم باشد.
۳. Inventory
انسیبل باید بداند کدام سرورها را مدیریت کند. این اطلاعات در فایلی به نام Inventory نگهداری میشود. در این فایل میتوان سرورها را بر اساس نقش یا کاربرد دستهبندی کرد. برای مثال، سرورهای وب، دیتابیس یا کش هرکدام در گروه جداگانهای قرار میگیرند. این دستهبندی باعث میشود اجرای دستورها روی گروه مشخصی از سرورها بسیار ساده باشد.
۴. Module
تقریباً هر کاری که Ansible انجام میدهد، توسط یک ماژول انجام میشود. ماژولها واحدهای آمادهای هستند که وظایف مشخصی را اجرا میکنند.
برای مثال، ماژولهایی برای:
- نصب و حذف پکیجها
- کپی فایل
- مدیریت کاربران
- اجرای دستورهای Shell
- راهاندازی یا توقف سرویسها
- مدیریت داکر و کوبرنتیز
وجود دارد. توسعهدهنده در این حالت نیازی به نوشتن این قابلیتها از ابتدا ندارد و فقط ماژول مناسب را انتخاب میکند.
۵. Playbook
اگر Moduleها ابزارهای انجام کار باشند، Playbook برنامهای است که مشخص میکند این ابزارها با چه ترتیبی و روی کدام سرورها اجرا شوند. یک Playbook میتواند شامل دهها یا حتی صدها وظیفه باشد: از نصب نرمافزار و ایجاد کاربر گرفته تا راهاندازی کامل یک سرور جدید.
همین معماری ساده باعث شده است که Ansible بدون نیاز به زیرساخت پیچیده، بتواند از مدیریت چند سرور کوچک تا اتوماسیون صدها یا هزاران سرور را پوشش دهد.
نصب Ansible
برای شروع کار، ابتدا باید Ansible را روی Control Node نصب کنید. این سیستم همان ماشینی است که قرار است دستورها و Playbookها از روی آن اجرا شوند. Ansible از سیستمعاملهای مختلف پشتیبانی میکند، اما رایجترین محیط برای استفاده از آن، توزیعهای لینوکسی مانند اوبونتو است.
در Ubuntu، نصب Ansible با استفاده از مدیر بسته apt انجام میشود:
sudo apt update
sudo apt install ansible
پس از پایان نصب، میتوانید با اجرای دستور زیر مطمئن شوید که Ansible بهدرستی نصب شده است:
ansible --version
اگر نصب موفقیتآمیز باشد، اطلاعاتی مانند نسخه Ansible، نسخه Python و مسیر فایلهای پیکربندی نمایش داده میشود.
پیشنیازهای استفاده از Ansible
پیش از آنکه بتوانید سرورهای دیگر را مدیریت کنید، چند پیشنیاز باید فراهم باشد:
- Ansible روی Control Node نصب شده باشد.
- روی سرورهای مقصد، SSH فعال باشد (برای سیستمهای لینوکسی).
- کاربری که Ansible با آن متصل میشود، مجوز اجرای دستورهای موردنیاز را داشته باشد.
- ارتباط شبکهای بین Control Node و سرورهای مقصد برقرار باشد.
برای اطمینان از اینکه اتصال SSH بهدرستی برقرار است، میتوانید ابتدا بهصورت دستی به سرور متصل شوید:
ssh user@192.168.1.10
اگر این اتصال بدون مشکل برقرار شود، Ansible نیز میتواند از همان مسیر با سرور ارتباط برقرار کند. در مراحل بعد، این اتصال بهصورت خودکار انجام خواهد شد و دیگر نیازی به ورود دستی به تکتک سرورها نخواهد بود.
اولین دستور Ansible
پس از نصب انسیبل و برقراری ارتباط با سرورهای مقصد، میتوانید اولین دستور خود را اجرا کنید. یکی از سادهترین و پرکاربردترین دستورها، اجرای ماژول ping است.
ansible all -m ping
این دستور از سه بخش اصلی تشکیل شده است:
allمشخص میکند که دستور روی تمام سرورهای موجود در Inventory اجرا شود. اگر بخواهید فقط گروه خاصی از سرورها را هدف قرار دهید، میتوانید بهجایallنام همان گروه را بنویسید.-mمخفف Module است و مشخص میکند کدام ماژول باید اجرا شود.pingماژولی است که اتصال Ansible به سرورهای مقصد را بررسی میکند.
نکته مهم این است که ماژول ping مانند دستور ping در سیستمعامل، بستههای ICMP ارسال نمیکند. این ماژول تلاش میکند از طریق SSH به سرور متصل شود، یک ماژول کوچک پایتون را اجرا کند و مطمئن شود که ارتباط بین Control Node و Managed Node بهدرستی برقرار است.
اگر همه چیز بهدرستی پیکربندی شده باشد، خروجی مشابه زیر خواهید دید:
192.168.1.10 | SUCCESS => {
"changed": false,
"ping": "pong"
}
192.168.1.11 | SUCCESS => {
"changed": false,
"ping": "pong"
}
وجود عبارت SUCCESS نشان میدهد که Ansible توانسته به سرور متصل شود و ماژول را با موفقیت اجرا کند.
البته قدرت Ansible به ماژول ping محدود نمیشود. برای مثال، با چند دستور ساده میتوان نسخه سیستمعامل سرورها را مشاهده کرد:
ansible all -m setup -a "filter=ansible_distribution*"
یا همه سرورها را بهروزرسانی کرد:
ansible web -m apt -a "update_cache=yes"
این مثالها نشان میدهند که Ansible بهجای ورود دستی به هر سرور، میتواند یک دستور را بهطور همزمان روی دهها یا صدها سرور اجرا کند، قابلیتی که هسته اصلی اتوماسیون در این ابزار را تشکیل میدهد.
کار با Inventory
همانطور که گفته شد Inventory در سادهترین حالت، فهرستی از آدرس سرورها است. اما در عمل، سرورها بر اساس نقش یا وظیفه در گروههای مختلف سازماندهی میشوند. این کار باعث میشود مدیریت تعداد زیادی سرور سادهتر شود.
برای مثال، یک فایل Inventory میتواند به شکل زیر باشد:
[web]
192.168.1.10
192.168.1.11
[database]
192.168.1.20
[cache]
192.168.1.30
در این مثال:
- گروه web شامل دو وبسرور است.
- گروه database یک سرور دیتابیس را در خود دارد.
- گروه cache برای سرور کش استفاده میشود.
مزیت این ساختار زمانی مشخص میشود که بخواهید یک دستور را فقط روی گروه خاصی از سرورها اجرا کنید. برای مثال، اگر قصد داشته باشید فقط وبسرورها را بررسی کنید، کافی است بهجای all نام گروه را وارد کنید:
ansible web -m ping
Ansible تنها سرورهای موجود در گروه web را هدف قرار میدهد و سایر سرورها نادیده گرفته میشوند.
استفاده از نام میزبان و اطلاعات اتصال
در پروژههای واقعی، معمولا بهجای IP خام، از نام میزبان (Host Name) استفاده میشود و اطلاعات اتصال نیز در همان فایل تعریف میشود.
برای مثال:
[web]
web-01 ansible_host=192.168.1.10
web-02 ansible_host=192.168.1.11
[database]
db-01 ansible_host=192.168.1.20
در این حالت، دستورها با نامهایی مانند web-01 یا db-01 اجرا میشوند که خوانایی بیشتری نسبت به IP دارند.
Inventory فقط یک فایل متنی نیست
اگرچه بسیاری از پروژههای کوچک از یک فایل متنی ساده استفاده میکنند، اما در زیرساختهای بزرگ، Inventory میتواند بهصورت پویا (Dynamic Inventory) تولید شود. برای مثال، Ansible میتواند به سرویسهای ابری مانند AWS، آژور یا Google Cloud متصل شود و فهرست سرورهای فعال را بهصورت خودکار دریافت کند. به این ترتیب، با اضافه یا حذف شدن ماشینها، نیازی به ویرایش دستی Inventory نخواهد بود.
به همین دلیل، Inventory را میتوان دفترچه راهنمای Ansible برای شناسایی سرورها دانست. تمام Playbookها و دستورهای Ansible بر اساس اطلاعات موجود در این بخش تصمیم میگیرند که کدام ماشینها باید مدیریت شوند.
Playbook چیست؟
اگر بخواهید فقط یک دستور روی چند سرور اجرا کنید، اجرای مستقیم یک Module کافی است. اما در پروژههای واقعی چندین مرحله باید بهترتیب انجام شوند، برای مثال نصب یک نرمافزار، ایجاد فایل پیکربندی، راهاندازی سرویس و در نهایت بررسی وضعیت آن. مدیریت این مراحل با دستورهای جداگانه هم زمانبر است و هم احتمال خطا را افزایش میدهد.
اینجاست که Playbook وارد عمل میشود.
Playbook فایلی با فرمت YAML است که مشخص میکند Ansible چه کارهایی را، روی کدام سرورها و با چه ترتیبی انجام دهد. به بیان دیگر، Playbook مانند یک سناریوی اجرایی است که تمام مراحل موردنیاز را در خود نگه میدارد و هر بار دقیقا همان مراحل را تکرار میکند.
نمونه زیر یک Playbook ساده برای نصب Nginx روی تمام وبسرورها است:
- hosts: web
become: yes
tasks:
- name: Install Nginx
apt:
name: nginx
state: present
در این Playbook:
hostsمشخص میکند این عملیات روی گروه web اجرا شود.become: yesدستورات را با دسترسی Administrator (یاsudo) اجرا میکند.- بخش
tasksفهرست کارهایی است که باید انجام شوند. nameتوضیحی برای همان مرحله است تا هنگام اجرا مشخص باشد چه کاری در حال انجام است.- ماژول
aptوظیفه نصب بسته را بر عهده دارد. - مقدار
state: presentتضمین میکند که Nginx روی سرور نصب باشد.
یکی از ویژگیهای مهم Playbookها، ویژگی Idempotency است. یعنی اگر همین Playbook را چندین بار اجرا کنید، نتیجه هر بار یکسان خواهد بود. برای مثال، اگر Nginx از قبل نصب شده باشد، Ansible دوباره آن را نصب نمیکند و فقط بررسی میکند که وضعیت موردنظر برقرار است.
برای اجرای Playbook نیز کافی است دستور زیر را اجرا کنید:
ansible-playbook install-nginx.yml
در پروژههای واقعی، Playbookها میتوانند دهها یا حتی صدها Task داشته باشند. برای مثال، یک Playbook ممکن است این مراحل را بهترتیب انجام دهد:
- بهروزرسانی بستههای سیستم
- نصب Nginx
- ایجاد کاربر جدید
- کپی فایلهای پیکربندی
- راهاندازی یا Restart سرویس
- باز کردن پورتهای Firewall
- بررسی سلامت سرویس پس از استقرار
همین قابلیت باعث شده است که Playbookها به یکی از مهمترین اجزای Ansible تبدیل شوند. بسیاری از تیمهای DevOps تمام فرآیندهای استقرار و مدیریت زیرساخت خود را در قالب Playbookها نگهداری میکنند تا هر زمان که لازم باشد، همان عملیات با دقت و ترتیب یکسان اجرا شود.
مزایا و محدودیتهای Ansible
Ansible یکی از سادهترین ابزارهای اتوماسیون زیرساخت است، اما مانند هر ابزار دیگری، نقاط قوت و محدودیتهای خاص خود را دارد. شناخت این موارد کمک میکند مشخص شود که آیا Ansible برای یک پروژه خاص انتخاب مناسبی است یا خیر.
مزایای Ansible
- راهاندازی آسان: برای شروع کار با Ansible فقط کافی است آن را روی Control Node نصب کنید. به دلیل Agentless بودن، نیازی به نصب نرمافزار اضافی روی سرورهای مقصد وجود ندارد.
- یادگیری ساده: Playbookهای Ansible با فرمت YAML نوشته میشوند و ساختار خوانایی دارند. همین موضوع باعث میشود افراد با تجربه کمتر در حوزه برنامهنویسی نیز بتوانند آنها را یاد بگیرند.
- اتوماسیون قابل تکرار: وظایفی مانند نصب نرمافزار، تنظیمات سرور و استقرار برنامهها میتوانند یکبار تعریف شوند و هر زمان با همان نتیجه اجرا شوند.
- کاهش خطاهای انسانی: اجرای دستی دستورها روی تعداد زیادی سرور احتمال اشتباه را افزایش میدهد. Ansible این فرآیندها را استاندارد کرده و خطاهای ناشی از عملیات دستی را کاهش میدهد.
- متنباز بودن و جامعه کاربری گسترده: Ansible دارای هزاران Module و Role آماده است که برای مدیریت سرویسها و زیرساختهای مختلف استفاده میشوند.
- پشتیبانی از محیطهای مختلف: این ابزار میتواند سرورهای لینوکسی، ویندوزی، سرویسهای ابری، تجهیزات شبکه و محیطهای مبتنی بر کانتینر را مدیریت کند.
محدودیتهای Ansible
- وابستگی به ارتباط شبکه: Ansible برای اجرای دستورات به اتصال SSH یا WinRM نیاز دارد. مشکلات شبکه یا تنظیمات نادرست دسترسی میتواند اجرای عملیات را متوقف کند.
- محدودیت در مقیاسهای بسیار بزرگ: در محیطهایی با هزاران سرور، اجرای همه عملیات از یک Control Node ممکن است به بهینهسازی یا معماریهای پیشرفتهتر نیاز داشته باشد.
- عدم مناسب بودن برای عملیات Real-time: انسیبل برای اتوماسیون وظایف و مدیریت پیکربندی طراحی شده است، نه پردازشهای لحظهای یا نظارت مداوم.
- نیاز به ساختاردهی مناسب در پروژههای بزرگ: با افزایش تعداد Playbookها، بدون استفاده از Roleها و استانداردهای مناسب، مدیریت کدهای Ansible میتواند دشوار شود.
- کنترل محدودتر نسبت به برخی ابزارهای مدیریت پیکربندی: در برخی سناریوهای پیچیده، ابزارهایی که معماری Agent-based دارند ممکن است کنترل بیشتری روی وضعیت دائمی سیستم ارائه دهند.
در مجموع، Ansible برای بسیاری از سناریوهای DevOps مانند مدیریت سرورها، استقرار برنامهها و خودکارسازی زیرساخت، تعادل مناسبی بین سادگی و قدرت ارائه میدهد.
Ansible در مقایسه با Puppet و Chef
در حوزه مدیریت پیکربندی و اتوماسیون زیرساخت، Ansible تنها گزینه موجود نیست. ابزارهایی مانند Puppet و Chef نیز سالها در این حوزه استفاده شدهاند و هرکدام رویکرد متفاوتی برای مدیریت سرورها دارند.
تفاوت اصلی این ابزارها در معماری، روش تعریف تنظیمات و تجربه کار با آنها است.
Ansible
Ansible بیشتر به دلیل سادگی و معماری Agentless شناخته میشود. برای مدیریت سرورها از SSH استفاده میکند و نیازی به نصب Agent روی ماشینهای مقصد ندارد.
ویژگیهای مهم Ansible:
- استفاده از YAML برای نوشتن Playbookها
- یادگیری سریعتر
- مناسب برای تیمهای DevOps
- مناسب برای استقرار برنامه و مدیریت پیکربندی
- نیاز کمتر به نگهداری زیرساخت مدیریتی
Puppet
Puppet یکی از قدیمیترین ابزارهای مدیریت پیکربندی است و بیشتر بر مفهوم Desired State یا وضعیت مطلوب تمرکز دارد، یعنی مدیر سیستم مشخص میکند وضعیت نهایی سرور چگونه باشد و Puppet تلاش میکند همیشه آن وضعیت را حفظ کند.
ویژگیهای مهم Puppet:
- معماری Agent-based
- نیاز به نصب Agent روی سرورها
- استفاده از زبان اختصاصی Puppet DSL
- مناسب برای زیرساختهای بزرگ و پایدار
- تمرکز قوی روی حفظ وضعیت سیستم
Chef
Chef نیز مانند Puppet بر مدیریت پیکربندی تمرکز دارد، اما رویکرد آن بیشتر به توسعه نرمافزار نزدیک است. در Chef تنظیمات سرور با استفاده از Ruby نوشته میشوند که انعطاف بیشتری ایجاد میکند.
ویژگیهای مهم Chef:
- استفاده از Ruby برای تعریف تنظیمات
- انعطافپذیری بالا
- مناسب برای تیمهایی با تجربه برنامهنویسی
- امکان ایجاد منطقهای پیچیده در Configuration
کدام ابزار را انتخاب کنیم؟
برای بسیاری از پروژههای جدید، Ansible به دلیل سادگی، سرعت راهاندازی و عدم نیاز به Agent، انتخاب محبوبتری است. تیمهایی که میخواهند سریعتر اتوماسیون را شروع کنند، با Ansible مسیر سادهتری خواهند داشت.
Puppet و Chef بیشتر در سازمانهایی دیده میشوند که سالها از این ابزارها استفاده کردهاند و زیرساختهای بسیار بزرگ و پایدار دارند.
انتخاب نهایی به نیاز پروژه بستگی دارد:
- اگر سادگی، سرعت توسعه و مدیریت آسان اهمیت دارد در نتیجه Ansible گزینه مناسبی است.
- اگر حفظ وضعیت دائمی هزاران سرور اولویت اصلی است در نتیجه Puppet میتواند انتخاب مناسبی باشد.
- اگر نیاز به منطق پیچیده در پیکربندی زیرساخت وجود دارد در نتیجه Chef انعطاف بیشتری ارائه میدهد.
با وجود این تفاوتها، هر سه ابزار یک هدف مشترک دارند: کاهش عملیات دستی و تبدیل مدیریت زیرساخت به فرآیندی قابل تکرار و خودکار.
جمعبندی
Ansible ابزاری برای تبدیل مدیریت دستی سرورها به فرآیندی خودکار، قابل تکرار و قابل اعتماد است. بهجای اجرای دستورات مشابه روی چندین سرور، میتوان وظایف موردنظر را در قالب Playbook تعریف کرد و آنها را با یک دستور روی تمام سیستمهای هدف اجرا کرد.
در این مطلب دیدیم که Ansible با معماری ساده و بدون نیاز به نصب Agent روی سرورهای مقصد، امکان مدیریت پیکربندی، استقرار نرمافزار، راهاندازی زیرساخت و اجرای عملیات DevOps را فراهم میکند. مفاهیمی مانند Inventory، ماژول و Playbook پایه اصلی کار با این ابزار را تشکیل میدهند.
اگرچه Ansible برای تمام سناریوهای زیرساختی بهترین گزینه نیست، اما برای بسیاری از تیمها که به دنبال کاهش کارهای تکراری، استانداردسازی سرورها و پیادهسازی Infrastructure as Code هستند، یکی از کاربردیترین ابزارهای موجود محسوب میشود.
یادگیری Ansible برای افرادی که قصد ورود به مسیر DevOps را دارند، یک مهارت ارزشمند است، زیرا درک اتوماسیون زیرساخت و مدیریت سرورها، بخش مهمی از فرآیند توسعه و نگهداری نرمافزارهای مدرن را تشکیل میدهد.
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید