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

Примеры Ansible-Playbook

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

Зачем нужен playbook

Плейбук — это сценарий, в котором описано, что именно должен сделать Ансибл: установить пакеты, создать пользователей, скопировать файлы, перезапустить сервис. Всё это выглядит как обычный список задач. Никакой магии — только логика и порядок. Благодаря этому playbook быстро читается, его легко редактировать, а изменения можно отслеживать в Git.

Вот пример самого простого playbook, который устанавливает nginx:

- hosts: web
  become: yes
  tasks:
    - name: Установить nginx
      apt:
        name: nginx
        state: present

Всё, что выше — это полноценный сценарий. Подразумевается, что у вас есть инвентори-файл, где указано, кто такие web. Ansible подключится по SSH и выполнит задачу: установит nginx.

Кто использует Ansible-playbook на практике

  • DevOps-инженеры — для автоматизации CI/CD, настройки кластеров и управления облачной инфраструктурой.
  • Системные администраторы — чтобы быстро разворачивать серверы, управлять конфигурациями, обновлять ПО.
  • Разработчики — особенно в небольших командах, где инфраструктурой занимаются «всем миром».
  • Инфраструктурные команды — для поддержки конфигурационного дрейфа и единых стандартов.

Сценарии, которые раньше писались вручную в Bash, теперь заменяются плейбуками. Это нагляднее и быстрее.

Простой сценарий: установка и запуск сервиса

Рассмотрим другой базовый пример — установка Apache и запуск его службы. Такой плейбук может пригодиться при автоматизации развёртывания веб-сервера:

- hosts: web
  become: yes
  tasks:
    - name: Установить Apache
      apt:
        name: apache2
        state: latest
    - name: Убедиться, что Apache запущен
      service:
        name: apache2
        state: started
        enabled: yes

Такой код решает сразу две задачи: установка нужного пакета и проверка, что служба запущена и будет подниматься при старте системы.

Структура плейбуков и модульный подход

Playbook строится вокруг идей идемпотентности и повторяемости. Каждая задача выполняется только при необходимости. Если nginx уже установлен — Ансибл это «поймёт» и пропустит шаг. Это особенно важно для стабильности и предсказуемости автоматизации.
Можно объединять несколько задач в один блок, использовать переменные, шаблоны, условия и циклы. Для повторно используемой логики лучше выделять роли (roles), но о них позже.

Вот как может выглядеть плейбук с использованием переменных:

- hosts: all
  become: yes
  vars:
    web_package: nginx
  tasks:
    - name: Установить веб-сервер
      apt:
        name: «{{ web_package }}»
        state: present

Такая структура позволяет быстро адаптировать сценарий под разные окружения. Например, можно заменить nginx на apache2, не меняя саму логику задач.

Реальные примеры: настройка пользователей и SSH

Ansible легко справляется с задачами, которые в обычной жизни надо выполнять вручную или с помощью Bash-скриптов. Например, можно добавить нового пользователя с SSH-ключом и sudo-доступом:

- hosts: servers
  become: yes
  tasks:
    - name: Добавить пользователя devops
      user:
        name: devops
        shell: /bin/bash
        groups: sudo
        append: yes
    - name: Установить SSH ключ
      authorized_key:
        user: devops
        key: «{{ lookup('file', 'id_rsa.pub') }}»

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

Автоматизация деплоя приложений

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

- hosts: app
  become: yes
  vars:
    repo_url: «https://github.com/example/project.git»‎
    dest: "/var/www/project"
  tasks:
    - name: Клонировать репозиторий
      git:
        repo: «{{ repo_url }}»‎
        dest: «{{ dest }}»‎
        version: main
    - name: Установить зависимости
      command: npm install
      args:
        chdir: «{{ dest }}»‎
    - name: Запустить сборку
      command: npm run build
      args:
        chdir: «{{ dest }}»‎

Этот плейбук уже ближе к «боевым»‎ задачам — в нём участвуют переменные, внешние команды и шаги, характерные для CI/CD пайплайнов.
Приглашаем в наше телеграм-сообщество, где делимся лучшими статьями с Хабра по рекомендациям и практикам работы с Ansible.
Все полезные материалы по Ansible в одном месте
Перейти в телеграм

Какой сценарий наиболее подходит для использования Ansible

Ансибл — это про стабильность, масштаб и повторяемость. Он особенно полезен, когда:

  • у вас много однотипных серверов;
  • вы хотите избежать ручной настройки;
  • конфигурации должны быть одинаковыми в dev/stage/prod;
  • нужно быстро восстановить окружение «‎с нуля»;
  • важна прозрачность и возможность код-ревью для инфраструктурных изменений.

