AWS ElasticBeanstalk та Docker - javascript.org.ua

AWS EB (ElasticBeanstalk) — це PaaS (Platform-as-a-Service), на якому ви можете керувати своїми

AWS інстанціями: EC2 сервіс
Групами безпеки
Масштабуванням (AutoScale)
Балансуванням навантаження (ELB)
Розгортанням коду та політикою розгортання
Версіонуванням артефактів: S3 використовується як сховище
Налаштуванням під час розгортання (Ті, що відрізняються між тестом, стадією, продакшеном...)
Моніторингом: використовуються сервіси CloudWatch та SNS
Pub-Sub Pattern

Кожен з цих сервісів AWS зазвичай потребує певної експертної знань, яких не потрібно для роботи з EB. Саме тому EB особливо може бути корисним для команд та компаній, які мають обмежені людські ресурси або для стартап-проектів, де ви надаєте EB права для управління вашими EC2, S3, ELB, AutoScale, моніторингом і розгортанням від вашого імені.

Конкуренти EB на ринку можуть бути:

Heroku
Azure Web Sites
Cloud Foundry
IBM Bluemix
Google App Engine
Openshift

Принципово, PaaS зазвичай не дозволяє доступ до ОС (Operating System) та посередницького програмного забезпечення (Middleware), але EB дозволяє вам підключатися через SSH до ваших інстанцій, навіть вносити зміни, що, як правило, не є хорошою практикою. Це в основному корисно для налагодження...

Ось таке розмежування між IaaS, PaaS і SaaS (1):

Ось мови та контейнери, які підтримує ElasticBeanstalk:

Java
.NET
Go
PHP
Ruby
node.js
Python
Docker

Архітектура EB

Архітектура EB побудована на додатках та середовищах, де існує відношення 1-N. Один додаток зазвичай має більше одного середовища, таких як Test, Staging, Production...

Кожне середовище має свій власний CNAME, що вказує на ELB. URL, наданий EB, має псевдонім Route53, що означає, що ви помітите його при керуванні вашими записами DNS в Route53, що дає зручність в користуванні.

На кожному інстанції є так звані скрипти Host Manager (HM), які відповідають за:

Розгортання додатків
Агреґування подій та метрик
Генерацію подій
Моніторинг стану
Ротацію лог-файлів та публікацію на S3
Патчинг компонентів інстанцій

На фоні EB генерує відповідні шаблони CloudFormation, і ці шаблони здійснюють виклики AWS SDK від вашого імені.

Існують два типи рівнів:

Web Tier: Веб-додатки, сайти, API
Worker Tier: Довготривалі задачі, споживачі

Web Tier зазвичай є більш переважним, але Worker Tier — ні. Тому я хочу детальніше пояснити, як працює Worker Tier:

Web Tier та Worker Tier працюють разом

Посилаючись на шаблон pub-sub, ми можемо назвати Web Tier публікатором, а Worker Tier — підписником. Один створює, а інший споживає за допомогою SQS. Sqsd — це демон, що працює на Worker Tier, який споживає чергу SQS і робить відповідні виклики до сервісу, що чекає на "localhost". Сервіс, що ви розгортаєте на Worker Tier, слухає лише "localhost" (щоб не порушити шаблон pub-sub, гадаю...). Ось приклад виклику:

sqsd робить виклик до сервісу на Worker Tier

Веб-додаток на localhost повертає HTTP 200, щоб повідомити, що повідомлення оброблено, а sqsd відправляє повідомлення на видалення до SQS.

Хуки — це основний механізм, який використовується для провізії серверів, розгортання нових версій, зміни конфігурацій… Це просто скрипти, специфічні для кожної мови програмування та відповідної версії середовища.
Це хоки, які використовуються в EB:

Хоки розгортання інстанції та версії Elastic Beanstalk

Хоки зміни середовища та перезавантаження серверу додатка Elastic Beanstalk

