Ansible для администраторов: автоматизация серверов

Для этого и создан Ansible.

Что такое Ansible и где применяется

Ansible — это инструмент автоматизации ИТ-процессов, который позволяет управлять серверами, настраивать инфраструктуру и разворачивать приложения с помощью простых YAML-файлов. Проект был создан компанией Red Hat и сегодня входит в экосистему решений для управления инфраструктурой.

Ansible работает по принципу Infrastructure as Code: вместо того чтобы настраивать серверы вручную, администратор просто пишет сценарий (playbook). В нём инструмент указывает, что нужно сделать: какие программы установить, какие службы включить и какие настройки поменять. Потом достаточно запустить Ansible — и он сам выполнит все эти действия на нужных серверах.

Ansible применяется для:

• автоматизации конфигурации серверов (установка пакетов, настройка служб, управление пользователями),
• оркестрации сложных ИТ-процессов (последовательный запуск задач на разных узлах),
• развёртывания приложений в тестовых и продакшен-средах,
• управления облачной инфраструктурой,
• поддержки DevOps-подхода и CI/CD-процессов.

Его используют системные администраторы, DevOps-инженеры и SRE-специалисты для ускорения внедрения изменений, снижения количества ошибок и обеспечения воспроизводимости конфигураций.

Возможности Ansible

Возможности Ansible охватывают почти весь цикл работ с инфраструктурой и приложениями. Включая:

• Управление конфигурацией. Ansible настраивает серверы так, как указано в сценарии: устанавливает программы, настраивает службы, создаёт пользователей, меняет параметры системы. Можно задать единые правила и применить их сразу к десяткам или сотням машин.
• Автоматический деплой приложений. С его помощью разворачивают новые версии сайтов и сервисов: копируют файлы, обновляют зависимости, выполняют миграции базы данных и перезапускают сервисы в нужном порядке.
• Оркестрация процессов. Ansible выполняет задачи по шагам и в правильной последовательности. Например, сначала обновляет базу данных, затем сервер приложения, а потом балансировщик нагрузки.
• Работа без установки агентов. Для управления серверами не нужно ставить дополнительное ПО на каждый хост. Ansible подключается по SSH (или WinRM для Windows) и выполняет команды удалённо. Это упрощает внедрение.
• Повторяемость и предсказуемость. Если запустить один и тот же сценарий несколько раз, система останется в корректном состоянии. Ansible не будет выполнять лишние действия, если всё уже настроено.
• Шаблоны и переменные. Можно создавать универсальные конфигурации и подставлять в них разные параметры для разных сред — разработки, тестирования и продакшена.
• Группировка серверов. Серверы объединяются в группы: по ролям, проектам или окружениям. Это помогает применять нужные настройки только к нужным машинам.
• Интеграция с облаками и сервисами. Ansible управляет виртуальными машинами в облаках, контейнерами, сетевым оборудованием и другими ИТ-сервисами через готовые модули.
• Работа с секретами. С помощью встроенного механизма шифрования можно безопасно хранить пароли, ключи и другие конфиденциальные данные.
• Интеграция с CI/CD. Сценарии Ansible можно запускать из пайплайнов, чтобы автоматически подготавливать окружения и выкладывать обновления без ручного вмешательства.

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

Базовые термины

Чтобы понимать, как работает Ansible, важно разобраться в основных понятиях:

• Control Node. Управляющий сервер, на котором установлен Ansible и откуда запускаются все сценарии. Именно он подключается к другим машинам и выполняет задачи.
• Managed Node. Сервер или устройство, которым управляет Ansible. На такие узлы не нужно устанавливать агент — подключение происходит по SSH.
• Inventory. Список управляемых серверов. В inventory указываются адреса хостов и их группировка, например: web-серверы, базы данных, тестовая среда.
• Playbook. Файл с описанием сценария автоматизации. В нём по шагам прописано, какие задачи и на каких серверах нужно выполнить. Playbook пишутся в формате YAML.
• Play. Один блок внутри playbook. В нём указывается, к какой группе серверов применяются задачи и какие именно действия нужно выполнить.
• Task. Отдельное действие в сценарии: установить пакет, скопировать файл, перезапустить сервис. Playbook состоит из набора таких задач.
• Module. Готовый инструмент для выполнения конкретной операции. Например, модуль может отвечать за установку пакетов, управление пользователями или работу с облаком. Ansible вызывает модули при выполнении задач.
• Role. Структурированный набор файлов и задач для выполнения одной логической функции, например настройки веб-сервера. Роли помогают поддерживать порядок в больших проектах и переиспользовать код.
• Variables. Переменные, которые позволяют подставлять разные значения в сценарии — например, имя пользователя, версию приложения или путь к файлу.

