Misc #17137

Cooperation on maintaining official docker ruby images

Added by deivid (David Rodríguez) about 2 months ago. Updated about 2 months ago.



It was pointed out to me at that the ruby-core team has started maintaining their own docker images at, and that the base Dockerfiles were initially started from the official docker images.

The maintainers of the official images would be interesting in collaborating on maintaining these images. Maybe merging the projects would be a nice idea from an end user point of view. I'm guessing there's a reason why was started as a separate project, but maybe any improvements over the official project could be merged back. The obvious new feature that I see in the README is the ability to build development images of specific revisions.

Anyways, I mentioned the approach of the docker folks to hsbt and he told me to open a ticket here. So here it is!


Updated by mrkn (Kenta Murata) about 2 months ago

There were three reasons why I started rubylang/ruby as separated from Docker's official ruby.

The first reason is that my personal reason. I needed a simplest pure ruby image. This image should be in the state after make install without any additional patches and there is no environment variables defined.

The second is I wanted to provide a nightly build image of the master branch. I assumed that the main use cases of this image is testing gems with the latest master branch.

The last reason is that I want to maintain the minimum number of images. So rubylang/ruby now provides only bionic-based images.

Moreover, I guess tfhe purposes of this and docker's images are different. Is Docker's image designed for the base image of Rails applications that run on a production environment? The images of rubylang/ruby aren't.

As you mentioned, indeed, I started rubylang/ruby with Dockerfile of Docker's image. But It doesn't mean I tried to follow Docker's image.

I don't know how can we cooperate. Any ideas?

Updated by deivid (David Rodríguez) about 2 months ago

I believe official images also want to be minimal and they are not explicitly designed for Rails. So in my opinion, many of the patches you have made to make your images thinner would probably be accepted upstream and benefit a larger user base. Regarding environment variables, they do set some environment variables to configure bundler & rubygems, I believe that is to fit better their "one container - one application" philosophy, but that configuration is really minimal too.

I don't think they want to have daily builds, but the images could still be unified and support building from trunk through environment variables or something, so that you can keep your nightly builds.

That's how I think you could collaborate and maybe eventually merge the projects, but I don't speak for the maintainers of the official images, so maybe my comments above are not 100% accurate.

Also available in: Atom PDF