Can you please confirm that we can have the same builded container without using the dotnet command but the regular docker build command? I assume I would need to precise the right targeted dotnet base docker image and Arch and ensure that my project is set for AOT and build it or publish it myself.
Will this affect our ability to install dotnet counters and other tools onto the image while it's running? Or is that one of the tradeoffs with this type of containerization?
Great question - chiseled images will have a hard time installing the trace tools. For that you'd probably want to run the trace tools in a sidecar container, and point them to the trace pipe locations. Or bundle the apps into a custom base image of your own.
I like where this is going! But please rehearse. Seems like anytime I watch a MS presentation these days, something (or multiple things) doesn’t go as it should.
Been running a couple of .net core solutions using Alpine-images in a production environment for years, and they've been nothing but rock solid. I'll definitely check out the new advancements.
I assume you choose the Dockerfile approach if you have customizations that need to be built in. For example, you have a special file that is required to be built into the container's image. Otherwise, you should be fine with using the publish container approach (sdk, runtime, runtime-deps).
I should make a FAQ for this 😅 I think 80% of .Net web/console/etc apps should default to the SDK feature. The main reason you should eject to a Dockerfile is if you have some specific Linux packages that you need installed on the underlying OS. However, with the aot and extra package variants we talked about in this tall, even that use case may be covered already!
