Введение

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

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

Из большого набора сервисов Амазона с контейнеризацией мы рассмотрим несколько сервисов, по которым есть достаточно достоверная выборка:

• Сервис контейнеризации Амазона (EC2 CS)
• Сервис краткосрочных операций (Lambda)
• Сервис компиляции/тестирования (CodeBuild)

Общее у них следующее:

1. Все эти сервисы запускаются на виртуальных машинах (инстансах), работающих под управлением Amazon Linux
2. Они построены на сервисе контейнеризации docker
3. Возможно контролировать практически все параметры контейнера

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

Сервис контейнеризации Амазона (EC2 CS)

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

Обычный сценарий работы: создаётся кластер контейнеров из нескольких ВМ (инстансов), и сервис запускается на них. Для высокодоступности используется ещё один сервис Амазона – Балансировщик (ELB), перенаправляющий запросы по необходимости в несколько контейнеров и даже умеющий расширять их число при повышении нагрузки.

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

1. Фиксированное ограничение CPU/Memory
2. При размещении нескольких контейнеров на 1 ВМ это не работает если котнейнеры используют одни и те же порты
3. Не умеет распределять контейнеры правильно по датацентрам Амазона (Availability Zone), и из-за этого нестабильно работает балансировщик нагрузки
4. Всегда надо иметь резерв по ВМ – иначе при перезапуске сервиса может случиться в Deadlock

Сервис краткосрочных операций (Lambda)

Декларируемое назначение данного сервиса это разнообразные высокодоступные краткосрочные клиент-сервисы, например, системы мониторинга, контроля, сообщений. Имеют жёткий лимит на время действия – не более 5 минут, используют только скрипт для работы (python, java jar, javascript nodejs). Не имеют входящих портов принципиально но умеют обрабатывать сообщения из очередей Амазона (например SNS).

Сервис очень удобен для крошечных простейших операций (например проверить веб-сервера и отослать СМС в случае недоступности) но при более-менее серьёзном использовании очень ограничен. В реальных сценариях использования имеет ряд недостатков:

1. Из-за времени использования многие возможности принципиально недоступны
2. Нет входящих портов или протокола UDP за редкими исключениями
3. Отладка просто чудовищно сложна из-за использования CloudWatch для хранения логов
4. Работа с бинарными приложениями страшно неудобна и сложна
5. Доступ к сервису SSH весьма нетривиален

Сервис компиляции/тестирования (CodeBuild)

Декларируемое назначение данного сервиса это компиляция/сборка/тестирование разнообразного кода. В идеале позволяет заменить комбайн типа Jenkins на контейнеризованные решения. Стандартное использование – исходный код забирается с хранилища S3 (веб хранилище Амазона), строится в контейнере, записыается снова на S3.

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

1. Для сервиса надо вначале подготовить базовый контейнер с системой сборки
2. Отладка построения очень сложна из-за использования CloudWatch для хранения логов
3. Сама постройка требует очень много времени из-за частей: развернуть контейнер, забрать файлы, положить файлы
4. При постройке есть фиксированный набор этапов, он выполняется весь, даже если этап вернул ошибку и только в конце сообщается о неудаче.
5. Интеграция «из коробки» через CodePipeline с git (например с гитхабом) очень ограничена.

Заключение

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