Support .NET Native Container Image build #2632
Comments
|
@weikanglim This seems also, in spirit, related to our Buildpack work. Wondering if you have thoughts here. Buildpacks currently require Docker on the user's machine. |
|
If Azure Container App service ends up supporting remote build in the future, the containerization could happen remotely which wouldn't require Otherwise, I could see how the native MSBuild/.NET solution for source-to-container ends up being a better experience for developers already familiar with MSBuild. The minimal support to enable this is a property we can set when invoking |
|
Note that starting in .NET 8 RC1 we will fully support pushing directly to ACR as part of the publish - so if you prefer you could sidestep any usage of Docker locally for .NET projects. The big blocker for us was supporting Docker OAuth Token Authentication (we only had username/password and non-Oauth token methods before). Happy to work with you all to enable any data points neccesary to make this happen! |
|
Using the following command |
When deploying to a host that requires a container image, if the `language` of a project was `dotnet` we required the use of Docker to both build and push the container image. If the user had not authored a Dockerfile, we would try to use Oryx to build the container image "from source". With .NET 8, the SDK itself now has good support for both building a container image for an app and pushing it to a remote registry. We leveraged this for our Aspire work but non Aspire dotnet projects couldn't leverage this. This change fixes the situation. If your language is `dotnet` and your host requires a container, we'll now use `dotnet publish /t:PublishContainer` to build and push the container image. This does mean that the typical "Build" and "Package" steps behave differently for these apps now. Since our "Publish" step now both builds and pushes the container image, we defer the the work we would have done in "Build" and "Package" into the "Publish" step. Doing this allows us to eschew the need for a local Docker daemon to be installed and running. The .NET tooling does support creating a `.tgz` which could later be `docker load`'ed, and you could imagine that "Build" or "Package" produces such a thing, but doesn't allow us to use this as the input to a publish, so for now we don't spend time producing this artifact which would be unused by the downstream publish step. Fixes Azure#2632
|
I had a draft of this in #3954 and will continue along with that, so I'm taking this one from you for now, @weikanglim. |
The `dotnet` tool has native support for producing (and pushing) a container image. This does not require a local docker daemon and in general "does the right thing" and is the prefered way for .NET customers to produce container images. https://learn.microsoft.com/dotnet/core/docker/publish-as-container gives a good overview of how this support works and we've been using it to build and push container images for Aspire apps. This change updates things such that we can use this support when building a non Aspire based .NET app. If a `Dockerfile` exists, we respect it, but otherwise instead of trying to use Oryx to produce a container image, we will use `dotnet publish`. A new recorded test was added - it builds on top of the existing `containerapp` sample, and the test aranges to remove the `Dockerfile` file from the template before running `up`. Fixes Azure#2632
The `dotnet` tool has native support for producing (and pushing) a container image. This does not require a local docker daemon and in general "does the right thing" and is the prefered way for .NET customers to produce container images. https://learn.microsoft.com/dotnet/core/docker/publish-as-container gives a good overview of how this support works and we've been using it to build and push container images for Aspire apps. This change updates things such that we can use this support when building a non Aspire based .NET app. If a `Dockerfile` exists, we respect it, but otherwise instead of trying to use Oryx to produce a container image, we will use `dotnet publish`. A new recorded test was added - it builds on top of the existing `containerapp` sample, and the test aranges to remove the `Dockerfile` file from the template before running `up`. Fixes Azure#2632
The `dotnet` tool has native support for producing (and pushing) a container image. This does not require a local docker daemon and in general "does the right thing" and is the prefered way for .NET customers to produce container images. https://learn.microsoft.com/dotnet/core/docker/publish-as-container gives a good overview of how this support works and we've been using it to build and push container images for Aspire apps. This change updates things such that we can use this support when building a non Aspire based .NET app. If a `Dockerfile` exists, we respect it, but otherwise instead of trying to use Oryx to produce a container image, we will use `dotnet publish`. In addition, we now use 8080 as the default port of a `dotnet` based application (with no Dockerfile) as that's the default port used by the standard ASP.NET base image. A new recorded test was added - it builds on top of the existing `containerapp` sample, and the test aranges to remove the `Dockerfile` file from the template before running `up`. Fixes Azure#2632 Fixes Azure#4583
The `dotnet` tool has native support for producing (and pushing) a container image. This does not require a local docker daemon and in general "does the right thing" and is the prefered way for .NET customers to produce container images. https://learn.microsoft.com/dotnet/core/docker/publish-as-container gives a good overview of how this support works and we've been using it to build and push container images for Aspire apps. This change updates things such that we can use this support when building a non Aspire based .NET app. If a `Dockerfile` exists, we respect it, but otherwise instead of trying to use Oryx to produce a container image, we will use `dotnet publish`. In addition, we now use 8080 as the default port of a `dotnet` based application (with no Dockerfile) as that's the default port used by the standard ASP.NET base image. A new recorded test was added - it builds on top of the existing `containerapp` sample, and the test aranges to remove the `Dockerfile` file from the template before running `up`. Fixes #2632 Fixes #4583
As of .NET 7, .NET developers can build their apps into containers natively. It would be great if, when using AZD in the absence of Docker, that an image could be built natively.
I'm not sure an ACR push could be implemented without Docker on the machine, but, if there's a way AZD could support .NET's native container features, it'd be great.
The text was updated successfully, but these errors were encountered: