Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Built-in container support for the .NET SDK

devblogs.microsoft.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Built-in container support for the .NET SDK

#11

Post by PretzelFisch »

cpuguy83 wrote: post #10
petilon wrote: post #6

Earlier quoted context omitted.

Yeah I read that paragraph and don't get what they are talking about. I don't understand what problem they are solving. I build docker images for my .NET web app multiple times a day and it works fine. You do a publish and then in Dockerfile do: COPY bin/Release/net5.0/publish . It works fine. WTF are they talking about a mismatch between explicit definition and the .NET build process?

.net knows what version it is, it knows what deps your project has, etc. Instead of declaring this effectively twice (once for .net and once for Docker), .net is handling everything.

I also see the big call out to cases where the dockerfile and project are not in the same directory, This looks like a more straight forward improvement.

Re: Built-in container support for the .NET SDK

#12

Post by [deleted] »

PretzelFisch wrote: post #11
cpuguy83 wrote: post #10

Earlier quoted context omitted.

.net knows what version it is, it knows what deps your project has, etc. Instead of declaring this effectively twice (once for .net and once for Docker), .net is handling everything.

I also see the big call out to cases where the dockerfile and project are not in the same directory, This looks like a more straight forward improvement.

[deleted]

Re: Built-in container support for the .NET SDK

#13

Post by Merad »

petilon wrote: post #6
teh_klev wrote: post #5

Earlier quoted context omitted.

> Does it support docker running on MacOS M1, or Raspberry Pi? Not at the moment, from the article: "We have focused on the Linux-x64 image deployment scenario for this initial release. Windows images and other architectures are key scenarios we plan to support for the full release, so watch out for new developments there." So, ignoring that, this seems like a first cut. The rational for this seems to be streamlining…

Yeah I read that paragraph and don't get what they are talking about. I don't understand what problem they are solving. I build docker images for my .NET web app multiple times a day and it works fine. You do a publish and then in Dockerfile do: COPY bin/Release/net5.0/publish . It works fine. WTF are they talking about a mismatch between explicit definition and the .NET build process?

Look at the example dockerfile farther down in the article. They're performing the build inside of a dotnet sdk container then creating the application container. It sounds like you're performing the build outside of a container and just packaging the artifacts.

Re: Built-in container support for the .NET SDK

#14

Post by teh_klev »

FridgeSeal wrote: post #8
petilon wrote: post #6

Earlier quoted context omitted.

Yeah I read that paragraph and don't get what they are talking about. I don't understand what problem they are solving. I build docker images for my .NET web app multiple times a day and it works fine. You do a publish and then in Dockerfile do: COPY bin/Release/net5.0/publish . It works fine. WTF are they talking about a mismatch between explicit definition and the .NET build process?

The cynic is me would say that this is a MS attempt to take ownership and mindshare over a piece of “commodity” tooling so that devs in the ecosystem become more familiar with that than the original system, add MS/dotnet specific features and push their own system. A modern variation of “embrace, extend, extinguish”. I doubt MS has the power or desire to extinguish containers, but getting a foot in to the deployments…

I kinda tire of this sort of comment. I lived/worked through the EEE phase of MS back in the 90's, for good or for bad, but ultimately every large scale vendor wants to own the current "hot" space with their vendor specific tooling. No corporation is your friend.

Re: Built-in container support for the .NET SDK

#15

Post by petilon »

Merad wrote: post #13
petilon wrote: post #6

Earlier quoted context omitted.

Yeah I read that paragraph and don't get what they are talking about. I don't understand what problem they are solving. I build docker images for my .NET web app multiple times a day and it works fine. You do a publish and then in Dockerfile do: COPY bin/Release/net5.0/publish . It works fine. WTF are they talking about a mismatch between explicit definition and the .NET build process?

Look at the example dockerfile farther down in the article. They're performing the build inside of a dotnet sdk container then creating the application container. It sounds like you're performing the build outside of a container and just packaging the artifacts.

Right. I have Visual Studio installed. I don't need a container to build the application, I only need it for deployment.

Re: Built-in container support for the .NET SDK

#16

Post by chusk3 »

Hey folks - author here, happy to answer any questions about the feature or what we're hoping to do with it.

