Аннотация
Если вы ищете, как в Ansible работать с файлами, пользователями и сервисами, — вы по адресу. За одну статью разберём copy/fetch/synchronize/unarchive/get_url, затем user/group/authorized_key/sudoers, и в конце — service/systemd + cron/timers. Всё по-человечески: боль → решение → шаги → подводные камни → мини-итог и три мини-практики, которые можно повторить на своей машине.
Зачем это вообще нужно (простыми словами)
Одна из самых частых «бытовых» задач инженера:
- доставить файл (бинарник, конфиг, архив),
- завести доступы людям,
- запустить сервис и следить, чтобы он жил по расписанию.
Ansible хорош тем, что вы делаете это одинаково на 1 сервере и на 100 — и результат получается предсказуемым.
Ручные правки на проде — как “я только чуть-чуть трону провод” 😄
1) Файлы и архивы: copy, fetch, synchronize, unarchive, get_url
Боль
«Я залил файл на сервер… а он оказался битый» / «Скачал архив… распаковалось не туда» / «Нужно быстро раздать бинарник на 20 машин».
Решение
Используем модули Ansible, которые умеют проверять, менять только когда нужно и не делать лишнего.
copy — положить файл на сервер
Когда использовать: конфиги, маленькие файлы, шаблоны.
Пример: кладём бинарник и сразу задаём права.
Подводные камни
- copy копирует файл с вашей машины / из репозитория, а не с удалённого сервера.
- Для больших файлов и пачек — удобнее synchronize.
get_url — скачать файл по ссылке на сервер
Когда использовать: артефакты релизов, пакеты, архивы.
Практика: “раздать бинарник и проверить checksum”
Checksum — это «контрольная сумма» (короткая подпись файла), чтобы понять, что файл не испорчен.
Где взять sha256? Обычно его публикуют рядом с релизом. Если файл у вас локально: sha256sum mytool.
unarchive — распаковать архив
Подводные камни
- remote_src: true означает: архив уже на сервере, не надо тянуть с вашей машины.
fetch — забрать файл с сервера к себе
Когда использовать: логи, дампы, отчёты.
synchronize — быстро синхронизировать каталоги
Это удобная обёртка над rsync (быстро копирует только изменения).
Подводные камни
- На управляемой машине нужен rsync.
- Хорошо подходит для много файлов / большие объёмы.
Мини-итог блока
Файлы в Ansible — это не «копипаст», а управляемая доставка: скачали, проверили, разложили, при необходимости распаковали, и умеем забрать обратно.
2) Пользователи и ключи: user, group, authorized_key, sudoers
Боль
«Новый человек пришёл — надо дать доступ, но аккуратно» / «Ключи поменялись» / «Кто-то залогинился под root…».
Решение
Создаём пользователей и ключи как код: повторяемо, прозрачно, откатно.
group + user — завести группу и пользователя
authorized_key — добавить SSH-ключ пользователю
Практика: “пачка пользователей + их ключи”
Самая удобная схема для онбординга — список пользователей.
sudoers — дать права sudo безопасно
Лучше не править /etc/sudoers руками. Делайте файл в /etc/sudoers.d/ и обязательно проверяйте валидность.
Подводные камни
- validate — спасение. Без него можно «сломать sudo» и потом грустить.
- Не давайте NOPASSWD всем подряд — только тем, кому реально нужно.
Мини-итог блока
Пользователи и доступы — идеальный кандидат для автоматизации: меньше ошибок, быстрее онбординг, прозрачные изменения.
3) Сервисы и таймеры: service/systemd, cron, timers
Боль
«Сервис не стартует после ребута» / «Нужно раз в 5 минут проверять здоровье» / «cron где-то есть, а где-то нет».
Решение
Управляем сервисами через systemd и задаём расписания — либо cron, либо systemd timers (таймеры systemd).
service (systemd) — включить и запустить сервис
Практика: health-скрипт по cron
- кладём скрипт
- ставим расписание.
Подводные камни cron
- Окружение в cron «беднее», чем в вашей интерактивной сессии. Всегда используйте полные пути к командам.
Альтернатива: systemd timer (когда хотите “как сервис”)
Идея: скрипт запускается как unit-сервис, а таймер дергает его по расписанию. Это часто удобнее, чем cron: видно статус, логи, ошибки.
Сервис unit:
Таймер unit:
Включаем таймер:
Мини-итог блока
Сервисы и расписания — это про «чтобы работало всегда»: старт при ребуте, понятные логи, регулярные проверки.
Почему всё это так работает
- Ansible старается быть идемпотентным: если всё уже как надо — он не ломает и не делает лишнего.
- Модули знают, что и как проверять: права, наличие файла, содержимое, состояние сервиса.
- Благодаря этому вы можете запускать playbook хоть каждый день — результат будет стабильным.
Что сделали
- Научились доставлять файлы и артефакты: copy/get_url/unarchive/synchronize/fetch.
- Разобрали онбординг пользователей и SSH-доступ: group/user/authorized_key/sudoers.
- Поняли, как управлять сервисами и расписаниями: service/systemd, cron, systemd timers.
Сделать прямо сейчас (мини-чеклист)
- Возьмите один сервер (хоть VM) и:
раздайте файл через copy и скачайте через get_url с checksum;
заведите 1–2 пользователей и добавьте им ключи через authorized_key;
включите любой сервис enabled: true;
сделайте health-скрипт и запустите его по cron или systemd-timer.
CTA
Подпишитесь и напишите в комментариях: что вам ближе для расписаний — cron или systemd timers, и почему?