null

Знакомство с Ansible. Часть 1.

Вместо предисловия.

Автор ни в коем случае не претендует на истину в последней инстанции, и не настаивает на том что его способ решения конкретной задачи получился  наиболее правильным и оптимальным. Это просто рассказ о том, как за ~~неделю переменной активности  автор из стадии "я слышал что оно существует" пришел к стадии "я написал плейбук, который решает мою задачу", и что в процессе удалось узнать об устройстве и принципах работы Ansible.

Итак, приступим. 
 

Описание поставленной задачи:

Для проведения лабораторных работ есть полностью укомплектованная  лезвиями корзина. На каждый сервер ставится CentOS, в котором производятся некие базовые настройки и устанавливается QEMU-KVM. При этом QEMU необходимо собрать из исходников,чтобы использовать некоторые его возможности(необязательно последней версии, чтобы не возиться с зависимостями).

После чего создаются виртуальные машины, к которым мы цепляем необходимый образ. Установку гостевой ОС будут проиводить уже сами обучающиеся.  В качестве гостевой ОС мы будем использовать гипервизор, т.е. получится nested virtualization.

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

Имеющиеся проблемы:

  1. Гайд, хоть и достаточно подробный все же опускает какие-то  вещи по типу, сначала укажи DNS сервер, потом скачивай архив с qemu. Т.е. просто бездумно копипастить команды не выйдет.
  2. Примеры конфигурационных файлов есть, но, опять же, их нужно редактировать под конкретную систему.
  3. Часть гайда устарела, либо ее выполнение не обязательно на текущей системе, либо допущенны ошибки в командах(забыли ключ, не указали параметр и т.д.). Т.е. знает как это целиком должно работать только тот человек который этот гайд писал, для всех остальных есть эмпирический метод нахождения ошибок.
  4.  QEMU собирается из сходников достаточно долго, а закрывать ssh сессию в этот момент нельзя. Ну и вообще сидеть и поочередно вводить одни и те же команды(пусть даже и методом копипаста)  на 10 серверах - не очень увлекательно.

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

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

Почему Ansible? 

Основных факторов было три:

  1. Не требуется установка агента, все взаимодействие происходит по ssh, т.е.  первоначальная настройка управляемых узлов  минимальна.
  2. Работает по модели push. Это удобно, когда  нужно выполнить ряд команд и забыть. 
  3. В отличие от 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 и готовы к написанию плейбука. 

Назад Вперед

Коротко о себе:



​​​​​​​Работаю инструктором в компании Tune-it. Занимаюсь какими-то проектами, связанными с чем-то.

Ничего не найдено. n is 0