Broadly we just want to lower barriers to containerization for all .NET developers. Jib/Ko/etc are proven patterns in this field, and we saw an opportunity to use the existing infrastructure of MSBuild to reduce the amount of concepts our users would need to know in order to be successful in their journey to the cloud. On top of that, having the feature in SDK provides some opportunities to help users adhere to conventions around container labeling (or customize container metadata entirely!) so we can make .NET containers good citizens in the container ecosystem overall.

Re: Built-in container support for the .NET SDK

#17

Post by chusk3 »

petilon wrote: post #6
teh_klev wrote: post #5

Earlier quoted context omitted.

> Does it support docker running on MacOS M1, or Raspberry Pi? Not at the moment, from the article: "We have focused on the Linux-x64 image deployment scenario for this initial release. Windows images and other architectures are key scenarios we plan to support for the full release, so watch out for new developments there." So, ignoring that, this seems like a first cut. The rational for this seems to be streamlining…

Yeah I read that paragraph and don't get what they are talking about. I don't understand what problem they are solving. I build docker images for my .NET web app multiple times a day and it works fine. You do a publish and then in Dockerfile do: COPY bin/Release/net5.0/publish . It works fine. WTF are they talking about a mismatch between explicit definition and the .NET build process?

Mainly what I was getting at here is that there are often repo-level files that are part of the .NET build process that are easy to forget to include in your build context/as part of the initial COPY command that most folks to do to a package restore before build to take advantage of Dockerfile layer caching. Right now as a user you have to be aware of the repo/file layouts and get your build contexts right if you build inside of a multi-stage Dockerfile.

IMO for a significant part of the user base there's no reason to have to manage that at all - .NET is capable of cross-targeting enough to not need to perform the build inside of a container. That keeps the user in the 'build context' that they are used to, and we can use all of that context to still end up at the ideal result - a correct container, with all of their app dependencies.

Re: Built-in container support for the .NET SDK

#18

Post by jhaygood86 »

petilon wrote: post #6
teh_klev wrote: post #5

Earlier quoted context omitted.

> Does it support docker running on MacOS M1, or Raspberry Pi? Not at the moment, from the article: "We have focused on the Linux-x64 image deployment scenario for this initial release. Windows images and other architectures are key scenarios we plan to support for the full release, so watch out for new developments there." So, ignoring that, this seems like a first cut. The rational for this seems to be streamlining…

Yeah I read that paragraph and don't get what they are talking about. I don't understand what problem they are solving. I build docker images for my .NET web app multiple times a day and it works fine. You do a publish and then in Dockerfile do: COPY bin/Release/net5.0/publish . It works fine. WTF are they talking about a mismatch between explicit definition and the .NET build process?

Many people want the build to be in Docker to.

I personally don't -- I publish on the host build agent and just Dockerize the publish directory

Re: Built-in container support for the .NET SDK

#19

Post by petilon »

cpuguy83 wrote: post #9
petilon wrote: post #2

What problem is this solving? I have been building containerized .NET applications for a couple of years now. It is super easy to use docker command to build x86 Linux and ARM docker images. I don't think I'll switch to Microsoft's half-assed solution since the docker command works just fine. Here's the problem Microsoft should be solving instead: Once a docker image is built, how can my customer (not me) deploy it t…

Honestly having .NET figure out what is needed for the image, the build context, etc. is a much better way to build and it doesn't require having the extra tooling. Full disclosure: Engineer at Microsoft (and previously Docker) not at all involved in .NET. I work on moby (aka docker project) and internal builds of docker and CNCF related projects.

This is all it takes:

   dotnet publish -c Release
Then in Dockerfile add this:

   COPY bin/Release/net5.0/publish .
Is that hard?

Re: Built-in container support for the .NET SDK

#20

Post by iamcreasy »

chusk3 wrote: post #16

Hey folks - author here, happy to answer any questions about the feature or what we're hoping to do with it. Broadly we just want to lower barriers to containerization for all .NET developers. Jib/Ko/etc are proven patterns in this field, and we saw an opportunity to use the existing infrastructure of MSBuild to reduce the amount of concepts our users would need to know in order to be successful in their journey to t…

Thank you for taking questions. Why do we need to run managed language inside a docker container? Doesn't the VM provide sufficient sandboxing?
Post reply on HN