Простой пример — обновление пакетов на десятках серверов. Без Ансибл вы бы заходили по очереди через SSH. С плейбуком — одна команда и всё готово.

Вот как выглядит типичный запуск:

ansible-playbook -i inventory.ini site.yml

Где inventory.ini — список хостов, а site.yml — основной playbook. Важно помнить, что Ансибл не требует установки агентов на управляемых машинах — только SSH-доступ и Python.

Резюме: почему стоит начать именно с плейбуков

  • Плейбук читается как обычный список задач — доступен даже новичкам.
  • Он позволяет управлять не только Linux, но и Windows, сетевым оборудованием, Docker, Kubernetes.
  • Логику можно версионировать, документировать, запускать в CI/CD.

Если вы новичок и не знаете, с чего начать — начните с простого hello world сценария. А если уже знакомы — попробуйте описать свои текущие задачи через playbook и посмотрите, сколько времени вы сэкономите.

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

Как запустить playbook Ansible

Запуск прост. Здесь не нужно настраивать сервер-агент, ничего компилировать или разворачивать окружения вручную. Достаточно установить Ансибл, создать инвентори и playbook, после чего — запустить одну команду в терминале.

Установка Ansible

Наиболее быстрый способ установить Ansible на Linux-систему — через пакетный менеджер:

sudo apt update
sudo apt install ansible -y

Для пользователей macOS:

brew install ansible

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

ansible --version

Если вы работаете в Windows, рекомендуемый путь — использовать WSL (Windows Subsystem for Linux) или виртуальную машину с Ubuntu.

Настройка inventory-файла

Inventory — это файл, где описано, какие хосты мы хотим конфигурировать. Самый простой формат — INI. Пример:

[web]
192.168.1.101
192.168.1.102

[db]
192.168.1.201

Также можно использовать YAML (формат inventory в стиле Ansible 2.0+) или динамический инвентори — например, на основе облачного API (AWS, Yandex.Cloud и т.д.).

Важно: чтобы подключение по SSH прошло без пароля, настройте доступ через ключи или используйте --ask-pass.

Простой плейбук для теста

Создадим тестовый сценарий, который просто проверит доступность хостов. Создайте файл ping.yml:

- hosts: all
  tasks:
    - name: Проверить доступность
      ping:

Чтобы его запустить:

ansible-playbook -i inventory.ini ping.yml

Если всё настроено правильно — увидите зелёные галочки «ok». Это значит, что соединение с каждым хостом успешно, и playbook выполнился корректно.

Интерпретация вывода Ansible

Когда вы запускаете плейбук, Ансибл поочерёдно выполняет задачи для каждого хоста и выводит статус:

  • ok — задача уже выполнена, изменений не требуется;
  • changed — задача что-то изменила;
  • failed — возникла ошибка;
  • skipping — задача была пропущена (например, из-за условия).

Пример вывода:

TASK [Установить nginx] *************************************************
changed: [192.168.1.101]
TASK [Убедиться, что nginx запущен] **************************************
ok: [192.168.1.101]

Вы можете использовать флаг -v (verbose), чтобы получить больше подробностей, или -vvv для полного вывода, включая SSH-сообщения.

Проверка результата

Ансибл по умолчанию не «навязывает» проверку — он просто сообщает статус. Но вы можете явно описывать проверки, например:

- name: Проверить, что порт 80 открыт
  shell: ss -tuln | grep ':80 '
  register: port_check
  failed_when: port_check.rc != 0

Или:

- name: Проверить ответ от сервера
  uri:
    url: http://localhost
    return_content: yes

Такие задачи могут быть частью smoke-тестов — сценариев, которые быстро проверяют, что всё работает после деплоя.
Получите ключевые знания и навыки по Ansible!
Дарим демодоступ к обучению на 3 дня, чтобы вы познакомились с материалами и спикерами курса.
Перейти к курсу

Передача переменных при запуске

Иногда удобно передавать параметры прямо из командной строки, особенно если вы не хотите хардкодить значения в YAML-файлах. Для этого используют флаг --extra-vars (или -e):

ansible-playbook -i inventory.ini site.yml -e "env=prod version=1.3.2"

В самом плейбуке можно обращаться к ним как к обычным переменным:

- hosts: all
  tasks:
    - name: Вывести переменные
      debug:
        msg: "Окружение: {{ env }}, версия: {{ version }}"

Такой подход позволяет использовать один и тот же сценарий для разных окружений без дублирования кода.

