Вместо предисловия.
Автор ни в коем случае не претендует на истину в последней инстанции, и не настаивает на том что его способ решения конкретной задачи получился наиболее правильным и оптимальным. Это просто рассказ о том, как за ~~неделю переменной активности автор из стадии "я слышал что оно существует" пришел к стадии "я написал плейбук, который решает мою задачу", и что в процессе удалось узнать об устройстве и принципах работы Ansible.
Итак, приступим.
Описание поставленной задачи:
Для проведения лабораторных работ есть полностью укомплектованная лезвиями корзина. На каждый сервер ставится CentOS, в котором производятся некие базовые настройки и устанавливается QEMU-KVM. При этом QEMU необходимо собрать из исходников,чтобы использовать некоторые его возможности(необязательно последней версии, чтобы не возиться с зависимостями).
После чего создаются виртуальные машины, к которым мы цепляем необходимый образ. Установку гостевой ОС будут проиводить уже сами обучающиеся. В качестве гостевой ОС мы будем использовать гипервизор, т.е. получится nested virtualization.
И собссно, имеется гайд, в котором описаны какие командочки нужно ввести и какие изменения нужно произвести в системе чтобы получить нужное окружение.
Имеющиеся проблемы:
- Гайд, хоть и достаточно подробный все же опускает какие-то вещи по типу, сначала укажи DNS сервер, потом скачивай архив с qemu. Т.е. просто бездумно копипастить команды не выйдет.
- Примеры конфигурационных файлов есть, но, опять же, их нужно редактировать под конкретную систему.
- Часть гайда устарела, либо ее выполнение не обязательно на текущей системе, либо допущенны ошибки в командах(забыли ключ, не указали параметр и т.д.). Т.е. знает как это целиком должно работать только тот человек который этот гайд писал, для всех остальных есть эмпирический метод нахождения ошибок.
- QEMU собирается из сходников достаточно долго, а закрывать ssh сессию в этот момент нельзя. Ну и вообще сидеть и поочередно вводить одни и те же команды(пусть даже и методом копипаста) на 10 серверах - не очень увлекательно.
Исходя из всего вышеперечисленного, хотелось получить решение, которое способно по нажатию одной кнопки развернуть весь необходимый софт и произвести необходимые настройки на всех системах.
Помочь в решении данной задачи нам должны системы управления конфигурациями, кои существуют уже достаточно давно и активно используются для задач автоматизации.
Почему Ansible?
Основных факторов было три:
- Не требуется установка агента, все взаимодействие происходит по ssh, т.е. первоначальная настройка управляемых узлов минимальна.
- Работает по модели push. Это удобно, когда нужно выполнить ряд команд и забыть.
- В отличие от Puppet или Chef не трубует знания Ruby для полноценной работы.
Итак, выбор сделан! Приступим к знакомству.
Итак, первое что нам нужно сделать это установить contoll node, который и будет управлять остальными узлами.
Здесь и далее предполагается, что на управляемые ноды уже установлен CentOS, на них настроен корректный ip-адрес, указан адрес DNS сервера и разрешено подключение по ssh пользователю root. Других настроек не требуется.
Поскольку ansible написан на python, требется его наличие в системе. Т.к. он есть в зависимостях, ставить его в ручную нужды нет.
Для установки используем команды
$ sudo yum install epel-release
$ sudo yum install ansible
$ sudo yum install python-argcomplete
Последняя команда установит необязательный модуль автодополнения команд.
Следующее что нужно сделать это настроить inventory. Inventory - это тот файл, в котором мы указываем группы хостов, которыми планируем управлять.
По умолчанию это /etc/ansible/hosts и в нем уже содержатся некоторые примеры.
Давайте рассмотрим что может быть в его содержимом
[kvm]
192.168.X.1
192.168.X.2
node03
node4 ansible_host=192.168.X.4
[web]
webserver01
[web:vars]
apache_listen_port=8080
[production:children]
kvm
web
somenode
[all:vars]
ansible_user=ansible
Итак первое, что нужно сделать - это придумать имя нашей группе серверов. Оно указывается в [ ].
После этого мы указываем сервера, которые входят в данную группу. Можно использовать IP адреса или FQDN. В рамках одной группы эти форматы можно совмещать.
Конструкция вида node4 ansible_host=192.168.X.4 нужна, чтобы в случае, если нода будет недоступна по имени(например, если DNS сервер недоступен) контроллер смог обратиться к ней по указанному адресу.
Важный момент - плейбук будет выполняться только на тех нодах в группе, доступ к которым он смог получить.
Для каждой группы мы можем определить какие-то переменные. Например, для группы web мы указали что apache слушает порт 8080.
Также переменные можно указать для всех групп, в примере выше таким образом указывается переменная ansible_user.
Группа может содержать в себе другие группы, либо другие группы и узлы, как в примере с группой production:children, которая содержит в себе гурппы kvm и web, а также узел somenode.
Поскольку в нашем сценарии предполагается минимальная первоначальная настройка управляемых узлов, группа будет представлять собой простое перечисление ip-адресов необходимых узлов.
У ansible есть несколько методов подключения. При большом количестве узлов как правило используются ssh-ключи, этот путь так же предпочтителен с точки зрения безопасности.
Однако, в нашем случае проще один раз ввести пароль при запуске плейбука, чем создавать ключи и раскладывать их по узлам.
По умолчанию для подключения используется пользователь root. И т.к. Ansible по умолчанию проверяет ssh fingerprint узла, нам необходимо подключиться к каждой ноде, чтобы соотвествующие записи попали в known_hosts.
Эти и другие настройки можно изменить в файле /etc/ansible/ansible.cfg .
Таким образом, путем нехитрых манипуляций мы установили contoll node и готовы к написанию плейбука.