Avoid defaulting to port 5000

[philliphoff]

macOS Monterey (12.1) includes support for AirPlay, enabling the machine to act as a display for other Apple devices, which is enabled by default. AirPlay happens to use port 5000 (among others). This means that applications using 5000 may run into "port already in use" errors that are difficult to diagnose, as use of this port by the system is not widely known. This will impact Mac users running either .NET and Python (Flask) applications which traditionally used port 5000, and will become more prevalent as Monterey proliferates.

Prior to .NET 6, ASP.NET applications were scaffolded to use port 5000 by default. In accordance with that convention, the Docker tooling prompts users to use port 5000 when scaffolding Docker support. In addition, the tooling will attempt to map the same ports exposed by an image when running an image (e.g. so an image exposing port 5000 will be run attempting to map the port to the local 5000 port). With .NET 6, however, ASP.NET applications are scaffolded to use a randomly chosen port (i.e. the port is chosen at scaffold-time and then used thereafter). (Note that, absent an explicitly-defined port, ASP.NET applications will ultimately fall back to port 5000.)

The Docker tooling should consider avoiding defaulting to 5000. In the case of .NET applications, the tooling could attempt to sniff the Kestrel launch profile in the Properties/launchSettings.json file, extracting the applicationUrl property, which will contain the port chosen at scaffold time. (This should also generally work for pre-.NET6 applications.) Alternatively, the tooling could default to its own random port (since it's fairly arbitrary) excluding 5000. Alternatively, the tooling could just avoid mapping ports to the local 5000 port (e.g. when running a container), or do so only when it detects 5000 already in use. Or, perhaps simply generate a warning/error if on Mac and 5000 is already in use (presumably by the AirPlay service).

[bwateratmsft]

sigh leave it to Apple...

[bwateratmsft]

According to @karolz-ms so is 3000. Woo!

[philliphoff]

I've seen that AirPlay also uses 7000, but not anything about 3000. (I've not encountered any issues with 3000 on either Intel or M1 Mac, whereas I definitely ran into the 5000 issue, which took a while to figure out.)

[karolz-ms]

I hit port 3000 being occupied on an Intel Mac. Unfortunately I do not remember anymore what exactly was hanging onto it; all I remember it was a system component, so I put my app on a different port. After machine restart the port was freed 🤷

[bwateratmsft]

In theory any port can be used at any time, which is why we let Docker select the port at least for debugging. Perhaps we make a setting that will flip between launching containers directly with the same host port as container port, vs. letting Docker pick?

[karolz-ms]

Having the app using different port each time it is launched is cumbersome. I think ASP.NET struck a good balance with their latest release (by using random port at scaffold time).

[philliphoff]

So that would be the "sniff the Kestrel launch profile application URL" option and use that as the default? (This is the option we went with in vscode-dapr, BTW.)

[bwateratmsft]

That seems reasonable enough to me. I really do not want to get into port scanning or anything like that. We could do the looking into launch settings as a best-effort sort of thing, and if anything goes sideways we just stick with some fixed default (maybe 5000 or maybe not).

[bwateratmsft]

This is now released in Docker extension version 1.20.0.