Dockerhub tag list does not reflect the addition of the 1.7 tag

https://registry.hub.docker.com/_/iojs/tags/manage/

please fix the last docker run command by replacing --it with -it

Basically, this is the same issue as nodejs/docker-node#10:

When I run the container iojs:1.1.0 using

$ docker run -it iojs:1.1.0 bash

and then inside if the container run

# npm install -g pm2-web

I get an error message by node-gyp telling me that the user is undefined:

gyp WARN EACCES user "undefined" does not have permission to access the dev dir "/root/.node-gyp/1.1.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/pm2-web/node_modules/mdns2/.node-gyp"

How do I fix that?

I am canot get node-gyp rebuild to run as an install step within the docker container:

npm install @corbinu/couchbase

gives the error
npm WARN cannot run in wd node-gyp @corbinu/[email protected] node-gyp rebuild

Any ideas?

Hi,

are there any plans to use optimize the image size?
We where using iojs image and a customer complained about the image with more than 700 MB, and suggested iojs-slim. The result was still 300 MB - including spm-agent-docker.

After using this as base:

FROM alpine:edge
RUN echo "http://dl-4.alpinelinux.org/alpine/edge/testing" >> /etc/apk/repositories 
RUN apk update
RUN apk add --update iojs
RUN apk add --update git

RUN apk update
RUN apk upgrade
RUN rm -rf /var/cache/apk/*

the image size for spm-agent-docker had a final size of 123 MB.
But here is my concern:

• how to ensure that there is the latest io.js available as .apk package?

In any case I would like to see a tiny, offical iojs base image.

Thanks
Stefan

Is 1.8 still "supported"? ie, if there's a problem discovered with 1.8.2, will there be a 1.8.3?

If it is still supported, is there some documentation somewhere pointing to supported versions (especially with EOL dates)?

docker build -t oreng/iojs .

INFO[0000] Get https://index.docker.io/v1/repositories/library/iojs/images: x509: certificate signed by unknown authority. 

Here is my Dockerfile:

FROM iojs:latest
RUN useradd -ms /bin/bash developer
WORKDIR /home/developer
USER developer

What advantage does this offer? From what I can see, most of the packages installed on top of debian:jessie in buildpack-deps:micro and buildpack-deps aren't dependencies of our project.

Run iojs and npm through their paces before considering them ready to deploy.

gpg: Signature made Tue Jan 20 07:54:40 2015 UTC using RSA key ID 7D83545D
gpg: Good signature from "Rod Vagg <[email protected]>"
gpg:                 aka "Rod Vagg <[email protected]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: <is this private?>

what does this mean?

In order to become the official iojs image on Docker Hub, we need to make some updates, as well as create docs. The process is described here:

https://github.com/docker-library/official-images
https://github.com/docker-library/docs

In case of security flaw in the application run and in docker (as it happenned and will happen)
cf:
http://blog.zeltser.com/post/104976675349/security-risks-and-benefits-of-docker-application
http://thenewstack.io/docker-addresses-more-security-issues-and-outlines-plugin-approach/
http://www.slideshare.net/jpetazzo/docker-linux-containers-lxc-and-security
https://blog.xenproject.org/2014/06/23/the-docker-exploit-and-the-security-of-containers/

I was having trouble finding what the differences were for the various tags (standard, onbuild and slim). After browsing the various iojs dockerfiles (and the relevant buildpack-deps dockerfiles), it makes sense.

I wanted to propose an addition to the readme. I'm envisioning a Tag Details section that explains the difference between the standard and slim (gives details as to what packages standard gives you that slim doesn't). Happy to provide a pr, but wanted to check that this was wanted first.

Posting here to draw attention to nodejs/build#43 to draw for anybody hovering around this project that would like to be more involved. I see the Docker effort as a sub working group of build but much of its activity will be entirely separate so you don't have to have an interest in broader build efforts to be involved here.

We are putting together a governance model for the io.js build team, and are proposing that the docker-iojs team be a sub-working group of that team. To be part of this conversation, check out: nodejs/build#49

Hi,

io.js 2.3.0 was released a few days ago, but there is still no 2.3.0 image in the official docker registry.

The builds are failing since we setup the repo to become an official image. https://registry.hub.docker.com/u/iojs/docker-iojs/builds_history/123497/

Planning on removing the repository this weekend.

List objections here 😄

io.js TC meeting 2015-05-13 voted for joining the Node.JS Foundation, meeting notes are @ nodejs/node#1700 and the video is @ http://www.youtube.com/watch?v=UbYiFLf7MpU. As per nodejs/node#1705 all repos and related working groups will be moved to the new "nodejs" org.

The impact on Working Groups is that they will also be moved in to the "nodejs" org and become part of the Foundation. However, since the Working Groups are autonomous they have the ability to relocate and detach from the Foundation and that is their right. If there are concerns within your Working Group(s) about this move, please discuss it and come to a decision according to the governance procedures you have set up.

So without further ado; should the Docker Working Group join the Node.JS Foundation or not?

As per nodejs/docker-node#28 I've added @chorrell and @dcrudgington to the @nodejs/docker team. Handing over to y'all now to discuss how to converge your resources to continue to produce both images but as a combined team. Timing and the details of how you manage both repos are entirely up to you of course. As usual if you need any resources from the Build WG then just @-mention us and we'll come running.

Happy times!

docker run iojs/docker-iojs:1.0

is a bit clunky, can we rename "docker-iojs" on Docker Hub to just "iojs" so it's more like:

docker run iojs/iojs:1.0

Of course if this becomes "official" it'll be nicer anyway but let's not presume that'll actually happen and optimise for the current case.

Thoughts? I'm assuming it's possible to have differing repo names here and on Docker Hub.

@chrisdickinson has just done v1.1.0 and it's signed with his key so for these dockerfiles to work they'll also need to pull in his key. All release keys in use will have their fingerprints listed at the bottom of https://github.com/iojs/io.js under each person authorized to release (Chris' will be making its way there shortly). You should just be able to append them together, space-separated at the end of the gpg command in the Dockerfile.

There has been some rumbling in the latest TC meetings, and very recently in nodejs/node#1436, about releasing one or more release candidates (RCs) for the next major version of io.js (v2.0). I can only assume that the RC versions will be available similarly to how the official builds are distributed.

How should we handle RC versions with regards to the io.js Docker image? Do we ignore them and wait until the final version has been landed? Or can we make them available through an 2.0-rc-x tag under the official image? If a tag on the official image is a no go, can we create a separate image for testing RCs? The latest tag will of course continue to point to latest 1.x version until v2.0 has been officially released.

I do think it is important to make RC versions available through the Docker image since the main purpose of an RC is to get as many people as possible to test them. What better way to test the new version than through Docker, right?! 🚀 😄

Some ideas suggested elsewhere:

1. Use a smaller base image for the default variant, e.g. buildpack-deps:jessie-micro
2. The build-essential package might be too fat, as it also brings stuff for Debian package development which we don't need. We may save space by installing only the useful bits.
3. The packages needed for building native modules might be left out (with a warning to the users that they should install them themselves if required).

This is a proposal and preliminary discussion about forming a new Docker Working Group within io.js. Refs #29. Working Groups are described here.

Possible WG charter (draft):

Docker WG

The Docker working group's purpose is to build, maintain, and improve official Docker images for the io.js project.

Its responsibilities are:

• Keep the official Docker images updated in line with new io.js releases
• Decide and implement image improvements
• Maintain and improve the images' documentation

We also need at least 3 initial WG members (the more the better IMO). Here is an alphabetical list of possible candidates who have contributed in the past (please respond if you would like/dislike to join):

@hmalphettes
@jlmitch5
@pesho
@rvagg
@Starefossen
@wblankenship

There have also been significant contributions from @jfrazelle, @tianon, @yosifkit from the Docker team, who are of course welcome to join if they wish.

Also /cc @mikeal

Thoughts?

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.

iojs-2.3.3 is available now with high security bug fix, https://medium.com/@iojs/important-security-upgrades-for-node-js-and-io-js-8ac14ece5852