Что такое Ansible простыми словами
Если совсем коротко, то Ansible это open-source инструмент автоматизации и управления конфигурацией от Red Hat. Ты описываешь желаемое состояние системы в текстовых файлах формата YAML, а Ansible приводит твои серверы к этому состоянию. Поставить nginx, открыть порт 443, положить конфиг, перезапустить сервис, завести пользователя - всё это становится кодом, который лежит в git, ревьюится и повторяется одинаково хоть на одной машине, хоть на тысяче.
Когда говорят "ansible это про автоматизацию", имеют в виду три уровня задач. Первый - настройка серверов (configuration management): пакеты, файлы, службы, пользователи. Второй - деплой приложений: выкатка новой версии кода на пул хостов в нужном порядке. Третий - оркестрация: согласованные действия на группах машин, например "сначала выведи ноду из балансировщика, потом обнови, потом верни". И всё это - инфраструктура как код (IaC): конфигурация перестаёт жить в голове админа и переезжает в репозиторий.
Для тех, кто осваивает ansible для начинающих, важно сразу понять: ты пишешь не последовательность команд "сделай это, потом то", а описание результата. Это называется декларативность. Ты говоришь "пакет httpd должен быть установлен", а не "выполни dnf install httpd". Разница принципиальная, и к ней мы ещё вернёмся.
Agentless и push-модель: главное отличие Ansible
Вот первая суперсила. Ansible работает без агентов - agentless. На управляемые узлы не нужно ставить никакой демон, никакой постоянный процесс, который висит в памяти и слушает порт. Всё, что требуется на стороне сервера, у тебя уже есть: рабочий SSH и Python (а для управления сетевыми железками - даже без Python, по API).
Схема такая. Есть управляющая нода (control node) - твой ноутбук или выделенная машина, где установлен сам Ansible. Есть управляемые узлы (managed nodes) - те серверы, которые ты настраиваешь. Ansible подключается к ним по SSH, копирует туда временные модули, выполняет их, забирает результат и подчищает за собой. Это push-модель: инициатива всегда исходит от управляющей ноды, ты сам решаешь, когда и что применять. Сравни с pull-моделью, где на каждом сервере крутится агент и сам ходит за конфигом к мастеру.
Почему agentless - это так ценно на практике:
- Нет агентов - нечего ставить, обновлять и чинить на сотнях машин. Меньше движущихся частей.
- Нет лишней поверхности атаки: не открываешь дополнительный порт под демон, используешь уже проверенный SSH.
- Завёл новый сервер - он управляем сразу, как только туда пускает твой ключ. Никакого bootstrap агента.
- Меньше зависимостей: версия Ansible живёт на control node, а не размазана по всему парку.
И сразу разведём Ansible и Terraform, потому что новички их путают. Terraform поднимает саму инфраструктуру: создаёт виртуалки, сети, балансировщики, диски у облачного провайдера - то, чего ещё нет. Ansible настраивает то, что уже существует: операционную систему и приложения внутри машины. Грубая формула: Terraform строит коробку, Ansible наполняет её содержимым. Часто их используют вместе - Terraform выдал тебе голые серверы, Ansible превратил их в рабочий кластер.
Идемпотентность - почему ansible на linux безопасно запускать дважды
Второе ключевое свойство, ради которого Ansible вообще стоит изучать, - идемпотентность. Звучит страшно, смысл простой: повторный запуск не ломает уже настроенное. Если ты прогнал плейбук и всё в нужном состоянии, второй прогон ничего не сделает и честно скажет "changed=0". Модули сначала проверяют текущее состояние и меняют только то, что отличается от желаемого.
Сравни два подхода. Голый скрипт:
Код: Выделить всё
#!/bin/bash
useradd deploy
echo "listen 8080;" >> /etc/myapp/ports.conf
systemctl restart myapp
А вот задача на Ansible, описывающая состояние, а не действия:
Код: Выделить всё
- name: Веб-сервер должен быть установлен и запущен
hosts: web
become: true
tasks:
- name: Пакет httpd установлен
ansible.builtin.package:
name: httpd
state: present
- name: Служба httpd включена и работает
ansible.builtin.service:
name: httpd
state: started
enabled: true
- name: Порт https открыт в firewalld
ansible.posix.firewalld:
service: https
state: enabled
permanent: true
immediate: true
Маленькое замечание про дистрибутивы. В RHEL и Fedora пакеты ставит dnf, службами рулит systemd, фаервол - это firewalld, а ещё есть SELinux, который любит ронять чужие конфиги в enforcing. Модуль ansible.builtin.package сам выберет менеджер по факту ОС: на RHEL это dnf, на Ubuntu/Debian - apt, на российских RED OS или Astra Linux - их штатные репозитории (RED OS из rpm-семейства, Astra - из deb). Имена пакетов и сервисов всё равно различаются между семействами, и это нормально - такие развилки разрулим в следующих уроках через факты и переменные.
Типичные грабли новичков
- Думают, что Ansible надо "поставить на сервер". Нет. Ansible ставится только на control node. На управляемые узлы - ничего, кроме SSH и Python.
- Пишут плейбук как bash в YAML-обёртке: пачка ansible.builtin.command и shell на всё подряд. Так ты теряешь идемпотентность, ведь Ansible не знает, что делает твоя сырая команда. Правило: ищи специализированный модуль, а command/shell - крайнее средство.
- Путают Ansible и Terraform, пытаясь Ansible создавать виртуалки с нуля. Можно, но это не его сильная сторона - инфру лучше отдать Terraform.
- Игнорируют, что для системных задач нужен become: true (эскалация до root через sudo). Без него получишь permission denied на установке пакетов.
- Забывают, что на RHEL в строгом режиме SELinux и firewalld не дадут сервису заработать, даже если сам сервис настроен идеально. Конфиг есть, а порт закрыт - и кажется, что "Ansible не сработал".
Глубокую установку разберём отдельно, а пока сделай минимальный круг, чтобы прочувствовать agentless и idempotency.
- Поставь Ansible на control node (RHEL/Fedora): На Ubuntu/Debian аналог -
Код: Выделить всё
sudo dnf install -y ansible-coreКод: Выделить всё
sudo apt install -y ansible - Проверь версию и убедись, что бинарь на месте:
Код: Выделить всё
ansible --version - Создай файл inventory.ini с одной строкой - например localhost ansible_connection=local, чтобы не возиться с SSH на первом шаге.
- Дёрни модуль ping (это не ICMP, а проверка связи и Python на узле): Хороший ответ - "pong".
Код: Выделить всё
ansible all -i inventory.ini -m ansible.builtin.ping - Собери факты о машине и посмотри, что Ansible о ней знает:
Код: Выделить всё
ansible all -i inventory.ini -m ansible.builtin.setup - Сохрани плейбук с httpd из урока в site.yml и прогони дважды подряд: Во второй раз поймай глазами changed=0 - это и есть идемпотентность вживую.
Код: Выделить всё
ansible-playbook -i inventory.ini site.yml
- Что значит "Ansible agentless" и что реально требуется на управляемом узле для работы?
- Чем push-модель Ansible отличается от pull-модели Chef или Puppet?
- Что такое идемпотентность и почему голый bash-скрипт обычно ей не обладает?
- Как разделить зоны ответственности между Terraform и Ansible на одном проекте?
Ansible - это agentless-инструмент управления конфигурацией: подключается по SSH, работает по push-модели и описывает желаемое состояние декларативно, а не пошагово. Два слова, которые надо унести из урока, - agentless и идемпотентность: первое снимает боль с поддержки агентов, второе делает прогоны безопасными и повторяемыми. Рядом стоит Terraform (поднимает инфру), а Ansible её настраивает. Это и есть фундамент всего курса и базовый контекст для экзамена EX294 - дальше будем наращивать инвентари, переменные, роли и шаблоны.
