also install node.js and grunt on images

[friism]

Most ASP.NET 5 projects assumes the presence of Node.js and Grunt during builds. Examples are the MusicStore apps and the default VS2015 File->New Project templates.

The PR adds those requirements to the images. Note that Git is required to run Grunt. I've added the --no-install-recommends flag to pull in less stuff when installing Git.

It's unfortunate that there's no nodejs packages for Debian Wheezy. This could be significantly simplified if the upstream Mono image was based on Debian Jessie (which has nodejs package).

[friism]

/cc @directhex

[ahmetb]

@friism thanks for starting the discussion on this.

Isn't a language image supposed to have minimal contents? Users can always build and publish images node/grunt are installed on top of this base image and call it aspnet-node-grunt and take that as a base application. (also, in the future most probably this image will be an official language stack image, therefore we should be careful what we're doing.)

Most ASP.NET 5 projects assumes the presence of Node.js and Grunt during builds.

Although I'm quite unfamiliar with the app ecosystem in this case, can somebody else verify this is the case and these stuff are quite “necessary to handle the common use case” (i.e. 80%-90% of the real world ASP.NET 5 apps rather than samples)?

[ThatRendle]

I'd be very wary of this sort of change. Docker is designed to run production code; it seems reasonable to expect that Grunt/Gulp would be run during the build of the container image, rather than at the run.

[friism]

Docker is designed to both build, debug and run apps. If you can't build your code in the docker container, then you can't run it either.

I'm vary of this change too, but it'd be sad if 90% if apps using this Dockerfile started with:

FROM microsoft/aspnet-docker
RUN apt-get -qq update && apt-get -qqy --no-install-recommends install \
    git \
    unzip

# Install Node.js and Grunt
RUN curl -sL https://deb.nodesource.com/setup | bash - \
    && apt-get install -qqy nodejs \
    && npm install -g grunt-cli

... or some broken, copy-pasted node install.

[akoeplinger]

I'm also 👎 on installing node and grunt by default in the image. I like @ahmetalpbalkan's suggestion to build another image on top of this one that includes those tools.

[friism]

I also note that it's weird that the default Docker microsoft/aspnet image doesn't build the default project template spurted out by Visual Studio.

[akoeplinger]

I wouldn't call it weird, since I primarily see Docker as a way to run applications, not build them. For example, the official Java Docker image also doesn't have Maven/Ant/Gradle preinstalled, so you can't build most Java projects on it as well.

[ahmetb]

This sounds like something we can address with ONBUILD image proposal #19. It appears we do not have the usage data to verify neither that 90% of the people are going to need it nor what ONBUILD image should look like, yet.

Most language stack program images (i.e. python, java, ruby) do not come with such 3rd party additions. Also, the new ASP.NET 5 does not run only web apps, it also supports running command line apps. In their case node/grunt will not be necessary at all.

By all means, docker is all about composability rather than putting everything into one image and making it a swiss knife. Users can always build other images on top of this image and if that happens to be the 90% use case, we can address this in a separate image or ONBUILD image.

[friism]

I think the best equivalent might be Rails, which does have nodejs: https://github.com/docker-library/rails/blob/7a7f05408cddabc75ca3c5252097e238021680a8/Dockerfile#L4

But ok, closing issue.

[ahmetb]

@friism please reopen, I'd live to keep this discussion open as it is a valid concern. We just need more time and data to see where the discussion will end up, just like the onbuild image proposal. I will internally seek more inputs to this discussion.

[KentaroAOKI]

Hi,

Visual Studio 2015 "ASP.NET 5 Starter Web" template contains bower.json to use with Bower to get frontend packages, package.json to use with NPM to get Grunt, and gruntfile.js to manage tasks defined by project.json scripts.

http://blogs.msdn.com/b/webdev/archive/2014/11/12/announcing-asp-net-features-in-visual-studio-2015-preview-and-vs2013-update-4.aspx

We use Visual Studio 2015 to create some ASP.NET Applications and We want to use github to build docker image.
I have two idea. First is aspnet image with forVS2015 image. Second is one asonet image.

First is
https://github.com/KentaroAOKI/aspnet-docker/blob/vs2015ctp5/vs2015/Dockerfile
see https://registry.hub.docker.com/u/kekekekenta/aspnet/ or http://kentablog.cluscore.com/2015/01/visual-studio-2015-ctp-5aspnet-5docker.html#mstto=en

Second is
https://github.com/KentaroAOKI/aspnet-docker/blob/vs2015ctp5/1.0.0-beta2/Dockerfile

Thanks,

[marrrcin]

I also upvote the proposition of putting node and other packages required to build project inside the image. If the Visual Studio Project requires npm, bower and grunt, then why deploy image is not providing them? The goal of this image should be to provide all neccessary features from start, so developers can focus on creating the app, not the issues during deployment. If the project builts fine in the Visual Studio, and you move it to a "aspnet5-ready" docker environment you expect that it will build too.

I've created an issue (#31) as I didn't look up in the Pull Request Section.

[akoeplinger]

@marrrcin would you actually be against the creation of a aspnet5-npm-bower-grunt image that sits on top of the "bare" aspnet5 image or is that OK for you?

The reason why I bring this up is because the core tenets of aspnet5 are composability and that you only pay for what you use. For example, I don't need npm etc. in my docker image cause I don't run any minification/bundling inside the image, but I'd get all this stuff nonetheless if it were included in the aspnet5 image.

Having a bare image with just enough to run simple aspnet5 apps and an extended version with everything required to run the VS template app sounds like a very good solution to me.

[friism]

@akoeplinger or you could use slim: https://github.com/docker-library/python/blob/c0c674911c50ca3e21ba5379541f70c1b42685b4/3.4/slim/Dockerfile

