Ansible для самых ленивых.

Есть много инструментов позволяющих не отрывать свою задницу от мягкого кресла и ansible в этом ряду занимает почетное… высокое место. Ниже рассмотрим, как минимальными телодвижениями получить годный инструмент по накоплению калорий.

В двух словах, ansible это инструмент, который позволяет по ssh массово развешивать пинки удаленным компам, это называется push-архитектура, что бы удаленные компы приходили за пинками сами существует ansible-pull и некоторые другие продукты, но в pull-архитектуру сейчас лезть не будем.

Сразу укажу три полезных источника информации:
Книга Основы Ansible для сетевых инженеров (2022)
Книга Запускаем Ansible (2023)
Документация на сайте docs.ansible.com

Для эксперимента понадобятся три скажем так рабочих станции, с неймингом мудрить не будем, по аналоги с виски танго фокстрот назовем их сокращениями от альфа браво чарли плюс названия оси.

al-win — комп на десятой винде, наш основной рабочий инструмент с ведьмаком и киберпанком (инструкция для ленивых, поэтому брать другую ось смысла нет)
br-ubu — комп, ну или почти комп на убунте или любом другом вменяемом лине (именно на нем будет установлен ansible)
ch-mos — комп жертва, их может быть несколько, в качества базовой оси возьмем используемый в хозяйстве максимальный треш в виде мос12

Итак, прелюдия, назовем это главой «Предварительные ласки». Так как это ленивая тема, то крутить виртуалку или точить отдельную рабочую станцию влом ибо есть такая прекрасная штука, как Windows Subsystem Linux.
На al-win обновим ос последнего билда и установим простой инструмент под названием «Подсистема Windows для Linux». Это можно сделать через панель управления.

Так же это можно сделать с помощью powershell командой

wsl --install

Во втором случае автоматом будет установлен линукс по умолчанию, то бишь убунта (не забываем указать логин/пароль линуксового пользователя)

Возможно так же понадобиться добавить инструменты виртуализации, если они ранее не были установлены

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

Посмотреть список доступных для установки линей можно командой

wsl --list --online

Установить нужный линь можно командой
wsl --install Ubuntu-22.04

Удалить
wsl --unregister Ubuntu-22.04

Список команд wsl можно глянуть по ссылке https://learn.microsoft.com/ru-ru/windows/wsl/basic-commands

Следует добавить, что файловая система установленного линя доступна в винде по шаре \\wsl$ либо \\wsl.localhost, для удобства выбранный дистрибутив можно подцепить как сетевой диск шарой типа \\wsl.localhost\Ubuntu и работать с текстовыми файлами удобным инструментарием из под винды

Так же диски винды будут доступы из линя в стандартной /mnt

Важно! Повторюсь, в качестве рабочей станции для установки ansible может быть выбрана любая машина с вменяемым линем, хоть железная, хоть виртуальная, в данном случае вариант с wsl используется лишь для удобства работы с файлами из под винды. Кроме того, про него знают не только лишь все и это откровение может быть полезно.

Прелюдия закончена, теперь переходим к этапу очень долгого и очень муторного процесса установки самого ansible, пусть это будет глава «Начало». В меню пуск находим значек Ubunta, запускаем, попадаем в терминал.
Накатываем обновления, в целом необязательно, но полезно

sudo apt update

sudo apt upgrade

 Далее добавляем репу ансибля и устанавливаем виновника торжества

sudo apt update

sudo add-apt-repository --yes --update ppa:ansible/ansible

sudo apt install ansible

Возможно понадобится поставить дополнительные компоненты (в последних релизах они либо уже установлены, либо ставятся в пункте выше, но возможны сюрпризы)

sudo apt install software-properties-common

sudo apt install python3-yaml python3-jinja2 python3-paramiko python3-cryptography

Как видно из названия модулей, используется питон, если по каким то причинам его нет, то необходимо будет установить.

Собственно все, ансибль установлен, можно смело делать перерыв на ирландский чай и пару миссий киберпанка.

