Обновления AWS для новой версии приложения
Попытка использовать неизменную стратегию развертывания для развертывания новой версии приложения на AWS Elastic Beanstalk. Есть ли способ определить, как AWS обрабатывает трафик со старых экземпляров на новые? Так как, похоже, есть 2 набора (старый + новый) экземпляра, работающего за балансировщиком нагрузки в данной точке.
Можно ли это рассматривать как вариант сине-зеленого развертывания? Так как мы попали в тот же балансировщик нагрузки и просто изменили версию приложения, работающую на этих экземплярах?
Я не вижу очевидных объяснений в документации AWS.
1 ответ
Как работает неизменяемое обновление?
Что происходит с неизменным обновлением, так это то, что Elastic Beanstalk создаст новую группу AutoScaling с точно такими же параметрами, что и активная группа AutoScaling. Он загрузит 1 экземпляр в эту группу, проверив, что он исправен. Этот экземпляр подключается к балансировщику нагрузки и начинает обслуживать трафик по уже активным экземплярам. Затем EB продолжит загрузку экземпляров, пока в группе AutoScaling не появится необходимое количество экземпляров, соответствующее номеру в исходной группе AutoScaling. Если все новые экземпляры загружены и исправны, EB переместит их в исходную группу автоматического масштабирования и очистит только что созданную группу автоматического масштабирования, а также старые экземпляры, с удалением соединения. Так что да, временно у вас будет запущено двойное количество экземпляров.
Каковы причины использования неизменяемых обновлений, а не обновляемых обновлений?
- Вы не рискуете частичным развертыванием, так как вы рискуете в результате обновления Возможно, что не все ваши пакеты будут запущены в обновлении, что приведет к частичному обновлению вашей среды. Здесь очень важно понять, что обновляемые обновления работают в одной и той же группе автоматического масштабирования, а неизменяемые обновления создают новую группу автоматического масштабирования.
- В случае неудачного обновления необходимо снова обновить группу автоматического масштабирования, чтобы выполнить откат обновления. Отменить неизменяемое обновление так же просто, как убить новую группу автоматического масштабирования - и готово.
- Учитывая, что вы выполняете откат группы автоматического масштабирования, может также случиться (в зависимости от ваших параметров), что вам придется перезагрузить определенное количество машин со старой версией приложения. Это означает некоторое нарушение вашей среды Elastic Beanstalk.
- Ваши экземпляры всегда заменяются. Хотя это может показаться тривиальным, но каждый раз при развертывании вы получаете новый экземпляр, а не работаете на одном экземпляре "навсегда".
Истинное значение неизменяемого обновления заключается в сочетании всех этих характеристик: каждое развертывание происходит сразу, "полностью", на новых новых экземплярах. Откат не нарушает ваши работающие экземпляры.
Какова связь с зелеными / синими развертываниями? Разве это не то же самое?
Green / Blue фактически загружает полностью новую среду, выполняет все виды проверок, а затем перелистывает URL-адреса балансировщиков нагрузки. С точки зрения инфраструктуры, неизменяемые развертывания во многом напоминают развертывание зеленого / синего цветов. Однако, если вы выполняете все виды функциональных проверок вашей среды (тесты дыма, проверки работоспособности, ...), которые не имеют инфраструктурного характера, это сильно отличается, поскольку этот процесс автоматизирован. EB выполняет только проверки работоспособности при выполнении этого обновления.
Итак... почему бы не всегда использовать эту форму развертывания?
Что ж, неизменяемые развертывания не могут обрабатывать обновления конфигурации ресурсов (т. Е. Настройки балансировки нагрузки) и обновления версий приложений одновременно. Если вы хотите выполнить оба действия, вам нужно либо разделить их на 2 последовательных обновления, либо использовать зеленое / синее развертывание.
Некоторые другие случайные размышления, которые приходят на ум:
учитывая, что у вас есть предел X экземпляров в вашей учетной записи, и вы уже используете X - 2 экземпляров. Ваша среда 5 экземпляров. Вы не можете выполнить неизменное обновление, так как оно не будет соответствовать вашим ограничениям.
если ваша среда составляет 50 экземпляров (я просто указываю здесь случайное огромное число). Потребуется много времени (= денег) и ресурсов для загрузки всей группы AutoScaling из 50 экземпляров вместе с вашей исходной группой AutoScaling для обновления.