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

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

К важнейшим вычислительным ресурсам относятся память, хранение данных, обеспечение ввода-вывода (I/O), а также все современные развивающиеся функции и сервисы «нового века», такие как механизмы анализа больших данных, искусственный интеллект и различные формы автоматизации. Хотя переход к контейнерам обеспечивает бóльшую модульность компоновки, это также в какой-то мере компромисс, потому что они представляют собой более сложный взаимосвязанный набор вычислительных ресурсов, требующих управления, поддержки и координации. Несмотря на популяризацию Kubernetes и всей экосистемы так называемых технологий «наблюдаемости», знать работоспособность, функции и общее состояние каждого развернутого контейнера одновременно не всегда просто.

Миграция в контейнерную среду

«Меня часто спрашивают, как лучше всего перенести приложения из среды ВМ в контейнеры, — говорит Лей Чжан, технический руководитель и директор системы управления облачными приложениями Alibaba Cloud Intelligence. — Среду Kubernetes пытается выстроить каждый заказчик, но сделать это довольно непросто. Однако есть ряд методов, инструментов и передовых практик, доступных для их использования». Первое, что нужно сделать организациям, которые желают контейнеризировать свой стек — составить четкий план миграции ВМ. Лей Чжан предлагает разбить миграцию на этапы, начать с наиболее стабильных приложений, например, веб-сайтов, и закончить переводом в контейнеры сложных приложений, когда стек контейнеров станет более зрелым.

По словам Льюиса Маршалла, технологического евангелиста Appvia, одна из основных причин, которая подталкивает компании к контейнеризации унаследованных систем, — снижение риска. «Использование фактически неизменяемых контейнеров с вашими унаследованными системами — это возможность избавиться от вредных привычек, процессов и методов работы в системах, которые в теории необходимо модернизировать, но практически это почти невозможно», — сказал он.

Три фазы контейнеризации

Разбив контейнеризацию на рассортированные по сложности части, вы можете добыть ряд быстрых побед и создать долгосрочную стратегию, говорит президент промышленного бизнес-подразделения Persistent Systems Цзяни Чжан. Для этого ИТ-руководителям надо сделать три шага.

• Рехостинг. Старайтесь применять самую простую технику контейнеризации — она позволяет добиться быстрых побед на ранней стадии. Рехостинг, который отраслевые эксперты часто называют быстрым переносом (lift-and-shift), или миграцией приложений, — это самый простой способ контейнеризации унаследованного приложения и перемещения его в облако. Рехостинг за короткое время может резко увеличить отдачу от инвестиций. Быстрому переносу подлежат не все приложения, но чем раньше вы начнете, тем больше времени у вас останется на более сложные задачи.

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

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

Как свидетельствует опыт Маршалла, контейнеры повышают безопасность при одновременном снижении эксплуатационных и операционных расходов. Например, некоторые унаследованные системы имеют множество ручных операций, что делает любое обновление невероятно трудоемким и сопряжено с риском. Маршалл рекомендует ИТ-администраторам стремиться к тому, чтобы стоимость эксплуатации унаследованных систем приближалась к нулю. «Если ваша система является источником затрат, представляя ограниченную ценность для бизнеса, то ее обновление или модернизация должны стать вашим приоритетом. Если поддержка зависит от нескольких человек, которые регулярно тратят на это сверхурочное время, это должно послужить для вас сигналом к изменению, — говорит он. — Стоит также помнить, что по мере старения системы ее обслуживание, как правило, становится более дорогостоящим, а риски безопасности и нестабильности — возрастают».

Проблемы контейнеризации

Неизменный характер контейнерных сервисов, которые при появлении нового обновления можно удалить и повторно развернуть, подчеркивает их гибкость и масштабируемость. Но, как говорит директор по исследованиям CCS Insight Бола Ротиби, хотя контейнеры легко создавать и удалять, всегда существуют критические данные, доступ к которым должен быть открыт и осуществляться с соответствующим контролем. «Физические компьютерные хранилища — это забота растущего числа разработчиков, использующих контейнерную модель. Разработчикам необходимо принимать участие в выделении ресурсов хранения для контейнеров. Умение работать с современным хранилищем данных, а также с физическим уровнем хранения данных жизненно важно для организаций, управляемых данными», — сказала она.

Дуглас Фоллстром, вице-президент по продуктам и операциям Hammerspace, обращает внимание на то, что приложениям нужны сведения об инфраструктуре и о том, где находятся данные. Он предупреждает, что это усложняет уровень контейнеризации и в случае любого изменения требует переконфигурации приложений. Кроме того, идея хранения данных не сочетается с идеей облачных рабочих нагрузок. «Чтобы упростить оркестровку, вычисления стали бессерверными, и точно также нам нужно, чтобы данные стали „безнакопительными“ (storageless) и приложения могли получать доступ к своим данным, ничего не зная об инфраструктуре, работающей для обеспечения их циркуляции, — говорит он. — Когда мы говорим о безнакопительных данных, на самом деле мы говорим о том, что управление данными с любого сайта или любого облака должно осуществляться автономно, а их защитой и обслуживанием должны заниматься инструменты автоматизации, а не ИТ».

Что касается управления данными, то СУБД, как правило, не предназначены для работы в облачной архитектуре. По словам Джима Уокера, вице-президента по маркетингу продуктов Cockroach Labs, управление унаследованной базой данных на современной инфраструктуре, такой как Kubernetes, очень сложно. Многие организации предпочитают запускать свои базы данных вместе с масштабируемой средой, предоставляемой Kubernetes. «Это часто создает узкое место или, что еще хуже, единственную точку отказа для приложения, — добавляет он. — Запуск базы данных NoSQL на Kubernetes — это более гладкий процесс, но вы все равно будете испытывать проблемы с согласованностью транзакций».

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

Вопросы управления

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

Однако Пронин предупреждает, что если команды разработчиков устанавливают в Kubernetes автоскейлеры — чтобы приложения были более доступными и устойчивыми, — ИТ-отделы могут обнаруживать, что их облачные счета начинают расти как снежный ком. Например, пользователю AWS Elastic Block Storage придется заплатить за 10 Тб зарезервированных EBS-томов, даже если на самом деле он использует только 1 Тб. Такие расходы на облачные службы могут выйти за рамки допустимого. «Каждый контейнер имеет зарезервированные стартовые требования к ресурсам, поэтому завышенная оценка прогнозируемых ресурсов может со временем добавить значительную сумму к вашему счету», — отмечает он.

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