Allow disabling ddev-router port bindings

[Cyborg572]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe

I have multiple services running on my computer, and my own reverse proxy already running on port 80 and 443.

I can tell the reverse proxy to route *.ddev.site to the ddev-router container, but I can't get the router to start because 80 and 443 are already in use.

Attempting to get the ddev-router to not bind on port 80 and 443 also re-configures the internal routing, and changes the reported URLs of the projects, so none of the links produced by the CLI work correctly.

Describe the solution you'd like

I'd like to be able to disable ddev-router's port bindings, without disabling all the routing logic. Something like bind_no_interfaces instead of bind_all_interfaces.

Alternatively, I'd like a way to say "This is the URL to display for this project, regardless of what the rest of the config would imply"

I'm trying to get to the point where the output from ddev is something like:

Successfully started my-project
Project can be reached at https://my-project.ddev.site

and variables like DDEV_PRIMARY_URL and DDEV_HOST_HTTPS_PORT to match that, without binding ddev-runner to any ports on the docker host.

Describe alternatives you've considered

I've tried disabling the ddev-router container with omit_containers, but this disables the routing entirely, and sets the url for the project to be something like https://localhost:9372. I tried setting additional_fqdns, but this seems to have no effect with the router disabled.

I've tried changing the router_http_port and router_https_port settings on the project, but this seems to stop the project's web container from listening on port 80/443, and adds the new port to the url (https://my-project.ddev.site:8080), which doesn't work, since the reverse proxy is routing the domain based on 80 and 443 working.

I've tried the .router-compose.yml overrides suggested in #1941 (comment), but that only adds additional ports/ips, and does not prevent the existing port 80/443 binding from happening.

Additional context

No response

[rfay]

And of course you used the first line of approach I hope, ddev config --router-http-port=8080 --router-https-port=8443 right? As in the troubleshooting instructions, https://ddev.readthedocs.io/en/latest/users/troubleshooting/#webserver-ports-are-already-occupied-by-another-webserver ?

[Cyborg572]

Thanks for following up so quickly.

I did try that (via config.yaml, those flags don't seem to exist for the config command - the guide you linked sets them in the file as well). While it did stop the router from binding to port 80 and 443 on the host, it also changed which ports were exposed by the router container, and added the ports to DDEV_PRIMARY_URL and the url reported from ddev start.

I'm not trying to work around a port conflict, that's easy enough to do, and there's plenty of options for it. I'm finding ddev to be very flexible. It's getting me to about 90% of where I want to be.

I guess at the core of the issue, what I really need to be able to do is tell ddev that it doesn't have the full picture of my network setup, and that it needs to trust the URLs I'm providing as being correct.

If I could comment out the ports section of ~/.ddev/.router-compose.yaml and have that persist, without changing anything else, then I would have exactly what I'm looking for. The way docker compose does yaml overrides doesn't allow for that, so was hoping it would be possible to add an option to just not write the ports there in first place.

[rfay]

If you want to fiddle with router-compose stuff you do it with a router-compose.*.yaml, not by editing the .router-compose.yaml. .router-compose.yaml gets overwritten on every start.

I guess I still don't understand what you're trying to do or why.

If I typoed the config command, you'll easily find the correct things to change in .ddev/config.yaml and you can experiment with them.

Maybe you can start over saying what it is you really want to accomplish. Maybe if we talk about what you want to accomplish we can get farther.

[Cyborg572]

I was fiddling with router-compose.*.yml files, but they only allowing adding to the port bindings, not removing them.

I mentioned removing the lines from .router-compose.yaml as an example of what I'm trying to accomplish. Which is to have ddev do exactly what it's doing right now, but without actually binding to any ports on the host.

These are my goals, in priority order:

1. within the containers, DDEV_PRIMARY_URL is https://my-project.ddev.site, and the other related variables also indicate that the site is running at that url, on port 80 and 443
2. the ddev-router container does not try to bind to port 80 or port 443 on the host.

• ideally, it does not bind to any host ports
• less ideally, it binds to alternative ports, without compromising the first goal
• even less ideally, but still workable, ddev-router doesn't run at all, without compromising the first goal

3. when I run ddev start it reports Project can be reached at https://my-project.ddev.site (note the lack of port numbers)

I can guarantee that traffic to *.ddev.site:80 and *.ddev.site:443 will be routed to the ddev-router (or the individual web containers, if I have to), I'm just trying to get ddev to report the correct URLs to everything running in the containers.

[rfay]

What I'm asking is what you're trying to accomplish, not how you're trying to accomplish it. Could you please say what it is you want to accomplish?

[Cyborg572]

My development machine has an existing docker-based reverse proxy running on ports 80 and 443 to give me access to things like portainer, phpmyadmin, n8n, and some other web-based tools that I would really like to keep running at all times.

I would like to also run ddev on this machine, without having to constantly add/remove port numbers when running commands, referencing documentation, or collaborating with others.

I would also like to have my existing reverse proxy be the only container binding ports on the host, but that's less important to me.

[rfay]

So it sounds like you just want ddev to have global configuration to change the ports it uses? As in

• Add global router_http(s)_port setting (can be overridden by project) #3240
  Which is slated for the next major release?

I'm sure you know that there are portainer add-ons for ddev, and that phpmyadmin is built in.

[Cyborg572]

I don't think that would solve my issue, unless it works entirely differently than the per-project setting does.

As I understand it, setting router_https_port to 8443 (globally, or at the project level) would do the following:

• bind dev-router to 8443 on the host: I'd rather not have anything bound to the host, but I can work around that.
• Make the dev-router container expose port 8443 instead of 443: Again, not ideal, but I can configure the other proxy to expect that
• set DDEV_PRIMARY_URL to https://my-project.ddev.site:8443 inside the web container: This is the problem, since the correct URL should still actually be https://my-project.ddev.site, due to the additional routing layer ddev does not control.

I'm sure I could probably reconfigure my entire machine to run everything through ddev, but I think I'd be running into other limitations pretty quickly.

I can work with ddev as-is, via workarounds and mentally adding/removing ports when I go between systems, and passing explicit URL arguments when needed. I just though disabling the port binding entirely, while maintaining the internal routing, would be a nice quality-of-life feature for running on existing docker setups.

[rfay]

I have to confess that I'm not too enthusiastic about adding features to DDEV to support one developer's workflow and how they have their machine set up.

It seems like you're saying you want to use your own reverse proxy for everything... and you want DDEV to know about that and work in that context.

DDEV's current ddev-router is a descendant of the same nginx-proxy you're using, I believe. But probably in the next major version it will be replaced by the more capable traefik.

• Replace ddev-router with Traefik Proxy #3458

[rfay]

I'm going to close this for now, but I'm happy to continue the conversation here or elsewhere. I suspect that when traefik becomes the router, you may want to use it instead of your existing router, and with its exceptional configuration techniques it could probably handle everything you do. However, that would also impact your current workflow.

[TwoD]

EDIT: After fiddling with some environment variable overrides I got the URIs to be the same inside and outside ddev, but now it looks like my main issue is that while inside the web container, foo.ddev.site still resolves to the router, and it doesn't know what to do about port 80 anymore.

It feels like this should be a really common issue when using a reverse proxy, and I find the default behavior very counter intuitive. I guess I'll have to resort to not using the proxy and stop everything else on port 80 or 443 the few times I need ddev.

---

I found this looking for a solution to the exact same issue, which essentially is that router_http_port and router_https_port not only change which ports traefik binds to, but also what the actual web container binds to.

The first part is great when you have a reverse proxy in front of ddev and other things that need to be on 80 or 443, but it's useless if the internal container ports are also changed because the apps think they are accessible on ports the router ignores.

Meaning; I can no longer run any of my tests using the external domain foo.ddev.site (without explicit ports) inside the containers because they are no longer accessible over port 80 (or 443).
I can't change the tests or app to explicitly use a different port because that would break the tests (and the app itself) for everyone else not using a reverse proxy.

Why would ddev ever need to change the container ports when all we need to do is change traefik's ports to avoid any conflicts or use a reverse proxy?

[rfay]

I don't seem to understand what you're asking for @TwoD . Inside the ddev-webserver only port 80 is used, and it's never changed. Inside the dbserver on mysql/mariadb only port 3306 is used and it's never changed.

foo.ddev.site will always resolved to 127.0.0.1, because it's being looked up in DNS on the internet, and a wildcard of *.ddev.site resolves to 127.0.0.1 (the ipv4 version of localhost).

If you need help, please come over to Discord to chat, https://discord.gg/hCZFfAMc5k, or consider opening a new issue with a clear explanation of your quest.

[TwoD]

@rfay , sorry, I see it got a bit unclear. Probably because I rewrote that halfway through and mixed up where I was and what I was talking about. I could have sworn the webserver port changed as well but looks like it doesn't.

foo.ddev.site does not resolve to 127.0.0.1 inside the container, it resolves to one of the container's interface ips (ex 192.168.144.11 ) - assuming foo is the actual name of the app. You are however correct that *.ddev.site resolves to 127.0.0.1 if I try any other subdomain than foo.
curl http://foo.ddev.site no longer works inside the container, curl http://foo.ddev.site:[router_port] does. After reading your comment I rechecked curl http://127.0.0.1:80 and that works, so you are correct the webserver listen port does not change.

There are no /etc/hosts entries for foo.ddev.site inside or outside the containers, and /etc/resolv.conf looks like this:

search [our_company_domain.se]
nameserver 127.0.0.11
options ndots:0

The hosts line in /etc/nsswitch.conf inside the container has hosts: files dns.
Outside the container foo.ddev.net does resolve to 127.0.0.1.

The next issue then becomes that the app in the container sees foo.ddev.site:[router_port] as its "public" name, when I've set a router port. That must stay as foo.ddev.site:80, which should resolve to 127.0.0.1, so that any links it generates back to itself stay correct regardless if they are uapsed inside or outside the container, but now they only work from the outside due to the aforementioned resolver issue.

I'll see if I can hop on the Discord later today or tomorrow if that doesn't clear things up.

[rfay]

Happy to talk with you in Discord. You're in the meat of things now! foo.ddev.site in a web container that is NOT in a project named foo does in fact resolve to the default 127.0.0.1. However, to help people out with curling by full URL, <projectname>.ddev.site does resolve to the router address inside the web container. That allows curl https://projectname.ddev.site to work correctly and naturally inside the web container and with a trusted TLS cert. It's 2 hops, but it's useful for many applications.