Stable port number for accessing mysql and http on localhost

[tmotyl]

Is your feature request related to a problem? Please describe.
I'm using mysqlworkbench to connect to ddev database using external port (found using ddev describe). The problem is that every time ddev is restarted the port changes, which means I need to reconfigure mysqlworkbench. This is very annoying.

Describe the solution you'd like
The mysql port should not change after restarting ddev.

[rfay]

I don't know of a way to accomplish this, since the localhost port binding is managed on ephemeral ports by docker. Of course http-based services (like phpmyadmin) use ddev-router for access, so they stay in a defined http-space.

[tmotyl]

can the port binding be generated once on ddev config and then saved in config.yaml?

[rfay]

Maybe. Seems like this wouldn't work at all for teams that check in their config.yaml. Every machine would have various kinds of conflicts based on what projects they were running.

[tmotyl]

In case of conflict I'm ok if the port is adapted.

[rickmanelius]

FWIW, there was a related request by @mglaman but solving this in a different way. See #691. Basically, rather than pinning the port numbers (and this will become problematic if users are working across multiple teams and they start to conflict), surface a way to expose the port number by exporting a file OR exposing it via ddev describe -j. Of course this might not help the use case of this issue because I don't think mysqlworkbench could pull this information.

[rfay]

in #691 I asked if this current output (published_port) from ddev describe -j is adequate to solve this problem:

    "raw": {
        "approot": "/Users/rfay/workspace/d7git",
        "dbinfo": {
            "dbname": "db",
            "host": "db",
            "password": "db",
            "port": "3306",
            "published_port": "32848",
            "username": "db"
        },

[tmotyl]

an alternative solution which would work for mysql workbench, would be to allow ddev to expose ssh serwer, then mysql workbench could connect through ssh tunnel.
But then again we have an issue with ports.

Or maybe we could have a similar proxy/router we have for http traffic, so stuff like:
mysql -h myprojectname.ddev.local -p
would work from the host machine?
I mean, the mysql proxy would be exposed always on some port like 3366 and then route the traffic to the correct container based on the domain?

[rfay]

Yeah, there's no ssh tunneling with ddev ssh, because it's actually docker exec which isn't actually related to ssh.

There's no way to redirect mysql traffic like we do with ddev-router, because there's no Host header or equivalent.

That doesn't mean we can't find some way that this will work out for you!

[indytechcook]

FWIW, lando allows this sort of configuration in the .lando.yml. I'm not sure it helps but perhaps we can see how they handle this flexibility. Sorry if it doesn't help.

services:
  database:
    portforward: 32780

[rickmanelius]

So allowing the ability to specify the port in a yaml file is certainly a consideration... but in thinking through the use case of many projects shared over many people, it could become more management to lock in all the ports.

[mfrieling]

rather than pinning the port numbers (and this will become problematic if users are working across multiple teams and they start to conflict)

Maybe you can add a syntax element to keep it dynamic, e. g.
published_port: auto
This way users or teams who need a fixed port for external tools can pin the port and those for whom it will be problematic can still use dynamic port assignment like now. Dynamic port assignment should be the default config then.

[outdoorsman]

Not sure I have any more answers but am seconding the desire to be able to set up a mysql workbench connection and not have to keep revisiting it with new port numbers.

[rfay]

Just an FYI that for macOS users ddev sequelpro is a beloved command.

[rfay]

I guess it would be super easy to add support for other database browsers in the exact same way as ddev sequelpro. That's a different way forward on this.

[rfay]

Just a note that ddev describe -j | jq -r .raw.dbinfo.published_port gets the port quite nicely.

[rfay]

This could be a part of a solution to generic access to multiple SQL guis; datagrip was suggested in #1397. There may be other ways to do it than using a stable port number, but it would be great however.

[rfay]

Added a note that we should do http when we do this, so the localhost URL is static.

[indytechcook]

@rfay that's my use case, I'm using datagrip and keep having to change the port in the config.

[kaystrobach]

the biggest problem is, that most tools have their own import / export format for that data ...

[unherz]

As a workaround you can write a bash script which executes the command ddev describe -j | jq -r .raw.dbinfo.published_port (thats what @rfay mentioned and it works great thx) and save the output as variable. So you can call it on your console without caring about the specific published port.

Also per docker ps you can view all the published and formarded ports.

But in the future it would be great to manually configure it

[tmotyl]

What about approach like:

1. allow to configure port in yaml file (by default you dont have to do it, but you can)
2. when running ddev start, ddev checks if the port is already taken and:

• if its free, then it binds to the configured port
• if it's taken, then it warns the user and bind to the random port number

3. ddev remembers the last port number which was used (inportant in case it was a random number) and on the next start tries to use the same port as before. So it changes the port only when there is a conflict.

[unherz]

Recently a co-worker mentioned that you actually CAN set a stable port number:
Just create a config file: docker-compose.environment.yaml (obviously you can change the name) and add your config under services - db - ports.
As example:

services:
  db:
    ports:
      - 32780:3306

In this example 32780 will be the forced stable port.
Actually I dont know in which version this feature came up.

Please correct me if im wrong!

So this issue can be closed

[rfay]

Thanks for the workaround @unherz ! So amazing what can be done with a little docker-compose magic. I'd like to keep this open because for both localhost webserver binding and db binding it would be so useful for it to be static.

[rfay]

There's a PR with artifacts to test on #1502 (comment) and I'd love to have some feedback on it.