Repository navigation
Add an Alpine variant? #46
Description
Activity
Related: nodejs/docker-iojs#44 and nodejs/docker-iojs#80
- Reacted by Steven, Alex Ellis, Nick White and Eric Zeng
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/DockerfileNice!
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.
👍 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/Dockerfilehttps://news.ycombinator.com/item?id=11000827
This seems relevant to the convo
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.
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.@retrohacker
make checkworks once those 2 pull requests are merged:
nodejs/node#5099
nodejs/node#5056I think all the issues should be resolved now.
@ncopa you rock! Those PRs are 🔥
@retrohacker anything else preventing this to move forward?
@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
Adding in
make checkwould be awesome if there is a way to do that without doing the whole build in the container.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?
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.
PR #144 is a start on this but I am wondering why there such a diff between versions
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.
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.
Reacted by Steven and William BlankenshipHey @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.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 OHaganAn 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.
Reacted by Ken Chen@retrohacker I've been experimenting with ways of shipping a minimal docker image without needing to use Alpine
FWIW, an official Alpine image is important for Docker inc. as we use Alpine for a lot other stuff.
@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?Reacted by Daniel Perez Alvarezwhy not adopt https://github.com/mhart/alpine-node?
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.Reacted by Pascal Andyah cool, that makes sense :)
On Thu, Sep 8, 2016 at 5:14 PM, William Blankenship <
notifications@github.com> wrote:Hey @jfrazelle https://github.com/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)
nodejs/node#8265 (comment)(for more background: #46 (comment)
#46 (comment))That being said @mhart https://github.com/mhart is doing something
amazing and is using libgcc as opposed to libmusl which should make this
a lot safer.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#46 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYNbLQZsCncTOa7KoG_azGDztYZW2PYks5qoKTagaJpZM4F_65j
.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
Having an Alpine variant would be useful.
This primarily depends on nodejs/build#75 though