docker-iojs

docker-iojs copied to clipboard

https://registry.hub.docker.com/_/alpine/

Though I'm not sure how much will actually be saved once Python2.7, build tools and libssl dependencies are installed, it might be worth considering.

:+1:

@tracker1 https://github.com/oren/alpine-node - only 22 MB

Perhaps run this binary against the test suite to make sure it passes?

@jbergstroem automated tests of our docker images is def on my roadmap. Just haven't had time. I'll open an issue for it though.

Just saying that the alpine stuff is pretty much bleeding edge (that alpine-node seems to pull the latest available from alpine). If this ends up being our recommended solution, it'd be great to back that statement up. Btw, I'm also really like the suggested approach of minimising the container size as long as we're very comfortable with the toolchain that leads us there.

@oren thanks, had considered doing the same... added issue suggesting the addition of pre-requisites for gyp...

@jbergstroem cool, I'd thought about just seeing which version was in apm and how well up to date the alpine image would be myself, hadn't taken the time. Agreed on minimizing the size... even though it's not too bad, ubuntu and debian images are a bit bigger and if we can start off small, it is a great thing.

yup. tiny images are nice. Here is nginx in 6 MB - https://github.com/oren/alpine-nginx

100% agree with the direction this is going. I'll be glad to tackle this, but it might be a few weeks before I'm at a point where I can explore this area (my backlog is pretty long right now). If @oren or @tracker1 (or others?) wants to kick off exploring this in the form of a PR to a new branch (maybe alpine?) we can start iterating on the idea. Thoughts?

( //CC: @pesho @Starefossen @hmalphettes @jlmitch5)

I also like this, and would welcome a PR adding it as a tag in this repo (possible tags: alpine, micro, busybox, or something else?)

IMO "alpine" would be the most self-descriptive tag :smile:

would welcome a PR adding it as a tag in this repo

A few points, before anyone starts working on such a PR:

• The image shouldn't rely on an external package repository (as @oren's image does). A possible exception is, if this repository is also managed by the (at this point hypothetical) Docker WG, but that would be a pretty major change requiring further discussion.
• The image should properly verify during build the GPG signatures of the downloaded binaries (assuming they are used at all), like the other variants do. I doubt the Alpine base image includes GnuPG, so it may need to be added, this increasing the image size (unless GnuPG is deleted before a layer is committed, of course).
• The image should fit the current build process, so that version updates won't be complicated. The helper scripts would have to be updated.

If it's not possible to satisfy the above, I think the Alpine image should remain separate.

The source of the iojs package build is here: https://github.com/alpinelinux/aports/blob/master/testing/iojs/APKBUILD

The image 'alpine:edge' does not contain gnupg indeed; Note that gnupg is available as a supported package.

If we go down this route dont we need to provide the rest of the images: "iojs:alpine-slim", "iojs:alpine", "iojs:alpine-onbuild" ?

Starting from @oren's Dockerfile I have been testing Alpine to run some modules with native dependencies. @oren's image is a fine alternative to iojs:slim.

We would need a second fatter alpine image with the build tools to support this situation:

