Repository navigation
Alpine Linux / Docker Build #75
Description
Would really be appreciated if some help could be rendered to getting an alpine image for iojs passing the test suite.
- Consider alpine/busybox base image docker-iojs#44
- Consider alpine/busybox base image docker-iojs#44 (comment)
If there could be two build images, one for just node, and another with everything needed for node_gyp and nan to run.
Also, would be nice to see tests for building common binary modules (sqlite3, expat and a few others).
Metadata
Metadata
Assignees
Labels
No labels
Activity
jbergstroem commentedon Apr 15, 2015
@tracker1 I think one challenge will be fully supporting musl as a libc replacement. I'm not against it but have very little knowledge about it. It doesn't look like its in too bad a shape. I'm keen on setting up a system based on musl, so I might give this a go down the road, but don't count on me for the moment.
tracker1 commentedon Apr 15, 2015
@jbergstroem understandable... :-) Really wish I had more time (and a more intimate working relationship with C/C++).
springmeyer commentedon Apr 15, 2015
As the maintainer of node-sqlite3, 👍
Same here. I'm also interested in musl.
mhart commentedon Apr 24, 2015
The failures in the tests (there are only two) are due to assumptions in the tests themselves. One being that the platform has glibc (which Alpine isn't), the other being that the
pscommand supports the-pflag (which Alpine doesn't).You can read more here: nodejs/docker-iojs#44 (comment)
Starefossen commentedon Jan 10, 2016
I am putting this on the agenda for #300
jbergstroem commentedon Jan 10, 2016
I don't think anyone objects to get this part of the ci, but work needs to be done. Lets get an outline going for whats required - feel free to add:
Starefossen commentedon Feb 2, 2016
Regarding version of Alpine linux it looks like the Docker Library guys are using
alpine:3.3for some of their official images on Docker Hub.https://github.com/docker-library/python/blob/master/3.5/alpine/Dockerfile#L1
https://github.com/docker-library/redis/blob/master/3.0/alpine/Dockerfile#L1
jbergstroem commentedon Feb 2, 2016
@Starefossen how often is stable updated? How does that affect toolchain, etc? (thinking if they have a LTS mindset)
Starefossen commentedon Feb 3, 2016
I had a chat with one of the Alpine Linux maintainers today. This is what they told me:
mhart commentedon Feb 3, 2016
@Starefossen some important things to note about the Node.js package in the aports repository are:
--shared-zlib)--shared-libuv)--shared-openssl) (this recently caused a compatibility issue)--without-snapshot)These may not be an issue but they're worth being aware of. They've certainly been a lot better at keeping up to date with releases since 4.x
(latest build file is here: http://git.alpinelinux.org/cgit/aports/tree/main/nodejs/APKBUILD?id=18fd7609f0ec2df89c873e788880119a703496a1)
jbergstroem commentedon Feb 3, 2016
@mhart the intention is to build node, so not being on edge shouldn't be a problem. Meeting the dependencies (if using shared libraries) might though.
MylesBorins commentedon Feb 3, 2016
Having just done the ssl update I know there are 4 floating patch's on top of the release
28 remaining items
rvagg commentedon Jul 5, 2016
I believe the question is about shipping musl binaries? I'm hesitant about adding musl binaries to nodejs.org for the following reasons:
It's a Pandora's Box that we have to be sure we want to open before we go ahead with this. Right now it's easy and obvious: our binaries only support libc.
Let's get this on the Build WG agenda and see if anything comes out of that.
shouze commentedon Jul 5, 2016
@rvagg for sure it need to be maintained... to me node docker alpine variants are sufficient. I'm not convinced that shipping musl compatible binaries (outside of docker containers) deserves many use cases. In general we talk about people that are used to compile node themself no?
rvagg commentedon Jul 5, 2016
I think the proposal here is for us to ship musl binaries on nodejs.org so the docker-node folks don't need to build it on image when shipping to Docker Hub. If that's incorrect then someone please clarify what the ask here is now.
bnoordhuis commentedon Jul 5, 2016
Security angle: statically linking in musl means we're obligated to track it for CVEs and make the proper announcements and releases when vulnerabilities are found. IOW, it's more work.
Starefossen commentedon Jul 5, 2016
That is correct, Rod!
shouze commentedon Jul 5, 2016
So... musl could be not statically linked then docker-node folks will need to build an image that include node compilation and on security angle it will benefit from docker hub security scanning feature.
Of course If I had nodejs binary ready to download for my docker container it would be cool, so I'm not against this proposition, just not convinced it worth it regarding the amount of energy to spend.
LaurentGoderre commentedon Oct 26, 2016
Couldn't I make the case that docker and Alpine are a wildly adopted platform and having a binary targeting those is good for Node. Couldn't you justify this one in particular and avoid the scfope creep since Docker has a consistent architecture.
LaurentGoderre commentedon Jan 19, 2017
I would like to bump this. Since we included an alpine variant to the docker project, we received a lot of questions about the alpine variant specifically. It's unfortunate that we don't have stats about specific docker tag downloads but it's possible that alpine will become on of the most used platforms for Node, if it isn't already.
Trott commentedon May 23, 2018
Is this resolved? I haven't read all the details, but I know that we have docker and alpine in CI now and I see that this issue has not received much in the way of comments lately.
SimenB commentedon May 23, 2018
I'm not sure what this issue is tracking, tbh. I'd still love alpine binaries as part the regular release, but that might not be tracked here?
Vanuan commentedon May 23, 2018
This was the first issue mentioning Docker/Alpine use case specifically asking to provide help with running test suite in alpine.
Several follow up issues were created since then.
So this apparently was re-purposed as an umbrella issue for all other issues mentioning Alpine.
Now, that Alpine variant is in CI and included into official docker library: https://github.com/docker-library/official-images/blob/master/library/node
the only missing part is providing node binary linked against musl (at least for x86_64) here:
https://nodejs.org/dist/
maclover7 commentedon Jun 19, 2018
Alpine (both 36 and 37) is being used in CI, which I believe closes this issue? Please reopen if I'm mistaken.