Создание Тестовых Сред С Использованием Openstack

ниже).

Любые другие требования и ограничения вытекают из сценариев использования программного обеспечения и методики тестирования.

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

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

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

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

В идеале обе тестовые среды должны работать на одном и том же оборудовании и, если возможно, иметь одинаковую конфигурацию сети.

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

Этот подход имеет следующие недостатки: • Высокие затраты на создание тестовых сред. Создание аппаратной тестовой среды стоит больших денег, особенно если тестируемое программное обеспечение критично и/или требует большого количества серверов.

А для двух сред эти затраты удваиваются.

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

• Сложность реализации.

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

• Трудности масштабирования.

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

• Команда тестирования не имеет возможности самостоятельно управлять тестовыми средами — они во многом зависят от ИТ-команды.

Тем, кто знаком с OpenStack и преимуществами этой технологии, это может показаться именно тем, что вам нужно.

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

Он позволяет предварительно настраивать компоненты тестовых сред и целые виртуальные тестовые среды, а затем быстро воспроизводить их в любом необходимом масштабе.

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

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

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

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

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

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

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

Первое и самое важное, о чем следует подумать, — это облачная архитектура.

Есть много аспектов, которые следует принять во внимание.

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

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

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

О том, как создать высокодоступный кластер OpenStack, можно прочитать здесь: Реализация HA в Mirantis OpenStack ,



Следующий момент — вопрос производительности кластера.

Будет полезно по этой теме пост о способах повышения производительности вычислений в облачных средах на базе OpenStack .

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

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

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

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

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

Предложения по отоплению шаблонизатор .

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

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

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

Перемещение тестовых сред в облако позволяет команде тестирования стать владельцами своих тестовых сред: они могут создавать, удалять и управлять ими без вмешательства ИТ-специалистов.

При этом ИТ-команда обычно управляет аппаратным кластером и облачной средой.

Теперь давайте рассмотрим конкретный вариант использования.

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

Тестовая среда также была построена на базе VMWare и управлялась ИТ-отделом.

Компания выявила ряд проблем: • Группа тестирования не смогла создать локальную тестовую среду по требованию.

• ИТ-специалистам потребовалось слишком много времени для выполнения запросов на создание новых тестовых сред. • Возникли трудности с масштабированием тестовой среды и/или добавлением новой.

• Затраты на создание, обслуживание и масштабирование тестовых сред были высокими (отчасти из-за стоимости лицензий VMWare).

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

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

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

• Изоляция различных тестовых сред. • Предоставление ИТ-команде возможности отслеживать потребление ресурсов каждой командой тестирования.

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

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

Например, один проект для команды тестировщиков, другой для команды консультантов и т. д. (См.

docs.openstack.org/trunk/openstack-ops/content/projects_users.html ) • Тепловые шаблоны позволяют быстро создавать новые среды.

Команда тестирования может самостоятельно создавать новые шаблоны Heat. • Самообслуживание включено через OpenStack CLI/Horizon и шаблоны Heat. • Общая стоимость решения на базе OpenStack ниже, поскольку компании не нужно платить за лицензии и она может использовать недорогое программное и аппаратное обеспечение общего назначения.

• Тестировщики являются владельцами своих тестовых сред. Они могут создавать и удалять среды в любое время.

• OpenStack позволяет ИТ-персоналу устанавливать квоты для каждого проекта.

Компонент OpenStack под названием Ceilometer также можно использовать для мониторинга потребления ресурсов облачных экземпляров.

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

Конечно, не каждая тестовая среда может быть построена на OpenStack и не каждый тест может быть выполнен в облаке.

OpenStack, как и любая другая облачная операционная система, имеет свои ограничения и проблемы.

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

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

Оригинальная статья по-английски .