Изменения конфигурации запуска Auto Scaling
Интересно, есть ли простой способ или рекомендации по обеспечению того, чтобы все экземпляры в группе AutoScaling были запущены с текущей конфигурацией запуска этой группы AutoScaling.
Чтобы привести пример, представьте себе группу автомасштабирования с именем www-asg
с 4 необходимыми экземплярами, на которых запущены веб-серверы за ELB. Я хочу изменить AMI или пользовательские данные, используемые для запуска экземпляров этой группы автомасштабирования. Поэтому я создаю новую конфигурацию запуска www-cfg-v2
и обновляю www-asg
, чтобы использовать ее.
# create new launch config
as-create-launch-config www-cfg-v2 \
--image-id 'ami-xxxxxxxx' --instance-type m1.small \
--group web,asg-www --user-data "..."
# update my asg to use new config
as-update-auto-scaling-group www-asg --launch-configuration www-cfg-v2
К настоящему времени все 4 запущенных экземпляра все еще используют старую конфигурацию запуска. Интересно, есть ли простой способ заменить все запущенные экземпляры новыми экземплярами для обеспечения новой конфигурации, , но всегда гарантирует, что минимум экземпляров будет запущен.
Мой текущий способ достижения этого заключается в следующем.
- сохранить список текущих запущенных экземпляров для данной группы автомасштабирования
- временно увеличить количество желаемых экземпляров +1
- ждать появления нового экземпляра
-
завершите один экземпляр из списка через
as-terminate-instance-in-auto-scaling-group i-XXXX \
--no-decrement-desired-capacity --force
-
подождите, пока экземпляр замены будет доступен
- Если осталось больше одного экземпляра с 4.
-
завершать последний экземпляр из списка через
as-terminate-instance-in-auto-scaling-group i-XXXX \
--decrement-desired-capacity --force
-
все экземпляры должны теперь запускаться с одинаковой конфигурацией запуска
У меня в основном автоматизирована эта процедура, но я считаю, что должен быть какой-то лучший способ достичь той же цели. Кто-нибудь знает более эффективный способ?
Mathias
Также опубликовал этот вопрос на официальном форуме AWS EC2.
Ответы
Ответ 1
Это не так много, но вы могли:
- создать новый LC
- создать новую ПГС, используя новый LC
- масштабировать старый ASG
- удалить старые asg и LC
Я делаю развертывания таким образом, и в моем опыте переходить с одной ASG на другую, вместо того, чтобы прыгать туда-сюда. Но, как я заметил, это не огромная разница.
Возможно, стоит посмотреть: https://github.com/Netflix/asgard, который является средством OSS Netflix для управления группами автомасштабирования. Я закончил тем, что не использовал его, но он тем не менее интересен.
Ответ 2
Старый вопрос, который я знаю, но я думал, что поделюсь своим подходом.
Я изменяю конфигурацию запуска для ASG, затем запускаю то же количество экземпляров, которые в настоящее время находятся в ASG, когда они становятся доступными (автоматическое тестирование), которые они прикрепляют к ASG. как только машины были добавлены, наша система развертывания обновляет наш лайнер loadbalancer (s) для использования новых экземпляров, а старые экземпляры завершаются.
Все вышесказанное автоматизировано, а полномасштабный переключатель масштаба сайта занимает около 5 минут в зависимости от времени запуска.
Если вам интересно, мы используем SNS для обработки обновления лака, когда экземпляры добавляются или удаляются, или в случае масштабирования loadbalancers (чего почти никогда не бывает) система развертывания обновляет конфигурацию route53 вместо этого.
Я думаю, что в значительной степени все охватывает