Зачем Ansible при миграции серверов

Ansible позволяет автоматически настраивать серверы по описанию (infrastructure as code). Не нужны агенты — работает через SSH. Для миграции это особенно ценно: вместо того чтобы вручную повторять настройку старого сервера на новом и неизбежно что-то забыть, вы один раз описываете конфигурацию и применяете её к любому числу серверов одинаково.

💡 Главное преимущество Ansible — идемпотентность: запустите плейбук 10 раз подряд — результат всегда будет одинаковым.

Установка Ansible

# Ubuntu/Debian
apt install ansible -y

# Проверка
ansible --version

Файл инвентаря (inventory)

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com

[all:vars]
ansible_user=ubuntu
ansible_ssh_private_key_file=~/.ssh/id_rsa

Порядок миграции конфигурации на новый сервер

Опишите текущую настройку старого сервера в виде плейбука — пакеты, конфиги, сервисы.
Добавьте новый сервер во временную группу инвентаря, отдельную от продакшена.
Примените плейбук к новому серверу с флагом --check — это тестовый прогон без реальных изменений.
Примените плейбук по-настоящему и сравните конфигурацию нового и старого сервера вручную.
Переведите новый сервер в боевую группу инвентаря только после успешной проверки.

Пример плейбука: установка Nginx

---
- name: Install and configure Nginx
  hosts: webservers
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
        update_cache: yes

    - name: Start and enable nginx
      systemd:
        name: nginx
        state: started
        enabled: yes

    - name: Deploy config
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: reload nginx

  handlers:
    - name: reload nginx
      systemd:
        name: nginx
        state: reloaded

Запуск плейбука

# Тест (dry-run)
ansible-playbook -i inventory.ini setup.yml --check

# Реальный запуск
ansible-playbook -i inventory.ini setup.yml

⚠️ Всегда запускайте с --check перед применением к production-серверам.

Сравнение способов настройки нового сервера

Способ	Повторяемость	Скорость на десяти серверах
Ручная настройка по инструкции	низкая — легко пропустить шаг	медленно, линейно растёт со временем
Bash-скрипт настройки	средняя — зависит от качества скрипта	быстро, но хрупко при различиях в ОС
Ansible-плейбук	высокая — идемпотентен по конструкции	быстро, один запуск на все серверы

Проверка результата на новом сервере до переключения

# Сравниваем список установленных пакетов
ansible webservers -i inventory.ini -a "dpkg -l nginx"

# Проверяем, что сервис действительно слушает порт
ansible webservers -i inventory.ini -a "ss -tlnp | grep :80"

Команда ansible ... -a выполняет разовую команду на всех серверах группы без написания плейбука — удобно для быстрой сверки состояния перед переключением трафика на весь новый парк серверов.

Типичные ошибки

Ошибка	Причина и решение
UNREACHABLE! Failed to connect to the host via ssh	Неверный путь к ключу в `ansible_ssh_private_key_file` или сервер не в списке known_hosts
FAILED! Missing sudo password	Нужен пароль для `become` — запустите с флагом `--ask-become-pass`
fatal: [host]: FAILED! => {"msg": "no python interpreter found"}	На минимальном образе ОС не установлен Python — укажите `ansible_python_interpreter` явно

Откат изменений

Храните плейбуки в git — откат конфигурации сводится к применению предыдущей версии плейбука.
Перед рискованными изменениями снимайте снапшот сервера на уровне VDS-панели, если это виртуальная машина.
Если после прогона плейбука сервис не поднимается, откатите последний коммит плейбука и прогоните заново.

Когда Ansible не подходит

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

Проверка после применения плейбука

Прогоните плейбук повторно — идемпотентный плейбук на втором запуске должен показать 0 изменений (changed=0).
Сверьте версии установленных пакетов на новом сервере с эталонными из плейбука.
Проверьте логи systemctl status для каждого сервиса, поднятого через плейбук.

Автоматизированный деплой поверх настроенных Ansible серверов описан в статье zero-downtime деплой: blue-green и rolling стратегии.