Коли я стояв перед вибором способу деплою додатку на AWS, я почав з Elastic Beanstalk, оскільки це здавалося найпростішим варіантом, і всі говорили, що це найпряміший шлях для деплою на AWS. На той момент я ще не працював з ECS.
Я активно працював з Beanstalk протягом останніх 6 місяців, але зрештою вирішив відмовитися від нього та спробувати щось нове, і це було ECS.
Під час спроби вказати на очевидні недоліки Beanstalk, я зрозумів, що це не так просто, але найпростіший спосіб висловити свої відчуття — це просто не давало мені чудового досвіду користувача.
Тому я зробив крок назад і почав знову аналізувати, які варіанти у мене є.
AWS пропонує три різні рівні деплою, що задовольняють різні потреби:
- Elastic Beanstalk: Це найпростіший рівень, який зосереджений лише на деплої коду.
- ECS (Elastic Container Service): Рішення середнього рівня, яке базується на Docker контейнерах. Це місце, де я знайшов свою золоту середину.
- EKS (Elastic Kubernetes Service): Найбільш просунутий варіант, який побудований на Kubernetes і пропонує велику гнучкість і можливості налаштування.
Якщо ваш додаток не такий великий, щоб вимагати Kubernetes, ECS буде найкращим рішенням для розгортання масштабованих контейнерних сервісів, особливо в керованих середовищах.
Є два основні варіанти хостингу для ECS:
- Fargate — це рішення, яке я обрав. Мені подобається повністю безсерверне (serverless) рішення.
- EC2 — означає, що вам потрібно буде керувати EC2 інстансами.
Як тільки я спробував ECS, мені стало легше вказати на відмінності між Beanstalk і ECS і чому перше не було таким хорошим:
- Управління логами: У Beanstalk доступ до логів є дуже трудомістким процесом. Якщо ви знаходитесь всередині Beanstalk і хочете побачити логи для конкретного сервісу, вам потрібно запросити логи, завантажити архів і потім блукати по лабіринту лог-груп і файлів. ECS значно спрощує цей процес.
- Оновлення конфігурацій: Оновлення конфігурацій у Beanstalk, особливо на декількох інстансах, було дуже неприємним. Бували моменти, коли сервіс зависав, залишаючи нас у поламаному стані. ECS пропонує більш стабільний і швидкий процес оновлення конфігурацій.
- Інтеграція з GitHub: Beanstalk не має офіційної GitHub Action для деплою, що змушує користувачів покладатися на пакети, створені спільнотою. В свою чергу, ECS має офіційну GitHub Action.
- Обмеження CI/CD в Beanstalk: Наші спроби налаштувати повноцінний CI/CD конвеєр у Beanstalk мали багато проблем. Ми не могли змінювати змінні середовища під час деплою або виконувати міграції баз даних. ECS, зі свого боку, краще підтримує інтеграції CI/CD.
- Автоматичне масштабування: Хоча в Beanstalk можна налаштувати автоматичне масштабування, це не зовсім просто. ECS досягає значних успіхів у цій області, пропонуючи більш надійне та ефективне рішення для автоматичного масштабування.
Висновок
Я вже виконув велику частину роботи з Beanstalk і можу сказати, що:
Я думаю, що Beanstalk виконав свою роль — бути стартовою точкою.
Хоча обидві платформи мають свої переваги, передові функції, можливості інтеграції та загальна надійність ECS зробили його очевидним переможцем для мене. Для тих, хто стоїть перед подібним вибором, я рекомендую приділити ECS більше уваги.
У наступній статті я розповім, як швидко і легко перейти на ECS, мігруючи з чогось дуже базового, як Beanstalk.
Перекладено з: Why I migrated from AWS Beanstalk to ECS + Fargate: A Personal Perspective