Я хотел бы иметь балансировщик нагрузки для моего сайта и обновлять его. Балансировщик нагрузки возьмет выбранный мной AMI и раскрутит больше этих экземпляров, когда вычислительная мощность достигнет определенного уровня. Проблема в том, что AMI может быть устаревшим, поэтому некоторые экземпляры будут обновлены, а другие нет. При развертывании я могу без проблем выполнить развертывание на всех экземплярах под балансировщиком нагрузки, но мне нужно будет знать, когда балансировщик нагрузки запускает новый экземпляр, чтобы запустить это развертывание. Также будет период времени, когда обновления будут происходить, что значительно снизит его скорость отклика. Итак, я придумал план.
Мой план:
После развертывания:
identify one of the instances and
get instance id
identify volume of instance id
ec2-create-snapshot vol-yyyyyyyy
get snapshot volume id
ec2reg -s snap-zzzzzzzz -a x86 -d Description -n imagename
get image id
as-delete-launch-config existinglaunchconfig
as-create-launch-config mylaunchconfig --image-id IMAGEID --instance-type m1.small --key mykey --group mysecuritygroup
as-update-auto-scaling-group --launch-configuration mylaunchconfig
Прежде чем я уйду и потрачу сколько угодно часов, пытаясь разобраться в этом и писать сценарии, тестировать и все остальное, мой вопрос: сработает ли это? Есть ли способ лучше? Есть ли учебник или публикация, о которых кто-либо знает, которые ускорили бы мои усилия по этой проблеме? Спасибо.
Другой подход, который может работать с AWS, - это хранить обновленный сайт / данные / конфигурацию где-то вроде S3. Настройте AMI (или укажите соответствующий сценарий пользовательских данных) так, чтобы при запуске нового экземпляра он обновлялся. Вы можете предотвратить его добавление в балансировщик нагрузки, не ответив положительно на проверку работоспособности, пока обновления не будут завершены.
В противном случае, если вам нужно, чтобы экземпляры появлялись быстрее, ваш подход кажется разумным. Просто убедитесь, что вы приостановили автоматическое масштабирование, прежде чем начинать обновление живых экземпляров и возобновить после новой конфигурации запуска. Вы не хотите, чтобы он запускал экземпляры, которые не обновляются.
Я также не уверен, что вы можете удалить конфигурацию запуска, которая используется ELB. Возможно, на этом этапе придется подождать, пока он не будет заменен. Опубликуйте здесь обновление, когда узнаете.
Я столкнулся с той же проблемой, что и вы. У меня есть группа автоматического масштабирования, которая масштабируется вверх и вниз с трафиком, и я все время отправляю обновления даже при пиковой нагрузке. Мое решение немного сложнее, поскольку мне нужна промежуточная область, чтобы можно было тестировать обновления моего кода, прежде чем они попадут на живые серверы. Вот как я собираю / обновляю свои серверы на самом простом уровне.
Сборка базы AMI - Это AMI без исходного кода, этот AMI может быть связан со сторонними приложениями, которые вам нужны или нет. Например, для одного из моих серверов мне нужны AppFabric, IIS, AWSSDK.NET и .NET 4.0. Я устанавливаю все эти инструменты и сохраняю ami. Мои серверы linux я делаю это во время выполнения, так как он намного быстрее.
Хранить исходный код в S3 или SVN - Когда ваш сервер запускается, он получает последний код из SVN или S3. Чтобы обновить существующие серверы, просто отключите их по одному или группами, и группа Auto Scaling запустит другой с последним кодом.
В зависимости от того, насколько терпима ваша служба к сбоям, вы также можете реализовать промежуточный сервер, например, я должен протестировать новый код перед отправкой запросов. Моя установка требует двух групп автоматического масштабирования. Первая группа - это в основном мой уровень безопасности и аутентификации, который использует PHP-код. После проверки запроса он пересылается в другую группу автоматического масштабирования.
Для обновления уровня аутентификации безопасности по-прежнему требуются шаги, описанные мной и Эриком Хаммондом. Однако я стараюсь не сильно обновлять этот код, он не содержит бизнес-логики и почти никогда не меняется. Изменения в этом слое всегда должны быть обратно совместимыми, чтобы, если вы все же вносите обновления, у вас может быть сразу 2 версии серверов онлайн без каких-либо проблем.
Обновления бизнес-уровня - это то место, где я применяю все изменения своего кода для обновления функций, исправления ошибок и т. Д. Хитрость заключается в создании другой группы автоматического масштабирования / балансировщика нагрузки при выполнении обновлений с его собственными серверами и кодом (снова из SVN или S3). После тестирования вы обновляете локальный DNS-сервер (при условии, что он у вас есть), и уровень аутентификации безопасности автоматически запускается с использованием новых серверов.
Изменить: забыл добавить эту ссылку http://www.slideshare.net/AmazonWebServices/aws-architectingjvariafinal. Содержит очень хорошую информацию о решении этого типа проблем и несколько других вещей, которые вы можете знать или не знать об aws.