Далее идет глава «После. Начало». В разных доках долго и нудно расписывается его структура, конфигурации и прочая скучная хрень, это конечно ценно и полезно, но только после самостоятельного зажигательно танца по граблям (главный ресурс на эту тему https://docs.ansible.com/ansible/latest/)

На данный момент важно знать про два файла.

Первый файл /etc/ansible/ansible.cfg, изначально он пуст, в грубом приближении это тюнинг ансибли, полезно в него сходу впихнуть пару параметров

[defaults]

host_key_checking = False

interpreter_python = auto_legacy_silent

Первый говорит ансибле забить болт на чек ssh ключей, ибо лень возиться с ключами, подключаться будем просто по логину/паролю
Второй рекомендует заткнуться на тему старый версий питона на компах, которые мы этой самой ансиблей и будем мучить.

Второй файл, на который следует обратить внимание, файл инвентаризации/инвентаря (inventory), по умолчанию это /etc/ansible/hosts, в нем перечисляются компы, с которыми предстоит работать ансибле и различные параметры этой самой работы.

В качестве жертвы у нас выступает ch-mos, внести его файл можно в любом виде, хоть по имени, хоть по ип, на нашем варианте укажем и имя (шоб красиво) и ип (ибо лень возиться с днс)

[mos]

ch-mos  ansible_host=192.168.1.10

Указание блока [mos] не обязательно, но полезно если в большом ворохе внесенных в файл инвентаризации компов нам надо будет работать с отдельной группой.

Так же имеет смысл внести в этот файл дополнительные параметры, в нашем случае параметры соединения и пароли

[all:vars]

ansible_connection=ssh

ansible_user=setup

ansible_ssh_pass=1

ansible_become_pass=1

Важно! Никогда так не делайте, пароли не должны храниться во всяких там конфигурациях, ясен пень что лучше настроить авторизацию с помощью ssh ключей. Но если лень… вообщем этот вариант исключительно если лень.

В итоге выглядеть файл инвентаризации будет примерно так

Там конечно будет еще куча всяких комментариев, на тему разных вариаций указания хостов, полезно, но опционально.

Следующая глава. «После. Все еще начало»

Запускаем ch-mos, из основного:

• оно должно быть в сети
• в нашем случае должен иметь ип 192.168.1.10
• должен быть доступен по ssh
• у пользователя который подключается по ssh дожны быть права на sudo (в нашем случае пользователь зовется setup с паролем 1)

Если все совпадает с реальностью, то на убунте запускаем скучнейшую команду из учебника

ansible all -m ping

Где all говорит что команда отрабатывает по всем компам, указанным в файле инвентаризации (если указать например mos, то отрабатывать будет только по компам, указанным в блоке mos)

Ключ m прямо указывает на модуль, который собственно и будет отрабатывать, в данном случае обычный пинг

На выходе получаем (либо не получаем) что-то типа

Единственный интересный момент здесь, так это то, что файл инвентаризации не обязательно должен быть расположен в /etc/ansible, править его придется достаточно часто, кроме того возможно таких файлов будет несколько под разные задачи. Имеет смысл держать его в папке home пользователя, например завести какой-нибудь файл типа hosts-test, в этом случае команда будет выглядеть следующим образом

ansible all -m ping -i hosts-test

Ключ i указывает на расположение файла инвентаризации

На этом работа непосредственно с модулями всё, список доступных модулей можно глянуть по ссылке https://docs.ansible.com/ansible/latest/collections/index_module.html

Ну и вообщем… типа удачи там, по ссылке. А когда волосы в самых нескромных местах снова уляжутся, можно будет перейти к следующей части.

Глава «The Playbook. Be awesome».

Основная фишка с которой приятно будет побаловаться это плейбуки, по сути это сценарии, наборы задач, которые формируются из относительно простых блоков. Например вот так будет выглядеть плейбук на тот самый пинг

Запустить его можно командой

ansible-playbook -i hosts-test ping.yml

Результат выполнения

Главный момент — это YAML и пробелы важны, в остальном же данный плейбук состоит из:

hosts: указывает на работу со всем компами, указанными в файле hosts-test (естественно можно указывать отдельные группы)

gather_fact: в нашем случае указывает ансиблю не собирать информацию о состоянии компом (например включены или выключены), по умолчанию этот параметр имеет значения yes, в данном случае сделано что бы не тратить время на лишние проверки

task: собственно перечень задач, в нашем случае одна задача с действием ping

Теперь чуть более сложный и вредный, но если прям лень, то полезный вариант плейбука

remote_user: setup — под кем подключаться, опционально, в файле инвентаризации уже есть переменная ansible_user=setup

become: yes – так как в этом плейбуке идет работа с системными файлами, то указываем что нужно повышение прав

become_user: root – повышение прав до пользователя рут

become_method: sudo – метод повышения прав судо

tasks: — задач в данном плейбуке три

— с помощью модуля lineinfile (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/lineinfile_module.html) меняем закомментированную строчку на не закомментированную, что бы разрешить пользователю рут подключаться по ssh

— с помощью модуля user (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html) меняем пароль пользователя (естественно указан хэш пароля, к примеру его можно получить командой mkpasswd -m sha512crypt)

— с помощью модуля service (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/service_module.html) перезапускаем службу sshd

Выполнение плейбука

ansible-playbook -i hosts-test root-ssh.yml

Результат выполнения этого плейбука

Результат повторного выполнения плейбука

Те задачи которые уже были выполнены (changed) в первом запуске, при повторном запуске не отрабатывают (ok), так как изменения уже были внесены (за исключением перезапуска службы, она по понятным причинам будет перезапускаться каждый раз)

Конечно можно было все три задачи выполнить одним шагом через модуль shell (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/shell_module.html), но тогда сложные плейбуки потеряют информативность и будет тяжело отследить например где случился затык и почему ничего нихрена не работает, но это исключительно вопрос вкуса и личных предпочтений.

Важно! Если используется правильный вариант авторизации по ssh-ключам, то естественно логины и пароли в файле конфигурации указывать не надо, в том числе и ansible_become_pass, если при выполнении плейбука требуются повышенные права, то при запуске можно указать параметр -K, в этом случае пароль будет запрошен сразу после ввода команды (выглядеть это будет например так ansible-playbook -i hosts-test root-ssh.yml -K)

Так как это ленивый мануал, то всё. Главная идея ansible — лучше день потерять, зато за 5 минут долететь. Этот инструмент позволяет автоматизировать немало задачь, от простой массовой правки конфигов и копирования файлов до установки софта и например подключения к домену, как для линуксовых машин, так и для виндовых.

Описание встроенных модулей и примеры их использования можно найти по ссылке https://docs.ansible.com/ansible/latest/collections/ansible/builtin/index.html

PS: про то, какими модулями рулить компами на винде, можно глянуть здесь https://docs.ansible.com/ansible/latest/collections/ansible/windows/index.html, для винды рекомендую установить на клиентов openssh, так как winrm местами ведет себя… странно.

2