You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For nodejs/build#75, testing builds against a Docker container I think would be good enough for our use case, but obviously they'd want a VM to build against too.
Using the word "switching" there is a fair bit misleading -- we're not outright replacing the base in any image so far, since the potential for breakage by doing so is far too great. In the cases where this is happening, we're simply offering an Alpine-based alternative for space-conscious consumers.
I'm going to work on some sort of automated testing for our PR process. If memory serves that was the blocker to trying to ship an alpine or scratch image.
I really like the templates approach. it would make updating minor versions (v4.5, v5.11, etc.) easier.
Generally speaking, we're at a point now where we want to be pretty conservative with what variants we add. I think an Alpine variant will be the last one we add for a while unless a very compelling use case comes up.
There are some differences between the 0.10, 0.12 images and the 4.x and 5.x. This is mostly due to the fact that 0.10 and 0.12 came from the Joyent org and 4.x etc came from iojs -- this was before the merge.
To reiterate why Alpine is a special case, the images we ship use releases of distributions that Node.js is tested against by the upstream project. Alpine isn't tested upstream, so by supporting it in this repo we are taking on the responsibility of testing that image and asserting it is stable.
As an awesome side effect of these requirements, we are getting thorough testing on all of our images 😄
Reacted by Steven, Kevin Karwaski, Martin Schinz and Tony OHagan
I've been experimenting with ways of shipping a minimal docker image without needing to use Alpine etc. It is looking like it is possible using debian:jessie to supply shared libraries for the nodejs binary (I have an image running locally that is down to 26MB for v4.X).
This would have the advantage of not requiring upstream to support libmusl (which is what busybox and alpine are using) while still having tiny Docker images.
It also has the advantage of using linked libraries from an officially supported distribution.
Hey @jfrazelle! I would def prefer to have Alpine tested in our CI/CD upstream before we release an official Docker image. It sounds like the build working group is making progress here: nodejs/node#8265 (comment)
That being said @mharthttps://github.com/mhart is doing something
amazing and is using libgcc as opposed to libmusl which should make this
a lot safer.
Activity
Starefossen commentedon Oct 6, 2015
Related: nodejs/docker-iojs#44 and nodejs/docker-iojs#80
notslang commentedon Dec 7, 2015
Related: https://github.com/mhart/alpine-node
Starefossen commentedon Jan 10, 2016
Ok, it looks like the Docker guys have given Alpine an official 👍 by adding
:alpinevariants to many of their managed official images:https://github.com/docker-library/python/blob/master/3.5/alpine/Dockerfile
https://github.com/docker-library/redis/blob/master/3.0/alpine/Dockerfile
chorrell commentedon Jan 11, 2016
Nice!
For nodejs/build#75, testing builds against a Docker container I think would be good enough for our use case, but obviously they'd want a VM to build against too.
gabeio commentedon Jan 16, 2016
👍 the alpine image is amazingly small
golang also has an alpine image! (hope this helps)
https://github.com/docker-library/golang/blob/master/1.6/alpine/Dockerfile
retrohacker commentedon Jan 30, 2016
https://news.ycombinator.com/item?id=11000827
This seems relevant to the convo
tianon commentedon Feb 1, 2016
Using the word "switching" there is a fair bit misleading -- we're not outright replacing the base in any image so far, since the potential for breakage by doing so is far too great. In the cases where this is happening, we're simply offering an Alpine-based alternative for space-conscious consumers.
retrohacker commentedon Feb 1, 2016
Thank you for clarifying @tianon.
I'm going to work on some sort of automated testing for our PR process. If memory serves that was the blocker to trying to ship an
alpineorscratchimage.nodejs/docker-iojs#44
ncopa commentedon Feb 25, 2016
@retrohacker
make checkworks once those 2 pull requests are merged:nodejs/node#5099
nodejs/node#5056
I think all the issues should be resolved now.
retrohacker commentedon Feb 25, 2016
@ncopa you rock! Those PRs are 🔥
ncopa commentedon Mar 3, 2016
@retrohacker anything else preventing this to move forward?
retrohacker commentedon Mar 3, 2016
@ncopa testing is all that is left.
If we can simply get something that runs
danteto smoke test 4 or 5 popular node modules on each PR, I would be happy to go to bat for this.This is what I do at NodeSource to reassure myself I'm not shipping a broken runtime: https://github.com/nodesource/docker-nsolid/blob/master/tests/npm/smoke_test.sh
retrohacker commentedon Mar 3, 2016
Adding in
make checkwould be awesome if there is a way to do that without doing the whole build in the container.LaurentGoderre commentedon Apr 4, 2016
I am in the process of creating a alpine variant for another service I use and I would like to help out with this.
https://github.com/docker-solr/docker-solr/pull/16/files
I like how that service has templates that are generated. Is this something you guys would consider to simplify adding and maintaining variants?
chorrell commentedon Apr 4, 2016
I really like the templates approach. it would make updating minor versions (v4.5, v5.11, etc.) easier.
Generally speaking, we're at a point now where we want to be pretty conservative with what variants we add. I think an Alpine variant will be the last one we add for a while unless a very compelling use case comes up.
LaurentGoderre commentedon Apr 11, 2016
PR #144 is a start on this but I am wondering why there such a diff between versions
chorrell commentedon Apr 11, 2016
There are some differences between the 0.10, 0.12 images and the 4.x and 5.x. This is mostly due to the fact that 0.10 and 0.12 came from the Joyent org and 4.x etc came from iojs -- this was before the merge.
ncopa commentedon May 19, 2016
People are moving away from the official node image. What can I do to help adding official alpine support?
There was some performance issues with node 4, so it might be an idea to only support node 5.x and newer for alpine.
retrohacker commentedon May 19, 2016
Hey @ncopa 😄
We have a dangling pull request here that I have meant to follow back up on: #141
This allows us to have a thorough test suite of the Docker images and smoke test against a collection of popular node modules.
Having this define a test that runs the
make checkscript would be amazing, and would allow us to assert that thenodebinary is behaving as expected.If we get smoke testing and
make checkto pass on #156 , I would be confident on 👍ing that PR.retrohacker commentedon May 19, 2016
To reiterate why Alpine is a special case, the images we ship use releases of distributions that Node.js is tested against by the upstream project. Alpine isn't tested upstream, so by supporting it in this repo we are taking on the responsibility of testing that image and asserting it is stable.
As an awesome side effect of these requirements, we are getting thorough testing on all of our images 😄
retrohacker commentedon Aug 25, 2016
An update on this:
I've been experimenting with ways of shipping a minimal docker image without needing to use Alpine etc. It is looking like it is possible using
debian:jessieto supply shared libraries for the nodejs binary (I have an image running locally that is down to 26MB for v4.X).This would have the advantage of not requiring upstream to support libmusl (which is what busybox and alpine are using) while still having tiny Docker images.
It also has the advantage of using linked libraries from an officially supported distribution.
ncopa commentedon Aug 26, 2016
FWIW, an official Alpine image is important for Docker inc. as we use Alpine for a lot other stuff.
retrohacker commentedon Aug 26, 2016
@ncopa the ones I've been experimenting with have been built from
scratch. Will that do or do you need something specific from the Alpine base image?jessfraz commentedon Sep 8, 2016
why not adopt https://github.com/mhart/alpine-node?
retrohacker commentedon Sep 9, 2016
Hey @jfrazelle! I would def prefer to have Alpine tested in our CI/CD upstream before we release an official Docker image. It sounds like the build working group is making progress here: nodejs/node#8265 (comment)
(for more background: #46 (comment))
That being said @mhart is doing something amazing and is using
libgccas opposed tolibmuslwhich should make this a lot safer.jessfraz commentedon Sep 9, 2016
ah cool, that makes sense :)
On Thu, Sep 8, 2016 at 5:14 PM, William Blankenship <
notifications@github.com> wrote:
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3
chorrell commentedon Nov 10, 2016
Closed via #156