Ansible چیست؟ آموزش Playbook و Inventory برای مدیریت سرورها

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

در این راهنما یک سناریوی واقعی و کوچک می‌سازیم: Ansible روی WSL نقش Control Node را دارد، دو سرور لینوکسی در Inventory تعریف می‌شوند و یک Playbook، Nginx را نصب و فعال می‌کند. سپس با Check Mode، خروجی اجرا و چند کنترل امنیتی مطمئن می‌شویم اتوماسیون قابل اعتماد است.

Ansible چیست و چرا Agentless بودن مهم است؟

Ansible یک ابزار متن‌باز اتوماسیون است که برای مدیریت پیکربندی، استقرار نرم‌افزار و اجرای عملیات تکراری استفاده می‌شود. شما وضعیت مطلوب را در Playbook می‌نویسید و Ansible از Control Node به Managed Nodeها متصل می‌شود. برای سناریوهای معمول لینوکس، ارتباط بر پایه SSH است و لازم نیست سرویس دائمی Ansible را روی هر سرور نصب کنید.

Agentless بودن، سربار نگهداری را کم می‌کند؛ اما به معنی بدون پیش‌نیاز بودن نیست. Control Node باید محیط پشتیبانی‌شده و Python داشته باشد. Managed Node لینوکسی نیز معمولاً به حساب کاربری قابل اتصال، SSH و Python نیاز دارد. کیفیت مدیریت کلیدها، سطح دسترسی و Inventory مستقیماً بر امنیت کل سامانه اثر می‌گذارد.

چه چیزهایی را با Ansible خودکار کنیم؟

• نصب و به‌روزرسانی بسته‌های سیستم‌عامل روی گروهی از سرورها
• ساخت کاربر، کلید SSH، پوشه و Permission به‌شکل یکسان
• تولید فایل تنظیمات از Template و Restart کنترل‌شده سرویس
• استقرار نسخه برنامه و اجرای Health Check پس از انتشار
• اجرای Rolling Update با محدودکردن تعداد میزبان‌های هم‌زمان

اگر مسئله شما ساخت منابع ابری است، Terraform معمولاً نقطه شروع مناسب‌تری است؛ Ansible بیشتر در پیکربندی سیستم و عملیات پس از آماده‌شدن زیرساخت می‌درخشد. این دو ابزار می‌توانند مکمل هم باشند.

Playbook در Ansible چیست؟ Inventory، Task و Module

در Playbook بهتر است نام کامل ماژول یا FQCN را بنویسید؛ برای مثال ansible.builtin.service. این کار منشأ ماژول را روشن می‌کند و هنگام اضافه‌شدن Collectionها از ابهام جلوگیری می‌کند.

نصب Ansible روی ویندوز با WSL

طبق مستندات رسمی، ویندوز بدون WSL به‌صورت بومی Control Node پشتیبانی نمی‌شود. بنابراین در ویندوز 10 یا 11 یک توزیع Ubuntu در WSL آماده کنید و فرمان‌های Ansible را داخل همان Shell اجرا کنید. خود ویندوز یا سرورهای Windows می‌توانند Managed Node باشند، اما اتصال آن‌ها معمولاً به WinRM یا PowerShell remoting و تنظیمات جداگانه نیاز دارد؛ مثال این مقاله برای میزبان‌های لینوکسی است.

sudo apt updatesudo apt install -y pipx openssh-clientpipx ensurepathpipx install --include-deps ansibleexec $SHELL -lansible --versionansible-community --version

بسته کامل ansible علاوه بر ansible-core مجموعه‌ای از Collectionهای منتخب را در اختیار می‌گذارد. اگر محیط کمینه و کنترل دقیق وابستگی‌ها می‌خواهید، pipx install ansible-core را انتخاب و Collectionهای لازم را جداگانه و با نسخه مشخص نصب کنید. خروجی ansible --version مسیر فایل تنظیمات، نسخه Core و Python را نشان می‌دهد و برای عیب‌یابی مهم است.

اتصال امن SSH پیش از ساخت Inventory

ابتدا بیرون از Ansible اتصال SSH را سالم کنید. روی Control Node یک کلید اختصاصی بسازید، کلید عمومی را روی حساب محدودشده سرور قرار دهید و Fingerprint میزبان را با کانالی مستقل تأیید کنید. خاموش‌کردن بررسی Host Key راه‌حل مناسبی برای خطای اتصال نیست؛ این بررسی از اتصال ناخواسته به میزبان جعل‌شده جلوگیری می‌کند.

mkdir -p ~/.sshchmod 700 ~/.sshssh-keygen -t ed25519 -a 64 -f ~/.ssh/ansible_labssh-copy-id -i ~/.ssh/ansible_lab.pub deploy@192.0.2.50ssh -i ~/.ssh/ansible_lab deploy@192.0.2.50

آدرس‌های محدوده 192.0.2.0/24 در این مقاله نمونه مستنداتی هستند و باید با IP خصوصی یا FQDN واقعی خودتان جایگزین شوند. از قرار دادن Private Key داخل مخزن، پوشه اشتراکی یا متن Playbook خودداری کنید. اگر کلید Passphrase دارد، از ssh-agent استفاده کنید تا رمز در فایل یا فرمان ثبت نشود.

ساخت Inventory خوانا و قابل توسعه

Inventory به Ansible می‌گوید چه میزبان‌هایی وجود دارند، در کدام گروه قرار می‌گیرند و اتصال به آن‌ها با چه کاربری انجام می‌شود. برای آزمایش کوچک، قالب INI ساده و خواناست. فایل زیر را با نام inventory.ini ذخیره کنید.

[webservers]web-01 ansible_host=192.0.2.50web-02 ansible_host=192.0.2.51 [webservers:vars]ansible_user=deployansible_ssh_private_key_file=~/.ssh/ansible_labansible_python_interpreter=/usr/bin/python3

نام مستعار مانند web-01 باعث می‌شود Playbook به IP وابسته نباشد. متغیرهای عمومی اتصال را در سطح گروه قرار دهید و رمز عبور، Token یا کلید خصوصی را در Inventory ننویسید. در محیط‌های بزرگ‌تر، Inventory به قالب YAML یا Dynamic Inventory مهاجرت می‌کند و متغیرها در ساختار group_vars و host_vars تفکیک می‌شوند.

اعتبارسنجی Inventory و تست Ping

ansible-inventory -i inventory.ini --graphansible-inventory -i inventory.ini --listansible webservers -i inventory.ini -m ansible.builtin.ping

ماژول Ping، ICMP Ping معمولی نیست؛ ورود، اجرای Python و پاسخ ماژول را می‌آزماید. خروجی pong با changed: false یعنی مسیر پایه آماده است. اگر UNREACHABLE دیدید، قبل از تغییر Playbook، DNS، Port، کاربر، کلید و Host Key را بررسی کنید.

نوشتن نخستین Playbook تکرارپذیر برای Nginx

Playbook زیر Cache بسته‌ها را فقط در صورت قدیمی‌بودن تازه می‌کند، Nginx را در وضعیت نصب‌شده نگه می‌دارد، سرویس را فعال می‌کند و در پایان از خود میزبان پاسخ HTTP می‌گیرد. استفاده از ماژول‌های تخصصی به‌جای اجرای خام apt یا systemctl به Ansible اجازه می‌دهد وضعیت فعلی را بفهمد.

---- name: Configure web servers  hosts: webservers  become: true  serial: 1  tasks:    - name: Install Nginx      ansible.builtin.apt:        name: nginx        state: present        update_cache: true        cache_valid_time: 3600     - name: Enable and start Nginx      ansible.builtin.service:        name: nginx        enabled: true        state: started     - name: Verify local HTTP response      ansible.builtin.uri:        url: http://127.0.0.1        status_code: 200

گزینه become: true برای Taskهای مدیریتی از افزایش سطح دسترسی استفاده می‌کند. حساب deploy نباید دسترسی نامحدود و بدون کنترل داشته باشد. در Production، فرمان‌های مجاز را محدود، گزارش‌های sudo را فعال و سیاست سازمان را رعایت کنید. serial: 1 نیز میزبان‌ها را یکی‌یکی تغییر می‌دهد تا خطا هم‌زمان کل گروه را تحت تأثیر قرار ندهد.

اجرای امن: Syntax Check، Check Mode و Limit

پیش از اجرای واقعی، نحو فایل را بررسی کنید. سپس روی یک میزبان آزمایشی و در حالت پیش‌نمایش اجرا کنید. Check Mode تضمین نمی‌کند همه Moduleها تغییرات را کامل شبیه‌سازی کنند، اما برای یافتن بخش بزرگی از خطاها و تغییرات ناخواسته مفید است.

ansible-playbook -i inventory.ini nginx.yml --syntax-checkansible-playbook -i inventory.ini nginx.yml --check --diff --limit web-01ansible-playbook -i inventory.ini nginx.yml --limit web-01ansible-playbook -i inventory.ini nginx.ymlansible-playbook -i inventory.ini nginx.yml --check

اجرای پنجم باید در حالت عادی بیشتر Taskها را با وضعیت ok و بدون تغییر نشان دهد. این همان آزمون عملی Idempotence است: وقتی وضعیت سیستم مطابق Playbook است، اجرای دوباره نباید هر بار تغییر تازه‌ای ایجاد کند. اگر Task همیشه Changed می‌شود، Module و پارامترهای آن را بازبینی کنید.

رمزها و داده‌های حساس را کجا نگه داریم؟

متغیر حساس را داخل Inventory، Playbook یا Git به‌صورت متن ساده قرار ندهید. Ansible Vault می‌تواند فایل یا متغیر را رمزگذاری کند، اما رمز Vault نیز باید بیرون از مخزن و در Secret Manager یا فرایند امن CI نگهداری شود. Vault داده در حالت ذخیره‌شده را محافظت می‌کند؛ پس از رمزگشایی در زمان اجرا، باید Log، سطح دسترسی و مقصد متغیر را نیز کنترل کنید.

ansible-vault create group_vars/webservers/vault.ymlansible-vault view group_vars/webservers/vault.ymlansible-playbook -i inventory.ini nginx.yml --ask-vault-pass

برای Taskهایی که احتمال چاپ مقدار حساس دارند، no_log: true را آگاهانه به‌کار ببرید. این گزینه جای مدیریت Secret نیست و عیب‌یابی را سخت‌تر می‌کند، اما از ثبت مقدار در خروجی جلوگیری می‌کند. فایل رمزگذاری‌شده را می‌توان نسخه‌بندی کرد، ولی Password Vault نباید کنار آن باشد.

خطاهای رایج و مسیر تشخیص

برای جزئیات اتصال، فرمان را با -vvv اجرا کنید؛ ولی خروجی Verbose ممکن است مسیرها و داده‌های محیطی را آشکار کند، پس آن را بدون بازبینی عمومی نکنید. ابتدا کوچک‌ترین گروه را با --limit هدف بگیرید و سپس دامنه اجرا را گسترش دهید.

تفاوت Ansible با Docker و Kubernetes چیست؟

Ansible می‌تواند Runtime، فایل تنظیمات یا Agent مانیتورینگ را روی سرورها آماده کند؛ Docker برنامه را در Container اجرا می‌کند و Kubernetes Workloadهای کانتینری را در کلاستر هماهنگ می‌کند. برای شناخت لایه ارکستریشن، آموزش Kubernetes و Minikube در ویندوز را بخوانید. برای یک استقرار تک‌میزبانه کانتینری نیز راهنمای نصب امن n8n با Docker Compose نمونه مناسبی است.

در CI بهتر است نسخه Ansible و Collectionها قفل شود، Syntax Check و Lint قبل از اجرا انجام شود، Credentialها از Secret Store تزریق شوند و انتشار Production به Approval و Audit Log متصل باشد. اجرای موفق روی لپ‌تاپ به‌تنهایی معیار آمادگی Production نیست.

چک‌لیست آماده‌سازی برای Production

1. میزبان‌ها بر اساس محیط و نقش گروه‌بندی شده‌اند و نام‌ها معنا دارند.
2. اتصال SSH با کلید اختصاصی، Host Key Verification و حساب کم‌اختیار انجام می‌شود.
3. نسخه Ansible، Collectionها و وابستگی‌های Python مشخص و قابل بازتولید هستند.
4. Secretها رمزگذاری شده‌اند و کلید رمزگشایی خارج از Git نگهداری می‌شود.
5. Playbook ابتدا در Syntax Check، Check Mode و محیط Staging آزمایش می‌شود.
6. تغییرات با serial یا محدودیت Batch کنترل و Rollback از قبل تعریف شده است.
7. خروجی اجرا، مالک تغییر و زمان اجرا برای Audit ثبت می‌شود.
8. Health Check پس از تغییر انجام می‌شود و شکست آن انتشار را متوقف می‌کند.

جمع‌بندی

Ansible زمانی بیشترین ارزش را دارد که یک کار تکراری و حساس را از حافظه افراد به یک تعریف نسخه‌پذیر منتقل کند. مسیر درست از اتصال امن و Inventory کوچک شروع می‌شود، با Playbook مبتنی بر Module ادامه پیدا می‌کند و پیش از گسترش دامنه، با Check Mode و اجرای محدود سنجیده می‌شود.

همین امروز دو میزبان آزمایشی را در Inventory ثبت کن، Playbook را ابتدا با Check Mode اجرا کن و نتیجه اجرای دوم را برای سنجش Idempotence بررسی کن.

منابع رسمی

• Introduction to Ansible
• Installing Ansible
• Building an inventory
• Creating a playbook
• Connection methods and details
• Protecting sensitive data with Ansible Vault