Как избежать типичных ошибок

Вот частые проблемы, с которыми сталкиваются при запуске плейбуков:

Permission denied по SSH
Убедитесь, что у вас есть доступ по ключу или используйте --ask-pass.

Python не найден на целевом сервере
Ansible требует установленный Python 2.7+ или 3.x на управляемых хостах. Если его нет — установите вручную или используйте raw.

Ошибка в синтаксисе YAML
YAML чувствителен к отступам. Не используйте табы, только пробелы. Проверяйте формат yamllint или валидатором.

Не найден модуль или роль
Проверьте, что нужный модуль действительно есть в версии Ансибл. Некоторые модули требуют установки плагинов или collections (ansible-galaxy).

Зависания без вывода
Чаще всего — неправильный SSH-доступ или firewall. Попробуйте ansible all -m ping -i inventory.ini -vvvv и посмотрите, где застревает.

Советы для стабильной работы

Всегда начинайте с пинга: команда ansible all -m ping -i inventory.ini — это ваш друг. Она проверит базовую связность и доступность целевых хостов.

Выводите переменные через debug — особенно на этапе отладки, чтобы понять, что именно «‎видит» playbook.

Разбивайте сложные сценарии на роли — об этом мы поговорим позже, но чем проще структура — тем легче сопровождение.

Используйте Git — храните свои playbook-и и inventory в репозитории, чтобы отслеживать изменения и откатывать при необходимости.

Документируйте задачи — name: в каждой задаче — не просто подпись, это то, что будет в логах. Пишите понятно и конкретно.

Мини-резюме

Запустить ansible-playbook — проще, чем кажется:

  1. Установили Ansible.
  2. Написали плейбук и inventory.
  3. Запустили одну команду.
  4. Получили предсказуемый, повторяемый результат.

📌 Главное — пробовать. Сценарии можно усложнять по мере необходимости. Даже самый базовый playbook уже даёт выигрыш в скорости и надёжности по сравнению с ручной настройкой.

💡 Хотите не просто запускать плейбуки, а понимать их изнутри, писать роли и строить автоматизацию под себя? Пройдите курс «‎Ansible: Infrastructure as Code» — получите доступ к примерам, практикам и разбору типовых ошибок. Первый модуль доступен бесплатно.

Использование переменных в плейбуках

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

Что такое переменные в Ansible

Переменные в Ансибл — это именованные значения, которые можно использовать в задачах, шаблонах, условиях и любых параметрах. Это позволяет не захардкодить IP-адрес или имя пользователя, а подставлять актуальные значения в момент выполнения.

Простой пример:

- hosts: all
  vars:
    user_name: devops
  tasks:
    - name: Создать пользователя
      user:
        name: "{{ user_name }}"

Где можно определить переменные

Ансибл поддерживает множество уровней, где можно задать переменные:

  • Внутри playbook (vars, vars_files, vars_prompt)
  • В inventory-файле (например, inventory.ini)
  • В переменных группы или хоста (group_vars/, host_vars/)
  • В командной строке (-e)
  • В роли (defaults/, vars/)
  • Через facts (автоматически собираемые данные)
  • Из внешних источников (lookup, set_fact, API)

Пример переменной в инвентори:

[web]
192.168.1.101 ansible_user=ubuntu ansible_ssh_private_key_file=~/.ssh/id_rsa env=stage

Внутри playbook можно обратиться к {{ env }}, и он подставит stage.

Как работает приоритет переменных

Когда переменная объявлена в нескольких местах, Ansible использует ту, которая ближе к выполнению. Упрощённая иерархия (от наименьшего к наибольшему приоритету):

  1. defaults в роли
  2. переменные из inventory
  3. переменные из group_vars и host_vars
  4. vars внутри playbook
  5. set_fact
  6. --extra-vars (командная строка)

Если вы задали env=prod в group_vars, но передали -e env=dev — победит dev. Это позволяет гибко переопределять значения «на лету».

Работа с шаблонами

Шаблоны в Ansible пишутся на Jinja2. Они позволяют вставлять переменные прямо в текстовые файлы. Это особенно полезно при генерации конфигураций.
Пример шаблона nginx.conf.j2:

server {
    listen 80;
    server_name {{ domain }};
    root /var/www/{{ site_dir }};
}

Playbook для рендера:

- hosts: web
  vars:
    domain: example.com
    site_dir: html
  tasks:
    - name: Сгенерировать конфиг nginx
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/sites-available/default

Такой подход упрощает развертывание и настройку, позволяя использовать один шаблон для разных проектов.

