Defaults today expose 80/443

[timheuer]

The default docker experience today exposes 80/443

EXPOSE 80
EXPOSE 443

Should we also make those the defaults in this experience?

[baronfel]

The base dotnet/aspnet container sets ASPNETCORE_URLS to bind on TCP port 80, and we do plan to auto-expose that port for ASP.NET core projects (and we can reliably detect that). The actual port mappings haven't been implemented yet, but it's on the radar for rc1.

[baronfel]

@richlander has a proposal to make .NET containers 'rootless' by default, which would involve different ports, so we should be able to react to that as well.

[baronfel]

Linking to the implementation issue: #93

[richlander]

The key piece is making the images non-root capable. There are two main aspects of that:

• Include a non-root user
• Don't listen in a port lower than 1024.

Related: dotnet/dotnet-docker#3968

[baronfel]

The port part is easy enough to do, and setting the container metadata for user/group is also straightforward (if for some reason that hasn't already been done in whatever base image the user chooses or has inferred for them). The gap with these SDK-generated containers will be actually creating the user and group on the running image - since we can't perform RUN commands we either

• push that creation step into another container entirely (i.e. have the user create and maintain a base image),
• or we start having to do really fun stuff like identify a cached/stored layer by digest somewhere and splice it in manually into the list of layers applied to this image. This is how images might be composed in an abstract way anyway, and also how the team at Google that initially made Jib demoed seamlessly including debug assets into their generated containers.

[richlander]

I think of EXPOSE as an advanced feature. Also, we need to ensure it matches ASPNETCORE_URLS. Is there a reason to provide support for EXPOSE in v1? None of our dotnet/dotnet-docker samples use it and we've never been asked for it.

[baronfel]

I don't think expose is necessarily advanced - it's the only way for an image to programmatically declare its dependencies. It's something that we should do in order to build correct containers, which was one of the selling points for this feature set overall.

It's also technically very easy to do - we're currently doing the parity-check you mention with ASPNETCORE_URLS @richlander in the targets - #113 just flows that already-computed data into the container config itself.

[timheuer]

I think of EXPOSE as an advanced feature. Also, we need to ensure it matches ASPNETCORE_URLS. Is there a reason to provide support for EXPOSE in v1? None of our dotnet/dotnet-docker samples use it and we've never been asked for it.

Our samples don’t but the default container tools experience in VS do use expose as an FYI

[richlander]

it's the only way for an image to programmatically declare its dependencies

Agreed. Do you know of any service that honors EXPOSE? I never checked, but I assume k8s doesn't not use this info, and you are responsible to map ports manually.

[baronfel]

If you use -P in docker run it will auto-assign ports on the host to the EXPOSEd ports on the container. These can then be queried with docker port <container name> [<private port number>] to drive other automation.

I can't find any matching mechanism (even in docker-compose) for performing this operation, though.

[richlander]

Got it. I've never done that. That's more a dev scenario than a prod one. You an only do it once (concurrently) on a given machine. As a result, using it within docker-compose might be a bad idea.

I expect people use EXPOSE today because they see others also doing so, not that they use the metadata or observe others using the metadata.

Anyway, it's fine if you add support for this (as long as it agrees with ASPNETCORE_URLS).

[baronfel]

We removed port customization in favor of delegating that to the base image. The dotnet base images already handle setting ASPNETCORE_URLS to correct values, we don't need to reimplement that here.