-
|
I'm having a bit of trouble getting the cluster up and running. I'm not sure if this is due to my inexperience with Redis itself or something else, but I can't seem to find good answers to my specific issues anywhere, so I figured I'd ask here and see if the problem is perhaps some way that I'm misusing the image. I'm using IORedis to try to connect my node application to the Here's my TypeScript code that's trying to connect to the cluster: And here's the output that I'm getting from my application when it tries to connect to the cluster: A few things that look suspicious to me are the Lastly, in case it's useful, here's the output from the Any help would be much appreciated! |
Beta Was this translation helpful? Give feedback.
Answered by
tjosephs
Jun 23, 2021
Replies: 2 comments 2 replies
-
|
@tjosephs Hi and thank you for using the discussions sections for this. So first i do not know how IORedis works so i can't speak for that part. I do know exactly what the error really is but i can't say for sure what you need to do to solve it fully. So this problem is really a common problem when doing redis cluster nodes inside docker specially and i am sure that running docker on mac as docker on mac is not always the exact same and works perfect as you want, it will cause issues like this. So your error. In redis cluster there is basically two different IP:s that if they are not in sync and reachable, they will not work out properly. One IP is the IP that you use with your client lib, IORedis in this case, to do the first initial connection to any cluster node to let the client configure itself and to fetch where all other nodes are. In your case you set this to you 192.x.x.x address. This address must be reachable from where you execute your client code and port 7000-7005 must be open on that IP as well. The other side of this is what IP address that each redis node uses internally to talk between each node. This node discovery process is one step that is done in the Docker container entrypoints and since all nodes lives inside the same docker container, they can all talk over 127.0.0.1: instead of using some other IP like the container IP or a public machine IP, redis will use the simplest mechanism for this. So the issue here and with all clients is that after you have connected to a redis cluster and done your node discovery step, what you see in IORedis is that "all nodes is on 127.0.0.1" so the client will think that, "hey the node i want is on 127.0.0.1" and when you are using mac this is the main issue where when running docker it dont always udnerstand that 127.0.0.1 should look inside the docker container or to bind the ports to that outside the docker container. However what is supposed to happen is that when you specify IP=0.0.0.0 what should happen is that on the inside of the container it should default back to binding all the nodes to 0.0.0.0: instead of 127.0.0.1 or if it was the other way around that docker should bind it to 0.0.0.0 on your host machine, i dont really remember and i do not have a mac machine to test this out myself on really. So when this 127.0.0.1 address comes back to your client lib, the lib will bind each slot in the cluster to each IP the cluster says they live on. But if your client do not know how to route or get to the IP that redis says it should route to, then you get this issue and you get a failure in your client layer. So in short, this is what the issue is and why it keeps happening, i can't however help so much on mac as i can't debug it myself and i have to have help from the community to test these things out for me. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Thank you so much for the timely response!!! That makes total sense of the issue. I had pretty much been able to figure out the two addresses situation and that 127.0.0.1 was internal to the container, but what I didn't realize was that my client was trying to then turn around and talk to localhost again from its own perspective. This gives me some definite ideas to follow up on. I'll spend some more time with it and see where I can get and will then report back. |
Beta Was this translation helpful? Give feedback.
-
|
Figured it out. Final About as easy as it gets. Now we're up and running! Container and app seem to be working well! We're about to try it in AWS with ElastiCache. Once I know that's working I'll post back here as well just to close the loop all the way. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
And confirmed - the code we were running locally against your container worked perfectly once we got it in ElastiCache. Thanks for providing a great solution for local dev! |
Beta Was this translation helpful? Give feedback.
Answer selected by
Grokzen
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Figured it out.
IP=0.0.0.0was doing the exact opposite of what we were wanting it to. It was causing the nodes inside the container to bind tolocalhost. That led to the problems you described above. As soon as I removed that line, the nodes bound to the external IP address on the container and I was able to address them from my application container.Final
docker-compose.ymllooked like this:About as easy as it gets.
Now we're up and running! Container and app seem to be working well! We're about to try it in AWS with ElastiCache. Once I know that's working I'll post b…