dev opsworks — обновление приложения, остановит ли оно apache

У меня на производстве есть среда с автоматическим масштабированием, которая в настоящее время вызывает хаос, когда мы обновляем сборку на ней, поэтому мы подумали, что лучше перейти к разработке в AWS, чтобы упростить процесс для нас. Мы не можем позволить себе простоя, ни сейчас, ни когда-либо, никогда; вторая потеря стоимости при обновлении сборки и, возможно, перезапуске apache стоит целое состояние.

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

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

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

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

Вам не нужно развертывать обновленное приложение в автономных экземплярах с резервным хранилищем, включая экземпляры на основе нагрузки и на основе времени; AWS OpsWorks автоматически развертывает последнюю версию приложения при перезапуске.

Вы должны перезапустить автономные инстансы с поддержкой EBS, работающие круглосуточно и без выходных, и вручную развернуть приложение; AWS OpsWorks не запускает рецепты развертывания на этих инстансах при их перезапуске.

Вы не можете перезапустить автономные инстансы с поддержкой EBS, основанные на нагрузке и времени, поэтому самый простой подход — удалить автономные инстансы и добавить новые инстансы для их замены.

Поскольку теперь это новые экземпляры, AWS OpsWorks автоматически развернет текущую версию приложения при их запуске.


person Brij Raj Singh - MSFT    schedule 27.11.2013    source источник


Ответы (1)


Прежде всего, позвольте мне сказать, что я начал изучать OpsWorks всего около 2 недель назад. Так что я далеко не профи. Но вот как я понимаю, как это работает:

Нам нужно различать экземпляры, поддерживаемые хранилищем экземпляров, и экземпляры, поддерживаемые EBS:

  • Хранилище экземпляров исчезает вместе с экземпляром после его закрытия. Поэтому, поднимая его снова, начинаем с нуля. Он должен снова загрузить последнее приложение и развернуть его.
  • Для экземпляров, поддерживаемых EBS, развернутый код остается неповрежденным (сохраняется) в течение срока жизни экземпляра, к которому он подключен. Таким образом, возвращение к жизни экземпляра, поддерживаемого EBS, не приведет к автоматическому обновлению вашего приложения. Старая версия остается развернутой.

Таким образом, ваше первое решение должно заключаться в том, какой тип экземпляра использовать. Как правило, рекомендуется иметь одну и ту же версию приложения для всех экземпляров. Поэтому я бы предложил использовать экземпляры с поддержкой EBS, которые не будут автоматически развертывать новые версии при загрузке. В этом случае развертывание новой версии будет означать создание совершенно новых экземпляров, на которых будет автоматически выполняться новый код (поскольку они новые), а затем уничтожение старых экземпляров. У вас будет очень короткое время, в течение которого старый и новый код будут работать бок о бок.

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

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

person André    schedule 28.11.2013
comment
Я бы сказал наоборот: используйте EBS только для экземпляров базы данных. Если вы хотите развернуть новую версию своего кода, просто циклически запускайте парк (запускайте новые экземпляры и уничтожайте старые). Если вам нужен больший контроль, откажитесь от ELB и используйте nginx/HAProxy. - person BraveNewCurrency; 24.12.2013