Вложенные переменные и словари

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

Пример словаря:

- hosts: app
  vars:
    app_config:
      port: 8080
      env: production
      debug: false
  tasks:
    - name: Вывести конфигурацию
      debug:
        msg: "Порт: {{ app_config.port }}, Debug: {{ app_config.debug }}"

Списки тоже поддерживаются:

- hosts: db
  vars:
    packages:
      - postgresql
      - postgresql-contrib
  tasks:
    - name: Установить пакеты
      apt:
        name: "{{ packages }}"
        state: present

Условия и переменные

Иногда задачи нужно выполнять только при определённых значениях. Здесь помогают директивы when:

- name: Установить debug-режим
  debug:
    msg: "DEBUG ВКЛЮЧЁН"
  when: app_config.debug == true

Также можно использовать переменные в выражениях, условиях, фильтрах (default, lower, replace, split, и др.):

- name: Показать домен в нижнем регистре
  debug:
    msg: "{{ domain | lower }}"

Динамические переменные и set_fact

Иногда переменные нужно вычислять прямо во время выполнения. Для этого есть модуль set_fact — он позволяет создать переменную «на лету»:

- name: Получить имя хоста без домена
  set_fact:
    short_hostname: "{{ inventory_hostname.split('.')[0] }}"

- name: Вывести имя
  debug:
    msg: "Имя хоста: {{ short_hostname }}"

Это особенно удобно, когда нужно сохранить результат предыдущей команды или сформировать значение из нескольких частей.

Частые ошибки при работе с переменными

  • Пропущенные фигурные скобки
    ➤ msg: «Привет, {{ имя }}» — всегда заключайте имя переменной в двойные фигурные скобки.
  • Конфликт имён переменных
    ➤ Используйте префиксы или структуры (web_user, db_user) вместо общих имён.
  • Переопределение переменных в нескольких местах
    ➤ Следите за иерархией и помните: переменные из -e всегда выигрывают.
  • Типизация
    ➤ Ansible неявно приводит типы, но для сравнения лучше явно задавать true/false, а не «yes».
  • Ошибка шаблона
    ➤ Проверяйте Jinja-выражения перед запуском, особенно если они строятся динамически.

Вывод: переменные — это гибкость

  • С ними один и тот же playbook адаптируется под разные окружения.
  • Их можно собирать из внешних файлов, динамически вычислять или переопределять при запуске.
  • Они делают код масштабируемым и удобным для поддержки.

💡 Хотите писать читаемые, мощные и переиспользуемые сценарии? Освойте переменные, шаблоны и роли на практике — в курсе «Ansible: Infrastructure as Code». Первые уроки доступны бесплатно.

Работа с репозиториями

Работа с Ансибл-проектами не заканчивается написанием плейбуков. Важно не просто их запускать, но и грамотно хранить, версионировать и интегрировать в процессы команды. Поэтому большинство инженеров работают с Ansible через Git — как с полноценным проектом с инфраструктурой как кодом.

Где и как хранить Ansible-playbook

Самый логичный и безопасный способ — хранить весь проект в Git-репозитории. Это позволяет:

  • отслеживать изменения в playbook и конфигурациях;
  • откатываться на стабильные версии;
  • работать в команде и делать code-review;
  • подключать сценарии к CI/CD.

Типовая структура проекта:

ansible/
├── inventory/
│   ├── dev.ini
│   └── prod.ini
├── group_vars/
│   └── all.yml
├── host_vars/
├── roles/
│   └── webserver/
│       ├── tasks/
│       │   └── main.yml
│       └── templates/
├── playbooks/
│   ├── deploy.yml
│   └── update.yml
└── ansible.cfg

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

Настройка репозитория

Создайте репозиторий (например, на GitHub, GitLab или Bitbucket), и загрузите туда свою структуру:

git init
git remote add origin git@github.com:user/ansible-project.git
git add .
git commit -m "init"
git push -u origin master

Важно: не храните файлы с секретами (пароли, токены, ключи) в открытом виде. Используйте .gitignore и шифрование через ansible-vault.

Работа с приватными репозиториями

Многие компании хранят конфигурации в приватных репозиториях. Ansible легко работает с ними, но потребуются SSH-ключи или access-токен.

Пример задачи, которая клонирует приватный репозиторий через SSH:

- hosts: app
  vars:
    repo_url: git@github.com:yourorg/private-repo.git
  tasks:
    - name: Клонировать приватный репозиторий
      git:
        repo: "{{ repo_url }}"
        dest: /opt/project
        version: main
        key_file: /home/ansible/.ssh/id_rsa