Установка Ansible

Разберёмся, как установить Ansible на виртуальный сервер с Ubuntu 24.04.

Установка выполняется на управляющем сервере (control node), с которого в дальнейшем будет происходить подключение к другим хостам.

1. Обновите систему:

sudo apt update
sudo apt upgrade -y

2. Установите необходимые пакеты:

sudo apt install software-properties-common -y

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

sudo add-apt-repository --yes --update ppa:ansible/ansible

Система автоматически обновит список пакетов.

4. Установите Ansible:

sudo apt install ansible -y

5. Проверьте установку:

ansible --version

Также можно проверить работу Ansible на самом сервере (локально):

ansible localhost -m ping

Если всё настроено правильно, в ответ появится:

localhost | SUCCESS => {
    "ping": "pong"
}

Настройка Ansible

Далее важно правильно настроить проект — тогда все команды будут работать одинаково. Нужно задать серверы, вывод, логи и SSH.

Ansible ищет конфигурационный файл в следующем порядке:

1. ./ansible.cfg — в текущей директории проекта
2. ~/.ansible.cfg — в домашнем каталоге пользователя
3. /etc/ansible/ansible.cfg — глобальный системный файл

Если файл лежит в каталоге проекта (например, /srv/ansible/ansible.cfg), у него приоритет. Так настройки хранятся рядом с playbook и не влияют на другие проекты.

Создать базовый файл можно вручную:

touch ansible.cfg

Пример конфигурации ansible.cfg:

[defaults]
inventory = ./hosts.yaml
host_key_checking = False
log_path = /var/log/ansible.log
vault_password_file = ./vault.key
force_color = 1
callback_result_format = yaml

[ssh_connection]
timeout = 10
retries = 2
server_alive_interval = 60
pipelining = True
ssh_args = -o StrictHostKeyChecking=no
scp_if_ssh = True
allow_world_readable_tmpfiles = True

Посмотрим на ключевые параметры:

Раздел [defaults]

• inventory = ./hosts.yaml — указывает путь к inventory-файлу. В нём хранится список серверов и их группировка. Можно использовать как YAML, так и INI-формат.
• host_key_checking = False — отключает проверку SSH-ключей хостов. По умолчанию проверка включена и защищает от подмены сервера. В продакшене её лучше не отключать, но для тестовых VPS и разработки это упрощает работу.
• log_path = /var/log/ansible.log — путь к файлу логов. Удобно для аудита и анализа ошибок. Важно, чтобы у пользователя были права на запись.
• vault_password_file = ./vault.key — файл с паролем для Ansible Vault. Используется для шифрования секретов (пароли, токены и ключи). Сам файл с паролем не стоит добавлять в репозиторий.
• force_color = 1 — включает цветной вывод в консоли. Делает результат выполнения более наглядным.
• callback_result_format = yaml — форматирует вывод задач в YAML-виде. Такой формат проще читать, чем стандартный JSON-подобный вывод.

Раздел [ssh_connection]

• timeout = 10 — время ожидания подключения по SSH в секундах.
• retries = 2 — количество повторных попыток подключения при ошибке.
• server_alive_interval = 60 — интервал отправки keep-alive пакетов для поддержания SSH-сессии.
• pipelining = True — ускоряет выполнение задач за счёт уменьшения количества SSH-операций. Работает быстрее, но требует отключённого requiretty в sudo (в современных Ubuntu обычно уже не используется).
• ssh_args = -o StrictHostKeyChecking=no — дополнительные параметры SSH. В данном случае отключается строгая проверка ключей.
• scp_if_ssh = True — использует SCP при передаче файлов по SSH.
• allow_world_readable_tmpfiles = True — разрешает создание временных файлов с более широкими правами доступа. В продакшене использовать осторожно.

Часть настроек можно задавать через окружение, например:

export ANSIBLE_CONFIG=/srv/ansible/ansible.cfg
export ANSIBLE_FORCE_COLOR=1

Также inventory и другие опции можно переопределить на уровне команды (часто удобно в CI):

ansible-playbook playbooks/site.yaml -i hosts.yaml

В этом случае используется конкретный inventory-файл, независимо от того, что указано в ansible.cfg.

