07/05/2020
Хотелось бы поговорить в этой статье о такой важной составляющей в работе системы управления Ansible, как файлы инвентаря и соответствующие переменные. Большая часть логики в работе Ansible содержится в соответствующих ролях, которые несут основную нагрузку при выполнении плейбуков. Но для полноценного понимания, как работает Ansible, необходимы знания о правильной настройке инвентаря и переменных для групп и конкретных хостов. С помощью правильно настроенных переменных мы можем направлять выполнение ролей в том или ином направлении. Это позволяет сделать Ansible чрезвычайно гибким и мобильным, а создаваемые роли более универсальными. Хороший пример, где без этого просто не обойтись — установка и настройка различного рода кластерного программного обеспечения. Как правило, в кластере есть сервер, выполняющий Master роль, и прочие сервера, что требует небольшого различия в проводимых настройках. Также, зачастую, различные сервера требует различных конфигураций в настройках одного и того же софта.
Безусловно, кроме инвентаря и ролей немаловажное значение в функционировании Ansible играют модули и дополнительные плагины, которые позволяют заметно расширить функционал системы управления. О том, как их использовать и создавать, мы поговорим в других статьях блога. Тут просто хотелось бы упомянуть, что используя все компоненты Ansible воедино, мы можем достигать максимальную отдачу от данной системы управления. При этом понимание того, как надо использовать инвентарь, а также настраивать переменные, является одной из базовых техник. Освоив ее в самом начале изучения Ansible, можно сразу начать выжимать из имеющихся ролей по максимуму.
Как использовать в реальной жизни
В первую очередь надо сказать, что для различных окружений развертывания мы можем использовать различные файлы инвентаря Ansible. Так для Dev окружения наш файл с описанием хостов будет dev, для qa окружения — соответственно qa, а для рабочего окружения — production. Однако кто-то делает описание всех хостов в одном файле инвентаря, после чего создает различные плейбуки для разных сред окружения. Это усложняет логику и структуру работы Ansible, а также создает возможность для ошибки при выполнении плейбуков.
Давайте, представим, что у нас есть Ansible проект, который занимается настройкой кластера keepalived на linux серверах нашего программного обеспечения. В папке проекта создадим следующие файлы и директории:
# ls -l
итого 8
-rw-rw-r-- 1 ansible ansible 0 мая 7 12:44 dev
drwxrwxr-x 2 ansible ansible 4096 мая 7 12:44 group_vars
drwxrwxr-x 2 ansible ansible 4096 мая 7 12:44 host_vars
-rw-rw-r-- 1 ansible ansible 0 мая 7 12:44 production
-rw-rw-r-- 1 ansible ansible 0 мая 7 12:44 qa
В файлах dev, qa и production укажем хосты, которые находятся в соответствующем окружении. Эти файлы абсолютно аналогичны /etc/ansible/hosts по формату содержимого. Пример содержимого файла dev может выглядеть следующим образом:
[keepalived-cluster]
dev-keepalived-01
dev-keepalived-02
dev-keepalived-03
В файлах qa и production будет содержаться аналогичная информация, только по хостам в окружении qa & production. Теперь скопировав роль и плейбук для keepalived в папку проекта, мы можем управлять различными окружениями, меняя только параметры выполнения плейбука. Так, чтобы заставить плейбук работать в окружении dev, выполним следующую команду.
# ansible-playbook ./keepalived.yml -i ./dev
Теперь посмотрим, какую гибкость дает нам использование переменных в директориях group_vars & host_vars при выполнении наших плейбуков и ролей. Так в кластере keepalived один из хостов у нас будет выполнять роль Master, а другие Backup. Если мы по умолчанию в роли установим переменную vrrp_state равную Backup, то в файле dev-keepalived-01 в директории host_vars пропишем значение этой переменой как Master. Образец такого файла ниже.
---
vrrp_state: MASTER
Как видим, при выполнении плейбука, нужный нам хост будет будет принимать режим Master и становится главным в кластере keepalived. При этом никаких лишних манипуляций с ролями и плейбуками нам проводить не требуется.
В папке group_vars мы создаем файлы для конкретных групп или вообще всех хостов, которые присуствуют в нашем инвентаре. Так например создадим файл all.yml, который будет применяться абсолютно ко всем хостам. Содержимое этого файла представлено ниже.
---
vrrp_router_id: '101'
vrrp_pass: PASSWORD
Теперь при выполнении плейбука, это позволит присвоить указанным переменным в данном файле значения, которые будут идентичны для всех хостов при развертывании. При этом мы ничего не изменяем в роли и плейбуке, а гибко вводим переменные, которые управляют выполнением заданий в Ansible.
Резюме
На пути к эффективному использованию всех возможностей Ansible, понимание того, как работает инвентарь и соответствующие переменные, это важная ступенька. Совместив эти знания с нужными ролями и плейбуками, мы сможем управлять сложнейшей IT инфраструктурой. В данной статье мы рассмотрели простую конфигурацию, с общими папками с переменными group_vars & host_vars, а также статическим инвентарем. В реальной жизни конфигурации могут быть гораздо сложнее, однако идеи статьи от этого не изменятся. Поняв принципы работы переменных и инвентаря на простом примере, можно в дальнейшем наворачивать конфигурации в соответствии со стоящими задачами.
