-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dotnet: Support dotnet publish
to produce container image
#4573
Conversation
cli/azd/test/functional/testdata/samples/containerapp/src/dotnet/Dockerfile
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good - just a couple questions to consider before merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love it! It makes the dockerfile-less builds experience for dotnet developers much better than the current status quo.
Just left a suggestion on if we wanted to update the default ports for generated infra-assets based on this change.
Good call out - I really hadn't considered the end-to-end flow for a non-aspire based .NET app via our easy-init stuff. I'll make the relevant changes and then play around with the |
e3823a3
to
15ced5d
Compare
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
15ced5d
to
b7366f0
Compare
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
WindowsPowerShell install
MSI install
Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
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 containerimages. 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 usedotnet publish
.A new recorded test was added - it builds on top of the existing
containerapp
sample, and the test aranges to remove theDockerfile
file from the template before runningup
.Fixes #2632