Ці хоки можна знайти на кожному інстансі AWS EB за адресою /opt/elasticbeanstalk/hooks. Ви помітите, що всі хоки є параметризованими скриптами. Коли вам потрібно налаштувати власне середовище, наприклад:

Замінити Apache на nginx
Встановити APM, наприклад NewRelic
Копіювати залежності (бібліотеки, файли…)

У вас завжди є можливість додавати/змінювати хоки та створювати кастомні образи згідно з вашими потребами.

Управління конфігурацією — ще одна функція в EB, яка спрощує налаштування під час розгортання. Підхід EB до налаштування під час розгортання специфічний для кожної мови програмування, наприклад:

Java: Змінні середовища
PHP: environment.ini
.NET: web.config
Docker: Змінні середовища

Після того як ви визначите свою конфігурацію у вигляді ключ-значення в EB Panel → Configuration → “Software Configuration”, і натиснете “Deploy”, EB застосує метод, специфічний для мови програмування/Docker. Потім усе, що вам потрібно, — це використовувати відповідні методи для кожної мови, наприклад:

Java: System.getProperty(“DBHost”)
PHP: getConfig()

Підхід до артефактів в EB також специфічний для кожної мови. Наприклад, для Java ви можете використовувати артефакти "war", але для .NET або PHP просто створюється zip-файл з поточним кодом, який версіюється і зберігається на S3. Це швидкий старт для стартап-проекту!

Артефакти коду EB на S3

Після того як ви маєте ці версії, ви можете просто розгорнути їх на своїх середовищах, використовуючи EB Panel:

Розгортання версії EB

EB підтримує майже всі останні політики розгортання (окрім канарейкових розгортань), які стають популярними в DevOps:

Підтримувані політики розгортання EB

Якщо ви віддаєте перевагу розгортанню за методом "Immutable", для кожного нового артефакту коду створюються нові інстанції (це означає, що поточні інстанції не змінюються), і трафік перенаправляється на нові інстанції, коли розгортання завершено і інстанції здорові. Або ви можете вибрати альтернативу "Rolling", яка вибирає певну кількість або відсоток інстанцій і виконує розгортання по частинах, що швидше, ніж "Immutable".
Усі ці варіанти є розгортаннями з "нульовим часом простою" (zero-downtime), за винятком "all at once".

Управління масштабуванням на EB вимагає знань про групи автоматичного масштабування AWS (AWS Auto-Scale groups), але EB все це управляє за вас! Все, що вам потрібно зробити — це визначити політику масштабування (на основі CPU, трафіку) в EB Panel → Configuration.

Якщо ви віддаєте перевагу розгортанню з використанням Docker у режимі одного контейнера або багатьох контейнерів, то оскільки EB використовує AWS AutoScale Groups, EB не може масштабувати контейнери, а лише інстанції, що означає, що всі контейнери в інстанції будуть масштабуватися разом.

EB має два варіанти, коли ви вибираєте Docker:

Один контейнер: Розгорнути Docker інстанцію та здійснити розгортання
Багато контейнерів: Використовує AWS ECS на задньому фоні

Коли ви розгортаєте багатоконтейнерне середовище, ви можете побачити це в AWS → ECS:

ECS кластер, створений через EB Multi-Container Docker

Також ви можете використовувати ECR (Elastic Container Registry) як репозиторій Docker образів:

AWS ECR — Elastic Container Registry

Ось прості команди Docker для завантаження образу до ECR:

aws ecr get-login — region eu-west-1

docker build -t nginx .

docker tag nginx:latest 417732881703.dkr.ecr.eu-west-1.amazonaws.com/nginx:latest

docker push 417732881703.dkr.ecr.eu-west-1.amazonaws.com/nginx:latest

Звичайно, оскільки це приватний репозиторій, ви не зможете здійснити "push".

Як результат, EB може бути "швидким стартом" для програмних проектів і також пропонує можливість розгортання для Docker, але коли ви розростаєтесь, вам обов'язково доведеться вибрати один із оркестраторів: