Ручне розгортання проти Amazon Elastic Beanstalk

Які переваги ми отримуємо за допомогою Elastic Beanstalk над тим, що вручну створювати екземпляр EC2 та налаштовувати сервер tomcat та розгортати тощо для типового веб-додатку Java. Чи є балансування навантаження, моніторинг та автоматичне масштабування єдиними перевагами?

Припустимо, для моєї веб-програми, яка використовує базу даних, я встановив базу даних в самому екземплярі EC2. Коли відбудеться автоматичне виклик, чи буде створена база даних у новоствореному екземплярі, або він матиме доступ до бази даних, яку я створив у головній інстанції ... Якщо це створює лише репліку, коли відбувається автоматичне масштабування, як відбуватиметься синхронізація даних між екземплярами?

Все, що ви згадали, як балансування навантаження, моніторинг та автоматичне масштабування - безумовно, переваги.

Однак вам належить думати про це так: У справжній Платформі як сервісі (PAAS) мета полягає в тому, щоб відокремити додаток від платформи. Як розробник, ви переживаєте лише про свою програму. Платформа вам "орендується". "Екземпляри" платформи автоматично оновлюються, адмініструються, масштабуються, врівноважуються тощо. Ви просто завантажуєте свій файл WAR, і він просто працює (принаймні теоретично).

EC2 сам по собі не є ПААС. Це більше схоже на IAAS ( інфраструктура як послуга) ). Ви все ще повинні дбати про екземпляри сервера, встановлювати на них програмне забезпечення, постійно оновлювати їх тощо.

Elastic Beanstalk - це система PAAS. Так само App Engine і Azure серед багатьох інших.

У справжній системі PAAS СУБД є окремим компонентом від серверів (-ів) веб-додатків. Причина очевидна: СУБД неможливо встановити на екземплярах, які використовуються для сервера додатків, оскільки, коли екземпляри створюються та знищуються на основі вашого трафіку, СУБД буде втрачена! Взагалі, наявність СУБД і сервера додатків на одній машині / екземплярі взагалі не є хорошою ідеєю.

У системі PAAS СУБД є окремою послугою. Для Amazon це був би RDS Amazon . Як і в Elastic Beanstalk, де вам не потрібно турбуватися про сервер додатків, і ви просто завантажуєте свій файл WAR, використовуючи RDS, вам не потрібно турбуватися про СУБД, і ви просто розгортаєте свою базу даних.

Elastic Beanstalk і RDS дуже добре працюють разом, особливо коли вони розміщені в одній зоні доступності, де затримка буде дуже низькою.

Нарешті, використання Elastic Beanstalk не коштує нічого більше, ніж розгорнуті ресурси (екземпляри EC2 та балансир навантаження). Однак RDS не є дешевим і, безумовно, буде дорожчим, ніж використання одного екземпляра EC2 як для сервера прикладних програм, так і для СУБД.

Elastic Beanstalk робить більше, ніж просто завантажувати балансування, моніторинг та автоматичне масштабування.

1) Керує версіями додатків, зберігаючи та керуючи різними версіями програми, дозволяючи легко перемикатися вперед і назад між різними версіями своїх додатків.

2) Має поняття "середовища" для кожної програми, що дозволяє розгорнути різні версії програми у кожному середовищі. Це зручно, наприклад, якщо ви хочете створити окремі середовища QA та DEV, і ви хочете легко розгорнути збірку спочатку в DEV, а потім розгорнути ту саму версію програми в QA, коли ваша команда з QA готова до наступної збірки.

3) Екстерналізує важливі властивості конфігурації контейнера (наприклад, параметри пам'яті Tomcat) для консолі та API Elastic Beanstalk. Через це ви можете легко зберегти налаштування та скопіювати їх між середовищами.

4) Перегляньте файли журналів додатків через консоль і автоматично прокатуйте та архівуйте файли журналів до S3. (Правда, ця функція наразі незначна.)

У мене було розгорнуто додаток як у EC2 (Nginx & Gunicorn), так і в середовищі Beanstalk (CentOS & Apache2).

Мої спостереження:

• BeanStalk - Paas. Створювати екземпляр EC2 (IAAS) вручну - це як робити все з нуля, але ви маєте надійний контроль.

• BeanStalk поставляється за замовчуванням CentOS та Apache (Httpd). Ви можете вибрати ОС у виділеному екземплярі.

• Ці речі, які були для мене важливі,

  • У середовищі Beanstalk виявилося багато 504 помилок.
  • Було важко налагоджувати помилку, коли сервер BeanStalk вийшов з ладу, оскільки журнали також не відображатимуться і не могли потрапити в машину. Це дуже важливо.
  • Встановлення / налаштування таких інструментів, як Celery, Redis (потрібно запустити інший порт) тощо. у виділеному екземплярі набагато простіше.

• У моєму випадку мені довелося масштабувати сервер (Beanstalk), щоб запустити встановлення деяких пакетів (наприклад, pandoc). У Ubuntu такі речі простіші.

• Масштабування набагато простіше у BeanStalk. Сервери клонування прості в BeanStalk.

• Я взяв мікро в обох випадках (присвячений & Beanstalk). Я відчував, що відданий мікро екземпляр був кращим.

• Автоматизоване розгортання в Beanstalk. Мені довелося писати сценарії для автоматизації тих же, що добре, оскільки це лише один раз.