В файле ansible.cfg фиксируйте основные настройки: список управляемых серверов, формат вывода, логирование и параметры SSH. Если нужно что‑то изменить ненадолго — используйте переменные окружения или аргументы при запуске.

Инструкция по работе

Давайте разберёмся, как работать с Ansible:

Шаг 1. Подготовьте каталог проекта

Создайте отдельную папку, где будут лежать конфигурация, inventory и playbook:

mkdir -p /srv/ansible
cd /srv/ansible

Как правило, минимальный набор файлов: ansible.cfg, hosts.yaml, playbooks/.

mkdir -p playbooks
touch ansible.cfg hosts.yaml

Шаг 2. Настройте ansible.cfg

Если вы уже сделали файл конфигурации ранее — пропустите шаг. Главное, чтобы Ansible видел inventory по умолчанию.

Шаг 3. Заполните inventory

Если вы используете формат YAML, пример hosts.yaml может выглядеть так:

all:
  children:
    web:
      hosts:
        web1:
          ansible_host: 203.0.113.10
    db:
      hosts:
        db1:
          ansible_host: 203.0.113.20
  vars:
    ansible_user: root

Где:

• all — корневая группа, в неё входят все хосты.
• children — вложенные группы серверов. В примере это web и db.
• hosts — конкретные серверы внутри группы.
• ansible_host — реальный IP-адрес сервера.
• ansible_user — пользователь, от имени которого будет происходить подключение по SSH.

Если вы подключаетесь не под root, укажите другого пользователя, например:

ansible_user: ubuntu

При необходимости можно добавить путь к SSH-ключу:

ansible_ssh_private_key_file: /root/.ssh/id_rsa

После сохранения файла проверьте, что Ansible корректно его читает:

ansible-inventory --list

Если структура YAML верная, вы увидите список групп и хостов.

Шаг 4. Проверьте доступ к серверам

Далее нужно убедиться, что Ansible может подключиться к серверам по SSH и выполнять команды.

Самый простой способ — использовать встроенный модуль ping. Это не обычный сетевой ping, а проверка того, что Ansible может подключиться к хосту и запустить Python:

ansible all -m ping

Если всё настроено правильно, в ответ вы увидите:

web1 | SUCCESS => {
    "ping": "pong"
}

Шаг 5. Создайте первый playbook

Создайте файл playbooks/nginx.yaml:

mkdir -p playbooks
nano playbooks/nginx.yaml

Добавьте содержимое:

- name: Install and start nginx
  hosts: web
  become: true
  tasks:
    - name: Update apt cache
      ansible.builtin.apt:
        update_cache: true

    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: Enable and start nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

Где hosts: web означает, что сценарий выполнится только на серверах из группы web в вашем hosts.yaml. А become: true включает выполнение задач с повышенными правами (через sudo).

Проверьте синтаксис:

ansible-playbook playbooks/nginx.yaml --syntax-check

Запустите playbook:

ansible-playbook playbooks/nginx.yaml

Если inventory не задан в ansible.cfg, укажите его явно:

ansible-playbook playbooks/nginx.yaml -i hosts.yaml

Шаг 6. Запускайте безопаснее: check mode и diff

Чтобы выполнить playbook в режиме проверки без внесения изменений, используйте --check:

ansible-playbook playbooks/nginx.yaml --check

В этом режиме Ansible анализирует текущее состояние системы и показывает, какие задачи были бы выполнены. Реальных изменений на сервере не происходит. Это удобно перед обновлениями или при работе в продакшене.

Чтобы дополнительно увидеть различия в конфигурационных файлах, используйте --diff:

ansible-playbook playbooks/nginx.yaml --diff

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

Можно объединить оба режима:

ansible-playbook playbooks/nginx.yaml --check --diff

Шаг 7. Используйте Vault для секретов

Ansible Vault нужен, чтобы хранить секреты (пароли, токены, ключи) в зашифрованном виде. Это удобнее и безопаснее, чем держать такие данные в открытых переменных в playbook или inventory.

Создайте зашифрованный файл с переменными:

ansible-vault create group_vars/all/vault.yaml

Добавьте туда, например:

db_password: "S3cret!"

Запуск playbook с вводом пароля:

ansible-playbook playbooks/nginx.yaml --ask-vault-pass

Если в ansible.cfg задан vault_password_file, пароль можно не вводить вручную.

Полезные команды Ansible

Заключение

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