Open bradygaster opened 1 year ago
@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 docker
installed. Users will do development locally without containerization.
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 dotnet publish
to include a filepath for writing out the built docker image ID. That way azd
can pick up the newly built image before pushing.
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 dotnet publish --os linux --arch x64 /t:PublishContainer -c Release
as an example, we can use .NET SDK to produce the image build locally in lieu of Docker. For any .NET 7+ applications, this should be the default for local builds.
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.
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.