.NET Containers advancements in .NET 8 | .NET Conf 2023
ฝัง
- เผยแพร่เมื่อ 15 พ.ย. 2023
- .NET 8 brings new advancements in performance in security not just for your apps, but for the containers that run them. Learn more about changes to the Microsoft base images to support rootless execution, new container images that support more secure deployment and entirely new scenarios like Ahead of Time compilation. Then, see how the SDK Container publishing tooling that builds on these to make container deployments easier than ever.
Download .NET 8 - aka.ms/get-dotnet-8
Hack Together - aka.ms/hacktogether/dotnet
Learn collection - aka.ms/learn-dotnet-8
.NET 8 Survey - aka.ms/dotnet-survey
Local Events - aka.ms/dotnetconf-local-event
Hero blog - aka.ms/dotnet8blog
Blog: aka.ms/dotnet/blog
Twitter: aka.ms/dotnet/twitter
TikTok: aka.ms/dotnet/tiktok
Mastodon: aka.ms/dotnet/mastodon
LinkedIn: aka.ms/dotnet/linkedin
Facebook: aka.ms/dotnet/facebook
Docs: learn.microsoft.com/dotnet
Forums: aka.ms/dotnet/forums
🙋♀️Q&A: aka.ms/dotnet-qa
👨🎓Microsoft Learn: aka.ms/learndotnet
#dotnet - วิทยาศาสตร์และเทคโนโลยี
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!
🎉🎉🎉🎉 great stuff! Can’t wait to try it.
Thank you both, great stuff!
Thanks guys.
dotnet is getting better and better!
cool，very cool
Your channel has become a reliable source of knowledge.
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!
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)
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 ?
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 wonder how Azure Container Reg Build Tasks support this? can I instruct it to use dotnet publish instead of dockerfile?
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.