Любой компании, разрабатывающей софт, нужны тестовые среды, приближенные к продакшн-окружению. Особенно это актуально для коробочного ПО, у которого длинный цикл релизов.
Многие проблемы построения тестовых сред решает их размещение в облаке. Мы расскажем про возможности тестирования на нашей облачной платформе Mail.Ru Cloud Solutions (MCS). Но часть из того, что мы расскажем, верна для любого облака.

Сложности настройки тестового окружения

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

Разные Git-ветки — разные среды

Большинство компаний, занятых в сфере разработки ПО, используют системы контроля версий. Наиболее распространенной из них является Git, который используют 87% разработчиков (опрос RhodeCode в Twitter).

Best practice в Git являются так называемые feature-branches (ветви), когда для каждой новой функциональности выделяется отдельная ветвь в репозитории. Такой подход позволяет разработчикам не «толкаться локтями» и делает внесение изменений более независимым, однако требует развертывания множества выделенных сред для тестирования отдельных фич.

Недоиспользование вычислительных ресурсов

25% физических серверов — это «зомби», которые потребляют электроэнергию, но не делают ничего полезного. А многие IT-специалисты не могут сказать, чем заняты 15–30% установленных в их компании серверов.

Так вот. On-premise железо под тестовые среды тут ничем не отличается от любого другого и, как правило, плохо утилизировано. И по-другому быть не может. Когда вы покупаете парк серверного оборудования, вы перезакладываетесь по ресурсам на случай роста потребления и количества тестовых сред. В итоге тестовые среды простаивают в ночное время и в выходные «на всякий случай», а вы просто платите за потребляемое электричество и охлаждение.
Простое применение виртуализации в вашем частном облаке никак не решает проблему негибкой масштабируемости и недоиспользования оборудования.

Сложность настройки

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

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

Ещё одна проблема — в том, что у штатного системного администратора часто нет экспертизы в развертывании специфических тестовых сред, и компания вынуждена привлекать дорогостоящих консультантов извне. Пример — песочница для больших данных на базе Hadoop, Spark, HDFS или Airflow. Развертывание подобного окружения занимает минимум неделю у квалифицированного в области BigData специалиста и не меньше месяца у обыкновенного системного администратора. Аналогичная история и с кластерами Kubernetes: построение тестового кластера, приближенного к продакшн-конфигурации, занимает минимум несколько дней.

В итоге компания вынуждена обращаться к третьей стороне — привлекать консультантов. Однако найти специалистов по большим данным достаточно сложно, а администраторов таких систем можно пересчитать чуть ли не по пальцам. Да, со всеми задачами по развертыванию тестовых сред может справится DevOps-инженер, но он тоже есть не в каждой компании, а найти хорошего эксперта в этой области ничуть не проще, чем специалиста по BigData. В 2016 году сайт по поиску работы indeed.com отметил, что компании ищут DevOps-инженера дольше любых других специалистов.

Как облако решает эти проблемы

Посекундный биллинг только за потребленные ресурсы и мгновенное масштабирование

Наиболее очевидный плюс облачных сервисов — возможность арендовать облачную инфраструктуру любой конфигурации (один сервер или целый кластер) на любой срок. На нашей платформе Mail.Ru Cloud Solutions (MCS) биллинг посекундный — платить нужно только за те вычислительные ресурсы, которые реально использовались.

В отличие от bare metal, private cloud и большинства российских облачных провайдеров, MCS не тарифицирует ресурсы остановленных виртуальных машин (RAM, CPU): оплачивать нужно лишь занятое дисковое пространство. Например, тестовая конфигурация 20 CPU, 40 ГБ RAM и 1 ТБ HDD стоит 24 800 ?/мес, а оплата дискового места — 7 000 ?/мес. Например, если средствами автоматизации останавливать такую среду в 21:00 и развёртывать в 9:00, вы будете платить 15 900 ? — в полтора раза меньше, чем при круглосуточной аренде.

По нашему опыту итоговая экономия от тестирования в облаке может достигать 60–70%, по сравнению с тестированием в инфраструктуре on-premise.

Возможность мгновенного масштабирования ресурсов в облаке в большую и меньшую сторону позволяет быстро развёртывать среды только на нужное время и утилизировать арендованные мощности практически на 100%. Время развертывания тестовой среды сокращается на несколько дней, а то и месяцев, по сравнению с on-premise.

Ресурсы выделяют сами разработчики

