Развертывание приложения Java EE в Amazon EC2

Question

У нас есть приложение Java EE (файл EAR , развернутый на JBoss , MySQL, MongoDB ), которое мы хотели бы развернуть на экземпляре Amazon EC2. У меня есть несколько вопросов относительно рекомендаций по развертыванию.

1. Какой наиболее часто используемый Linux AMI , на который мы можем положиться для надежного развертывания (Существует очень много вариантов Linux, и я не уверен, какой AMI обычно используется, это Fedora, CentOS , Red Hat, SUSE ...)
2. Как мы обрабатываем производственные обновления (модификации файла EAR или обновления схемы). Существуют ли какие-либо инструменты, доступные для этой установки или откат этих изменений.
3. Какие возможности резервного копирования данных доступны для базы данных?
4. Стоит ли полагаться на Amazon RDS для поддержки MySQL?
5. Как мне обращаться с поддержкой MongoDB?

Впервые я размещаю веб-приложение и буду признателен за некоторые сведения о том, как управлять производственным экземпляром.

Answer 1

1. Я согласен с ответом Марка Робинсона: используйте тот вариант Unix, который вам удобнее всего.Может быть стоит выбрать один с приличной облачной поддержкой.Для своего сайта я использую Ubuntu.

2. У меня есть общий образ, который является основой каждой развернутой версии, которую я делаю.У меня есть www.mysite.com, указывающий на Elastic IP, чтобы я мог решить, к какому экземпляру он перейдет.В общем образе установлено все необходимое мне программное обеспечение (Postgres / Postgis / Tomcat / etc), кроме папок данных базы данных и веб-сервера и ссылки на экземпляры Elastic Block Store (EBS).

   Когда придет времяРазвертывание Я запускаю новый экземпляр, замораживаю и снимаю тома EBS на производстве и создаю новые тома.Я указываю свой новый экземпляр на новые тома, а затем устанавливаю на него все, что мне нужно.После того, как я успешно все проверил на дыме, я могу переключить Elastic IP на новый экземпляр, и все будет продолжаться.

   Замечу, что у меня сейчас есть преимущество, когда только я могу изменять базу данных;пользователи не могут.Это вскоре станет проблемой.

3. Если вы используете файловую систему XFS поверх тома EBS, вы можете указать XFS заморозить файловую систему (чтобы обновления не происходили), затем вызватьEC2 API для моментального снимка тома, а затем разморозить файловую систему.В результате снимок делается быстро и отправляется на S3.У меня есть ночной сценарий, который делает это.

4. Если RDS выглядит так, как вам нужно, используйте его.Amazon быстро создает множество надежных инструментов, и это облегчит ваши проблемы с масштабируемостью, если они у вас есть.

5. Извините, я понятия не имею.

Answer 2

Хороший вопрос!

1) Я бы порекомендовал использовать тот вариант Linux, который вам наиболее удобен.Если у вас есть кто-то, кто действительно заинтересован в CentOS, пойдите с этим.Как только вы выбрали свой AMI, возьмите его и настройте, настроив, как вы хотите.Затем сохраните этот AMI в качестве базового макета.Это значительно упростит развертывание новых машин и спасет ваш бекон, если EC2 выйдет из строя.

2) Обновления с EC2 могут быть очень хорошими.Вместо обновления работающей системы возьмите предварительно настроенный AMI, обновите его и сохраните этот AMI как myAMI-1.1 (или что-то еще).Таким образом, вы можете почти мгновенно переключиться на новую систему и вернуться к предыдущей версии, если что-то сломается.Вы также можете выполнить резервное копирование экземпляров БД на S3.Это дешево, около $ 0,10 / ГБ / месяц.

3) Это зависит от того, где вы храните свою БД.Если вы храните его на своем экземпляре EC2, у вас проблемы.Экземпляры EC2 не имеют постоянного хранилища.Так что, если ваша машина сломается, вы потеряете все.Я не знаком с системой Amazon DB, но вы также должны заглянуть в Elastic Block Store.По сути, это настоящий жесткий диск, на который вы можете писать.Если вы хотите обновить свою схему, выполните полный дамп БД до S3, а затем выполните обновление вашей фактической схемы.Если что-то пойдет не так, вы можете вытащить предыдущую версию из S3.

4) & 5) Я никогда не использовал их, поэтому не могу вам помочь.

Answer 3

Если вы можете жить с развертыванием приложения Java EE на TomEE вместо JBoss, Boxfuse делает то, что вы хотите.

Для вашего приложения Java EE вам буквально нужно только выполнить (TomEE использует файлы war вместо файлов ear):

boxfuse run my-tomee-app-1.0.war -env=prod

Это будет

1. Создание AMI, содержащего TomEE, и ваше приложение готово к загрузке
2. Создание эластичного IP или ELB
3. Создать группу безопасности с правильными определенными портами
4. Создать группу автоматического масштабирования
5. Запустите свой экземпляр (ы)

Любое последующее обновление будет выполнено как развертывание с синими / зелеными с нулевым временем простоя.

Подробнее: https://boxfuse.com/blog/javaee-aws

Answer 4

What is the most commonly used Linux AMI which we can rely on for a robust deployment (There are so many Linux variants, and I am not sure which AMI is commonly used, is it Fedora, CentOS, Red Hat, SUSE ...)
How do we handle production upgrades (EAR file modifications or schema upgrades). Are there any tools which are available to handle this installation or rollback of these changes.
What kind of data backup capability is available for the database?
Should I rely on Amazon RDS for MySQL support?
How should I handle support for MongoDB?

1. Любой Linux AMI выполнит эту работу, вам нужен только JRE. (при условии, что разработка не требуется). Если вам нужно отслеживать поведение JVM, установите JConsole.
2. Самый простой и безболезненный способ - это SSH в локальный домашний каталог, передать обновленный файл класса / EAR-файл (зависит от количества примененных изменений), скопировать и заменить в каталог развертывания Tomcat, перезапустить apache. (убедитесь, что вы проверили локально перед загрузкой в ​​производство).
3. Зависит от того, какую базу данных вы используете, если вы используете MySQL, просто сделайте запланированное резервное копирование, которое записывает в ваш домашний каталог, чтобы время от времени вы могли входить в SSH и загружать копию для целей резервного копирования.
4. Я бы не стал рассматривать ответ на Amazon RDS для поддержки MySQL по 2 причинам: MySQL достаточно мал и управляем, а также я хотел бы иметь полный полный контроль над базой данных и зачем платить больше, если вы можете сделать это самостоятельно ВОК
5. Использование MongoDB должно соответствовать цели вашего приложения и преимуществам, которые вы получаете от этого. Я бы порекомендовал вам использовать MongoDB для статического извлечения данных, таких как состояние, страна, область и т. Д., Где MySQL будет использоваться только для данных транзакций.