Построение тестовых окружений с помощью OpenStack

Автор: Евгения Шумахер

Евгения Шумахер – бизнес-аналитик компании Mirantis и автор предложения: How to Avoid Picking Problems that OpenStack Can’t Solve, докладчик по теме Will your Cloud be Compliant? на саммите OpenStack, который пройдет этой весной в Атланте.

Опрос пользователей OpenStack, проведенный в октябре прошлого года, показал, что построение тестовых окружений входит в 10-ку самых популярных вариантов использования OpenStack. В данном посте мы поговорим о том, как строятся тестовые среды, проанализируем способы, с помощью которых OpenStack может упростить этот процесс и сделать его более эффективным.

Пожалуй, самое важное требование к тестовой среде – чтобы она было копией соответствующей рабочей среды (хотя в действительности это не всегда на 100% так – см. ниже). Любые другие требования и ограничения вытекают из сценариев использования программного обеспечения (ПО) и методологии тестирования.

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

Рассмотрим подход к тестированию, который предполагает выполнение следующих шагов:
• выполнить тесты на предыдущей версии ПО в первой тестовой среде;
• выполнить тесты на новой версии ПО во второй тестовой среде; и
• сравнить результаты.

Если при таком подходе рабочая версия приложения работает не в виртуализированной среде, а на baremetal, то для каждого тестового окружения требуется отдельный аппаратный кластер. Аппаратное обеспечение, конфигурация сети, настройки ПО и данные (естественно, обезличенные) из рабочего окружения должны быть отзеркалированы в этих двух тестовых окружениях. В идеале оба тестовых окружения должны работать на одинаковом аппаратном обеспечении и, по возможности, иметь аналогичную сетевую конфигурацию.

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

Такой подход имеет следующие недостатки:
• Высокие затраты на построение тестовых сред. Построить тестовое окружение на базе аппаратного обеспечения стоит немалых денег, особенно если тестируемое ПО является критически важным и/или требует большого количества серверов. А для двух окружений эти расходы удваиваются. И это еще без учета дополнительных требований, возникающих при тестировании нескольких приложений.
• Сложность реализации. Два тестовых окружения должны иметь схожие конфигурации, являться репликами ваших рабочих настроек, и оба они должны хорошо работать.
• Трудности при масштабировании. Что если потребуется еще одно тестовое окружение для пользовательских приемочных испытаний или юзабилити-тестирования, к примеру? Больше ресурсов, больше времени, больше зависимостей.
• Команда тестировщиков не имеет возможности самостоятельно управлять тестовыми средами – они во многом зависят от команды IT.

В качестве ключевых требований к тестовым средам можно выделить следующие характеристики:
• Низкие затраты на построение;
• Простая и быстрая настройка и эксплуатация;
• Простое и быстрое масштабирование;
• Возможность самообслуживания.

Для тех, кто знаком с OpenStack и преимуществами этой технологии, может показаться, что это именно то, что нужно. OpenStack – это бесплатная платформа с открытым исходным кодом, которую можно развернуть на недорогих аппаратных средствах общего назначения. Она позволяет выполнить предварительную настройку компонентов тестовых сред и виртуальных тестовых окружений целиком, а затем быстро воспроизвести их в любом требуемом масштабе. Наконец, OpenStack имеет портал самообслуживания (Horizon), через который пользователи могут получить доступ к ресурсам по требованию, чтобы:
• создавать виртуальные сервера (Nova);
• создавать/прикреплять тома для хранения данных (Cinder);
• настраивать сети (Neutron);
• формировать инфраструктуры для облачных приложений (Heat).

Подходит ли вам облако?

Перенос тестовой среды в облако требует глубокого понимания тестируемого приложения (приложений) и технических возможностей для:
• выполнения сравнительного тестирования базовых платформ и разработки протоколов, которые позволят вам установить соответствие между производительностью на базе облака и на базе baremetal, когда они достаточно различаются.
• адаптации тестового окружения на базе облака для обеспечения необходимого тестового покрытия, несмотря на органичения по производительности и прочие различия. Например, путем настройки размеров тестовых баз данных, запросов и других переменных таким образом, чтобы тестовое окружение на базе облака работало сопоставимо с тестовым окружением на baremetal. Это может сделать возможным выполнение в тестовом окружении на базе облака тестов, аналогичных тем, которые выполняются на решении, работающем на baremetal, во многих сферах.

• адекватной оценки ситуаций, когда тестовая среда не моделирует рабочую среду должным образом (так часто случается при проведении нагрузочного тестирования).

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

Если, вы уверены, что ваше приложение будет работать должным образом, и что тестирование в облачной среде будет давать осмысленные результаты, то облако (и, вместе с тем OpenStack) – это правильный выбор.

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

Что же требуется для переноса стека, на базе которого работает приложение, в виртуальную среду?

Предположим, вы строите облако OpenStack на существующем аппаратном обеспечении.

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

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

Во-первых, требование высокой доступности облака одно из основных. О том, как построить высокодоступный OpenStack кластер можно прочитать вот здесь: Mirantis OpenStack’s implementation of HA,

Следующим пунктом стоит вопрос производительности кластер. По данной теме полезным будет пост о способах повышения производительности вычислений в облачных средах на базе OpenStack.

