Ansible  • 3 мая 2025 • 10 мин чтения

Ansible — инструмент, который избавляет от рутины в работе с серверами. Вместо ручной настройки — чёткие инструкции в виде сценариев. Эти сценарии называются Ansible-playbook. Они задают последовательность шагов, которые система выполнит на удалённых машинах.

Плейбук — это не магия. Это обычный YAML-файл, в котором по пунктам описано: что нужно установить, какие сервисы запустить, какие конфигурации применить. Такой подход позволяет автоматизировать всё — от простой установки nginx до настройки сложной кластерной среды.

Пример из жизни. Сисадмин настраивает 20 серверов. Без Ansible он подключается по SSH к каждому, вводит команды, следит за логами. С Ansible — он запускает один плейбук, и всё делает автоматом. Ошибок меньше, времени уходит в разы меньше.

Вот базовый пример простого плейбука:

- name: Установка Nginx на веб-серверы
hosts: webservers
become: true
tasks:
- name: Установить Nginx
apt:
name: nginx
state: present

Что здесь происходит:

• hosts — на какие машины нацелен сценарий.
• become: true — нужен доступ суперпользователя.
• tasks — список задач: в этом случае — установка nginx.

Такой сценарий можно переиспользовать, изменять, хранить в Git и применять в любой момент. А главное — Ansible-playbook не делает лишнего. Он проверяет, нужно ли что-то менять. Если всё уже в нужном состоянии — просто пропускает задачу. Это называется идемпотентностью.

В этом и сила Ansible: управляем серверами так же чётко, как пишем код. Именно это и называют подходом «инфраструктура как код»‎ — понятным, версионируемым, надёжным.

🔹 Узнайте, с чего начать работу с Ansible на курсе от Слёрм. Вы научитесь создавать, использовать плейбуки и роли, освоите деплой приложений, получите навыки автоматизации процессов управления IT-инфраструктурой. Начать обучение можно с бесплатным доступом.

Что такое плейбук в Ansible и как им пользоваться? Плейбук — это не набор случайных команд. Это чётко структурированный документ, в котором всё построено по строгим правилам. Его читают сверху вниз, как обычный сценарий. Каждая часть плейбука отвечает за определённый этап настройки.

Вот ключевые элементы Ansible-playbook:

• name: человекочитаемое описание цели. Не обязательно, но помогает понять, что делает сценарий.
• hosts: список целевых серверов или групп. Указывается имя из файла инвентаризации.
• become: если нужно выполнять команды от имени root.
• vars: переменные, используемые в задачах.
• tasks: основная часть, где описываются действия.
• handlers: триггеры, которые запускаются только по уведомлению, например, для перезапуска сервисов.
• roles: подключение предварительно организованных наборов конфигураций.

Пример шаблона плейбука:
- name: Настройка веб-сервера
hosts: web
become: true
vars:
nginx_port: 8080
tasks:
- name: Установить Nginx
apt:
name: nginx
state: present
- name: Убедиться, что Nginx запущен
service:
name: nginx
state: started
handlers:
- name: Перезапустить Nginx
service:
name: nginx
state: restarted

🧩 Что важно:

• Каждое действие — это task. Он вызывает модуль, например apt, service или copy.
• Если в задаче указано notify, и задача изменила состояние системы — сработает соответствующий handler.
• Использование переменных ({{ nginx_port }}) делает плейбук гибким и удобным для разных окружений.

Всё это превращает YAML-файл в мощный инструмент автоматизации, читаемый как текст и исполняемый как код. Такой сценарий легко адаптировать, расширять и применять на новых машинах, не меняя суть конфигурации.

Дальше — разберём ключевые строительные блоки: play, task и модули, на которых держится вся магия.

Ансибл плейбук состоит из одного или нескольких play — логических блоков, которые описывают, что делать с группой серверов. А каждый play включает tasks — пошаговые действия, которые выполняет Ansible.

🔸 Play — это как глава сценария. Она задаёт:

• на какие машины отправлять команды (hosts);
• нужно ли использовать sudo (become);
• какие переменные применить (vars);
• какие роли или задачи подключить.

🔸 Task — это инструкция: «‎установить пакет»‎, «‎запустить сервис»‎, «‎скопировать файл»‎. Ansible выполняет их по порядку.

Каждый task вызывает модуль — встроенный компонент Ansible, который делает конкретную работу.

Вот пример задачи с модулем copy:

- name: Скопировать конфиг Nginx
copy:
src: ./nginx.conf
dest: /etc/nginx/nginx.conf
notify: Перезапустить Nginx

Если nginx.conf на сервере изменится, будет отправлено уведомление на handler с именем Перезапустить Nginx.

📦 Часто используемые модули:

• apt, yum — установка пакетов.
• copy, template — работа с файлами.
• service — управление службами.
• command, shell — запуск произвольных команд.
• file — изменение прав, владельцев и атрибутов файлов.

🔁 Все задачи работают идемпотентно. Это значит: если сервер уже в нужном состоянии, Ansible не будет ничего менять. Это снижает риски и делает сценарии безопасными для повторного запуска.

Плейбуки заменяют ручную настройку и shell-скрипты. Они точнее, прозрачнее и проще в сопровождении. А если playbook начинает разрастаться — его разбивают на роли.

Дальше — расскажем, как устроены роли и зачем они нужны.

Когда сценариев становится много, обычный playbook превращается в громоздкий файл. Чтобы навести порядок и переиспользовать код, Ansible предлагает концепцию ролей (roles).

Роль — это шаблон, в который можно завернуть:

• задачи (tasks),
• обработчики (handlers),
• переменные (vars),
• шаблоны (templates),
• файлы (files).

Каждая роль живёт в отдельной папке. В итоге структура становится понятной и логичной:

roles/
└── webserver/
├── tasks/
│ └── main.yml
├── handlers/
│ └── main.yml
├── templates/
│ └── nginx.conf.j2
├── files/
│ └── index.html
└── vars/
└── main.yml

Это удобно, когда:

• проект работает с разными окружениями (dev, staging, prod);
• одни и те же настройки нужно применять на многих машинах;
• команда работает над сценарием совместно.

Пример подключения роли в плейбук:

- name: Настройка веб-сервера через роль
hosts: web
become: true
roles:
- webserver

Зачем всё это? Потому что роли:

• делают код переиспользуемым;
• упрощают тестирование;
• повышают читаемость;
• ускоряют работу с CI/CD.

Когда структура разложена по ролям — вы можете изменить одну часть, не трогая остальное. Это как модули в программировании: компактно, изолированно и понятно.

Далее — как запускать плейбуки на практике: команды, параметры, проверка.

💡 Начните автоматизировать управление вашей IT-инфраструктурой с курсом «‎Ansible: Infrastructure as Code»! Узнайте, как создавать и использовать плейбуки и роли в Ansible. Получите бесплатный доступ к учебным материалам и сделайте шаг к повышению своей квалификации.

Когда плейбук готов, его нужно правильно запустить. Это делается с помощью команды ansible-playbook. Именно она выполняет сценарий на указанных серверах.

🔧 Базовая команда:

ansible-playbook playbook.yml

Если у вас есть свой inventory (список хостов), укажите его:

ansible-playbook -i inventory.ini playbook.yml

📌 Пояснение параметров:

• -i — путь до файла с хостами.
• -u — имя пользователя, от которого выполнять задачи.
• -k — запрос пароля SSH (если вход по ключу не настроен).
• -b — активирует become, то есть выполнение от имени root.

Пример запуска с конкретным пользователем:

ansible-playbook -i inventory.ini -u deploy -k -b playbook.yml

🎯 Чтобы ограничить выполнение только для части серверов:

ansible-playbook -l webservers playbook.yml

📍 Перед запуском полезно проверить плейбук на синтаксические ошибки:

ansible-playbook --syntax-check playbook.yml

Эта команда ничего не выполняет — только проверяет структуру YAML.
🔍 А чтобы безопасно протестировать плейбук — запустите его в режиме dry-run:

ansible-playbook playbook.yml --check

