Развертывание приложения 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) Я бы порекомендовал пойти с любым вариантом Linux, с которым вам наиболее удобно. Если у вас есть кто-то, кто действительно заинтересован в CentOS, пойдите с этим. После того как вы выбрали свой AMI, возьмите его и настройте, настроив, как вы хотите. Затем сохраните , что AMI как вы базовый макет. Это ускорит развертывание новых машин и спасет ваш бекон, если EC2 снизится.

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

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

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

Answer 2

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 3

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 по двум причинам: MySQL достаточно мал и управляем, а также я хотел бы иметь полный полный контроль над базой данных и почему платить за больше, когда вы можете сделать это самостоятельно ВОК?
5. Использование MongoDB должно быть согласовано с целью вашего приложения и выгоды от этого. Я бы порекомендовал вам использовать MongoDB для статического поиска данных, такого как состояние, страна, область и т. Д. ... где MySQL должен использоваться только для данных транзакций.

Answer 4

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

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

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

Это будет

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

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

Дополнительная информация: https://boxfuse.com/blog/javaee-aws