En

JazzTeam Software Development Company

Agile Java Development

DevOps. Ansible и Docker

Цель данной статьи немного рассказать о том, что из себя представляет Ansible и Docker, привести примеры, когда их можно использовать и как можно эффективно, объединив две технологии, упростить жизнь QA специалистов.

Термины и определения

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

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

Docker – программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы.

SSH (англ. Secure Shell) – сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов).

Power Shell – это язык сценариев от компании Microsoft, можно сказать что это более продвинутый вариант командной строки. Может использоваться для управления операционной системой Windows и ее компонентами, а также создания автоматизированных сценариев для администрирования системы.

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

Общие сведения о Ansible

Итак, Ansible – это очень гибкий и легкий инструмент для написания сценариев автоматизации любой сложности, обычно используется для управления Linux-узлами, но целевой системой может выступать и Windows, а также MacOS. Кроме того поддерживается работа и с сетевыми устройствами, на которых установлен Python версии 2.4 и выше по SSH или PowerShell соединению. Хотя при помощи Ansible можно управлять Windows системами, но в качестве Ansible хоста может выступать только Unix-подобная система (Linux, MacOS, FreeBSD и т.д.).

Важно понимать, что целевых систем может быть множество, и на них нет необходимости ставить Ansible, достаточно установить только на 1 машине для управления остальными системами. Вся работа происходит с использованием SSH/PowerShell соединения.

Какие задачи можно решить, используя Ansible:

Структура проекта Ansible

В общем виде проект Ansible может включать в себя:

Переменные

Переменные используются для хранения значений, которые могут применяться в playbook.
Переменные можно определять:

Специальные файлы с переменными могут хранится в 2 директориях:

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

Файлы переменных должны быть в формате YAML.

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

Приоритеты переменных (в порядке возрастания):

Playbooks

Для выполнения сценариев используются playbooks.
Playbook представляет собой *.yml файл, в котором написано, что необходимо выполнить при вызове данного сценария.

Playbook минимально должен иметь такую структуру:

Также можно указать:

Roles

Роль представляет собой структурированный playbook, содержащий набор (как и минимум) тасков (task), и дополнительно – обработчиков событий (handler), переменных (defaults), файлов (files), шаблонов (templates), а также описание и зависимости (meta).

Пример структуры роли для установки couchbase на проекте:

├───couchbase
│ ├───create_views
│ │ └───tasks
│ ├───loading
│ │ └───tasks
│ ├───loading_light
│ │ └───tasks
│ ├───load_to_cache
│ │ └───tasks
│ └───options
│ └───tasks

Из текущей структуры мы видим, что при вызове данной роли будет выполнено:

  1. Будут созданы view.
  2. Загружены данные для работы.
  3. Загружены настройки для основного приложение или light поставке.
  4. Загружены дополнительные параметры.

Inventory

Можно сказать что Inventory это файл, в котором описываются устройства, к которым будет подключаться Ansible. В файле Inventory устройства могут указываться, используя IP-адреса или имена. Устройства могут быть указаны по одному или разбиты на группы. Файл описывается в формате INI.

Пример файла:

Название, которое указано в квадратных скобках, – это название группы. В данном случае созданы три группы устройств: service, service_light, service_backend. При этом, так как для них указано ansible_connection=local, все операции будут выполнены на текущей локальной машине, а параметр ansible_host будет проигнорирован. Нужно быть очень внимательным!

[simple:children] – показывает, что было выполнено объединение нескольких групп в одну.

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

Запуск готового playbook осуществляется командой:

$ ansible-playbook simple-service.yml -i inventory/localhost -u имя_пользователя -k -vv

Общие сведения о Docker

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

После появления Docker упростилась работа системных администраторов и DevOps специалистов, поскольку теперь вместо того, чтобы думать как запустить приложение, нужно думать, где его запустить.

Docker может использоваться на всех типах ОС, но в Windows-системах могут появиться проблемы при установке и использовании. Подробнее про установку Docker можно почитать Get started with Docker.

Использование Docker на проекте

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

Конечно были и подводные камни. После перехода (повышения версии) к другой версии контейнера couchbase начались проблемы: работающий контейнер мог в неожиданный момент перестать отвечать на запросы, зависнуть и т. п. А из-за того, что выбор готовых контейнеров ограничен, не было времени на подготовку своего контейнера – приняли решение использовать локальную установку приложения.

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

В качестве интересного примера запуска приведу пример скрипта добавления контейнера Apache Tomcat:

Позволю пояснить некоторые моменты:

Какие же компоненты окружения мы вынесли в docker? Внимательный читатель заметит, что это был Apache Tomcat, а также RabbitMQ и ZooKeeper. Образы Couchbase выше версии 4.4.x, к сожалению, имеют те или иные проблемы, поэтому мы решили использовать локальную установку, но никто не мешает в будущем перенести Couch также в контейнер.

После вышеописанного может показаться, что Docker может быть идеальным решением для замены всего окружения, но всегда нужно взвешивать все за и против, иначе можно попасть в ситуацию: “Когда в руках молоток, все вокруг кажется гвоздями”.

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

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

Вместо итога

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

Самым лучшим применением этих двух технологий мне видится в тандеме, где Ansible – для первичной установки и настройки того, что должно быть вне контейнеров, а Docker используется для виртуализации конкретных приложений. Собственно к такому применению мы и пришли на проекте.

Полезные ссылки

  1. Ansible для сетевых инженеров – https://legacy.gitbook.com/book/natenka/ansible-dlya-setevih-inzhenerov/details
  2. 15 вещей, которые вы должны знать об Ansible – https://habr.com/post/306998/
  3. Контейнерно-ориентированное интеграционное тестирование – https://habr.com/company/redhatrussia/blog/420385/
  4. Шпаргалка по Docker – https://github.com/wsargent/docker-cheat-sheet



, , , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *