Итак, во-первых, я новичок в AWS, так что терпите меня.
У меня был один экземпляр, работающий уже несколько месяцев, и теперь мне нужно его автоматическое масштабирование, так как я получаю большие пики трафика, и он временами перегружается.
Так что позвольте мне пройти через то, что я сделал до сих пор, и вы, ребята, можете сказать мне, где я ошибся и что мне нужно сделать по-другому.
По сути, я хочу, чтобы мой исходный экземпляр работал постоянно. Затем, когда он начинает выходить за пределы емкости, я хочу, чтобы группа автоматического масштабирования начала запускать экземпляры, а балансировщик нагрузки распределял нагрузку между ними. Правильно ли здесь мое мышление?
Другие важные вопросы.
Когда я вношу изменения в код и данные в свой исходный экземпляр, нужно ли мне переделывать образ, который использует моя конфигурация запуска?
Что нужно с DNS-именами и IP-адресами? В настоящее время я использую Route 53, могу ли я указать это на моем балансировщике нагрузки и все?
Спасибо, парни!
Давайте рассмотрим ваши вопросы.
По сути, я хочу, чтобы мой исходный экземпляр работал постоянно. Затем, когда он начинает выходить за пределы емкости, я хочу, чтобы группа автоматического масштабирования начала запускать экземпляры, а балансировщик нагрузки распределял нагрузку между ними. Правильно ли здесь мое мышление?
я бы сказал да, но у меня есть пара оговорок. Если я правильно понимаю, вы разместили свой «основной» экземпляр вне группы автоматического масштабирования. Теоретически это гарантирует, что автоматическое масштабирование не убьет ваш исходный экземпляр. Я хотел бы упомянуть несколько вещей:
min-size из 1, автоматическое масштабирование автоматически заменяет отказавший экземпляр.Когда я вношу изменения в код и данные в свой исходный экземпляр, нужно ли мне переделывать образ, который использует моя конфигурация запуска?
я бы сказал нет, но это скорее проблема дизайна. Ваше изображение должно описывать штат вашего сервера, но он не должен отвечать за распространение кода. Рассмотрим ситуацию, когда вам нужно обновить приложение из-за срочной ошибки, но ваши серверы сильно загружены. Звучит ли обновление основного сервера, создание AMI, обновление конфигурации запуска и отключение автоматически масштабируемых серверов, чтобы их можно было возродить с помощью последней версии AMI, привлекательным решением? Мой ответ на это был бы нет (очередной раз). Изучите стратегии управления версиями исходного кода и развертывания (я разработчик Rails 60% времени и использую git и capistrano, например).
Бывают ситуации, когда ваш подход тоже сработает, и здесь есть много компромиссов (я бы также рекомендовал изучить Chef и userdata скрипты). Я сам редко использую кастомные AMI, благодаря Chef.
Что нужно с DNS-именами и IP-адресами? В настоящее время я использую Route 53, могу ли я указать это на моем балансировщике нагрузки и все?
В принципе, да. Вы можете выбрать балансировщики нагрузки, которые должны быть присоединены к новым экземплярам при создании вашей группы автоматического масштабирования. Я еще не использовал графический интерфейс для автоматического масштабирования, но уверен, что он где-то там есть. В противном случае CLI по-прежнему поддерживает его. Направьте свою запись Route53 на свой ELB alias и это в основном все.
Ответ на дополнительные вопросы (23.02.2014):
Если вы разрабатываете с использованием Rails, я очень рекомендую Capistrano для развертываний, которые могут принимать определенную версию вашего приложения в предпочитаемой вами системе управления версиями (например, git) и развертывать ее на нескольких серверах в определенной среде. Существует множество руководств, но исправленные (и профессиональные) Railscast Райана Бейтса по этому вопросу очень краткие, хотя вам нужна подписка на его веб-сайт, чтобы смотреть оба из них. Однако большинство других руководств также помогут вам. Запустите новый сервер с вашим AMI и сценарием запуска, который извлекает временный клон вашего репозитория git и запускает локальную команду Capistrano для запуска вашего приложения. Это гарантирует, что в дальнейшем вы также сможете развертывать новые версии вашего приложения с помощью Capistrano с помощью всего одной команды на всех работающих серверах.
Capistrano также предоставляет несколько других преимуществ, в том числе возможность выполнять определенные задачи на всех или только на одном из серверов и откатывать развертывание, что очень сложно выполнить, используя только git.