Ansible
Инструмент управления конфигурацией: описывает состояние серверов в YAML-плейбуках и приводит их к нему по SSH, без агентов.
Что такое Ansible
Ansible — инструмент управления конфигурацией и автоматизации: вы описываете в YAML-файле, каким должен быть сервер (какие пакеты, конфиги, пользователи, службы), запускаете одну команду — и Ansible приводит к этому состоянию хоть один сервер, хоть сотню.
Два свойства объясняют его популярность:
- Без агентов. На управляемых машинах ничего устанавливать не нужно — Ansible подключается по SSH и выполняет модули на месте. Требуется только Python на целевом хосте. Конкуренты (Puppet, Chef, Salt) требуют своего демона на каждом сервере.
- Идемпотентность. Плейбук описывает состояние, а не шаги. Запустите его десять раз — сервер изменится только в первый: модули сначала проверяют текущее состояние и ничего не делают, если оно уже целевое. Bash-скрипт при повторном запуске так себя не ведёт.
Ansible — часть подхода IaC: плейбуки лежат в Git, проходят code review, а история коммитов становится журналом изменений инфраструктуры.
Из чего состоит
| Понятие | Что это |
|---|---|
| Inventory | Список хостов и групп, к кому применять |
| Playbook | YAML-файл: что и на каких хостах привести в порядок |
| Play | Блок плейбука: группа хостов + список задач |
| Task | Один вызов модуля |
| Module | Готовый кирпичик: apt, copy, service, user, docker_container |
| Role | Переиспользуемый набор задач, шаблонов и переменных |
| Handler | Задача, выполняемая только при изменении (обычно перезапуск службы) |
| Vault | Шифрование секретов прямо в репозитории |
Inventory — список хостов и групп, к которым применяется плейбук:
[web]
web-01 ansible_host=10.0.1.10
web-02 ansible_host=10.0.1.11
[gpu]
gpu-01 ansible_host=10.0.3.10
[all:vars]
ansible_user=deploy
ansible_ssh_private_key_file=~/.ssh/deploy_ed25519
Что такое playbook
Playbook (плейбук) — YAML-файл, описывающий желаемое состояние группы хостов. Это центральный объект Ansible: не «сценарий команд», а декларация результата.
- name: Настроить веб-серверы
hosts: web
become: true
vars:
app_port: 8000
tasks:
- name: Установить пакеты
ansible.builtin.apt:
name: [nginx, ufw]
state: present
update_cache: true
- name: Выложить конфиг nginx
ansible.builtin.template:
src: templates/app.conf.j2
dest: /etc/nginx/conf.d/app.conf
owner: root
mode: '0644'
notify: Reload nginx # handler сработает только при изменении файла
- name: Служба запущена и в автозагрузке
ansible.builtin.service:
name: nginx
state: started
enabled: true
handlers:
- name: Reload nginx
ansible.builtin.service:
name: nginx
state: reloaded
Конструкции, ради которых плейбук лучше скрипта: template подставляет переменные в конфиг через Jinja2 (один шаблон на все окружения), а notify/handlers перезапускают Nginx только если конфиг реально изменился.
Запуск
ansible-playbook -i inventory.ini site.yml
ansible-playbook -i inventory.ini site.yml --check --diff # dry-run: что изменится
ansible-playbook -i inventory.ini site.yml --limit web-01 # только один хост
ansible-playbook -i inventory.ini site.yml -f 20 # 20 хостов параллельно
ansible all -i inventory.ini -m ping # разовые команды
ansible web -i inventory.ini -a "uptime"
--check --diff — привычка, которая экономит нервы: показывает изменения, ничего не применяя.
Секреты
Пароли в открытом виде в репозитории недопустимы. Ansible Vault шифрует значения на месте — в Git уезжает шифротекст:
ansible-vault encrypt_string 'S3cretP@ss' --name 'db_password'
ansible-vault edit group_vars/prod/vault.yml
ansible-playbook site.yml --ask-vault-pass
Альтернатива для больших установок — подтягивать секреты из HashiCorp Vault во время выполнения.
Ansible и Terraform: разные слои
Частый вопрос — что выбрать. Ответ: обычно оба, они про разное.
| Terraform | Ansible | |
|---|---|---|
| Задача | Создать инфраструктуру (серверы, сети, диски) | Настроить то, что создано |
| Модель | Декларативная, хранит state | Приводит к состоянию, state не хранит |
| Уровень | Провайдер облака | Внутренности ОС |
Типовая связка: Terraform поднимает облачные серверы → cloud-init делает первичную настройку и кладёт SSH-ключи → Ansible доводит систему до рабочего состояния → приложение выкатывает CI/CD.
Ansible для GPU-серверов
Ровно тот случай, где Ansible оправдан на все сто: поднять драйверы и окружение на новом GPU-инстансе вручную — это час работы и шанс ошибиться в версиях, плейбуком — минуты и одинаковый результат на всём парке.
- name: Подготовить GPU-хост
hosts: gpu
become: true
tasks:
- name: Драйвер и NVIDIA Container Toolkit
ansible.builtin.apt:
name: [nvidia-driver-550, nvidia-container-toolkit]
state: present
notify: Restart docker
- name: Проверить, что карта видна
ansible.builtin.command: nvidia-smi
changed_when: false
handlers:
- name: Restart docker
ansible.builtin.service:
name: docker
state: restarted
Плейбук ставит драйвер NVIDIA и NVIDIA Container Toolkit — минимум, после которого Docker на хосте начинает видеть GPU. Повторный запуск на настроенной машине не изменит ничего.
Связанные термины
- GitOps / IaC — подход, к которому относится Ansible
- SSH — транспорт, по которому Ansible работает
- cloud-init — первичная настройка машины до Ansible
- CI/CD — откуда обычно запускают плейбуки
- Linux — то, чем Ansible управляет
- NVIDIA Container Toolkit — типичная цель установки на GPU-хостах
Готовы запустить GPU-задачу?
Запустить GPU-сервер