Развертывание вручную и Amazon Elastic Beanstalk

Каковы преимущества, которые мы получаем, используя Elastic Beanstalk, по сравнению с созданием экземпляра EC2, настройкой сервера Tomcat, развертыванием и т.д. для типичного веб-приложения Java Балансировка нагрузки, мониторинг и автомасштабирование - единственные преимущества?

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

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

Однако вы должны думать об этом следующим образом: в настоящей платформе как услуге (PAAS) цель состоит в том, чтобы отделить приложение от платформы. Как разработчик, вы беспокоитесь только о своем приложении. Платформа вам «сдана в аренду». «Экземпляры» платформы автоматически обновляются, администрируются, масштабируются, балансируются и т. Д. Для вас. Вы просто загружаете свой файл WAR, и он просто работает (по крайней мере, теоретически).

EC2 сам по себе не является PAAS. Это больше похоже на IAAS ( Инфраструктура как услуга). ). Вам по-прежнему нужно заботиться об экземплярах серверов, устанавливать на них программное обеспечение, обновлять их и т. Д.

Elastic Beanstalk - это система PAAS. Так же, как App Engine и Azure среди многих других.

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

В системе PAAS СУБД - это отдельная служба. Для Amazon это будет Amazon RDS . Как и в случае с 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 - это Паас. Создание экземпляра EC2 (IAAS) вручную - это все равно что делать все с нуля, но у вас есть надежный контроль.

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

• Эти вещи, которые имели для меня значение,

  • В среде Beanstalk было обнаружено множество ошибок 504.
  • При сбое сервера BeanStalk было трудно отлаживать, поскольку журналы также не отображались и не могли подключиться к компьютеру по ssh. Это очень важно.
  • Установка / настройка инструментов, таких как Celery, Redis (необходимо запустить другой порт) и т. Д.,. в выделенном экземпляре намного проще.

• В моем случае мне пришлось масштабировать сервер (Beanstalk), чтобы запустить установку некоторых пакетов (например, pandoc). В Ubuntu это проще.

• В BeanStalk масштабирование намного проще. Клонирование серверов в BeanStalk выполняется просто.

• Я взял микро в обоих случаях (посвященный и бобовый стебель). Я чувствовал, что специальный микро-экземпляр был лучше.

• Автоматическое развертывание в Beanstalk. Мне пришлось писать сценарии, чтобы автоматизировать то же самое, и это нормально, так как это делается только один раз.