В этом случае Ansible покажет, что бы он сделал, но не будет ничего менять. Особенно полезно для продакшн-серверов.
Можно добавить флаг --diff, чтобы увидеть различия между текущим и ожидаемым состоянием:

ansible-playbook playbook.yml --check --diff

Такой подход позволяет заранее понять последствия изменений. Это ключевой инструмент в DevOps-практике: никакой импровизации, только предсказуемые действия.

📌 На курсе от Слерм вы получите ключевые знания и навыки по Ansible, научитесь создавать, использовать плейбуки и роли в Ansible, освоите деплой приложений, освоите навыки автоматизации процессов управления IT-инфраструктурой.

Следующая тема — переменные и шаблоны: как сделать плейбук гибким и удобным для масштабирования.

Одна из сильных сторон Ansible — гибкость. Вместо того чтобы жёстко прописывать значения в задачах, вы можете использовать переменные. Это делает плейбуки универсальными, адаптируемыми под разные окружения и задачи.

🔹 Где задаются переменные?

1. Прямо в плейбуке:
2. vars:
3. app_port: 3000
4. Через командную строку:
5. ansible-playbook site.yml -e «‎app_port=3000»
6. В inventory-файле:
7. [web]
8. server1 ansible_host=192.168.1.10 app_port=3000
9. В отдельном YAML-файле и подключаются через vars_files:
10. vars_files:
11. - vars/main.yml

📌 В Ansible есть иерархия приоритетов. Значения из -e в командной строке перекрывают всё остальное.

🔹 Как использовать переменные в задачах?

Через двойные фигурные скобки:

- name: Открыть порт
ufw:
rule: allow
port: "{{ app_port }}"

🔹 Шаблоны Jinja2
Можно создавать конфиги с переменными и использовать шаблоны. Например:

Шаблон конфигурации (nginx.conf.j2):

server {
listen {{ nginx_port }};
server_name localhost;
}

Подключается в задаче так:

- name: Сгенерировать конфиг
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf

Ansible сам подставит значения переменных, и сгенерирует готовый файл.

🔹 Условия и логика

Можно добавить условия:
- name: Копировать файл, если приложение активно
copy:
src: conf.j2
dest: /etc/app/config.yaml
when: app_enabled

Это позволяет делать сценарий «‎умным»: выполнять действия только при определённых условиях.

📎 Всё это превращает Ansible playbook в мощный инструмент автоматизации, который работает с десятками серверов так же легко, как с одним.

Далее — заключение: коротко о главном.

Ansible — это не просто набор команд для автоматизации. Это язык управления инфраструктурой, который легко читается, масштабируется и позволяет точно контролировать каждое изменение.

Сценарии в формате Ansible-playbook:

• сокращают время настройки;
• исключают человеческий фактор;
• упрощают командную работу;
• легко интегрируются в CI/CD;
• обеспечивают повторяемость действий.

📌 Вы можете:

• автоматизировать развёртывание приложений;
• управлять обновлениями и сервисами;
• конфигурировать целые кластеры;
• писать сценарии, которые можно использовать годами.

Главное — всё прозрачно. YAML читается проще скриптов, а структура playbook'а напоминает хорошо написанный техдок.

🧠 Если представить инфраструктуру как программный продукт, то Ansible — это его компилятор. А playbook — это исходный код, который описывает, как всё должно работать. И вы сами выбираете, где и когда его применить.

Ansible подойдёт как DevOps-инженерам, так и разработчикам, которые хотят ускорить развёртывание и сделать свой стек предсказуемым.

🎯 Освоив Ansible-playbook, вы сможете:

• быстро настраивать любые окружения;
• не бояться масштабирования;
• внедрить практики GitOps и DevOps в ежедневную работу.

Теперь, когда вы знаете, как устроен playbook и как с ним работать — вы готовы к следующему шагу: создать свой первый автоматизированный сценарий и сделать инфраструктуру подконтрольной.

🚀 Узнайте, как эффективно управлять IT-инфраструктурой с помощью Ansible! Запишитесь на курс «Ansible: Infrastructure as Code»‎ и откройте для себя автоматизацию процессов.