Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an Alpine variant? #46

Closed
chorrell opened this issue Sep 18, 2015 · 27 comments
Closed

Add an Alpine variant? #46

chorrell opened this issue Sep 18, 2015 · 27 comments

Comments

@chorrell
Copy link
Contributor

Having an Alpine variant would be useful.

This primarily depends on nodejs/build#75 though

@Starefossen
Copy link
Member

Related: nodejs/docker-iojs#44 and nodejs/docker-iojs#80

@notslang
Copy link

notslang commented Dec 7, 2015

Related: https://github.com/mhart/alpine-node

@Starefossen
Copy link
Member

Ok, it looks like the Docker guys have given Alpine an official 👍 by adding :alpine variants 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
Copy link
Contributor Author

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
Copy link

gabeio commented 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
Copy link
Contributor

https://news.ycombinator.com/item?id=11000827

This seems relevant to the convo

@tianon
Copy link
Contributor

tianon commented 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
Copy link
Contributor

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 alpine or scratch image.

nodejs/docker-iojs#44

@ncopa
Copy link

ncopa commented Feb 25, 2016

@retrohacker make check works once those 2 pull requests are merged:
nodejs/node#5099
nodejs/node#5056

I think all the issues should be resolved now.

@retrohacker
Copy link
Contributor

@ncopa you rock! Those PRs are 🔥

@ncopa
Copy link

ncopa commented Mar 3, 2016

@retrohacker anything else preventing this to move forward?

@retrohacker
Copy link
Contributor

@ncopa testing is all that is left.

If we can simply get something that runs dante to 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
Copy link
Contributor

Adding in make check would be awesome if there is a way to do that without doing the whole build in the container.

@LaurentGoderre
Copy link
Member

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
Copy link
Contributor Author

chorrell commented 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
Copy link
Member

PR #144 is a start on this but I am wondering why there such a diff between versions

@chorrell
Copy link
Contributor Author

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
Copy link

ncopa commented 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
Copy link
Contributor

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 check script would be amazing, and would allow us to assert that the node binary is behaving as expected.

If we get smoke testing and make check to pass on #156 , I would be confident on 👍ing that PR.

@retrohacker
Copy link
Contributor

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
Copy link
Contributor

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: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.

@ncopa
Copy link

ncopa commented Aug 26, 2016

@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.

@retrohacker
Copy link
Contributor

retrohacker commented 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
Copy link

jessfraz commented Sep 8, 2016

@retrohacker
Copy link
Contributor

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 libgcc as opposed to libmusl which should make this a lot safer.

@jessfraz
Copy link

jessfraz commented Sep 9, 2016

ah cool, that makes sense :)

On Thu, Sep 8, 2016 at 5:14 PM, William Blankenship <
[email protected]> 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

@chorrell
Copy link
Contributor Author

Closed via #156

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants