Что такое модуль в Ansible?

Слушай, давай разжую про модули Ansible, а то некоторые думают, что это какая-то магия, а на деле всё просто, как три копейки. Представь себе, что модуль — это такой маленький, но зубастый скрипт-исполнитель. Написан он может быть на чём угодно — Python, PowerShell, хоть на Ruby. Задача у него одна, зато конкретная: прийти на удалённый сервер и сделать там ровно одно дело. Это как раз те самые кирпичики, из которых потом складываются целые плейбуки. Ansible ему аргументы суёт, модуль на той стороне отрабатывает и отчитывается в формате JSON. Всё, приехали.

Теперь про главные фишки, без которых нихуя не работает:

1. Идемпотентность. Это модное слово означает простую вещь: если ты второй раз наткнулся на ту же кнопку, ничего не должно ебнуться. Запустил задачу — пакет установился. Запустил ещё раз — модуль посмотрел, что пакет уже на месте, и просто пожимает плечами: «changed: false, чувак, всё уже есть, расслабься». Красота же.
2. Факты. Есть специальные модули-шпионы, типа setup. Их работа — обшарить систему и набрать инфы: какой процессор, сколько памяти, какие диски. Вся эта куча данных потом превращается в переменные, которые можно тыкать куда угодно. Очень удобно.
3. Состояние (State). Это вообще гениально. Ты не говоришь системе «сделай вот это», ты говоришь «я хочу, чтобы было вот так». Например, state: present для файла — «будь, сука, на месте». А дальше модуль сам соображает, что делать: создать его или просто проверить, что он уже есть.

Вот смотри, как это выглядит в жизни, на примере настройки Nginx. Код ниже — это святое, не трогаем его.

- name: Deploy Nginx configuration template
  ansible.builtin.template:
    src: templates/nginx.conf.j2
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
  notify: restart nginx  # Запускает handler при изменении

- name: Ensure Nginx service is running and enabled
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: yes

Видишь? Первая задача говорит: «Хочу, чтобы конфиг лежал по такому-то пути, с такими-то правами». Вторая — «Хочу, чтобы служба nginx была запущена и влюблена в автозагрузку». Всё. Чётко и по делу.

А теперь, ёпта, самое интересное — как эти модули вписываются в реальную жизнь девопса. Тут целый зоопарк:

• Облачные модули (типа amazon.aws.ec2_instance). Это твой Infrastructure as Code в чистом виде. Написал плейбук — и понеслась: виртуалки, сети, балансировщики. Овердохуища возможностей, если честно.
• Модули для оркестрации. Нужно дернуть API Grafana, чтобы дашборд обновить? Или запустить пайплайн в Jenkins? Пожалуйста, для этого тоже есть свои модули. Они как удалённые руки, которые могут всё.
• Модули для мониторинга и логов. Чтобы не бегать по серверам и не копировать конфиги агентов вручную, есть модули, которые всё развернут и настроят. Доверия ебать ноль к ручному труду после этого.
• Свои, кастомные модули. А если вдруг нужной фичи нет? Да похуй! Берёшь Python и пишешь свой. Например, для управления какой-нибудь внутренней, пиздопроебибной системой деплоя, которую кроме вас никто не использует.

Ну и на последок, как же это всё работает под капотом, а? Всё просто до безобразия. Ansible закидывает этот модуль-исполнителя на целевой хост, запускает его с твоими аргументами, ждёт, когда тот отрапортует JSON'ом, а потом прибирает за собой — удаляет скрипт. В ответе всегда есть ключевые поля: поменялось ли что-то (changed), сломалось ли (failed), что за сообщение (msg). В общем, хитрая жопа, но логичная.