Können Sie eine Verbindung zu Amazon ElastiСache Redis außerhalb von Amazon herstellen?


86

Ich kann über EC2-Instanzen eine Verbindung zu einer ElastiCache Redis-Instanz in einer VPC herstellen . Ich würde jedoch gerne wissen, ob es eine Möglichkeit gibt, eine Verbindung zu einem ElastiCache Redis-Knoten außerhalb von Amazon EC2-Instanzen herzustellen, z. B. über mein lokales Entwickler-Setup oder über VPS-Instanzen anderer Anbieter.

Derzeit beim Versuch von meinem lokalen Setup:

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

Ich bekomme erst nach einiger Zeit eine Auszeit.

Antworten:


73

Nein, Sie können nicht ohne auf Tricks wie einen Tunnel zurückgreifen, der möglicherweise zum Testen in Ordnung ist, aber jeden echten Vorteil der Verwendung eines superschnellen Caches mit zusätzlicher Latenz / Overhead zunichte macht.

... auf einen Amazon ElastiCache-Cluster innerhalb oder außerhalb einer VPC darf niemals über das Internet zugegriffen werden .

Von hier aus: http://aws.amazon.com/elasticache/faqs/#Can_I_access_Amazon_ElastiCache_from_outside_AWS

EDIT 2018: Diese Antwort oben genau war , wenn geschrieben, jedoch ist es nun möglich , mit einiger configuation des Zugriff auf Redis Cache von außerhalb der Richtungen ca. 1/2 Weg unten auf dieser Seite mit: https://docs.aws.amazon.com/AmazonElastiCache /latest/red-ug/accessing-elasticache.html#access-from-outside-aws


1
Ist das noch der Fall? Die Dokumente sagen dies nicht mehr - sie behaupten, dass Redis durch Standardrichtlinien für Sicherheitsgruppen geregelt wird, aber ich kann trotzdem keinen Zugriff auf meinen Redis-Knoten erhalten. Schlag das. Ref wurde gerade verschoben: Auf Amazon ElastiCache-Knoten, die in einer VPC bereitgestellt werden, kann niemals über das Internet oder über EC2-Instanzen außerhalb der VPC zugegriffen werden.
Metalaureate

7
Ich finde, dass 'töten' ein bisschen stark ist. Zum Beispiel erhalten wir keinen nennenswerten Leistungseinbruch, wenn wir unsere Apps außerhalb von AWS (über einen solchen Tunnel) ausführen. Der Overhead des Tunnels ist im Vergleich zu DB-Vorgängen, Browserlast, Festplatten-E / A usw. winzig.
sming


93

Die SSH-Portweiterleitung sollte den Trick machen. Versuchen Sie, dies von Ihrem Client aus auszuführen.

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

Dann von Ihrem Kunden

redis-cli -h 127.0.0.1 -p 6379

Für mich geht das.

Bitte beachten Sie, dass der Standardport für Redis 6379nicht ist 6739. Stellen Sie außerdem sicher, dass Sie die Sicherheitsgruppe des EC2-Knotens zulassen, mit dem Sie eine Verbindung zu Ihrer Redis-Instanz in Ihrer Cache-Sicherheitsgruppe herstellen.

Außerdem unterstützt AWS jetzt den Zugriff auf Ihren Cluster. Weitere Informationen finden Sie hier


Vielen Dank für den Hinweis auf den Port, nur ein Tippfehler. Wollen Sie damit sagen, dass das SSH-Tunneln über EC2 der einzige Weg ist, um Zugriff auf einen Elasticache-Knoten außerhalb von Amazon zu erhalten? Vielen Dank,
Loic Duros

Das ist richtig, genau wie @EJBrennan in der anderen Antwort erwähnt.
Rico

Wie können wir die Weiterleitung von SSH-Ports widerrufen ...?
Muthukumar K

Sie können den SSH-Prozess beenden. Unter Linux: kill -9 <pid>
Rico

27

Diese Antworten sind veraltet.

Sie können außerhalb von AWS auf den Elastic-Cache zugreifen, indem Sie die folgenden Schritte ausführen:

  1. Erstellen Sie eine NAT-Instanz in derselben VPC wie Ihr Cache-Cluster, jedoch in einem öffentlichen Subnetz.
  2. Erstellen Sie Sicherheitsgruppenregeln für den Cache-Cluster und die NAT-Instanz.
  3. Überprüfen Sie die Regeln.
  4. Fügen Sie der NAT-Instanz eine iptables-Regel hinzu.
  5. Stellen Sie sicher, dass der vertrauenswürdige Client eine Verbindung zum Cluster herstellen kann.
  6. Speichern Sie die iptables-Konfiguration.