[marrrcin]

@akoeplinger - it will be OK, as long as there will be proper guidelines to which image use. Following your idea, there should be aspnet-web with everything required to run web applications, aspnet-core (or just aspnet as it is now) and aspnet-whatever if there will be more scenarios.

[akoeplinger]

@friism I'm not sure I follow, what's the difference?

[friism]

@akoeplinger Microsoft could maintain two image-sets:

• aspnet has node, npm, grunt and other kitchen sink components
• aspnet-slim has the bare minimum

[akoeplinger]

@friism ahh ok. yeah that would be the same what I proposed, just with different names (assuming aspnet builds on top of aspnet-slim).

[marrrcin]

@friism
It will be event better :)

[ahmetb]

Thanks for the awesome feedback folks. We are meeting (VS, ASP.NET, Azure teams) next week to get input from the internal folks as well. Microsoft also wants this image to play nice with the Visual Studio experience. I started to agree you maintaining two different images. Please stay tuned, I'll keep this discussion up to date.

[litan1106]

I had the same error, but I got it to work with the following installs:
npm install -g grunt-cli
npm install -g nodejs

[marrrcin]

@ahmetalpbalkan - could you provide us status update?

[ahmetb]

Hello everybody,

We had a meeting internally about this. Here's a quick summary of it:

• aspnet image will stay as is at this point. It will contain only the required runtime.
• We will release onbuild images, they will be distributed as tags of existing version tags.
  (e.g. 1.1-onbuild). Thinking around this is, this would copy an already packaged applications (using kpm pack and such) to a standardized path and would invoke a standard ENTRYPOINT (i.e. k) and a standard but overrideable CMD (i.e. kestrel).

Therefore plan is not towards distributing an image that contains extra bits (e.g. node.js/grunt/bower) to “build” the application at this point. At this point, decision is to keep the image minimal and make an ONBUILD image which is for applications packaged on dev machine.

Several reasons we thought we probably should not do this is because:

1. Image is getting bigger with dependencies.
2. Build time is increasing downloading dependencies etc.
3. Other languages working with cross-platform IL/bytecodes provide only the runtime/compiler. Take java as an example, given that mostly tools like ant/maven would be needed to compile the bits, these are not distributed and community has plenty of good images doing this.
4. Attack surface on the image will just increase as we install stuff.

I know this sounds like we will not be doing an image that takes your Visual Studio 2015 project, puts in an application container, builds it inside the container and starts it. That being said, we would love to advertise a community-developed image doing this job. If somebody comes up with a good ”aspnet-visualstudio” image, we'd happily mention it in our readme, use it in our tutorials and demos! This also does not mean we will never do such a thing officially, it's just we are still in preview and still have not discovered the common use cases of containerized vNext.

By the way, I would love to host an online Hangouts session to discuss this and meet you folks. Anyone?

cc: @Eilon @davidfowl @shanselman

[ThatRendle]

I'm doing mad stuff with ASP.NET and Docker at the moment, and for the record I agree 100% with your reasoning. The advantage of Docker is that anyone can FROM an existing image and add on extras that they want, be that Node, Python, Ruby or whatever.

Regarding the Visual Studio integration, I think a Dockerize workflow in a similar vein to the existing Publish functionality could be a big win. Maybe something for YoloDev.

I'd be very interested to attend a Hangout talking about this stuff.

[friism]

@ahmetalpbalkan Roger that. If this image is supposed to be minimal runtime, how come it relies on a mono image that installs mono-devel (which pulls in compilers and other crap)?

[akoeplinger]

@ahmetalpbalkan sounds good 👍

@friism I guess cause no one requested a minimal mono image yet? 😄

[ahmetb]

I'd love to remind that mono is an interim solution.

I'll set up Hangouts with interested folks soon and post the dates here.

[Eilon]

I like this plan too, thanks for meeting today! (I think I walked by the focus room where you guys were sitting, and I knew you were all up to no good 😉)

[marrrcin]

@ahmetalpbalkan - so Visual Studio 2015 & Docker support will never be "out-of-the-box"? What about the "play nice" experience you had mention in previous post?

However, I would like to contribute to this aspnet-visualstudio image. Has anyone started it yet?

[ahmetb]

@marrrcin as I said, the onbuild image will be supporting the packaged applications. So if you develop your application using VS and pack/bundle it using the relevant command, you still won't be crafting a big Dockerfile. That being said, it doesn't mean that we wouldn't ever release an aspnet:vs image; it's just we are not planning at this point. What we are not doing is building your source code inside the container. That's where the VS image would make a difference. I suggest re-reading my comment. :-)

[vlesierse]

I like the idea to have a unbuild image that copies the kpm pack output. Currently I'm working this out in our CI pipeline like this. Having a image with node & grunt (why not gulp) sounds like a bad idea because you will never use that at runtime in production.

[friism]

Here's an interesting way to create a runtime Docker image through a builder image, so that the runtime image doesn't end up with the compiler and toolchain and other crap: https://github.com/jamiemccrindle/dockerception

[ahmetb]

@friism that's indeed very interesting and definitely easily applicable to the statically compiling languages like Go. It also helps keeping the runtime image minimal.

I'm thinking if we should still have an image with node/grunt/gulp etc in it. If you guys like to provide and maintain a builder image in your personal repos on top of this image, we can refer to that in our docs/tutorials.

The current direction we are going appears like we will not be providing a swiss army knife image and will stick with the minimal runtime image that could run the bundled/packaged applications.

[muratg]

Interesting discussion, though not sure if we need to keep this PR open. @ahmetalpbalkan?

[muratg]

Looks like we're not going in with this approach, and have a minimal runtime instead. Closing this one. Thanks @friism for the interesting discussion and PR.

[friism]

+1, thanks!