Навіщо 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 стратегії.