Установка и первая команда ping

Урок 3 - устанавливаем Ansible и проверяем связь с сервером.

«Прежде чем автоматизировать сложное, научись надёжно делать простое: достучаться до сервера».

Ansible ставится только на control node - твою рабочую машину или отдельный сервер автоматизации. На целевые серверы ничего ставить не надо (мы это уже знаем). Установка обычно делается через пакетный менеджер Python:

# Современный способ - через pip в виртуальное окружение
python3 -m venv ansible-venv
source ansible-venv/bin/activate
pip install ansible

# Проверим версию
ansible --version

Пакет ansible включает в себя ядро (ansible-core) и большой набор коллекций с модулями. Для минимальной установки есть отдельный пакет ansible-core, но новичку проще начать с полного.

Первая команда: ad-hoc ping

Самый быстрый способ проверить, что Ansible достучится до сервера - ad-hoc команда. Это разовое действие без playbook. Модуль ping ничего не «пингует» в сетевом смысле: он проверяет, что Ansible смог зайти по SSH, запустить Python и получить ответ.

# Проверить связь с хостом по IP, зайдя пользователем deploy
ansible all -i "203.0.113.10," -u deploy -m ping

# Ожидаемый ответ:
# 203.0.113.10 | SUCCESS => {
#     "changed": false,
#     "ping": "pong"
# }

Запятая после IP в -i - не опечатка: так Ansible понимает, что это инлайновый список хостов, а не путь к файлу инвентаря. Флаг -m задаёт модуль, -u - пользователя SSH.

Как работает под капотом

Когда ты запускаешь ansible all -m ping, происходит ровно та цепочка, что мы разбирали: разбор инвентаря, установка SSH-соединения, копирование модуля ping, его запуск, чтение JSON-ответа {"ping": "pong"} и пометка статусом SUCCESS. Поле changed: false подсказывает, что ничего на сервере изменено не было - ping только читает состояние.

Смоделируем логику разбора ответа от хоста на Python - так понятнее, что Ansible делает с результатом каждого хоста.

# Имитация обработки ответов от нескольких хостов
raw_results = {
    "web1": {"ping": "pong", "changed": False},
    "web2": {"ping": "pong", "changed": False},
    "db1":  {"unreachable": True, "msg": "SSH timeout"},
}

ok, failed = [], []
for host, res in raw_results.items():
    if res.get("unreachable"):
        failed.append((host, res["msg"]))
    elif res.get("ping") == "pong":
        ok.append(host)

print("SUCCESS:", ok)
for host, msg in failed:
    print(f"UNREACHABLE: {host} -> {msg}")

Попробуй сам ▶ Так Ansible и формирует итоговую сводку: какие хосты ответили, а какие недоступны. В реальной работе db1 с таймаутом - первый сигнал проверить ключи, сеть или имя пользователя.

Частые ошибки

• Host key verification failed. Сервер новый, его ключ ещё не в known_hosts. Зайди один раз руками по SSH или настрой host_key_checking в конфиге.
• Permission denied. Не подошёл SSH-ключ или пользователь. Проверь -u и наличие публичного ключа на сервере.
• Забыть запятую в инлайн-инвентаре. Без неё Ansible решит, что 203.0.113.10 - это путь к файлу, и не найдёт хостов.

Best practices

• Ставь Ansible в виртуальное окружение - не засоряй системный Python.
• Фиксируй версию Ansible в проекте (например, в requirements.txt), чтобы у всей команды было одинаково.
• Всегда начинай работу с новым окружением с ping - это снимает половину «почему не работает» ещё до первого playbook.

В реальной работе

Перед первым реальным проектом полезно завести файл ansible.cfg в корне репозитория: в нём задают путь к инвентарю по умолчанию, пользователя SSH, поведение при проверке ключей хоста и другие настройки. Это избавляет от длинных команд с кучей флагов - ты пишешь просто ansible-playbook site.yml, а все детали берутся из конфига. Ещё одна привычка опытных инженеров - держать рядом отдельный inventory для тестового хоста (например, локальной виртуалки), на котором безопасно обкатывать playbook'и перед боевыми серверами. Ad-hoc ping по этому тестовому хосту - первое, что запускают после любой смены окружения или ключей.

Итоги

Ansible ставится на control node через pip, а первая проверка связи делается ad-hoc командой с модулем ping, который возвращает pong при успешном SSH-доступе. Теперь у нас есть рабочий канал к серверу - пора описать его в инвентаре.