Любой компании, разрабатывающей софт, нужны тестовые среды, приближенные к продакшн-окружению. Особенно это актуально для коробочного ПО, у которого длинный цикл релизов.
Многие проблемы построения тестовых сред решает их размещение в облаке. Мы расскажем про возможности тестирования на нашей облачной платформе 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 можно массово развертывать тестовые среды, останавливать, обновлять и удалять их. Таким образом, можно настроить полный жизненный цикл для тестовых сред и поддерживать в работоспособном состоянии сотни сред. Благодаря мгновенному масштабированию облака и посекундному биллингу достигается гибкость и сокращение расходов на эксплуатацию.
Вот пример из нашего опыта
Компания разрабатывает софт для 150 банков. Для каждого банка есть своя ветка в Git с дополнительными функциями, надстроенными над коробочным решением. Компания вынуждена поднимать две–три параллельно работающие тестовые среды для каждого клиента: тестирование с текущей версией, тестирование с новой версией, проверка обновления с текущей на новую. Итого для 150 клиентов приходится развертывать и поддерживать в работоспособном состоянии одновременно до 450 только тестовых сред — это без учёта сред разработки.
В режиме частного облака (они используют виртуализацию в собственном ЦОД) работать с такой нагрузкой практически невозможно, так как доступного «железа» часто не хватает для параллельной работы всех сред. В итоге разработчики ждут своей очереди на тестирование и не могут быстро проверить работу новой версии приложения.
Автоматизированное развёртывание и управление тестовыми средами в публичном облаке снимает ограничение в скорости тестирования и в итоге сокращает time to market. Кроме того, управление расходами при аренде облачных ресурсов более предсказуемо, а сами расходы ниже, чем при использовании собственного специализированного оборудования для тестовых стендов.
В режиме частного облака (они используют виртуализацию в собственном ЦОД) работать с такой нагрузкой практически невозможно, так как доступного «железа» часто не хватает для параллельной работы всех сред. В итоге разработчики ждут своей очереди на тестирование и не могут быстро проверить работу новой версии приложения.
Автоматизированное развёртывание и управление тестовыми средами в публичном облаке снимает ограничение в скорости тестирования и в итоге сокращает time to market. Кроме того, управление расходами при аренде облачных ресурсов более предсказуемо, а сами расходы ниже, чем при использовании собственного специализированного оборудования для тестовых стендов.
Еще одно преимущество облачных тестовых сред — интеграция с 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 рублей на счёт и тестировать-тестировать-тестировать.
В нашем телеграм-канале — новости об этом и других сервисах на облачной платформе Mail.ru Cloud Solutions.
