Система управления конфигурацией Ansible
Представьте себе, что вам нужно управлять парком серверов, расположенных к тому же в разных географических точках. Каждый из этих серверов требует настройки, регулярного обновления и мониторинга. Конечно, для решения этих задач можно воспользоваться самым простым способом: подключиться к каждому серверу по ssh и внести необходимые изменения. При всей своей простоте этот способ сопряжен с некоторыми трудностями: он чрезвычайно трудоемок, а на выполнение однообразных операций уходит очень много времени.
Чтобы упростить процессы настройки и конфигурирования серверов, можно также писать shell-скрипты. Но и этот способ вряд ли можно назвать совершенным. Скрипты нужно постоянно изменять, подстраивая их под каждую новую задачу. При их написании необходимо учитывать различие операционных систем и версий. Не будем забывать и о том, что отладка скриптов отнимает много усилий и забирает немало времени.
Оптимальным вариантом решения описанных проблем является внедрение системы удаленного управления конфигурацией. В таких системах достаточно лишь описать нужное состояние управляемого узла. Система должна сама определить, что нужно сделать для достижения этого состояния, и осуществит все необходимые действия.
Со всеми сложностями, о которых идет речь выше, мы хорошо знакомы на собственном опыте: у нас имеется 10 точек присутствия с NS-серверами, расположенные в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное ПО, изменять конфигурцию и т.п. Мы решили все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями. Изучив имеющиеся решения, мы остановили свой выбор на Ansible.
В этой статье мы бы хотели подробно рассказать о его возможностях этого инструмента управления конфигурациями и поделиться собственным опытом его использования.
Что такое Ansible?
Ansible — опенсорсное программное решение для удаленного управления конфигурациями, разработанное Майклом Де Хаанном в 2012 году. Название продукта взято из научно-фантастической литературы: в романах американской писательницы Урсулы Ле Гуин ансиблом называется устройство для оперативной космической связи.
Ansible берет на себя всю работу по приведению удаленных серверов в необходимое состояние. Администратору необходимо лишь описать, как достичь этого состояния с помощью так называемых сценариев (playbooks; это аналог рецептов в Chef). Такая технология позволяет очень быстро осуществлять переконфигурирование системы: достаточно всего лишь добавить несколько новых строк в сценарий.
Почему Ansible?
Преимущества Ansible по сравнению с другими аналогичными решениями (здесь в первую очередь следует назвать такие продукты, как Puppet, Chef и Salt) заключаются в следующем:
- на управляемые узлы не нужно устанавливать никакого дополнительного ПО, всё работает через SSH (в случае необходимости дополнительные модули можно взять из официального репозитория);
- код программы, написанный на Python, очень прост; при необходимости написание дополнительных модулей не составляет особого труда;
- язык, на котором пишутся сценарии, также предельно прост;
- низкий порог вхождения: обучиться работе с Ansible можно за очень короткое время;
- документация к продукту написана очень подробно и вместе с тем — просто и понятно; она регулярно обновляется;
- Ansible работает не только в режиме push, но и pull, как это делают большинство систем управления (Puppet, Chef);
- имеется возможность последовательного обновления состояния узлов (rolling update).
Push или pull?
“Из коробки” все сценарии и команды выполняются методом push: когда возникает необходимость, мы запускаем сценарий, и он последовательно выполняется на удалённых серверах. Однако разработчики также предусмотрели метод pull и даже написали специальное приложение для установки необходимой для этого части ansible на удалённые хосты.
Установка
Требования для установки Ansible минимальны. На машине с которой производится управление должен быть установлен Python 2.6 или выше. На управляемых узлах должен быть установлен только Python версии не ниже 2.4, но он, как правило, по умолчанию включен в состав большинства дистрибутивов linux-систем. MS Windows не поддерживается.
Вам также могут потребоваться следующие модули Python, устанавливаемые через pip или пакетный менеджер вашей операционной системы:
- paramiko;
- PyYAML;
- jinja2.
В Ubuntu установка самого Ansible и зависимостей осуществляется добавлением репозитория и установкой пакета:
О процедуре установки в других ОС можно прочитать в официальной документации .
Группы серверов
Список групп серверов, которыми нужно управлять, Ansible может получать двумя основными способами:
- из специального текстового файла (далее этот вариант будет рассмотрен более подробно);
- с помощью внешнего скрипта, возвращающего нужный нам список серверов, например из MongoDB . В официальном github-репозитории есть готовые скрипты для получения списка из Cobbler , Digital Ocean , EC2 , Linode , OpenStack Nova , Openshift , Spacewalk , Vagrant , Zabbix .
Файл hosts
Дефолтное расположение файла — /etc/ansible/hosts, но оно может также быть задано параметром окружения $ANSIBLE_HOSTS или параметром -i при запуске ansible и ansible-playbook. Содержимое этого файла может выглядеть, например, так (в квадратных скобках указаны имена групп управляемых узлов, ниже перечисляются входящие в эти группы серверы):
Помимо списка управляемых узлов, в файле hosts могут быть указаны и другие сведения, необходимые для работы: номера портов для подключения по SSH, способ подключения, пароль для подключения по SSH, имя пользователя, объединения групп и т.п. В некоторых случаях — в частности, при работе с большими и сложными конфигурациями, — различные параметры можно выносить в отдельные файлы и каталоги (о структуре каталогов см. ниже).
Более подробно о файле hosts и правилах его написания можно почитать в официальной документации .
Информация об узлах (Facts)
Перед внесением изменений Ansible подключается к управляемым узлам и собирает информацию о них: о сетевых интерфейсах и их состоянии, об установленной операционной системе и т.п. Он может делать это как с помощью собственного модуля, так и с помощью инструментов ohai и facter, если они установлены (такая возможность специально предусмотрена для пользователей, уже имеющих опыт работы с системами удаленного управления конфигурациями: ohai и facter являются библиотеками фактов для Chef и Puppet).
Переменные
Во время деплоя, как правило, требуется не только установить какое-либо приложение, но и настроить его в соответствии с определенными параметрами на основании принадлежности к группе серверов или индивидуально (например, ip-адрес BGP-соседа и номер его AS или параметры для базы данных). Как уже было сказано, загромождать файл hosts будет не очень красиво, поэтому разработчики Ansible пошли следующим путём:
- файлы с переменными групп хранятся в директории “group_vars/имя_группы”;
- файлы с переменными хостов в директории “hosts_vars/имя_хоста”;
- файлы с переменными роли (о них речь пойдет ниже) в директории “имя_роли/vars/имя_задачи.yml”;
Помимо пользовательских переменных можно (и даже нужно) использовать факты, собранные ansible перед выполнением сценариев и отдельных задач.
Модули Ansible
В состав Ansible входит огромное количество модулей для развёртывания, контроля и управления различными компонентами, которые можно условно разделить на следующие группы (в скобках приведены названия некоторых продуктов и сервисов):
- облачные ресурсы и виртуализация (Openstack, libvirt);
- базы данных (MySQL, Postgresql, Redis, Riak);
- файлы (шаблонизация, регулярные выражения, права доступа);
- мониторинг (Nagios, monit);
- оповещения о ходе выполнения сценария (Jabber, Irc, почта, MQTT, Hipchat);
- сеть и сетевая инфраструктура (Openstack, Arista);
- управление пакетами (apt, yum, rhn-channel, npm, pacman, pip, gem);
- система (LVM, Selinux, ZFS, cron, файловые системы, сервисы, модули ядра);
- работа с различными утилитами (git, hg).
О том, с чем умеет работать Ansible “из коробки”, можно прочитать в официальной документации . Список действительно впечатляет.
Примеры простых задач
С помощью Ansible можно одновременно выполнить одну задачу на целой группе серверов. Попробуем, например, отправить запрос ping на серверы выбранной группы:
Следующий пример соберёт информацию о хостах и выведёт её на консоль в формате JSON:
$ ansible dnsservers -m setup
А вот так можно создать логический том (или, в зависимости от текущего состояния, изменить его размер) с именем examplevolume в группе examplegroup:
Ansible позволяет не только выполнять единичные задачи, но и писать сценарии, которые необходимо выполнить на управляемых узлах. Рассмотрим структуру и правила написания таких сценариев более подробно.
Cценарии (playbooks)
Все сценарии в Ansible пишутся на YAML. Это — человекочитаемый формат сериализованных данных, гораздо более простой, чем XML или JSON.
Чтобы выполнить сценарий используется команда ansible-playbook со следующим сиснтаксисом:
В начале сценария обязательно должна присутствовать последовательность символов «–––» (так в YAML обозначается начало документа). Перед каждым новым разделом списка ставится дефис ( – ):
Основными параметрами/группами простого сценария являются:
- hosts — в нем указываются управляемые узлы или группы узлов, к которым нужно применить изменения;
- tasks — здесь описывается состояние, в которое необходимо привести управляемый узел, альтернативой этому могут служить роли;
Также в сценарии перед непосредственным описанием задач могут быть указаны следующие параметры или группы параметров:
- gather_facts — собирать или нет информацию о хостах перед выполнением задач, по умолчанию — да;
- vars — в нем указываются различные переменные, которые будут использованы при выполнении сценария;
- connection — можно указать метод соединения с хостами: pure ssh, paramiko, fireball, chroot, jail, local, accelerate (применимо также для выполнения отдельного модуля);
- sudo — после установления соединения выполнять задачу с привилегиями другого пользователя, по умолчанию другой пользователь — root;
- sudo_user — в сочетании с предыдущим параметром можно указать с привилегиями какого именно пользователя будет выполнена задача;
- vars_prompt — перед выполением плэйбука Ansible в интерактивном режиме может уточнить указанные в этом разделе параметры;
- remote_user (в предыдущих версиях — просто user) — имя пользователя для авторизации на удалённом хосте.
Рассмотрим все эти разделы более подробно.
В разделе hosts указывается группа управляемых узлов, к которой будут применены описываемые в сценарии изменения.
Так, строка формата:
означает, что изменения будут применены к узлам из группы webservers.
Сценарии могут выполняться не только от имени пользователя, под именем которого установлено соедиение, но и любого другого. В следующем примере авторизация на хосте будет произведена с именем yourname, но задачи будут выполняться от имени пользователя root (если, конечно, этому пользователю это разрешено):
Если добавить параметр “user: postgres”, то все действия будут выполняться с привилегиями пользователя postgres.
В разделе vars указываются переменные, которые будут использованы в сценарии, и их значения:
Список изменений, которые необходимо произвести на управляемом узле, приводится в разделе tasks. Каждой задаче (task) присваивается имя (name). Далее указываются модули Ansible, которые будут задействованы при ее выполнении:
Для каждой задачи можно указывать пользователя, от имени которого она будет выполнена:
Шаблонизация
В Ansbile используется шаблонизатор Jinja2 . Приведём пример шаблона (часть конфига powerdns ):
В приведённом примере мы подставляем в шаблон следующие значения:
- из заранее собранных фактов о хосте:
- ansible_default_ipv4.address — основной IPv4-адрес хоста;
- ansible_default_ipv6.address — основной IPv6-адрес хоста;
- ansible_hostname — имя хоста (результат выполнения команды hostname).
Обработку шаблонов и, в данном случае, генерацию конфигурационного файла выполняет модуль template ; он же может задать необходимые права доступа и изменить владельца/группу:
Обратим внимание на то, что файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.
Обработчики событий (Handlers)
Ansible не просто выполняет задачи в указанном порядке, но и проверяет их состояние на наличие изменений. Если при выполнении сценария требовалось, например, добавить строку в конфигурационный файл, и в результате выполнения он изменился (необходимой строки действительно не было), то Ansible может выполнить специальную задачу, описанную как обработчик события (handler). Если при выполнении строка уже была в конфигурационном файле, то обработчик выполнен не будет. Обработчики событий описываются в конце сценария; в описании задачи они указываются через параметр notify. Приведём пример:
Контроль выполнения
Допустим, что при выполнении сценария нам нужно проверять определённые переменные или состояния и, в зависимости от них, выполнять или не выполнять какие-либо задачи. Для этого можно использовать оператор “when”:
Делегирование задачи другому хосту
Иногда требуется выполнить задачу на определённом узле, но в контексте другого узла. Например, во время обновления узла может возникнуть необходимость отключить для него мониторинг, находящийся на отдельном сервере. Для этого используется управляющая директива delegate_to. Приведём пример:
Результатом выполнения этой задачи будет отключение сообщений для сервиса dnsserver в Nagios.
Ролью называется типовой набор переменных и задач, назначаемых для одного или нескольких серверов. Если вам нужно применить к серверу или группе серверов типовой набор операций, вам достаточно просто назначить ему роль. Предварительно в проекте каталоге проекта должна быть создана соответствующая структура. В сценариях роли назначаются следующим образом:
Структура проекта
Пример сценария
Чтобы понять, как это все работает, рассмотрим практический пример: простой сценарий развёртывания новой версии PostgreSQL 9.3 на debian-based ОС. Роли в этом примере не используются.
Ansible AWX
Во всех приведенных выше примерах управление Ansible осуществляется с помощью интерфейса командной строки. Но с официального сайта можно загрузить графическую панель управления Ansibleworks AWX , очень симпатичную внешне и удобную в использовании. Собственно, за счет ее распространения и осуществляется монетизация продукта: управление небольшим (до 10) количеством серверов обходится бесплатно, если же серверов больше — нужно приобретать лицензию. Похожие варианты монетизации используются и разработчиками конкурирующих решений — Puppet и Chef .
Заключение
Ansible — достаточно простой, но при этом эффективный инструмент для удаленного управления конфигурациями. В рамках этой статьи мы сделали лишь беглый обзор его возможностей и рассказали, как пишутся сценарии для решения простых задач. Все возможности и варианты использования Ansible в рамках одной статьи охватить невозможно. О применении этого инструмента для решения более специфических задач мы расскажем в последующих публикациях.
Как установить Ansible AWX 17.1.0 на Ubuntu 20.04
AWX — это проект сообщества с открытым исходным кодом, спонсируемый компанией Red Hat. Он служит средой разработки для Ansible. Так же AWX имеет частые релизы и новые разработки.
Ansible AWX предоставляет веб-интерфейс пользователя для управления Ansible хостами, учебниками, модулями, расписанием заданий, автоматизацией рабочих процессов, общим доступом к учетным данным и инструментами для делегирования.
В этой инструкции мы покажем процесс установки Ansible AWX на Ubuntu 20.04.
Требования для установки Ansible AWX 17.1.0 на Ubuntu 20.04
- root-доступ или пользователь с привилегиями sudo для SSH-соединения.
- Ubuntu 20.04 или 18.04
- Минимум 4 ГБ оперативной памяти
- Минимум 2 vcpu (vcpuэто это виртуальный процессор, содержащий одно ядро и занимающий один сокет.)
- Минимум 20 ГБ свободного места на диске SSD/HDD
Для успешного запуска и запуска Ansible AWX также необходимо будет установить:
- Ansible
- Docker and Docker compose
- Node and NPM
1. Установка Ansible на Ubuntu 20.04
Первое что потребуется это обновить систему
Чтоб выполнить установку Ansible, выполните следующую команду:
$ sudo apt install ansible -y
Для проверки версии установленного Ansible выполните команду:
ansible 2.9.6
config file = /etc/ansible/ansible.cfg
configured module search path = [‘/home/linoxide/.ansible/plugins/modules’, ‘/usr/share/ansible/plugins/modules’]
ansible python module location = /usr/lib/python3/dist-packages/ansible
executable location = /usr/bin/ansible
python version = 3.8.5 (default, Jan 27 2021, 15:41:15) [GCC 9.3.0]Основной файл конфигурации хранится в файле /etc/ansible/hosts.
2. Установка Docker и Docker Compose
Для успешной установки и настройки Docker посмотрите статью Как установить Docker Compose на Ubuntu 20.04
После установки Docker проверьте его версию:
Ответ в терминале:
Client: Docker Engine — Community
Version: 20.10.6
API version: 1.41
Go version: go1.13.15
Git commit: 370c289
Built: Fri Apr 9 22:47:17 2021
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine — Community
Engine:
Version: 20.10.6
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: 8728dd2
Built: Fri Apr 9 22:45:28 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.4
GitCommit: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
runc:
Version: 1.0.0-rc93
GitCommit: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
docker-init:
Version: 0.19.0
GitCommit: de40ad0После установки Docker Compose проверьте версию:
docker-compose version 1.29.2, build 5becea4c docker-py version: 5.0.0
CPython version: 3.7.10
OpenSSL version: OpenSSL 1.1.0l 10 Sep 20193. Установите Node.js и NPM
Далее, требуется установить Node.js
$ sudo apt install -y nodejs npm
а также Установить NPM
4. Установка Ansible AWX в Ubuntu 20.04
После того, как мы сделали подготовку к установке Ansible AWX в Ubuntu 20.04, пришло время установить Ansible.
Установите модуль docker-py python со следующей командой.
$ sudo apt install python3-pip git pwgen vim
далее введите команду
Кроме того, нам понадобится модуль docker-compose для python, который соответствует вашей установленной версии Docker Compose.
docker-compose version 1.29.2, build 5becea4c docker-py version: 5.0.0
CPython version: 3.7.10
OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019Проверьте версию docker-compose (моя версия 1.29.2). Далее установите модули с помощью следующей команды.
$ sudo pip3 install docker-compose==1.29.2
После установки pi-модулей мы собираемся загрузить последний zip-файл AWX из GitHub со следующей командой.
Распакуйте загруженный архив этой командой:
И измените каталог на awx-17.1.0/installer/
Сгенерируйте секретный ключ для AWX с помощью следующей команды:
Затем найдите файл инвентаризации и откройте его с помощью любимого редактора:
Попробуйте сохранить следующие настройки:
ПРИМЕЧАНИЕ: замените секретный ключ тем, который мы только что сгенерировали:
dockerhub_base=ansible
awx_task_hostname=awx
awx_web_hostname=awxweb
postgres_data_dir=/tmp/pgdocker
host_port=80
host_port_ssl=443
docker_compose_dir=/tmp/awxcompose
pg_username=awx
pg_password=awxpass
pg_database=awx
pg_port=5432
admin_user=admin
admin_password=password
create_preload_data=True
secret_key=6YJ0TM4MsmpKIrNCqEVA1i4TAa3zbGПосле сопоставления этой конфигурации с вашей пришло время выполнить playbook. Сделать это можно следующей командой:
$ ansible-playbook -i inventory install.yml
install.yml – это имя файла playbook
параметр -i говорит ansible использовать инвентарный файл
Убедитесь, что все идет хорошо, без неудачных выполнений заданий.
После установки ansible-playbook проверьте контейнеры docker, чтобы получить список запущенных контейнеров:
Как видите, скрипт ansible создает и запускает 4 docker-контейнера:
- awx_task
- awx_web
- awx_redis
- awx_postgres
Для нас важнее всего awx_web, который работает на порту 80.
Вы можете получить доступ к Ansible AWX Web-UI через hostip или hostname на порту 80.
Войдите в систему с учетными данными, которые ранее были определены в файле инвентаризации.
После входа в систему вы увидите главную панель мониторинга. Оттуда вы можете начать управлять Ansible AWX и насладится панелью мониторинга.
Заключение
В этой инструкции мы показали, как установить Ansible AWX на Ubuntu 20.04 с помощью ansible-playbook с контейнерами Docker.
Autoscaling своими руками с помощью AWX, Ansible, haproxy и Облака КРОК
Какое-то время назад мы сделали безагентский (Agentless) мониторинг и алармы к нему. Это аналог CloudWatch в AWS с совместимым API. Сейчас мы работаем над балансировщиками и автоматическим скейлингом. Но пока мы не предоставляем такой сервис — предлагаем нашим заказчикам сделать его самим, используя в качестве источника данных наш мониторинг и теги (AWS Resource Tagging API) как простой service discovery. Как это сделать покажем в этом посте.
Пример минимальной инфраструктуры простого веб-сервиса: DNS -> 2 балансера -> 2 backend. Данную инфраструктуру можно считать минимально необходимой для отказоустойчивой работы и для проведения обслуживания. По этой причине мы не будем «сжимать» еще сильнее эту инфраструктуру, оставляя, например, только один backend. А вот увеличивать число backend серверов и сокращать обратно до двух хотелось бы. Это и будет нашей задачей. Все примеры доступны в репозитории.
Базовая инфраструктура
Мы не будем останавливаться детально на настройке приведённой выше инфраструктуры, покажем лишь, как её создать. Мы предпочитаем разворачивать инфраструктуру с помощью Terraform. Он помогает быстро создать всё необходимое (VPC, Subnet, Security Group, VMs) и повторять эту процедуру раз за разом.
Скрипт для поднятия базовой инфраструктуры:
Все сущности, описываемые в этой конфигурации, кажется, должны быть понятны рядовому пользователю современных облаков. Переменные, специфичные для нашего облака и для конкретной задачи, выносим в отдельный файл — terraform.tfvars:
Настройка мониторинга
Запущенные выше ВМ автоматически мониторятся нашим облаком. Именно данные этого мониторинга будут являться источником информации для будущего автоскейлинга. Полагаясь на те или иные метрики мы можем увеличивать или сокращать мощности.
Мониторинг в нашем облаке позволяет настроить алармы по различным условиям на различные метрики. Это очень удобно. Нам не нужно анализировать метрики за какие-то интервалы и принимать решение — это сделает мониторинг облака. В данном примере мы будем использовать алармы на метрики CPU, но в нашем мониторинге их также можно настроить на такие метрики как: утилизация сети (скорость/pps), утилизация диска (скорость/iops).Описание некоторых параметров, которые могут быть непонятны:
—profile — профиль настроек aws-cli, описывается в
/.aws/config. Обычно в разных профилях задаются разные ключи доступа.
—dimensions — параметр определяет для какого ресурса будет создан аларм, в примере выше — для инстанса с идентификатором из переменной $instance_id.
—namespace — пространство имён, из которого будет выбрана метрика мониторинга.
—metric-name — имя метрики мониторинга.
—statistic — название метода агрегации значений метрики.
—period — временной интервал между событиями сбора значений мониторинга.
—evaluation-periods — количество интервалов, необходимое для срабатывания аларма.
—threshold — пороговое значение метрики для оценки состояния аларма.
—comparison-operator — метод, который применяется для оценки значения метрики относительно порогового значения.
В примере выше для каждого backend инстанса создаётся два аларма. Scaling-low-<instance-id> перейдёт в состояние Alarm при загрузке CPU менее 15% на протяжении 3 минут. Scaling-high-<instance-id> перейдёт в состояние Alarm при загрузке CPU более 80% на протяжении 3 минут.
Настройка тегов
После настройки мониторинга перед нами встаёт следующая задача — обнаружение инстансов и их имён (service discovery). Нам нужно как-то понимать, сколько у нас сейчас запущено backend инстансов, а также нужно знать их имена. В мире вне облака для этого хорошо подошел бы, например, consul и consul template для генерации конфига балансера. Но в нашем облаке есть теги. Теги помогут нам категоризировать ресурсы. Запросив информацию по определённому тегу (describe-tags), мы можем понимать, сколько инстансов у нас сейчас в пуле и какие у них id. По умолчанию уникальный id инстанса используется в качестве hostname. Благодаря внутреннему DNS работающему внутри VPC эти id/hostname резолвятся во внутренние ip инстансов.
Задаём теги для backend инстансов и балансеров:
—resources — список идентификаторов ресурсов, которым будут установлены теги.
—tags — список пар ключ-значение.
Пример describe-tags доступен в документации Облака КРОК.
Настройка автоскейлинга
Теперь когда облако занимается мониторингом, и мы умеем работать с тегами, нам остаётся только опрашивать состояние настроенных алармов на предмет их срабатывания. Тут нам нужна сущность, которая будет заниматься периодическим опросом мониторинга и запуском задач по созданию/удалению инстансов. Здесь можно применить различные средства автоматизации. Мы будем использовать AWX. AWX — это open-source версия коммерческого Ansible Tower, продукта для централизованного управления Ansible-инфраструктурой. Основная задача — периодически запускать наши ansible playbook.
С примером деплоя AWX можно ознакомиться на странице wiki в официальном репозитории. Настройка AWX также описана в документации Ansible Tower. Чтобы сервис AWX начал запускать пользовательские playbook, его необходимо настроить, создав следующие сущности:
- Сredentials трёх типов:
— AWS credentials — для авторизации операций, связанных с Облаком КРОК.
— Machine credentials — ssh ключи для доступа на вновь созданные инстансы.
— SCM credentials — для авторизации в системе контроля версий. - Project — сущность, которая склонит git репозиторий с playbook.
- Scripts — скрипт dynamic inventory для ansible.
- Inventory — сущность, которая будет вызывать скрипт dynamic inventory перед запуском playbook.
- Template — конфигурация конкретного вызова playbook, состоит из набора Credentials, Inventory и playbook из Project.
- Workflow — последовательность вызовов playbooks.
Процесс автоскейлинга можно разделить на две части:
- scale_up — создание инстанса при срабатывании хотя бы одного high аларма;
- scale_down — терминация инстанса, если для него сработал low аларм.
В рамках scale_up части необходимо будет:
- опросить сервис мониторинга облака о наличии high алармов в состоянии «Alarm»;
- досрочно остановить scale_up, если все high алармы находятся в состоянии «OK»;
- создать новый инстанс с необходимыми атрибутами (tag, subnet, security_group и т.д.);
- создать high и low алармы для запущенного инстанса;
- настроить наше приложение внутри нового инстанса (в нашем случае это будет просто nginx с тестовой страницей);
- обновить конфигурацию haproxy, сделать релоад, чтобы на новый инстанс начали идти запросы.
В create-instance.yaml происходит: создание инстанса с правильными параметрами, тегирование этого инстанса и создание необходимых алармов. Также через user-data передаётся скрипт установки и настройки nginx. User-data обрабатывается сервисом cloud-init, который позволяет производить гибкую настройку инстанса во время запуска, не прибегая к использованию других средств автоматизации.
В update-lb.yaml происходит пересоздание /etc/haproxy/haproxy.cfg файла на haproxy инстансе и reload haproxy сервиса:
Где haproxy.cfg.j2 — шаблон файла конфигурации сервиса haproxy:
Так как в секции backend конфига haproxy определена опция option httpchk, сервис haproxy будет самостоятельно опрашивать состояния backend инстансов и балансировать траффик только между прошедшими health check.
В scale_down части необходимо:
- проверить стейт low аларма;
- досрочно закончить выполнение play, если отсутствуют low алармы в стейте «Alarm»;
- терминировать все инстансы, у которых low alarm находится в стейте «Alarm»;
- запретить терминацию последней пары инстансов, даже если их алармы находятся в стейте «Alarm»;
- удалить из конфигурации load balancer инстансы, которые мы удалили.
В destroy-instance.yaml происходит удаление алармов, терминация инстанса и его тега, проверка условий запрещающих терминацию последних инстансов.
Мы явно удаляем теги после удаления инстансов в связи с тем, что после удаления инстанса связанные с ним теги удаляются отложенно и доступны ещё в течение минуты.
AWX.Настройка задач, шаблонов
Следующий набор tasks создаст необходимые сущности в AWX:
Предыдущий сниппет создаст по template на каждый из используемых ansible playbook’ов. Каждый template конфигурирует запуск playbook набором определённых credentials и inventory.
Построить pipe для вызовов playbook’ов позволит workflow template. Настройка workflow для автоскейлинга представлена ниже:
В предыдущем шаблоне представлена схема workflow, т.е. последовательность выполнения template’ов. В данном workflow каждый следующий шаг (success_nodes) будет выполнен только при условии успешного выполнения предыдущего. Графическое представление workflow представленно на картинке:
В итоге был создан обобщающий workflow, который выполняет create-instace playbook и, в зависимости от статуса выполнения, destroy-instance и/или update-lb playbook’и. Объединённый workflow удобно запускать по заданному расписанию. Процесс автоскейлинга будет запускаться каждые три минуты, запуская и терминируя инстансы в зависимости от стейта алармов.
Тестирование работы
Теперь проверим работу настроенной системы. Для начала установим wrk-утилиту для http бенчмаркинга.
Воспользуемся облачным мониторингом для наблюдения за использованием ресурсов инстанса во время нагрузки:
Предыдущий скрипт раз в 60 секунд забирает информацию о среднем значении метрики CPUUtilization за последнюю минуту и опрашивает состояние алармов для backend инстансов.
Теперь можно запустить wrk и посмотреть на утилизацию ресурсов backend инстансов под нагрузкой:
Последняя команда запустит бенчмарк на 500 секунд, используя 12 потоков и открыв 100 http соединений.
В течение времени скрипт мониторинга должен показать, что во время действия бенчмарка значение статистики метрики CPUUtilization увеличивается пока не дойдёт до значений 300%. Через 180 секунд после начала бенчмарка флаг StateValue должен переключиться в состояние Alarm. Раз в две минуты происходит запуск autoscaling workflow. По умолчанию, параллельное выполнение одинаковых workflow запрещено. То есть каждые две минуты задача на выполнение workflow будет добавлена в очередь и будет запущена только после завершения предыдущей. Таким образом во время работы wrk будет происходить постоянное наращивание ресурсов, пока high алармы всех backend инстансов не перейдут в состояние OK. По завершению выполнения wrk scale_down workflow терминирует все backend инстансы за исключением двух.
Пример вывода скрипта мониторинга:
Также в Облаке КРОК есть возможность просмотра графиков используемого в посте мониторинга на странице инстанса на соответствующей вкладке.
Просмотр алармов доступен на странице мониторинга на вкладке алармы.
Заключение
Автоскейлинг довольно популярный сценарий, но, к сожалению, в нашем облаке его пока нет (но только пока). Однако у нас достаточно много мощного API, чтобы делать подобные и многие другие вещи, используя популярные, можно сказать почти стандартные, инструменты такие как: Terraform, ansible, aws-cli и прочие.