Чек-лист: внедряем контейнеры

Выбор технологии

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

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

Плюсы использования контейнеров:

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

У кадрового агентства был сайт, который располагался внутри одной из виртуальных машин и был построен `по классике`. В какой-то момент ресурс был взломан, и единственная машина превратилась в тыкву — бизнес на несколько дней был лишен сайта, который генерировал большинство заказов. Когда клиент обратился к нам за помощью, мы предложили полностью перенести сайт в контейнерные кластеры. В этом случае, если компрометируется один из контейнеров, он выводится из обращения, при этом остаются его копии, продолжающие выполнять все функции, данные доступны и в несколько кликов создается его полный аналог рядом. Владимир Свиридов, директор по развитию бизнеса, IBS Datafort

Кому не подходит

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

Контейнеры не понадобятся:

компаниям, работающим на старых монолитных приложениях;

Например, классическое «1С:Управление торговлей» не предусмотрено разработчиками для масштабирования и соответственно не может быть помещено в контейнеры потребителями, – поясняет Владимир Свиридов. – Всегда есть приложения, которые лучше работают в монолите, но при этом находятся клиенты, которые хотят и их контейнеризировать. Технически это возможно, но в этом случае понижается производительность всей системы.

когда задача не может быть параллелизирована: ее можно решить исключительно последовательными действиями; при работе с Big Data: сверхбольшие объемы данных имеет смысл хранить не в контейнерах, которые подразумевают что-то маленькое и легкое, а разместить рядом на отдельно стоящих системах – довольно распространена схема, когда данные хранятся отдельно от приложений, а контейнеры забирают данные с сервера баз данных (при этом количество контейнеров и конечных приложений, обращающихся к базе данных, может быть огромное количество – десятки, сотни и даже тысячи).

Подготовка

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

Процедуру подготовки можно разбить на несколько этапов:

Формирование команды Переход на контейнеры требует, чтобы в команде были технари, для которых контейнеры, оркестрация и CI-СD (Continuous integration & Continuous delivery, непрерывная разработка и непрерывная доставка) не будут набором новых слов. Сейчас рынок перенасыщен подобными специалистами, благодаря этому всегда можно отдать процесс на аутсорс – в этом случае будет произведен анализ потребностей конкретного клиента и предложена схема перехода.

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

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

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

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

Основная суть контейнера и заключается в том, что он выполняет только одну функцию, – подчеркивает Денис Альшанов. – Контейнер, выполняющий сразу несколько задач, не имеет смысла, так как он уже ничем не отличается от классического виртуального сервера.

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

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

Внедрение

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

Приватное облако / On-premise инфраструктура – с полностью выделенным контуром и комплексными мерами защиты. Решение может быть развернуто в полуавтоматизированном режиме. Вместе с настройками это может занять до нескольких дней. Стоимость решений в полуприватном или приватном облаке рассчитывается в зависимости от необходимого числа виртуальных машин или физических серверов, в случае большого объема ресурсов. При этом зачастую не удается добиться значительной оптимизации расходов, т.к. оплата ресурсов провайдера или собственные затраты фиксированы.

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

В облаке IBS Datafort готовый продуктивный кластер Kubernetes можно развернуть за 20 минут со всеми основными компонентами, – рассказывает Денис Альшанов. – Время переноса данных приложений зависит от объемов информации.

Выбор сервис-провайдера

При выборе провайдера необходимо в первую очередь обратить внимание на следующие моменты: насколько автоматизированы процессы создания контейнера, развертывания кластера и управления ими; есть ли возможность централизованного контроля и обновлений; имеются ли встроенные средства организации процесса разработки (CI/CD) и мониторинга; наличие глубокой экспертизы у инженеров провайдера; насколько развит продуктовый портфель дополнительных сервисов, который может не потребоваться в текущий момент, но с ростом и развитием компании окажется полезной возможность их простой интеграции с существующей инфраструктурой; уровень SLA и технические параметры качества сервисов.

Услуга по быстрому развертыванию кластеров Kubernetes становится все более востребованной, отмечает Владимир Свиридов. – В IBS Datafort поступает минимум один запрос в неделю от достаточно крупных клиентов, которые либо уже имеют в собственном приватном облаке некие контейнерные решения и хотят их повторить у нас, либо ищут площадку, где можно запустить новую архитектуру.

Экономическая целесообразность микросервисного подхода хорошо видна на сравнении типичной конфигурации кластера Kubernetes в классическом облаке и на платформе микросервисов IBS Datafort. Ниже приведен расчет для следующих параметров: Мастер-ноды — 1 шт. 4 vCPU, 32 памяти и 100ГБ SSD; Компьют-ноды — 3 шт 4 vCPU, 32 памяти и 100ГБ SSD. В классической модели необходимо сразу создать 4 виртуальных сервера с фиксированной платой.

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

Таким образом, даже при максимальном потреблении всех ресурсов кластера контейнеров стоимость реализации данного сервиса в микросервисной платформе IBS Datafort Cloud почти на 20% ниже по сравнению со стандартной схемой аренды вычилительных машин. При этом заказчик получает всю дополнительную функциональность в виде автоматического масштабирования систем по требованию, автоматического развертывания большинства решений, доступа к маркетплейсу с сотнями доступных для скачивания и установки приложений.