Eine detailliertere Beschreibung finden Sie in der aws-Anleitung:

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


Ich möchte keine NAT-Instanz, ich möchte sie für eine Minute überprüfen. Ricos Antwort ist genau das, was ich wollte.
Pysis

6

Nicht so alte Frage, ich bin selbst auf dasselbe Problem gestoßen und habe es gelöst:

Manchmal müssen Sie aus Entwicklungsgründen von außen darauf zugreifen (um Mehrfachbereitstellungen nur für eine einfache Fehlerbehebung zu vermeiden?).

Amazon hat einen neuen Leitfaden veröffentlicht, der den EC2 als Proxy für die Außenwelt verwendet:

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

Viel Glück!


3
Als Referenz ist der von Amazon erwähnte Ansatz eine NAT-Instanz.
Russellpierce

Zu Ihrer Information, aus den Dokumenten: "Dieser Ansatz sollte nur zu Test- und Entwicklungszwecken verwendet werden. Er wird nicht für die Verwendung in der Produktion empfohlen"
jasonjonesutah

1
Ja, das stimmt @jasonjonesutah Ich habe dies auch in meiner Antwort erwähnt. Eine sehr schlechte Idee für die Produktion, aber hervorragend für die Entwicklung.
Shay Elkayam

4

Wir verwenden HAProxy als reservierten Proxyserver.

Ihr System außerhalb von AWS ---> Internet -> HAProxy mit öffentlicher IP -> Amazon Redis (Elasticache)

Beachten Sie, dass es (zu diesem Zeitpunkt) einen weiteren guten Grund dafür gibt.

Da wir den node.js-Client verwenden, der kein Amazon DNS-Failover unterstützt, unterstützt der Client-Treiber keine DNS-Suche. Wenn die Redis fehlschlagen, bleibt der Client-Treiber mit dem alten Master verbunden, der nach einem Failover Slave ist.

Durch die Verwendung von HAProxy wurde dieses Problem gelöst.

Mit dem neuesten ioredis-Treiber wird das DNS-Failover von Amazon unterstützt.


1
Update für node.js, jetzt unterstützt ioredis DNS-Failover. Wenn Sie den DNS-Hostnamen verwenden, kann ein automatisches Failover ohne HAProxy durchgeführt werden.
Teddychan

4

Übrigens, wenn jemand eine Windows EC2-Lösung möchte, versuchen Sie diese an der DOS-Eingabeaufforderung (auf dem Windows EC2-Computer):

Hinzufügen der Portweiterleitung

C: \ Benutzer \ Administrator>netsh interface portproxy add v4tov4 listenport=6379 listenaddress=10.xxx.64.xxx connectport=6379 connectaddress=xxx.xxxxxx.ng.0001.use1.cache.amazonaws.com

Zum Auflisten von weitergeleiteten Ports

C: \ Benutzer \ Administrator>netsh interface portproxy show all

Hören Sie auf IPv4: Stellen Sie eine Verbindung zu IPv4 her:

Adressport Adressport


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

Portweiterleitung entfernen

C: \ Benutzer \ Administrator>netsh interface portproxy delete v4tov4 listenport=6379 listenaddress=10.xxx.128.xxx


3

Dies ist ein solides Knotenskript, das die ganze Drecksarbeit für Sie erledigt. Getestet und verifiziert, dass es funktioniert hat.

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

Verwendung: uzys-elasticache-tunnel [Optionen] [Befehl]

Befehle:

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

Optionen:

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

Anwendungsbeispiel

  • start - uzys-elasticache-tunnel start ./config.json
  • Stop - Uzys-Elasticache-Tunnel Stop
  • status - uzys-elasticache-tunnel status

1

Es ist nicht möglich, von einer VPC-Instanz aus direkt auf den Classic-Cluster zuzugreifen. Die Problemumgehung besteht darin, NAT auf der klassischen Instanz zu konfigurieren.

NAT benötigt einen einfachen TCP-Proxy

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

Sie haben die gleiche Antwort auch im unten genannten Beitrag gegeben, für die unterschiedliche Anforderungen gelten. Wie kann es in dem gegebenen Szenario auch funktionieren? stackoverflow.com/questions/38066908/…
abby37

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.