Лучший способ управлять изменениями кода для приложения в Amazon EC2 с автоматическим масштабированием

Question

У меня есть несколько экземпляров, работающих за балансировщиком нагрузки с автоматическим масштабированием в AWS.

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

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

Любые указатели в этом направлении будут высоко оценены.

Answer 1

Способ, которым я изменяю код, заключается в том, чтобы иметь главный сервер, на котором я редактирую код.Все подчиненные серверы, которые затем масштабируют rsync через ssh с помощью задания cron, обновляют все файлы.Все серверы синхронизируются каждые 30 минут + - несколько случайных секунд, чтобы избежать доступа к нему в ту же секунду.(обратите внимание, что я оставляю мастер вне балансировщика нагрузки, чтобы пользователи всегда отправляли ему один и тот же код. Точно так же, когда я решаю опубликовать свои изменения кода, я делаю rsync с моего тестового сервера на мой главный сервер.

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

РЕДАКТИРОВАТЬ: Мы прекратили использовать этот метод сейчас и начали использовать новый сервис AWS CodeDeploy, который предназначен именно для этой цели:

http://aws.amazon.com/codedeploy/

Надеюсь, это поможет.

Answer 2

Мы настраиваем нашу Конфигурацию запуска для использования «чистого» готового AMI - мы используем их: http://aws.amazon.com/amazon-linux-ami/

Одна из особенностей этих AMI - CloudInit - https://help.ubuntu.com/community/CloudInit

Эта функция позволяет нам доставлять во вновь порожденный простой ванильный экземпляр EC2 некоторые данные. В частности, мы даем экземпляру скрипт для запуска.
Скрипт (в двух словах) делает следующее:

1. Обновляет себя (чтобы убедиться, что все исправления безопасности и исправления ошибок применены).
2. Устанавливает Git и Puppet.
3. Клонирует репозиторий Git от Github.
4. Применяет кукольный сценарий (который является частью репо) для самостоятельной настройки. Puppet устанавливает остальные необходимые программные модули.

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

Теперь, чтобы обновить программное обеспечение, мы используем локальный скрипт boto. Скрипт убивает серверы, на которых работает старый код, один за другим. Механизм автоматического масштабирования запускает новые (и обновленные) серверы.

Обязательно используйте as-terminate-instance-in-auto-scaling-group, поскольку использование ec2-terminate-instance приведет к тому, что ELB продолжит отправлять трафик на экземпляр завершения работы, пока не пройдет проверку работоспособности.

Интересное сообщение в блоге: http://blog.codento.com/2012/02/hello-ec2-part-1-bootstrapping-instances-with-cloud-init-git-and-puppet/

Answer 3

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