С помощью порталов самообслуживания настраивать тестовые среды в облаке и выделять для них ресурсы могут сами разработчики, не обращаясь к администраторам. Даже это простое действие может сократить time-to-market продукта на несколько недель.

API для автоматического создания и уничтожения тестовых сред

Облако позволяет создавать короткоживущие окружения по модели «точно в срок». С помощью REST API и CLI можно массово развертывать тестовые среды, останавливать, обновлять и удалять их. Таким образом, можно настроить полный жизненный цикл для тестовых сред и поддерживать в работоспособном состоянии сотни сред. Благодаря мгновенному масштабированию облака и посекундному биллингу достигается гибкость и сокращение расходов на эксплуатацию.


Еще одно преимущество облачных тестовых сред — интеграция с CI/CD-инструментами. Эти решения (например, Jenkins) содержат плагины, которые позволяют динамически создавать тестовые окружения в облаке MCS во время билда. Тестовую среду можно активировать прямо перед запуском функциональных или регрессионных тестов. Если тесты прошли успешно, среда свернётся автоматически, если что-то не так — среда сохранится, чтобы разработчики могли переподключиться и понять причину регрессии.

Готовые строительные блоки для тестовых окружений

Быстро развернуть тестовое окружение платформе Mail.Ru Cloud Solutions
помогают PaaS, например — контейнеры Kubernetes и Базы данных в облаке. На базе Kubernetes развивается сервисный каталог с сотнями приложений.

Из каталога можно развернуть за несколько минут кластеры ActiveMQ, RabbitMQ, Kafka, системы мониторинга и анализа логов, различные CMS и базы данных. В отличие от популярного Docker Hub, который содержит только индивидуальные шаблоны приложений, в Kubernetes Service Catalog есть высокоуровневые шаблоны, упрощающие интеграцию. Из шаблонов можно развёртывать преднастроенные компоненты приложений (message queue, service discovery, базы данных, серверы приложений, CI/CD инструменты, кеширующие серверы, инструменты блокчейн и многое другое), без необходимости настраивать виртуальные машины, на которых они развёрнуты.


Приложения, доступные в Kubeapps marketplace.

Песочницы для Big Data

На MCS можно разворачивать тестовые среды для приложений, работающих с большими данными. С помощью PaaS-сервиса Большие Данные можно создавать кластеры Hadoop, Spark, HBase и Airflow. Процесс развёртывания полностью автоматизирован, и это экономит недели времени по сравнению с самостоятельной настройкой.

Дополнительное преимущество здесь дает посекундный биллинг и мгновенное масштабирование. Возможность создавать расширяемые тестовые среды на короткие периоды сокращает расходы компании на поддержание аналитической IT-инфраструктуры. Экономия может достигать 80% по сравнению с on-premise.

Интеграция с Infrastructure-as-a-Code

В отличие от проприетарных решений на базе VMWare, облачная платформа MCS построена на базе открытого ПО OpenStack, которое имеет полноценную интеграцию с различными инструментами: Terraform, Ansible, Puppet, Chef.

Terraform построен в духе Infrastructure-as-Code (IaC), когда процесс настройки инфраструктуры устроен как написание кода и более привычен разработчикам. Terraform сложно использовать в частном облаке, поскольку у него отсутствует полноценная интеграция с VMware. В облаке MCS компании могут использовать готовые примеры работы с Terraform (лежат в этом GitHub-репозитории).


Создание тестовой среды с помощью Terraform.

Запомнить

• Тестирование в облаке становится естественной практикой в IT-индустрии и уже применятся самыми разными организациями: от государственных университетов до крупных IT-компаний.
• Построение тестовых сред в облаке помогает сэкономить за счёт возможности мгновенного масштабирования и автоматизации через API, которые дают практически 100% утилизацию арендованной инфраструктуры.
• Дополнительные сервисы на облачной платформе и шаблоны на контейнерах Kuberntetes — готовые строительные блоки, которые не нужно настраивать.
• Сложные в настройке сервисы, такие как инструменты обработки Big Data, проще арендовать в облаке в виде преднастроенных шаблонов. Вы сэкономите недели, избежав погружения в настройки.
• MCS построена на OpenStack и полноценно интегрирована с Terraform и другими инструментами DevOps.

Все эти инструменты можно бесплатно попробовать в платформе Mail.Ru Cloud Solutions. До конца ноября по этой ссылке с промокодом ILOVEHABR можно добавить 1000 рублей на счёт и тестировать-тестировать-тестировать.