Андрей Зайчиков, Архитектор AWS

Всем привет!

Этим постом мы открываем серию публикаций по использованию Amazon Web Services для создания и управления средами разработки и тестирования. Это будет серия постов, отражающих разные аспекты создания, управления и использования сред разработки и тестирования на AWS.

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

Если вы когда-нибудь начинали работать над ИТ проектом с нуля – вы точно знаете, что Аристотель был прав. Это как раз тот случай, когда начало – это, как минимум, половина дела.

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

• Настроить репозитории;
• Настроить тестовые среды;
• Настроить среду для проектной документации;
• Настроить build и CI сервера;
• Завести проект в баг трекер, настроить представления для клиента, настроить отчеты для менеджеров;
• Завести почтовые рассылки и группы в мессенджерах;
• Убедиться, что у всех есть доступ;
• Далее – в зависимости от того, насколько большая команда, проект, насколько «продвинутый» заказчик и проч.

Как раз на этом этапе пойдет всё не так, как может пойти. Окажется, что часть арендованных серверов занята, аренда части ресурсов подходит к концу, человек, который в прошлом проекте отвечал за документацию уволился, а для хранения вики вы всегда использовали его собственный аккаунт на файл-шеринге. Команда поменяется на 30% и появятся еще две субподрядные организации, которые слыхом не слыхивали о половине ваших инструментов и пользуются своими, появятся удаленные разработчики; централизованного почтового сервиса у вас никогда не было, баг-трекер хочется поменять и нужно перенести данные. Да мало ли, что пойдет не так.

И это, естественно, только на первом этапе. Дальше будет увеличение ресурсов где-нибудь на collocation, незапланированный переезд, долгий процесс настройки сети и последующие разборки, насколько сеть влияет на тестирование. Болезненный сбор логов, метрик и сравнение одного с другим.

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

Очевидно, когда трудозатраты на администрирование очень большие, эксперименты становятся довольно накладными и рисковать временем и ресурсами не хочется. На одном из моих предыдущих проектов (вне рамок AWS) выделение одного «голого» сервера с Ubuntu для экспериментов удаленного разработчика заняло 32 дня при условии, что ресурсы были в наличии.

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

Вот, что мы получаем.

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

• Вы всегда знаете, где можно получить необходимое количество ресурсов, а также, то, что эти ресурсы будут предоставлены по требованию;
• Вы платите только за то, что используете (например: выборочная остановка виртуальных машин по окончании рабочего дня, по выходным и в праздники позволит рациональнее расходовать ресурсы);
• Вы полностью контролируете выделение, использование и стоимость ресурсов (доступ к ресурсам, управление ресурсами; политики контроля стоимости ресурсов и проч.);
• В AWS уже есть большое количество сервисов, обычно входящих в состав общих ресурсов команды разработчиков (S3, CodeCommit, CodeDeploy, проч.). Для многих популярных продуктов существуют заранее подготовленные образы виртуальных машин (Amazon Machine Image – AMI), включающих лицензию в стоимость использования;
• У вас есть практически неограниченный объем ресурсов в зрелых регионах;
• Вам не нужно тратить время на админитсрирование: значительная часть сервисов AWS не требует никакой дополнительной работы по администрированию.

Есть несколько основных сценариев использования тестовых сред и сред разработки:

• Персональные тестовые среды;
• Общие ресурсы команды разработчиков;
• Среды для быстрого прототипирования;
• Prod-like среды.

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

В этом сценарии:

• Используются три AWS accounts: один для общих ресурсов и персональных сред, один для прототипирования, один для организации продуктивной среды;
• Virtual Private Cloud (VPC) используется для разделения ресурсов по подсетям, упрощения контроля ресурсов и эмуляции реальной сети. Доступ к VPC осуществляется через VPN туннель или Интернет;
• Elastic Compute Cloud (EC2) используется в качестве основных вычислительных ресурсов. Это виртуальные сервера в облаке, которые разворачиваются с использованием Amazon Machine Image (AMI);
• Simple Storage Service (S3) – объектное хранилище, которое можно использовать для хранения объектов (очевидно ;)) любых типов и объемов (размер одного объекта до 5Tb);
• CloudFormation используется для автоматизации процедуры выделения ресурсов,  в том числе, связанных ресурсов.

Несколько интересных ресурсов и видео:

На сегодня, пожалуй, все. Спасибо за внимание.

Следите за нашими следующими постами. Будет интересно!