g5search/ruby-base
Docker base image for G5 Ruby applications.
50K+
The g5search/ruby-base
Docker image descends from the official Ruby image. The parent image uses debian, and we install a number of universal (or nearly so) libraries that child images probably need.
We maintain images for several versions of Ruby. Our versioning scheme is the Ruby major/minor/patch version, followed by a semantic version starting at 1.0.0 for each Ruby version (e.g. 2.7.x-v1.0.0
, 2.6.x-v1.0.3
).
Why not just tag your images with the Ruby version? Most of our Docker image releases just bump Ruby versions as they come out, but occasionally we tag releases that only update other software (SSL certificates, Postgres drivers). If we had a Docker image tagged
2.6.3
when Ruby 2.6.3 came out, but then wanted to release a new image with an upgraded version of Node, what would we tag it? It can't be2.6.4
, the Ruby version is still 2.6.3. Would we call it2.6.3.1
? That's not valid semver.2.6.3-v2
or something might work, but the Semver spec says anything after-
is for pre-release version, not a post-release version.
2.7.X-vX.X.X
Ruby 2.7 image series. Built from the ruby27.dockerfile
, releases triggered when a git tag is created with the 2.7.X-vX.X.X
naming convention.3.0.X-vX.X.X
Ruby 3.0 image series. Built from the ruby30.dockerfile
, releases triggered when a git tag is created with the 3.0.X-vX.X.X
naming convention.3.1.X-vX.X.X
Ruby 3.1 image series. Built from the ruby31.dockerfile
, releases triggered when a git tag is created with the 3.1.X-vX.X.X
naming convention.3.2.X-vX.X.X
Ruby 3.2 image series. Built from the ruby32.dockerfile
, releases triggered when a git tag is created with the 3.2.X-vX.X.X
naming convention.Retired images are still available for use, but we are no longer releasing new versions of the image when new Ruby versions are released. Upgrade to an actively maintained image variant.
2.3-vX.X.X
Ruby 2.3 image series. Retired 01/20232.4-vX.X.X
Ruby 2.4 image series. Retired 20182.5-vX.X.X
Ruby 2.5 image series. Retired 10/20192.6-vX.X.X
Ruby 2.6 image series. Retired 01/2023The Docker Hub builds images via automated builds, and respects Semantic Version (with our Ruby version prefix). As an example, you can create a 2.6.2-v2.0.0-beta.1
image if you want to create a beta base image to test upcoming changes.
Create a GitHub release with information about any changes you've made. The semver of the different tags are independent of each other and unrelated. If we have 2.6.2-v1.20.0
when Ruby 2.7 comes out, the first version of that new image should be 2.7.0-v1.0.0
. There is significant duplication between the Dockerfiles, so ensure you've considered all maintained versions when you make updates to any of the Dockerfiles.
You need:
Copy one of the existing files like ruby31.dockerfile to your new ruby version. In that file, update the FROM ruby:3.1.3
to whatever version you're upgrading to. At some point you might need to install system packages or make some other kind of changes to the dockerfile.
Rename the docker file you made to Dockerfile. You will rename it back when you're done.
Ugly Node
Right now the images are built with node 18 but our apps still need node 14 for some reason. I don't remember why. We need to follow up and strong arm some people off of it... I think part of it is the default rails pipeline and that when they bump to 7 it is easier. Like I said; can't remember why. In the meantime... you need to specify which node 14 version to install. There is a section in the dockerfile that looks like this:
# install node 14 and latest NPM
nodejs=14.21.3-deb-1nodesource1 && npm install -g npm@latest && \
After you run this, curl -sL https://deb.nodesource.com/setup_14.x | bash -
, you'll be able to see what the package name for node14 is by using apt policy nodejs
. I was building the docker image, docker run -it image_name bash
and then apt policy nodejs
to see what the 14.x version was.
Gemfury Token If your child image needs to install gems from Gemfury, you should provide it as a build argument. Unfortunately, these are not inherited from parent images and so cannot be specified there. Here's how to do it:
Do like so in the Dockerfile
:
ARG gemfury_token
RUN FURY_AUTH=$gemfury_token bundle install
If you're not sure what your gemfury token is you can probably find it with bundle config
. You'll need it for this part;
Make sure to change the version number in this docker build command. The --tag
should look something like g5search/ruby-base:2.7.0-v1.0.2
but with your ruby version. It is rubyVersion-g5Version
. Build the image:
docker build --tag g5search/ruby-base:#.# . --build-arg gemfury_token="yourtoken"
Add --platform linux/amd64
if you're on an ARM (M1)
Make sure you've docker login
'ed and then you will run something like this
docker push g5search/ruby-base:3.0.0-v1.0.0
docker pull g5search/ruby-base