How to gracefully expose service ports on the host?

[faytecCD]

When reviewing the documentation, I learned about the host_db_port configuration. If it’s not set, Ddev will randomly assign a host port when the project starts. If it is set, the port becomes fixed. This is convenient.

For example, after installing the Redis add-on using:

ddev add-on get ddev/ddev-redis

the service is not exposed to the host by default, so it cannot be accessed directly from the host machine. To expose it, I created an additional compose file:

docker-compose.redis_extra.yaml:

services:
  redis:
    ports:
      - "${REDIS_HOST_PORT:-6379}:6379"

If I then create .ddev/.env.redis-build and set REDIS_HOST_PORT, the port will be mapped to the host:

.env
.env.*
!.env.example

If I don’t set the variable, it defaults to 6379, which causes conflicts when running multiple instances locally. The only workaround is to create a .env.redis-build file for each project and assign different ports.

I’m wondering whether there is a mechanism similar to host_db_port:
• when the variable is not set, generate a random host port
• when the variable is set, use the user-defined port

One idea is to create a pre-start hook that runs on the host and manages .ddev/.env.redis-build:

1. If the file exists and contains a marker comment (e.g., #user-generated), generate a random port and write it.
2. If the file does not exist, create it and generate a random port.
3. If the file exists without the marker but the port is missing, generate one.
4. Only skip generation when the user has explicitly set a port.

This works, but feels clumsy. Is there a better approach?

A simpler option would be to create a docker-compose.redis_local.yaml, ignore it in git, and define a port mapping there. Since services do not expose ports by default, running multiple projects is not a problem. The file is only created when needed, and each project can choose whether or not to expose Redis.

This approach is also viable, but I’d like to know if there’s a more elegant built-in solution.

[rfay]

ports is not a great thing for use with multiple projects, as you already understand.

Why do you need to bind the port to the host? Are you using redis from something on the host? If something inside the DDEV/Docker network is using redis, there's no need to bind it to the host.

(host_db_port just basically does what you've done with your composer snippet, and has the same collision problem.)

[faytecCD]

Because sometimes I may install tools on the host to access services running inside containers. For example, JetBrains DataGrip can connect to Redis and MySQL, allowing me to manage all data within a single application.

Of course, I know that ddev provides the ddev/ddev-redis-insight add-on, which lets you manage Redis data through a web interface.

Another example: I can install Kibana on the host to access the Elasticsearch service. (In this case, I know that HTTP services can be exposed through HTTP_EXPOSE, and it appears to be managed by Traefik, so there shouldn’t be any conflict.)

[faytecCD]

Additionally, I’m now starting to try the second approach because I think it’s simple enough.

[rfay]

For Kibana, you might be interested in https://github.com/JanoPL/ddev-kibana, although it doesn't seem very active. HTTP_EXPOSE only works for things that use http protocol, which I don't think includes redis. There's some interesting experimentation with non-http services in #7549 though.

[stasadev]

I’m wondering whether there is a mechanism similar to host_db_port:
• when the variable is not set, generate a random host port
• when the variable is set, use the user-defined port

Yes, it's simple:

services:
  redis:
    ports:
      - "${REDIS_HOST_PORT:-}:6379"

[faytecCD]

@stasadev Cool, see feature.

Thanks.