Как автоматически обновить список вышестоящих серверов nginx при изменении или увеличении имени хоста aws ec2?

Я хочу настроить автомасштабирование в AWS. Я не хочу использовать Elastic Load Balancer.

Автоматический вызов в Amazon создает экземпляры EC2 незаметно в периоды пиковых нагрузок для поддержания производительности и автоматически снижается в периоды затухания спроса для минимизации затрат.

Поскольку эти экземпляры EC2 создаются автоматически, их имена хостов неизвестны NGINX.

Я знаю и уже настроил апстрим в nginx до 10 экземпляров EC2.

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

— Луис Лобо Боробия
источник

Вы должны удалить «автомасштабирование» из вашего вопроса. Автомасштабирование - это термин AWS. Я думаю, что вы имеете в виду, что вы хотите автоматически масштабировать (по горизонтали), добавляя больше восходящих узлов к вашему nginx, действующему как LB, и вы спрашиваете, как автоматически изменить конфигурацию nginx при добавлении / удалении / изменении вышестоящих узлов. Если это так, пожалуйста, измените ваш вопрос соответственно.

— talonx

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

— Луис Лобо Боробия

Вопрос яснее сейчас, в его намерениях. Я хотел проголосовать, чтобы открыть заново, но я не вижу выбора - думаю, у меня еще недостаточно представителей.

— talonx

Спасибо @talonx. Я надеюсь, что другие могут прислушаться к моему ответу

— Луис Лобо Боробия

Я думаю, что вы можете объединить уведомления AWS для автоматического масштабирования (доставленные с использованием SNS) - при условии, что он возвращает имя хоста вновь созданного / прерванного экземпляра - и один из сторонних API nginx для обновления и перезагрузки конфигурации nginx. Извините за расплывчатость - я не очень знаком с API для автоматического масштабирования.

— talonx

Ответы:

Это может быть достигнуто с помощью Amazon SDK (я почти закончу с ним, переместу его на github), используя сервисы SNS, EC2 и Autoscaling.

Я выполнил следующие шаги для достижения этой цели:

Включить HTTP-уведомление и подписаться на мой веб-сервер.
В мою группу автоматического масштабирования для завершающего сервера добавлен хук жизненного цикла с сердцебиением в 1 минуту (ожидание в течение 1 минуты перед завершением).
Создан индексный файл для разбора сообщения, чтобы определить тип сообщения (например, Launch or Terminate)
Как только тип события определен, я запросил у EC2 частный ip экземпляра.
В случае запуска дождитесь получения заголовка 200, затем добавьте ip в конфигурацию nginx и перезагрузите
В случае Завершения удалите IP из конфигурации и перезагрузите nginx

Пожалуйста, найдите скрипт здесь https://github.com/singhupendra/aws-autoscale

— Upendra
источник

Есть ли шанс, что вы разместили это на github? Я пытаюсь сделать то же самое, и любая помощь будет оценена.

— Аарон

пожалуйста , используйте - github.com/singhupendra/aws-autoscale

— Упендра

Спасибо @talonx, я провел некоторое исследование, Amazon Autoscale имеет API для запроса текущего статуса автомасштабирующей группы и перечисляет ее членов. Он возвращает идентификатор экземпляра ( http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/api_requests.html#query-example ), затем вы можете использовать инструменты описания, чтобы получить имя сервера ( http: // docs .aws.amazon.com / AWSEC2 / latest / CommandLineReference / ApiReference-cmd-DescribeInstances.html ) и, наконец, воссоздать исходный включаемый файл. Я мог чувствовать уведомления Autoscaling, чтобы запустить процесс, который выполняет эти задачи.

Я все еще не реализовал это, но это путь.

Можно также использовать Autocaling с SNS http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.html

— Луис Лобо Боробия
источник

Это в основном то, что я сделал. Я написал скрипт ruby, который запускается каждые N минут. Используя AWS SDK, он запрашивает членов ASG и, используя шаблон ERB, генерирует новую конфигурацию. Если новый конфиг отличается от текущего, он копирует его на место и говорит демону (haproxy в моем случае) перезагрузить свой конфиг. Обратите внимание, что экземпляры остаются в ASG на некоторое время после их завершения, поэтому убедитесь, что instance.status ==: running. Также обратите внимание, что если для обслуживания запросов требуется N минут после запуска экземпляра, не используйте его до тех пор, пока> instance.launch_time + N.

— Марк Вагнер,

Спасибо @MarkWagner. Есть ли возможность где-нибудь поделиться этим сценарием? Gist, GitHub? Благодарность!

— Луис Лобо Боробия

Вам повезло с этим сценарием? Есть ли пример на github или где-то еще?

— Аарон

Нет, но сейчас nginx-plus (платная версия) позволяет это больше.

— Луис Лобо Боробия

Я еще не реализовал это сам, но я изучаю возможность быстрой реконфигурации NGiNX Plus . Я думаю, что либо AMI, либо управление конфигурацией (Puppet, Salt и т. Д.), Которое устанавливает экземпляр группы автоматического масштабирования, может достичь API переконфигурирования NGiNX (возможно, через внутреннее доменное имя Route53, поэтому никакой фиксированный IP-адрес не будет необходимо использовать), и добавьте себя в вышестоящий кластер для обратного прокси. После этого встроенная проверка работоспособности NGiNX заменит этот [добавленный] экземпляр и отбросит его на случай, если он станет недоступным. Это кажется самым чистым решением, и нет никакой задержки в добавлении экземпляра, и почти нет задержки в его отбрасывании, поскольку в NGiNX Plus имеется внешняя проверка работоспособности.

При таком подходе не требуется настраивать систему автоматического обнаружения (Consul, Serf и т. Д.), Которая для небольших установок часто кажется слишком сложной как с точки зрения настройки / администрирования, так и с точки зрения требуемых экземпляров EC2. Консул, например, требует, чтобы минимум три экземпляра были стабильными. Возможно, Serf может работать на самих экземплярах ASG, но все еще есть издержки на его обслуживание, и если ASG уменьшится до одного или двух экземпляров, вы потеряете кворум.

Наконец, это может быть объединено с автоматическим уведомлением об изменениях группы автоматического масштабирования, возможно, на серверах NGiNX, которые используются для балансировки нагрузки. Слушатель, запускаемый таким уведомлением (это может быть то, на что также ссылался Upendra), может затем мгновенно добавить новый экземпляр в NGiNX через API модификации «на лету». Помимо стоимости NGiNX Plus, возникает вопрос: зачем вообще использовать Elastic Load Balancer с его многочисленными проблемами?

Редактирование 2015-12-07: ngx_openresty «ы балансир-на-Lua ( см это GitHub нить ) предлагает другое возможное решение с открытым исходным кодом для горячего добавления / удаления серверов из группы Nginx вверх по течению. Я еще не экспериментировал с этим сам, но хотел бы добавить здесь упоминание для всех, кто наткнулся на этот пост.

— Виль
источник