Внедрение приложений Java EE на Amazon EC2

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

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

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

Ответы

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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) Я никогда не использовал их, поэтому я не могу вам помочь.

Ответ 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?
  • Любой Linux AMI выполнит эту работу, вам нужна только JRE. (при условии, что разработка не требуется). Если вам необходимо отслеживать поведение JVM, запустите JConsole.
  • Самый простой и безболезненный путь - это SSH в локальный домашний каталог, перенос обновленного файла класса/файла EAR (зависит от количества примененных изменений) и копирования и замены в каталог развертывания Tomcat, перезапуск apache. (убедитесь, что вы тестировали локально перед загрузкой на производство).
  • В зависимости от используемой вами базы данных, если вы используете MySQL, просто выполните запланированное резервное копирование, которое записывается в ваш домашний каталог, чтобы время от времени вы могли использовать SSH и загружать копию для целей резервного копирования.
  • Я бы не стал рассматривать ответ на Amazon RDS для поддержки MySQL из-за 2 причин: MySQL достаточно мал и управляем, а также я хотел бы иметь полный полный контроль над базой данных и зачем платить больше, когда вы можете сделать это самостоятельно ВОК?
  • Использование MongoDB должно быть согласовано с целью вашего приложения и выгоды от этого. Я бы порекомендовал вам использовать MongoDB для поиска статических данных, таких как состояние, страна, область и т.д.... где MySQL должен использоваться только для данных транзакций.

Ответ 4

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

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

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

Это будет

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

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

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