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!
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.
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.
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.
Cannot be happier of not having to mess with a dockerfile for a lot the scenarios, thanks for making it easier and showing it to us!
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.
Thanks for the work! Quite exciting to see you guys are working on that 2 M reduction to push to the limit! Respect!
Thanks for a demo! Was really useful. A question- when would one prefer sdk path vs dockerfile?
Sdk
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!
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.
This thing ca be done with a mvc app? i try my best but just rich 153mb image :(
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.
What about ci/cd where it expects a dockerfile ?
I wonder how Azure Container Reg Build Tasks support this? can I instruct it to use dotnet publish instead of dockerfile?
Very cool this. Is it also possible to have for example a nginx base image and put the .net application on top of it? (in case of a webapp)
Thanks guys.
Thank you both, great stuff!
dotnet is getting better and better!
🎉🎉🎉🎉 great stuff! Can’t wait to try it.
Your channel has become a reliable source of knowledge.
cool，very cool
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.