ИТ-портал компании «Инфосистемы Джет»

Наводим мосты между Dev и Ops

Наводим мосты между Dev и Ops

Спросите руководителя ИТ-отдела, часто ли ему приходится создавать/пересоздавать среды тестирования и разработки. Спросите руководителя отдела разработки, хватает ли ему тестовых сред и устраивает ли его скорость их создания. Уверены, согласия в оценках не будет. Ведь одни должны обеспечивать непрерывность и информационную безопасность, в то время как вторые — необходимую скорость разработки новых функций и отсутствие ошибок в коде. Те, кто успешно внедрил у себя частные облака и конвейер CI/CD, не поймут этих проблем. Остальные же сталкиваются с ними регулярно. Как же их решить?

Привычный ответ — использовать модель «инфраструктура как сервис» (IaaS). Технически ПО оркестрации, лежащее в основе большинства частных облаков, может управлять созданием (provisioning) и последующей настройкой ИТ инфраструктур, включающих серверы (как виртуальные, так и физические), СХД, сеть, службы каталога, службы терминального доступа и пр. Все наиболее развитые оркестраторы: BMC TrueSight Orchestration, MicroFocus Operations Orchestration, VMware vRealize Orchestrator и другие — имеют богатую библиотеку компонент для управления оборудованием и ПО. Но начинают обычно с решения, лежащего на поверхности: давайте автоматизируем создание виртуальных машин.


Создание универсальной услуги по развертыванию виртуальной машины с удобной настройкой — очень непростая задача. Только представьте, сколько параметров необходимо учесть: число процессоров, объем памяти, один или несколько виртуальных дисков (каждый из которых, в свою очередь, может быть размещен в различных хранилищах), один или несколько сетевых интерфейсов. А ведь может потребоваться изменение этих настроек в течение жизненного цикла сервера. В общем, море работы для программистов.

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

Чаще всего среда тестирования больше, чем просто виртуальный сервер:

  • Несколько виртуальных машин. А как же серверы приложений, менеджеры очередей, балансировщики нагрузки, серверы БД, веб-серверы?…
  • Процесс развертывания прикладного ПО. Корпоративные системы далеко не так просты в установке, как хотелось бы.
  • Тестовый набор данных — обезличенный, ограниченный по глубине хранимой информации, иначе тестовые отчеты будут выполняться слишком долго.
  • Хотя бы минимальная документация. А что, ваш отдел информационной безопасности разрешает бесконтрольно создавать серверы и заливать туда данные из промышленных систем?

Согласитесь, услуга по развертыванию виртуалки, скорее всего, не будет «бутылочным горлышком», замедляющим весь процесс тестирования. И ее автоматизация не ускорит процесс выведения новых возможностей ПО в продуктив. По нашему опыту, непосредственно работы по настройке оборудования занимают не более 15% времени при создании тестовой среды. Его большая часть уходит на проведение миграции данных, развертывание ППО и интеграцию со смежными системами. Поэтому мы считаем, что при построении частных облаков стоит включать в каталог услуги по созданию сред бизнес-приложений, а не только элементы виртуальной инфраструктуры. Какие преимущества это может дать?

Эффективность использования тестовых сред. Ресурсы существующих сред больше не будут простаивать, а новые среды станут создаваться по мере необходимости. У разработчиков больше не будет резона резервировать среды «впрок». А админы точно будут знать, чья это среда и нужна ли она.

Стабильность результатов тестирования. Все среды теперь абсолютно одинаковые, так как создаются «бездушной машиной», то есть обнаруженные проблемы будут воспроизводиться во всех средах. Что-то пошло не так? Просто пересоздадим среду с нуля. Уйдет проблема ручного переноса конфигураций между средами и «докручивания» сред вручную.

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

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

Теперь поговорим о технических средствах, которые могут все это автоматизировать. И главный инструмент — оркестратор. Это программный продукт для автоматизации управления сразу многими элементами ИТ-инфраструктуры. Таким образом, основной его характеристикой можно считать возможность гибкого управления как можно большим числом таких элементов, как серверы, виртуальные машины, системы хранения, сеть, терминальные сервисы, службы каталогов и пр. Существуют как решения от известных производителей ПО управления (BMC, Microfocus, IBM, Microsoft), так и продукты на свободном ПО (Red Hat, Cloudify и др). Выбор непрост.

По нашему опыту, нужно обратить внимание на следующие возможности ПО:

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

О последнем пункте стоит поговорить отдельно. С одной стороны, большинство компаний на сегодняшний день с опаской смотрят на публичные облака. Сможет ли провайдер облака обеспечить необходимую доступность? Что делать, если что-то сломается? Как обезопасить данные? Все эти вопросы действительно важны, и маловероятно, что прямо завтра бизнес-критичные системы будут массово переноситься в облака. Но критичность сред разработки и тестирования ниже, а частота изменений в них выше. Это ли не идеальный кандидат на миграцию? Таким образом, возможность управлять ресурсами публичного и частного облаков из одного средства автоматизации станет критичной в самом ближайшем будущем. А это уже гибридное облако.

Вычислительные ресурсы внешнего облачного провайдера представляются в оркестраторе как среда виртуализации, аналогичная по возможностям локальным виртуальным инфраструктурам, таким как VMware vSphere или Microsoft Hyper-V. Интеграция с ними не сложнее, чем настройка управления локальной фермой. Более сложной является задача обеспечить прозрачную миграцию приложений из частного облако в публичное и обратно. Например, если требуется временно расширить имеющиеся вычислительные ресурсы за счет внешних. Здесь многое будет зависеть как от архитектуры приложений, так и от инфраструктуры. Используется ли микросервисная архитектура или речь идет о монолитном приложении? Насколько интенсивен обмен данными между различными модулями приложения? Что за данные обрабатываются и каковы требования по их защите? Как обеспечить сетевую связность между облаками? Наверное, это тема для отдельной статьи. Что стоит подчеркнуть, так это то, что автоматизация и оркестрация ИТ-инфраструктуры в гибридных средах — одна из четырех основных технологических тенденций этого года и последующих лет (Gartner, 2019 Planning Guide Overview: Architecting Your Digital Ecosystem).

Кстати, к выбору средства автоматизации нужно привлечь не только ИТ-специалистов, но и разработчиков. Ведь в их руках имеются инструменты CI/CD  — например, Jenkins или Gitlab, которые могут быть использованы как средства автоматизации. В частности, с помощью плагинов Jenkins может управлять созданием виртуальных машин. Если же средств автоматизации, имеющихся в инструментах CI/CD, окажется недостаточно, то обратите внимание на возможность интеграции выбранного оркестратора с ними. Ведь следующим шагом после автоматизации развертывания среды будет ее включение в конвейер разработки и тестирования.

Но создание отдельной среды, например для тестирования, — это только полдела. Часто бывает так, что разрабатываемое приложение само по себе, без окружения, не может полноценно функционировать. Ему нужно получать данные из одних смежных систем и передавать их в другие. Окружение приложения может включать справочники, шины данных, средства ETL, какие-либо шлюзы, службу каталогов и т.п. А раз без них приложение не может функционировать, то и качественно протестировать его не получится — набор возможных проверок очень ограничен. Решение: тестовая среда должна включать не только само приложение, но и некий минимальный набор смежных систем. И тогда это будет уже не среда, а полноценный тестовый полигон. Его создание выходит за рамки CI/CD, но может быть успешно обеспечено возможностями частного облака и его средствами автоматизации/оркестрации.

***

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

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: journal@jet.su