RUN apk update && \
  apk add --update iojs make g++ git gnupg python bash && rm -rf /var/cache/apk/*

That image weighs 203 MB to be compared with the 700 MB of the debian based iojs image.

What about having 2 images: 22 MB image for situations where native modules are not needed, and 700 MB for the other case.

@oren at the moment there are 3 images based off debian jessie

• iojs:slim (just runtime no support for native dependencies) - 193 MB
• iojs (with build tools) - 700 MB
• iojs:onbuild (build tools and some extras for installing and running an app) - 700 MB

@oren could you specify the content of the 2 images you have in mind?

Good thing to have in mind: alpine runs on musl (at least when I last checked). Has anyone run the iojs test suite on such a docker image yet?

Both _mjones from #alpine-linux and myself run the test suite.

_mjones

environment alpine edge on kvm full virtualisation. results 7 tests fail, 828 tests pass. It looks like the failures are deliberate behaviour of musl libc (the failed tests are one due to busybox 'ps' not having the p option, and the rest TLS/SSL). He will investigate it later. Details here: http://paste.ubuntu.com/10710805/

Mine

environment ubuntu + docker. Steps to reprouce my setup: https://github.com/oren/test-iojs-docker-alpine results I was not able to run the tests. When I run ./configure --prefix=/usr --shared-openssl --shared-zlib I get: http://paste.ubuntu.com/10710714 And When I run make I get: http://paste.ubuntu.com/10710640/

@hmalphettes you are correct about the number of images needed. It should match whatever we currently have.

@hmalphettes given the binary capable version is about the same size as the current slim, I'd say that's pretty nice.

@tracker1 agreed: it is very nice.

I second @pesho's comment on verifying binaries in order for this to become an official io.js image under the :alpine tag.

:+1: on verification, and I would still like to see #46 be a prerequisite to shipping this if it gets that far.

Update: I am able to run the tests and get 4 errors. To reproduce it follow https://github.com/oren/test-iojs-docker-alpine

make -C out BUILDTYPE=Release V=1
make[1]: Entering directory '/tmp/iojs-v1.6.3/out'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/tmp/iojs-v1.6.3/out'
ln -fs out/Release/iojs iojs
/usr/bin/python tools/test.py --mode=release message parallel sequential -J
Path: parallel/test-cluster-http-pipe
events.js:141
      throw er; // Unhandled 'error' event
            ^
Error: read EACCES
    at exports._errnoException (util.js:749:11)
    at Pipe.onread (net.js:538:26)

assert.js:88
  throw new assert.AssertionError({
        ^
AssertionError: false == true
    at process.<anonymous> (/tmp/iojs-v1.6.3/test/parallel/test-cluster-http-pipe.js:22:5)
    at emitOne (events.js:82:20)
    at process.emit (events.js:166:7)
    at process.exit (node.js:659:17)
    at Worker.<anonymous> (/tmp/iojs-v1.6.3/test/parallel/test-cluster-http-pipe.js:19:13)
    at emitTwo (events.js:87:13)
    at Worker.emit (events.js:169:7)
    at ChildProcess.<anonymous> (cluster.js:351:14)
    at ChildProcess.g (events.js:257:16)
    at emitTwo (events.js:87:13)
Command: out/Release/iojs /tmp/iojs-v1.6.3/test/parallel/test-cluster-http-pipe.js
Path: parallel/test-http-client-pipe-end
events.js:141
      throw er; // Unhandled 'error' event
            ^
Error: read EACCES
    at exports._errnoException (util.js:749:11)
    at Pipe.onread (net.js:538:26)
Command: out/Release/iojs /tmp/iojs-v1.6.3/test/parallel/test-http-client-pipe-end.js
Path: parallel/test-http-client-response-domain
assert.js:88
  throw new assert.AssertionError({
        ^
AssertionError: 'should be caught by domain' == 'read EACCES'
    at Domain.<anonymous> (/tmp/iojs-v1.6.3/test/parallel/test-http-client-response-domain.js:29:12)
    at emitOne (events.js:77:13)
    at Domain.emit (events.js:166:7)
    at ClientRequest.emit (events.js:139:14)
    at Socket.socketErrorListener (_http_client.js:254:9)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:166:7)
    at net.js:438:14
    at process._tickDomainCallback (node.js:366:13)
Command: out/Release/iojs /tmp/iojs-v1.6.3/test/parallel/test-http-client-response-domain.js
Path: parallel/test-http-unix-socket
Error: read EACCES
    at exports._errnoException (util.js:749:11)
    at Pipe.onread (net.js:538:26)
assert.js:88
  throw new assert.AssertionError({
        ^
AssertionError: false == true
    at process.<anonymous> (/tmp/iojs-v1.6.3/test/parallel/test-http-unix-socket.js:63:10)
    at emitOne (events.js:82:20)
    at process.emit (events.js:166:7)
    at process.exit (node.js:659:17)
    at ClientRequest.<anonymous> (/tmp/iojs-v1.6.3/test/parallel/test-http-unix-socket.js:55:13)
    at emitOne (events.js:77:13)
    at ClientRequest.emit (events.js:166:7)
    at Socket.socketErrorListener (_http_client.js:254:9)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:166:7)
Command: out/Release/iojs /tmp/iojs-v1.6.3/test/parallel/test-http-unix-socket.js
Path: parallel/test-module-loading-error
util.debug: Use console.error instead
DEBUG: load test-module-loading-error.js

assert.js:88
  throw new assert.AssertionError({
        ^
AssertionError: -1 != -1
    at Object.<anonymous> (/tmp/iojs-v1.6.3/test/parallel/test-module-loading-error.js:22:10)
    at Module._compile (module.js:410:26)
    at Object.Module._extensions..js (module.js:428:10)
    at Module.load (module.js:335:32)
    at Function.Module._load (module.js:290:12)
    at Function.Module.runMain (module.js:451:10)
    at startup (node.js:123:18)
    at node.js:867:3
Command: out/Release/iojs /tmp/iojs-v1.6.3/test/parallel/test-module-loading-error.js
Makefile:76: recipe for target 'test' failed

Looks like the first 3 are permission errrors (maybe)? The last one is a bit strange. I'm not used to running the iojs-test suite though.

Unfortunately there are some challenges with running the io.js test suite 😕 Maybe someone at iojs/build may be able to help?

FWIW, I've been using io.js on my Alpine Docker image for a while now (only 24.6 MB!) – there are only two failing tests on my stack, due to assumptions in the tests themselves.

One test (test-module-loading-error.js) is loading an already-built native linux module, which I assume is built with glibc because it fails with "Exec format error" – native modules work fine on Alpine if they're compiled using musl (which npm/node-gyp will do during an npm install) – so I think the test scope here is too narrow. The test shouldn't just check for linux, but also for glibc – and perhaps have another option for musl-based linux distros.

The other test (test-setproctitle.js) is failing because it's trying to run ps with a -p flag, which isn't supported on the Alpine version of ps – so I'd argue that the test should be changed with that in mind.

So apart from those minor test issues, it runs fine. You can check it out here:

https://registry.hub.docker.com/u/mhart/alpine-iojs/

:+1:

Sorry for jumping in mid-stream here and not fully groking the entirety of this thread but I think @jbergstroem's point about testing needs to be expanded on: when @iojs/docker is considering releasing images based on specific platforms like this it would be great if we could take a more coordinated approach to the issue of platform support. If you go ahead and push an Alpine Linux based image while this distro is not part of our CI suite for io.js you're creating a gap in our understanding of what it means for it to be supported.

I'd suggest that if you're set on doing this then @iojs/docker and @iojs/build find some way to integrate testing into regular CI such that we can be clearer about it being a supported platform, both in the current state of io.js and as it evolves over time. I don't know enough (anything?) about this distro so can't suggest a way forward but would love to help explore this. Perhaps something like build-containers for this if it's a container-focused distro?

@rvagg I can commit to having a CI figured out for the iojs docker images by end of June.

In this presentation redbeard makes the case that we should build our iojs/nodejs containers from scratch instead of relying on a general purpose distro: https://www.youtube.com/watch?v=gMpldbcMHuI