Другие проектные решения, такие как:
• Конфигурация сети
o Сколько сетей вам потребуется?
o Как будет осуществляться передача трафика VM?
o Потребуется ли доступ в Интернет, и как он будет предоставляться?
• Конфигурация компонентов OpenStack
o Какие компоненты необходимо установить?
o Где следует установить сервисы OpenStack (на вычислительном узле, на узле контроллера, на каком-то другом выделенном узле, например, узле хранения данных)?

… зависят от характеристик ПО, способов передачи данных и требований к ограничению трафика (например, большая пропускная способность, малая задержка, качество обслуживания, время отклика) и самого процесса тестирования. Попробуйте ответить на следующие вопросы:
• Как рабочие данные копируются в тестовое окружение?
• Как часто создается или обновляется тестовое окружение?

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

Решив, какой будет архитектура, можно начать подготовку образов виртуальных машин. Необходимо составить:
• набор универсальных образов для vCPU, vRAM, vHDD, гостевой ОС и некоторых фиксированных программ, которые установлены и настроены;
• набор образов для конкретных vCPU, vRAM, vHDD, возможно, необычных ОС и особых программ, которые установлены и настроены.
Целью здесь является создание библиотеки образов для возможности оперативного развертывания разнообразных тестовых окружений, компоненты которых настроены строгим образом, предварительно задокументированы и протестированы.

Как обеспечить разворачивание тестовых окружений?

На помощь приходит Heat, компонент OpenStack, отвечающий за оркестрацию облачных приложений.

Heat предлагает механизм шаблонов. Шаблон Heat описывает инфраструктуру облачного приложения, например, набор серверов, томов и связей между ними, сетевые настройки, в т.ч. плавающие IP-адреса, группы безопасности, настройки аутентификации и т.д. Для автоматической настройки ПО можно использовать такие инструменты, как Puppet или Chef.

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

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

Пример использования

Выше описан общий подход к построению виртуального тестового окружения. Теперь давайте рассмотрим конкретный пример использования.

Компания занимается разработкой приложений для WEB.

Приложение использует стандартный стек серверных технологий LAMP. Рабочая среда работала в облаке на базе VMWare. Данное решение стоит относительно дорого ввиду необходимости лицензирования и платы за использование. Тестовая среда также была построена на VMWare и управлялась IT командой.

Компания выявила ряд проблем:
• Команда тестировщиков не могла создать локальные тестовые окружения по требованию.
• IT-специалистам требовалось слишком много времени для выполнения запросов на создание новых тестовых окружений.
• Были трудности с масштабированием тестового окружения и/или добавления нового.
• Затраты на создание, поддержку и масштабирование тестовых окружений были высокими (отчасти из-за стоимости лицензий на VMWare).

Компания хотела изменить подход к построению тестовых окружений. Новое решение должно было отвечать следующим требованиям:
• Предоставление тест-инженерам возможности создавать и поддерживать тестовую среду через портал самообслуживания.
• Оперативное создание и подготовка тестовых сред.
• Простота масштабирования и поддержки функционирования тестовых окружений.
• Низкая общая стоимость решения.
• Предоставление возможности другим пользователям, например консультантам по продуктам, создавать demo-окружение через портал самообслуживания, поскольку реплики рабочей среды полезны не только команде тестировщиков.
• Изолированность разных тестовых окружений.
• Предоставление команде IT возможности контролировать потребление ресурсов каждой командой тестировщиков.

Архитектор решений предложил построить тестовое окружение в облаке на базе OpenStack. В результате был развернут кластер OpenStack, состоящий из 10-20 узлов с высокой степенью доступности узлов контроллера.

Полученное в результате решение дает следующие преимущества:
• Для обеспечения изолированности каждое тестовое окружение работает в отдельном тенанте. Например, один проект для команды тестировщиков, другой для команды консультантов и т.д. (См. docs.openstack.org/trunk/openstack-ops/content/projects_users.html)
• Шаблоны Heat позволяют оперативно создавать новые окружения. Команда тестировщиков может создавать новые шаблоны Heat самостоятельно.
• Самообслуживание обеспечивается через OpenStack CLI/Horizon и шаблоны Heat.
• Общая стоимость решения на базе OpenStack ниже, т.к. компании не нужно платить за лицензии и она может использовать недорогое ПО и аппаратные средства общего назначения.
• Тестировщики являются владельцами своих тестовых окружений. Они могут создавать и удалять окружения в любое время, когда это необходимо.
• OpenStack позволяет сотрудникам IT устанавливать квоты на каждый проект. Компонент OpenStack под названием Ceilometer также может использоваться для мониторинга потребления ресурсов облачными инстансами.

Заключение

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

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

Тесты, зависящие от аппаратного обеспечения (например, тестирование на отказ и восстановление), просто не могут быть запущены в виртуальной среде. Конечно, даже в этом случае можно использовать эмуляторы аппаратного обеспечения, но насколько будут адекватны результаты?

При принятии решения о переносе тестового окружения в облако на базе OpenStack важно тщательно планировать каждый шаг.

Оригинал статьи на английском языке

Автор: Mirantis_OpenStack

Источник