Test port 80 rather than just try to use it: Graceful sharing and management

[rfay]

What happened (or feature request):

People will have processes on their machine that use port 80. We need to handle that situation by

• Testing the port
• Optionally figuring out the process that is using the port
• Gracefully explaining the situation to the user (and not trying to bind to the port)
• Optionally offer to use a different port (edit: Spun off to Allow webserving on an alternate port instead of port 80/443 #481 )

Edit: Note that 3306 was originally mentioned here, but we no longer expose 3306 directly, and docker should be choosing an unused port???

Original OP continues:

I noticed in the ddev describe PR #116 that mysql is expected to be exposed on the local machine as port 3306. I don't think it currently is, but when we expose it, it will just be no end of support complaints if it is exposed on 3306, as many people like me are running mysql locally for a variety of reasons.

Update: As long as ddev properly detects collisions and gives simple instructions to the user, that approach of detect-warn-assist is fine.

It's worth considering exposing http on a port other than 80 as well, although this is more problematic since browsers absolutely love port 80.

What you expected to happen:

I expect ddev sites to respect existing listeners when exposing ports.

How to reproduce it (as minimally and precisely as possible):

Create a ddev site and see where the mysql port is exposed. ddev describe will tell this in the future. Alternately, run the mysql client with mysql -h127.0.0.1 -uroot and see which mysql server you get.

Anything else do we need to know:

Related source links or issues (like source JIRA issue):

[beeradb]

I don't think there's anything inherently wrong w/ defaulting to 80/3306, we just need to make sure there's an easy way to change the default if there's a port conflict. It's also worth deciding if the value gained by using those default ports is worth the inevitable support requests.

[rfay]

I can buy that: If the detection and feedback given to the user are adequate, all is good.

[rickmanelius]

To weigh in on this, Brad and I surfaced this in the conversation re:custom containers #121. As noted, we will need to warn if there is collisions and provide a manner of configuring around.

[rfay]

I edited the OP and updated the title.

[rickmanelius]

Looks like this could be a quick win and allow ddev to play nicer in the larger ecosystem.

[rickmanelius]

Assigned to @nmccrory. Please post a suggested plan of attack and I'd love for @rfay to provide feedback during that process as well as the resulting PR given that he's done a great job defining the issue and desired result.

[rfay]

The key issue that needs to be sorted here is whether we're going to provide configuration for an alternate port. IMO we should start by just testing and explaining, rather than trying to solve the alternate port problem.

Spun off the config-for-alternate-ports problem into #481

[rfay]

Strategy for this:

• Before docker-compose up, probe port 80 and 443 on local machine.
• If connection is established, fail with explanation of what is happening.
• Add documentation on how to find out what is occupying a port on mac/linux/maybe-windows
• Suggest some common turn-off-webserver techniques

[rfay]

After reading some of the comments in https://www.reddit.com/r/golang/comments/34efmu/checking_tcp_port_in_go/ (testing for a listener is not enough) it's worth thinking a little further. The problem is we don't want to use root (which you'd need to do to directly bind to those). However, docker has supercow privs and can bind to those. So we might want to issue a docker run (with port binding on 80/443) on a trivial docker container and harvest the results of those to determine whether we'll be able to get 80/443.

docker run -it -p80:80 -p443:443 busybox:1.27.2