Досвід використання AWS ECS в нашій інфраструктурі

image
У даній статті я б хотів поділитися нашим досвідом використання AWS ECS в інфраструктурі, розповісти про плюси і мінуси цього продукту і про те, як ми вирішували проблеми з цим пов'язані. Почнемо з визначення:
Amazon EC2 Container Service – це високопродуктивний сервіс управління контейнерами з високими можливостями масштабування.
По суті ECS це спроба компанії Amazon влізти в ринок управління контейнерів, де зараз існують Kubernetes, Mesos/Marathon, Docker Swarm та інші. Однак, на відміну від них Amazon надає сервіс з API, таким чином найбільш близький аналог це Google Compute Engine (aka kubernetes-as-a-service). Варто відзначити, що сам ECS безкоштовний, а ви платите тільки за EC2 инстансы.

Робота з ECS виглядає наступним чином:

  • Створюємо кілька EC2 инстансов, встановлюємо на них ECS-агента і об'єднуємо в кластер
  • Створюємо файл з описом контейнерів і як їх потрібно запускати (кількість, стратегія деплоя, змінні оточення, etc)
  • Передаємо цей файлик через API в наш кластер
  • ECS сам вибере на якому з инстансов слід запустити контейнер і перезапустить його в разі падіння
  • ???
  • PROFIT
Для читачів, які вже використовували Kubernetes, ця схема здасться вельми знайомою. Крім роботи через API, ці ж дії можна виконати через веб-інтерфейс. Наочно діаграмі:

image
Проблема балансування і service discovery
Запустити контейнери зазвичай буває мало, потрібно ще як то до них достукатися. Для цього потрібно знати на якому з инстансов і на якому порту запущений наш контейнер. Для вирішення цієї проблеми AWS пропонує інтеграцію з ELB, де ви повинні вказати статичний порт для вашого контейнера і підключити до кластеру ELB на цьому порту. Такий підхід використовується в PaaS Empire.

Примітка: я не дивився на новий AWS ALB, можливо там все по-іншому.

Цей спосіб не позбавлений недоліків, наприклад, нам потрібно платити за кожен ELB для кожного типу сервісів, навіть якщо на них немає трафіку. Особливо ця проблема гостро стоїть якщо ми плануємо створювати сервіси динамічно. Так само мине можемо запускати більше 1 сервісу на 1 инстансе з-за конфлікту портів. Все це веде до неефективної утилізації ресурсів і незручностей використання. Це не наш шлях.

Після пошуку інструментів для service discovery наш вибір припав на consul від Hashicorp. Для реєстрації контейнерів в consul ми використовуємо registrator. Таким чином на инстансы крім ECS-агента ми встановлюємо ще consul-агента і registrator. На схемі:

image
Після старту контейнера ECS-агентом випадковому порту, registrator отримує нотифікацію через docker api і реєструє сервіс в consul. Registrator дозволяє використовувати магічні змінні оточення для того щоб визначити healthcheck для сервісу в consul, а так само вказати теги.

Далі нам необхідно вирішити проблему балансування трафіку між consul сервісами і ми вирішили спробувати fabio, основна перевага якого відсутність конфігурації. Fabio конфігурує себе, читаючи список сервісів з consulа, і, відповідно тегах, будує таблицю маршрутизації. При зміні статусу сервісу або додавання нового, fabio моментально відновлює таблицю маршрутизації. У Fabio є так само інтерфейс, в якому можна подивитися поточні маршрути та кількість трафіку перенаправляемого на певний контейнер:


На спрощеною схемою, можна бачити, що нам вдалося використати лише 1 ELB для всього кластера:


Сервіси
В ECS ми деплоим стандартні stateless 12factor програми, обгорнені в docker контейнери. Ми використовуємо власну обгортку над AWS API для ECS, щоб деплоить сервіси було ще легше і зручніше. Так замість JSONа, який приймає ECS, ми використовуємо спрощений yml, що нагадує формат Kubernetes:

demo-service.yml
---
- name: demo-service
image: test-image
версія: 4.2
region: eu-central-1
cluster: ecs-cluster
cpu: 128
memory: 256
port: 8080
instances: 2
custom_env:
SOMEVAR: somevalue


Такий файл лежить в кожному сховищі кожного сервісу, який деплоится на ECS. Можете порівняти його з JSON, який приймає AWS. При цьому для деплоя потрібна тільки обгортка і AWS API ключ.

Ми так само інтегрували ECS з github через Jenkins і деплоим кожен pull request на ECS при відкритті, для розробників це виглядає так:



Так при code review кожен може перевірити пропоновані зміни в сервісі і запустити інтеграційні тести. Так і запустити додаток відразу «в хмарі» досить приємно.

Плюси
На мій погляд, ECS цілком справляється із завданням оркестрування контейнерів і з цим «можна жити». До очевидних плюсів я б відніс наступне:

  • Безкоштовність — плата лише за EC2.
  • Hosted рішення, де вам не потрібно думати про fault tolerance.
  • Низький поріг входу, все можна «накликати» через веб-інтерфейс.
  • Інтеграція з EC2 і ECS відразу знає, коли інстанси не доступний.
  • Інтеграція з CloudWatch і AutoScalingGroup, яка дозволяє регулювати кількість EC2 инстансов в ECS кластері в залежності від кількості запущених контейнерів.
Мінуси
А тепер те, чого нам не вистачає і чому для наступного проекту я буду використовувати Kubernetes.

  • Vendor-lock на AWS.
  • Повільний розвиток ECS як продукту, так і інтеграцій інших сервісів з ним. Так у eu-central-1 до цих пір немає інтеграції з OpsWorks.
  • AWS SDK немає прямого способу перевірити exit code контейнера, при запуску one-off task. У Kubernetes це є.
  • Хоча заявлено, що ECS знає про зони доступності (aka availability zone aka AZ), розподіл контейнерів між AZ не такий як ви могли б очікувати. Так, наприклад, у разі якщо одна AZ буде не доступна, то всі контейнери будуть переміщені в іншу, однак, після підняття цієї AZ ваші контейнери вже не будуть переміщені. Так само я спостерігав дивацтва при деплое, коли весь сервіс був задеплоен тільки в 1 AZ, тому що там були инстансы з найбільшою кількістю ресурсів.
  • ECS нічого не знає про healthcheckи контейнерів, запущений сервіс це той, де контейнер запустився. У Kubernetes це є.
  • Якщо ви хочете statefull програми — ECS не для вас. При цьому в Kubernetes вже є стерпна підтримка і з кожним релізом ситуація поліпшується.
  • Пропрієтарний продукт, куди можна надіслати патч.
Висновок
Коли ми починали використовувати ECS (кінець 2015 року) він був досить непоганий в порівнянні з конкурентами. Однак, по закінченні часу можна сказати, що ECS не встигає за ринком і цього продукту мало шансів на успіх в майбутньому. Можна, наприклад, подивитися куди тепер коммитит найактивніший розробник ecs-agentа. ECS підходить тим, хто тільки почав своє занурення в світ оркестрации контейнерів, але якщо ви плануєте серйозний проект на тривалий термін, то подивіться в сторону Kubernetes або Mesos/Marathon.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.