Используйте докер или пользовательский AMI в Amazon ElasticBeanstalk

Question

Я переношу приложение на Amazon и ElasticBeanstalk, кажется, правильным инструментом.

Это приложение требует некоторых пакетов, которые не установлены в значениях по умолчанию AMI, и я нашел два пути для получения полной среды для моего приложения:

• Пользовательских AMI: Просто добавьте некоторые пакеты по умолчанию AMI и сохраните его как пользовательский AMI.

• Docker Container: используйте изображение Amazon с поддержкой Docker, предоставляя Dockerfile и позволяя Amazon создавать и разворачивать изображение.

Мой вопрос в том, что является рекомендуемым вариантом?

Я беспокоюсь о таких вещах, как производительность или время развертывания, связанные с автомасштабирования (там будет несколько экземпляров)

Я хочу знать, если кто-нибудь знает реальные плюсы и константный или все опции (в теории оба варианта " равно "). Я также знаю оба метода (пользовательский AMI и Docker), но никогда не пробовал в среде с высокой нагрузкой.

Answer 1

После некоторого времени, пытаясь использовать разные варианты, у меня достаточно информации для ответа на вопрос.

Вместо того, чтобы использовать пользовательский AMI, тем лучше я нашел Elastic Beanstalk, а затем настроить экземпляр с помощью ebextensions С ebextensions вы можете полностью настроить свой экземпляр (пакеты, файлы .. все). Преимущества в том, что ваш экземпляр будет обновлен автоматически, и вы не потеряете контроль над экземпляром экземпляра. Недостатки заключаются в том, что вы обязаны использовать эластичный бобовый стебель.

Я также заметил, что докер - лишний дополнительный слой. Очень полезно для развития, но немного головная боль для производства, потому что вы теряете контроль над своим экземпляром.

Мой выбор (основанный на моем личном опыте) используется по умолчанию amazon ami, а затем использовать ebextensions для их автоматической настройки.

Answer 2

У AWS documentation on creating custom AMIs for Elastic Beanstalk есть шаги по правильному созданию пользовательского AMI. Интро обсуждает плюсы и минусы AMI против конфигурационных файлов довольно хорошо:

Обычай AMI может улучшить время инициализации, когда экземпляры запускаются в среде, если вам нужно установить много программного обеспечения, которое не входит в стандартные ОИМ.

Использование конфигурационных файлов отлично подходит для настройки и настройки вашей среды быстро и последовательно. Однако применение конфигураций может занять много времени при создании и обновлении среды. Если вы выполняете большую конфигурацию сервера в файлах конфигурации, вы можете уменьшить это время, создав пользовательский AMI, у которого уже есть требуемое программное обеспечение и конфигурация.

Пользовательский AMI также позволяет вносить изменения в компоненты низкого уровня, такие как ядро ​​Linux, которые трудно реализовать или использовать в файлах конфигурации долгое время. Чтобы создать пользовательский AMI, запустите платформу Elastic Beanstalk AMI в Amazon EC2, настройте программное обеспечение и конфигурацию в соответствии с вашими потребностями, а затем остановите экземпляр и сохраните AMI.

Это, очевидно, зависит от использования, но, как правило, рекомендуемый подход заключается в использовании конфигурации, если вам не нужно сильно изменять свою среду настолько, чтобы время разворота становилось фактором. Следует также рассмотреть возможность того, что их команда может отделить файлы конфигурации от кода приложения.