ValKey won't give up port 6379/tcp in a Docker Compose deployment #920
-
Hello ValKey Community! We are currently using Redis as the cache service in our system (Tazama.org). Our system is a distributed platform and we are trying to introduce ValKey into the ecosystem on a trial basis alongside Redis until we are able to fully replace Redis end-to-end. In the short-term, we need to be able to run Redis and ValKey side-by-side. We currently have Redis running on the default ports (6379) and we are attempting to deploy ValKey to port 6380. Our test deployment of ValKey is into our Docker stack that we deploy via Docker Compose. I've tried a number of different deployment settings and I am unable to deploy ValKey without the container claiming and exposing 6379/tcp, as well as the explicit ports I specify. I am sure I am missing a vital setting somewhere, but I've read the docs and have not found a solution yet. Some background: From our valkey:
container_name: valkey
hostname: valkey
image: valkey/valkey:7.2.5
volumes:
- ./conf/valkey.conf:/etc/valkey/valkey.conf
- ./data:/data
command: valkey-server /etc/valkey/valkey.conf
healthcheck:
test: ["CMD-SHELL", "valkey-cli ping | grep PONG"]
interval: 1s
timeout: 3s
retries: 5
ports:
- 16380:6380 The contents of the port 6380 When the container is deployed, the "NetworkSettings": {
"Bridge": "",
"SandboxID": "stuff",
"SandboxKey": "/var/run/docker/netns/otherstuff",
"Ports": {
"6379/tcp": null,
"6380/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "16380"
}
]
}, What am I missing here? The 6379 port here seems to conflict with the port that Redis is using and it seems that our other services are now confused and unable to find the Redis server. Not only that, but the ValKey container is declaring itself unhealthy because: "Health": {
"Status": "unhealthy",
"FailingStreak": 23,
"Log": [
{
"Start": "2024-08-19T10:03:54.905361138Z",
"End": "2024-08-19T10:03:54.926224423Z",
"ExitCode": 1,
"Output": "Could not connect to Valkey at 127.0.0.1:6379: Connection refused\n"
}, Can anyone maybe give me some idea of what we might be missing here? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
Update: If I update the health check to explicitly request port 6380, then the health-check works: valkey:
container_name: valkey
hostname: valkey
image: valkey/valkey:7.2.5
volumes:
- ./conf/valkey.conf:/etc/valkey/valkey.conf
- ./data:/data
command: valkey-server /etc/valkey/valkey.conf
healthcheck:
test: ["CMD-SHELL", "valkey-cli -p 6380 ping | grep PONG"]
interval: 1s
timeout: 3s
retries: 5
ports:
- 16380:6380 "Health": {
"Status": "healthy",
"FailingStreak": 0,
"Log": [
{
"Start": "2024-08-19T10:46:30.230023571Z",
"End": "2024-08-19T10:46:30.251193299Z",
"ExitCode": 0,
"Output": "PONG\n"
}, It's still not clear why port 6379 is exposed, or why ValKey thinks the "default" port is 6379 and not the 6380 we specified. |
Beta Was this translation helpful? Give feedback.
-
Another update - Redis does the same thing. If I remap Redis ports to 6381, it also still exposes 6379. |
Beta Was this translation helpful? Give feedback.
-
I think I know why it is like that
This maps port 6380 on the host to port 6379 inside the container for valkey service and maps port 6390 on the host to port 6379 inside the container for valkey2 So from the host point of view from the host we can access both the services using any clients using the respective ports 6380, 6390
So in the case mentioned above you can map redis and valkey on different ports and access them on these ports on the host. Let me know if this helps. |
Beta Was this translation helpful? Give feedback.
I think I know why it is like that
Here: https://github.com/valkey-io/valkey-container/blob/mainline/7.2/alpine/Dockerfile#L112
Here we expose the port 6379 as valkey runs by default on this one.
This is the inside view of the container hosting valkey on 6379 and you can bind it to some other port on the host something like