Легко поддаться очарованию мантры «собрать один раз, запустить в любом месте», не осознавая в полной мере, насколько сильно может отличаться опыт развертывания контейнеров в разных средах, пишет на портале InformationWeek Дерек Эшмор, директор по трансформации приложений компании Asperitas.

Отчасти популярность контейнеров объясняется тем, что один и тот же образ приложения может работать практически в любой среде. Разработчикам не нужно перекомпилировать или переупаковывать приложение для поддержки различных сред.

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

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

Принципы, применимые ко всем контейнерным развертываниям

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

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

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

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

Различия между контейнерами в разных облаках

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

Например, между крупнейшими публичными облаками — Amazon Web Services, Microsoft Azure и Google Cloud Platform (GCP) — в целом нет больших различий в управлении контейнерами. Однако каждое облако предлагает различные варианты сервисов оркестровки контейнеров. Так, AWS предлагает как собственный контейнерный оркестровщик Elastic Container Service (ECS), так и оркестровщик на базе Kubernetes под названием Elastic Kubernetes Service (EKS). В свою очередь, Azure и GCP предлагают в основном только оркестровку на базе Kubernetes (хотя Azure поддерживает ограниченную интеграцию с некоторыми другими оркестраторами, например Swarm, через Azure Container Instances). Это означает, что сервисы, которые вы используете для управления контейнерами, могут отличаться в зависимости от того, в каком облаке они размещены.

Инструментарий и конфигурации безопасности контейнеров также различаются в разных облаках. Инструментарий управления идентификацией и доступом (IAM) у каждого провайдера свой, что требует различных политик и определений ролей. Аналогично, если настроить контейнеры на использование определенных облачных ресурсов — например, данных в ведрах хранилища Amazon S3 или уведомлений SNS, — то они будут работать только с той облачной платформой, которая предоставляет эти ресурсы. По этим причинам нельзя переносить политики безопасности контейнеров из одного облака в другое. Для переноса приложения между облаками необходимо провести рефакторинг.

Аналогичным образом, если вы используете встроенные службы мониторинга и оповещения облачного провайдера (например, Amazon CloudWatch или Azure Monitor), то должны понимать, что инструменты и процессы мониторинга и наблюдаемости в разных облаках будут отличаться. Это особенно актуально, если вы встраиваете агенты мониторинга конкретного облака непосредственно в контейнеры: в этом случае вам придется обновлять агенты, чтобы переместить контейнеры в другое облако, не нарушая рабочий процесс мониторинга и оповещения.

Влияние Kubernetes на управление контейнерами

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

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

Сетевая интеграция в развертываниях на базе Kubernetes также выглядит иначе. Kubernetes поддерживает множество методов (например, ClusterIP и NodePort) для доступа контейнеров к публичным сетям, но все они основаны на концепциях и инструментах, характерных только для Kubernetes. Вы не можете взять сетевую конфигурацию, созданную, например, для Docker Swarm, и применить ее к кластеру Kubernetes.

Другой пример: большинство команд используют для управления средами инструменты, специально разработанные для Kubernetes, например Helm. Кроме того, Kubernetes поставляется с собственным инструментом администрирования — kubectl.

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

Вывод: «собрать один раз, настраивать каждый раз»

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

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