Users can easily containerize their applications in a CI pipeline

[baronfel]

Users should be able to take a standard .NET application and seamlessly containerize it, publishing directly from the .NET CLI. The entire experience should be as easy as

> dotnet new web -n my-awesome-app
# Publish the my-awesome-app:1.2.3 image containing the runtime assets of the application to a local Docker daemon.
# Because this is a web application on .NET 7, the mcr.microsoft.com/dotnet/aspnet:7.0 image was used as the base.
# The ASPNETCORE_URLS variable was set to http://localhost:5000, and the image shows a port exposure of 5000.
> dotnet publish --profile container -p:Version="1.2.3"

Users should be able to rely on sane defaults for the containers generated from this mechanism, but also be able to 'eject' at any time and take over those defaults.

Users should be able to customize key container properties, including but not limited to:

• base image and tags (optionally specifying digests directly for reproducibility)
• environment variables
• container labels
• exposed ports
• entrypoint/starting command definitions
• the resulting image name, version, and tag(s)
• the destination registry for the image
• container group and user names
• working directory
• and more!

There should be smart defaults for common scenarios - for example, ASP.NET Core applications should specify the default listen urls via the ASPNETCORE_URLS environment variable based on the default values, and the matching ports should be exposed by default. Similarly, we should use bare OS containers with publishing with --self-contained set. More conventions along this line of thinking may be possible.

Users should be able to create and push the generated images for any container registry, which generally fall into two camps: local Docker daemon registries and remote, authenticated-access-required registries like Azure Container Registry, AWS Container Registry, Docker Hub, and many others.

The mechanism that we will use to implement this is a Publish Profile. While classically an ASP.NET-focused concept, the mechanism is general enough for us to use here. A Publish Profile is a named fragment of MSBuild logic (typically just Properties) that identifies a WebPublishMethod and other Properties that are only relevant to that publish mechanism. They are a pluggable mechanism, but most user interaction is via the PublishProfile MSBuild property, which takes a file name (for example PushToACR), extrapolates that to a file at <Project Root>/Properties/PublishProfiles/<Profile Name>.pubxml, and Imports that file. A later mechanism uses the value of the WebPublishMethod property to dynamically load targets bundled in the SDK for the given Publish Method.

As a part of this effort, we will

• Define a new WebPublishMethod called Container
• Define a default PublishProfile in the SDK for containerization that sets this property, as well as any other defaults we decide on
• Provide targets for the Container publish method in the SDK that provide an 'interface' for this project to plug into. If you look at the pre-existing Docker targets, they define a few targets that are expected to be present. If we do the same then we can 'just' supply a tasks/targets package from this repository for iteration purposes, before needing to fully integrate into the SDK
• Implement these targets here. I think we will need two targets:
  • One target (something like "ComputeContainerImageProperties") that represents the point at which all of the container-relevant metadata has been inferred. This is an external integration point for IDE tools that want to do Container-y things. We should sync with the VS Web Tools and Container Tools teams to make sure this is usable for their needs. This should be design-time friendly.
  • One target (something like "CreateAndPublishContainerImage") that uses the metadata from the previous target to generate and publish the container image to the desired registry.

[baronfel]

dotnet/sdk#26161 covers the mechanism of invoking the publish profile from the SDK perspective. It's a nice-to-have, but it is far nicer than the current experience (supplying an MSBuild property directly).

[baronfel]

We've now implemented this as a basic level. There are properties we need to add, we need to support windows containers, and we need to support non-web projects, but those will be tracked in subsequent issues.