Можно ли подключиться к Amazon ElastiСache Redis за пределами Amazon?


90

Я могу подключиться к экземпляру ElastiCache Redis в VPC из экземпляров EC2 . Но я хотел бы знать, есть ли способ подключиться к узлу ElastiCache Redis за пределами инстансов Amazon EC2, например, из моей локальной установки разработчика или инстансов VPS, предоставленных другими поставщиками.

В настоящее время при попытке из моей локальной настройки:

redis-cli -h my-node-endpoint -p 6379

Я получаю тайм-аут только через некоторое время.

Ответы:


75

Нет, вы не можете не прибегать к «уловкам», таким как туннель, который, возможно, подходит для тестирования, но убьет любое реальное преимущество использования сверхбыстрого кеша с добавленной задержкой / накладными расходами.

... доступ к кластеру Amazon ElastiCache, как внутри, так и за пределами VPC, через Интернет запрещен .

Отсюда: http://aws.amazon.com/elasticache/faqs/#Can_I_access_Amazon_ElastiCache_from_outside_AWS

РЕДАКТИРОВАТЬ 2018: этот ответ был точным на момент написания, однако теперь можно с некоторой конфигурацией получить доступ к кешу Redis извне, используя направления примерно на 1/2 пути вниз по этой странице: https://docs.aws.amazon.com/AmazonElastiCache /latest/red-ug/accessing-elasticache.html#access-from-outside-aws


1
Так ли это до сих пор? В документации больше не говорится об этом - они утверждают, что redis регулируется стандартными политиками группы безопасности, но, несмотря на это, я все еще не могу получить доступ к моему узлу redis. Ударьте это. Ссылка только что переехала: к узлам Amazon ElastiCache, развернутым в VPC, нельзя получить доступ из Интернета или из инстансов EC2 за пределами VPC.
металауреат

7
Мне кажется, что «убить» - это немного сильно. Например, мы не получаем заметного снижения производительности при запуске наших приложений за пределами AWS (через такой туннель). Накладные расходы туннеля незначительны по сравнению с операциями БД, загрузкой браузера, дисковым вводом-выводом и т. Д.
sming


94

Переадресация портов SSH должна помочь. Попробуйте запустить это от своего клиента.

ssh -f -N -L 6379:<your redis node endpoint>:6379 <your EC2 node that you use to connect to redis>

Тогда от вашего клиента

redis-cli -h 127.0.0.1 -p 6379

Меня устраивает.

Обратите внимание, что порт по умолчанию для Redis - 6379нет 6739. Также убедитесь, что вы разрешили группе безопасности узла EC2, который вы используете, подключаться к вашему экземпляру Redis в вашу группу безопасности кэша.

Кроме того, AWS теперь поддерживает доступ к вашему кластеру подробнее здесь


Спасибо, что указали порт, просто опечатка. Итак, вы говорите, что SSH-туннелирование через EC2 - это единственный способ получить доступ к узлу эластичной памяти за пределами Amazon? Спасибо,
Лоик Дурос

Это правильно, как @EJBrennan, упомянутый в другом ответе.
Rico

Как мы можем отменить переадресацию порта ssh ...?
Muthukumar K,

вы можете убить процесс ssh. В Linux: kill -9 <pid>
Рико

27

Эти ответы устарели.

Вы можете получить доступ к эластичному кешу за пределами AWS, выполнив следующие действия:

  1. Создайте экземпляр NAT в том же VPC, что и ваш кластер кеша, но в общедоступной подсети.
  2. Создайте правила группы безопасности для кластера кэша и экземпляра NAT.
  3. Подтвердите правила.
  4. Добавьте правило iptables к экземпляру NAT.
  5. Убедитесь, что доверенный клиент может подключиться к кластеру.
  6. Сохраните конфигурацию iptables.

Более подробное описание см. В руководстве по AWS:

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/accessing-elasticache.html#access-from-outside-aws


Мне не нужен инстанс NAT, я хочу его на минутку проверить. Ответ Рико - именно то, что я хотел.
Pysis

6