Если ключ шифруется passphrase, потребуется использовать агент ssh-agent или предварительно его разблокировать.

Альтернатива — авторизация через HTTPS и переменные окружения:

repo_url: "https://{{ git_user }}:{{ git_token }}@github.com/yourorg/private-repo.git"

В таком случае git_user и git_token лучше передавать через --extra-vars или шифровать в ansible-vault.

Как избежать утечек

  • Добавьте .gitignore и исключите *.pem, *.key, vault_password.txt.
  • Не коммитьте реальные IP, логины и пароли — используйте переменные.
  • Зашифруйте всё чувствительное с помощью ansible-vault:

ansible-vault encrypt group_vars/prod.yml

И используйте:

ansible-playbook site.yml --ask-vault-pass

Автоматизация через Git и CI/CD

Чтобы запустить ansible playbook при каждом пуше в репозиторий — подключите его к CI/CD. Это позволяет:

  • автоматически развёртывать конфигурации;
  • синхронизировать изменения с инфраструктурой;
  • тестировать playbook-и при коммите.

Пример GitLab CI

В .gitlab-ci.yml можно описать задачу:

stages:
  - deploy

deploy_prod:
  stage: deploy
  script:
    - ansible-playbook -i inventory/prod.ini playbooks/deploy.yml --vault-password-file vault_pass.txt
  only:
    - main

Пример GitHub Actions

Для GitHub создаётся .github/workflows/deploy.yml:

name: Deploy
on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Setup Python
        uses: actions/setup-python@v2
      - name: Install Ansible
        run: pip install ansible
      - name: Run playbook
        run: ansible-playbook -i inventory/prod.ini playbooks/deploy.yml --vault-password-file vault_pass.txt

Такой подход превращает Git в центральную точку управления. Любой коммит, прошедший review — это потенциально новый релиз или обновление.

Best practices для организации Ansible-проектов в Git

Чтобы ваш репозиторий не превратился в хаос, придерживайтесь следующих рекомендаций:

  1. Разделяйте окружения — создайте отдельные inventory-файлы для dev, stage, prod.
  2. Изолируйте чувствительные данные — используйте ansible-vault или внешние секрет-хранилища.
  3. Пользуйтесь ролями — роли делают код повторно используемым и чище.
  4. Пишите README.md — даже для инфраструктуры. Объясните, как запускать playbook, где переменные, что за inventory.
  5. Автоматизируйте всё — интеграция с CI/CD убережёт от «запустил руками и забыл».

Вывод

Хранение и запуск Ansible-playbook через Git делает ваш проект:
  • прозрачным — все изменения видны и документированы;
  • управляемым — легко откатиться, понять, кто и что изменил;
  • автоматизированным — подключение CI/CD упрощает обновления и снижает риски.

Заключение

Ансибл — не просто инструмент автоматизации. Это язык взаимодействия с инфраструктурой, который понятен как новичку, так и опытному инженеру. Сценарии на YAML читаются легче, чем shell-скрипты, а результат — надёжнее и масштабируемее.

В этой статье мы разобрали:

  • примеры плейбуков ansible, на чём они основаны и зачем нужны;
  • как запускать плейбуки: от подготовки окружения до разбора вывода;
  • как использовать переменные, условия и шаблоны, чтобы адаптировать один сценарий под разные окружения;
  • как организовать хранение проектов через Git, подключать их к CI/CD и строить инфраструктуру как код.

Теперь у вас есть фундамент. И главное — практическое понимание, как Ansible работает в реальных задачах: от настройки сервера до автоматизации деплоя.

Что дальше?

Ansible — это не про «поставил nginx и забыл». Он позволяет:
  • выстраивать сложные конфигурации;
  • описывать зависимости;
  • строить надёжные пайплайны CI/CD;
  • управлять сотнями машин одной командой;
  • работать не только с Linux, но и с Windows, сетевыми устройствами, облаками.
Каждый написанный playbook — это шаг к более чистому, понятному и масштабируемому управлению.

Хотите перейти от теории к практике?

💡 Начните бесплатно  на курсе «Ansible: Infrastructure as Code» и сразу получите доступ к репозиторию с готовыми плейбуками.

 Научитесь писать плейбуки, роли, подключать Git, vault, работать с CI/CD и строить автоматизацию, которая экономит часы рутинной работы.

Статью подготовили

Редакция Слёрма
Понравилась статья? Будем рады вашему лайку и репосту — вдруг кому-то тоже пригодится:)
Оцените статью

Читайте также: