Как заставить HTTP-вызов достигать всех экземпляров за балансировщиком нагрузки amazon AWS?

Ответ 1

Вы не можете выполнять эти запросы через балансировщик нагрузки. Поэтому вам нужно будет открыть группу безопасности экземпляров, чтобы разрешить входящий трафик из другого источника, кроме ELB. Это не значит, что вам нужно открыть его для всего прямого трафика. Вы можете просто перечислить IP-адрес в группе безопасности, чтобы разрешить запросы с вашего конкретного компьютера.

Если вы не хотите добавлять общедоступные IP-адреса на эти серверы, вам нужно запустить что-то вроде команды curl для экземпляра EC2 внутри VPC. В этом случае вам нужно будет только открыть группу безопасности, чтобы разрешить трафик с какого-либо сервера (или группы серверов), который существует в VPC.

Ответ 2

один из способов решить эту проблему -

1. запись данных в корзину AWS s3
2. автоматический запуск лямбда-функции AWS из записи s3
3. использование AWS SDK для идентификации экземпляров, подключенных к ELB, из функции Lambda, например, используя boto3 из python или AWS Java SDK
4. вызывать/обновлять отдельные экземпляры Lambda
5. при создании нового экземпляра (из-за автоматического масштабирования или развертывания) он загружает данные из корзины s3 во время запуска
6. гарантируя, что частные подсети, в которых находятся экземпляры, разрешают трафик из подсетей, подключенных к лямбде
7. обеспечение того, чтобы группы безопасности, подключенные к экземплярам, разрешали трафик от группы безопасности, подключенной к лямбде

ключевые победы этого решения -

• процесс полностью автоматизирован с момента записи данных в s3,
• позволяет избежать несогласованности данных из-за автоматического масштабирования/развертывания,
• прост в обслуживании (вам нигде не нужно жестко кодировать ip-адреса экземпляров),
• вам не нужно выставлять экземпляры вне VPC
• высокая доступность (AWS гарантирует, что Lambda вызывается при записи s3, вам не нужно запускать скрипт в экземпляре и следить за тем, чтобы экземпляр работал и работал)

надеюсь, что это полезно.

Ответ 3

Хотя это может быть невозможно с учетом ограничений вашего приложения и обстоятельств, стоит отметить, что наилучшая практика архитектуры приложений для экземпляров, работающих за ELB AWS (особенно, если они являются частью AutoScalingGroup), гарантирует, что экземпляры не являются с сохранением состояния.

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

Один из вариантов заключается в том, чтобы изменить приложение для хранения результатов перезагрузки эталонных данных в хранилище данных вне экземпляра, таких как кеш или база данных (например, Elasticache или RDS), а не в памяти.

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

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

Ответ 4

Как вы используете S3, вы можете автоматизировать свою задачу, используя уведомление ObjectCreated для S3.

https://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html

https://docs.aws.amazon.com/cli/latest/reference/s3api/put-bucket-notification.html

Вы можете установить AWS CLI и написать простой Bash script, который будет отслеживать это уведомление ObjectCreated. Запустите задание Cron, которое будет искать уведомление S3 для создания нового объекта.

Установите условие в этом файле script для завивки "http://127.0.0.1/refresh", когда файл script обнаруживает новый объект, созданный на S3, он будет скручивать 127.0.0.1/refresh и делает вас каждый раз нужно делать это вручную.

Ответ 5

Лично мне нравится ответ @redoc, но я хотел предложить другую альтернативу для всех, кто интересуется, - это сочетание его и принятого ответа. Используя события создания объектов SEE, вы можете запускать лямбду, но вместо того, чтобы обнаруживать экземпляры и вызывать их, что требует, чтобы лямбда была в vpc, вы могли бы использовать лямбду, использующую SSM (aka Systems Manager) для выполнения команд через powershell или bash документ для экземпляров EC2, на которые нацелены теги. Затем документ будет вызывать 127.0.0.1/reload, как и принятый ответ. Преимущество этого заключается в том, что ваша лямбда не обязательно должна быть в vpc, а вашим EC2 не нужны входящие правила, чтобы разрешить трафик от лямбды. Недостатком является то, что для инстансов необходимо установить агент SSM, что звучит как большая работа, чем на самом деле. Там AMI AMS уже оптимизированы с агентами SSM, но установить их самостоятельно в пользовательских данных очень просто. Другим потенциальным недостатком, в зависимости от вашего варианта использования, является то, что он использует экспоненциальное увеличение для одновременных выполнений, что означает, что если вы нацеливаетесь на 20 экземпляров, он запускает один 1, затем 2 сразу, затем 4 сразу, затем 8, пока они все не будут сделаны, или пока не достигнет того, что вы установили для макс. Это происходит из-за встроенных средств восстановления после ошибок. Он не хочет уничтожать все ваши вещи, если что-то не так, например, медленно набирать вес на льду.

Ответ 6

Я решил это по-другому, не открывая новый трафик в группах безопасности или прибегая к внешним ресурсам, таким как S3. Он гибкий в том, что он будет динамически уведомлять экземпляры, добавленные через ECS или ASG.

Целевая группа ELB предлагает функцию периодической проверки работоспособности, чтобы убедиться, что находящиеся за ней экземпляры работают Это URL, на который отвечает ваш сервер. Конечная точка может содержать параметр метки времени самой последней конфигурации. Каждый сервер в TG получит пинг проверки работоспособности в пределах настроенного порога Interval. Если параметр ping изменяется, это означает, что он обновился.

URL может выглядеть так: /is-alive?last-configuration=2019-08-27T23%3A50%3A23Z

Выше я прошел отметку времени UTC 2019-08-27T23:50:23Z

Служба, получающая запрос, проверит, является ли состояние в памяти, по крайней мере, таким же недавним, как параметр метки времени. Если нет, он обновит свое состояние и обновит метку времени. Следующая проверка работоспособности приведет к неработоспособности, так как ваше состояние было обновлено.

Замечания по реализации

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

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