#amazon-web-services #amazon-ec2 #scalability #autoscaling #amazon-ami
#amazon-веб-сервисы #amazon-ec2 #масштабируемость #автоматическое масштабирование #amazon-ami
Вопрос:
У меня есть несколько экземпляров, работающих за балансировщиком нагрузки с автоматическим масштабированием в AWS.
Теперь, если мне нужно внести некоторые изменения в код этих экземпляров и любых новых экземпляров, которые могут запускаться из-за политики автоматического масштабирования, каков наилучший способ сделать это?
Единственный известный мне способ — создать новый AMI с последним кодом, изменить политику автоматического масштабирования, чтобы использовать этот новый AMI, а затем завершить работу существующих экземпляров. Но это может потребовать более длительного простоя, и я не уверен, можно ли автоматизировать весь процесс.
Любые указания в этом направлении будут высоко оценены.
Комментарии:
1. На какой платформе выполняется этот код, J2EE, PHP и т.д.? Например, если J2EE, какой движок, Jetty, Tomcat и т.д.?
2. Я использую Ubuntu AMI с установкой LAMP для PHP-приложения.
Ответ №1:
Способ, которым я выполняю свои изменения в коде, заключается в том, чтобы иметь главный сервер, на котором я редактирую код. Все подчиненные серверы, которые масштабируются, затем синхронизируются через ssh с помощью задания cron, чтобы обновить все файлы. Все серверы синхронизируются каждые 30 минут несколько случайных секунд, чтобы не допустить доступа к нему в ту же секунду. (обратите внимание, что я оставляю мастер отключенным от балансировщика нагрузки, чтобы пользователям всегда отправлялся один и тот же код. Аналогично, когда я решаю опубликовать свои изменения в коде, я выполняю rsync со своего тестового сервера на свой главный сервер.
Используя этот подход, вам просто нужно ввести команду синхронизации при запуске, и вам не нужно беспокоиться о том, в каком состоянии находился код на ведомом образе, поскольку он будет обновлен после загрузки.
РЕДАКТИРОВАТЬ: Сейчас мы прекратили использовать этот метод и начали использовать новый сервис AWS CodeDeploy, который создан именно для этой цели:
http://aws.amazon.com/codedeploy/
Надеюсь, это поможет.
Комментарии:
1. как синхронизировать подчиненный экземпляр с основным?
2. Я использую rsync witch довольно просто, если у вас настроен ssh с аутентификацией пары ключей между подчиненными устройствами и главным сервером. Пример команды: rsync -arvzi —perms —exclude «.*» -e ssh MyUser@Master. MyDomain.com:/var/www/ /var/www/ Эта команда выполняется на подчиненном устройстве и будет извлекать изменения с главного сервера. Тогда у меня была бы настроена команда, подобная этой, для запуска каждые 30 минут. как хроническое задание. Надеюсь, это прояснит это для вас.
3. Итак, я предполагаю, что изменений схемы базы данных никогда не будет? Потому что тогда вы бы выдавали ошибки на подчиненных устройствах, которые еще не были обновлены. Да?
4. На самом деле мы используем DynamoDB для управления нашей базой данных (NoSQL). Наша структура данных на самом деле в формате JSON и хранит только ту информацию, которая отличается от значений строк по умолчанию. Это делает так, что если вводится новое значение, значение по умолчанию уже подразумевается для предыдущих строк, и это также означает, что сама схема устанавливается со стороны программного обеспечения и обновляется одновременно.
Ответ №2:
Мы настраиваем нашу конфигурацию запуска на использование «чистого» готового AMI — мы используем эти:http://aws.amazon.com/amazon-linux-ami
Одной из особенностей этих AMI является CloudInit — https://help.ubuntu.com/community/CloudInit
Эта функция позволяет нам передавать во вновь созданный простой экземпляр vanilla EC2 некоторые данные. В частности, мы предоставляем экземпляру скрипт для запуска.
Скрипт (в двух словах) выполняет следующее:
- Само обновление (чтобы убедиться, что все исправления безопасности и багов применены).
- Устанавливает Git и Puppet.
- Клонирует репозиторий Git с Github.
- Применяет сценарий puppet (который является частью репозитория) для настройки самого себя. 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/
Комментарии:
1. Прочитайте блог codento: Похоже, причина, по которой недостаточно просто создать снимок AMI для запуска, недостаточна:
The problem with that is that you need to repeat the process whenever you want to upgrade to a new base AMIс точки зрения автоматического масштабирования, это ужасно медленно. Я вижу, что вы уничтожаете экземпляры (спасибо за совет as по сравнению с ec2), но как насчет простого обновления репозитория var / www / directory экземпляра ec2 с поддержкой ebs с помощью git clone и позволить серверу продолжать работать? Новые экземпляры с автоматическим масштабированием также будут извлекаться оттуда. Есть ли проблема с таким простым подходом?2. Очевидно, что исправление существующих серверов происходит быстрее. Я не уверен, как бы вы синхронизировали ELB с перезапуском веб-сервера, чтобы не допустить простоя конечного пользователя. Кроме того, у меня нет проблем примерно в течение 5 минут с момента предупреждения о пиковом использовании, пока у меня не будет столько серверов, сколько я хочу присоединиться к пакету. В моем случае использования это просто достаточно быстро. и в большинстве случаев я бью тревогу раньше.
Ответ №3:
Похоже, вы можете вручную удвоить размер группы автоматического масштабирования, это создаст экземпляры EC2 с использованием AMI из текущей конфигурации запуска. Теперь, если вы уменьшите группу автоматического масштабирования до прежнего размера, старые экземпляры будут уничтожены, и выживут только экземпляры, созданные из нового AMI.