Не такой уж старый вопрос, я сам столкнулся с той же проблемой и решил ее:

Иногда по причинам разработки вам необходимо получить доступ извне (чтобы избежать множественных развертываний только для простого исправления ошибки?)

Amazon опубликовал новое руководство, в котором EC2 используется в качестве прокси для внешнего мира:

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/accessing-elasticache.html#access-from-outside-aws

Удачи!


3
Для справки подход, упомянутый Amazon, - это экземпляр NAT.
russellpierce

К вашему сведению, из документации: «Этот подход следует использовать только для целей тестирования и разработки. Он не рекомендуется для производственного использования»
jasonjonesutah

1
Да, это правда @jasonjonesutah Я тоже упомянул об этом в своем ответе. Очень плохая идея для производства, но отлично подходит для разработки.
Шай Элкаям,

4

Мы используем HAProxy в качестве зарезервированного прокси-сервера.

Ваша система вне AWS ---> Интернет -> HAProxy с общедоступным IP-адресом -> Amazon Redis (Elasticache)

Обратите внимание, что для этого есть еще одна веская причина (в то время)

Поскольку мы используем клиент node.js, который не поддерживает аварийное переключение Amazon DNS, драйвер клиента не поддерживает повторный поиск DNS. Если redis не удастся, драйвер клиента продолжит подключение к старому мастеру, который после сбоя становится ведомым.

Используя HAProxy, он решил эту проблему.

Теперь, используя последнюю версию драйвера ioredis, он поддерживает аварийное переключение amazon dns.


1
обновление для node.js, теперь ioredis поддерживает аварийное переключение DNS. Если вы используете имя хоста DNS, оно может быть выполнено автоматически без HAProxy.
teddychan

4

Кстати, если кому-то нужно решение для Windows EC2, попробуйте их в командной строке DOS (на указанной машине с Windows EC2):

Чтобы добавить переадресацию портов

C: \ Пользователи \ Администратор>netsh interface portproxy add v4tov4 listenport=6379 listenaddress=10.xxx.64.xxx connectport=6379 connectaddress=xxx.xxxxxx.ng.0001.use1.cache.amazonaws.com

Чтобы перечислить порты с переадресацией портов

C: \ Пользователи \ Администратор>netsh interface portproxy show all

Слушайте ipv4: Подключитесь к ipv4:

Адрес Порт Адрес Порт


10.xxx.128.xxx 6379 xxx.xxxxx.ng.0001.use1.cache.amazonaws.com 6379

Чтобы удалить переадресацию портов

C: \ Пользователи \ Администратор>netsh interface portproxy delete v4tov4 listenport=6379 listenaddress=10.xxx.128.xxx


3

Это надежный скрипт узла, который сделает за вас всю грязную работу. Протестировал и убедился, что все работает.

https://www.npmjs.com/package/uzys-elasticache-tunnel

Как использовать Использование: uzys-elasticache-tunnel [параметры] [команда]

Команды:

start [filename]  start tunneling with configuration file (default: config.json)
stop              stop tunneling
status            show tunneling status

Параметры:

-h, --help     output usage information
-V, --version  output the version number

Пример использования

  • start - начало uzys-elasticache-tunnel ./config.json
  • стоп - узыс-эластика-туннель стоп
  • status - статус uzys-elasticache-tunnel

1

Невозможно получить прямой доступ к классическому кластеру из экземпляра VPC. Обходной путь - настроить NAT на классическом экземпляре.

NAT должен иметь простой tcp-прокси

YourIP=1.2.3.4
YourPort=80
TargetIP=2.3.4.5
TargetPort=22

iptables -t nat -A PREROUTING --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort
iptables -t nat -A POSTROUTING -p tcp --dst $TargetIP --dport $TargetPort -j SNAT \
--to-source $YourIP
iptables -t nat -A OUTPUT --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort

Вы также дали тот же ответ в упомянутом ниже сообщении, у которого разные требования. Как это может работать и в данном сценарии ?? stackoverflow.com/questions/38066908/…
abby37

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.