Rethinkdb 2.3.6 Alpine version

[xemuliam]

Alpine-linux based Docker image for RethinkDb 2.3.6

Latest Alpine linux image + native Alpine package for RethinkDb.
jq package is also added to be able to easily work with JSON data on RethinkDB host if required.
All settings are completely similar to original Debian-based image, however Alpine-based final image size is 3+ times less than original.

[stuartpb]

Looks good enough to me. Covers most of my thoughts from #40 (I added a commit to tag the Alpine release), and while I'm generally no fan of adding foreign-tree dependencies to official images, jq is a small/lightweight enough utility to make sense as a core component of the image to me (it's the cleanest way to allow for scrips to do stuff like push changes to the config table without having to make any package changes).

If there are no objections from the relevant parties (cc @tianon, @yosifkit, anybody else who's currently wrangling best practices for Docker, and the new RethinkDB maintainers pinged below), I think I'll probably merge it some time in mid-October (I'm technically on vacation for the next week and a half).

That said, since this would be a (moderate) functional change to the image, I'm not sure I'd want to push it to the official repositories until I've had a look at introducing the other outstanding changes proposed to coincide with any such breaking change in #44, namely running as a non-root user (#39) and dropping the VOLUME directive (#14).

RebirthDB folks (ping @srh @grandquista @atris @floydkots @gabor-boros and anybody I might have missed): are you planning on cutting a new release of RethinkDB in the next couple months (as rethinkdb/rethinkdb#27 notes, there aren't currently any published/standing milestones)? If Alpine is due to have a RethinkDB 2.4 (or, ideally, 3.0, as it looks like the coming changes in the next branch switched the underlying JS engine, which would constitute a potentially-breaking change by my fastidious standards) packaged some time before 2019, I'm thinking we can merge this now and push it as an alternative tag (like rethinkdb:2.3-alpine), then migrate future tags (2.4/3.0 onward) to Alpine with the aforementioned rootless+volumeless behavior changes.

[daveisfera]

I would argue that it's become somewhat of a standard and is definitely a best practice for the official images to be built from source and not just installing a build from another repo. This gives complete control over what's in the Dockerfile and means that version upgrades are simply changing a value in the Dockerfile rather than having to make sure that that external repo has been updated and then updating the Dockerfile.
Since there's already a version of a Dockerfile that does this, I would argue that it should be the preferred method:
#32 (comment)

[tianon]

From a WIP "official images" FAQ:

Why do so many official images build from source?

The tendancy for many official images to build from source is a direct result of trying to closely follow each upstream's official recommendations for how to deploy and consume their product/project.

For example, the PostgreSQL project publishes (and recommends the use of) their own official .deb packages, so the postgres image builds directly from those (from http://apt.postgresql.org/).

On the flip side, the PHP project will only officially support users who are using the latest release (https://bugs.php.net/, "Make sure you are using the latest stable version or a build from Git"), which the distributions do not provide. Additionally, their "installation" documentation describes building from source as the officially supported method of consuming PHP.

One common result of this is that Alpine-based images are almost always required to build from source because it is somewhat rare for an upstream to provide "official" binaries, but when they do they're almost always in the form of something linked against glibc and as such it is very rare for Alpine-compatible binaries to be published (hence most Alpine images building from source).

So to summarize, there isn't an "official images" policy one way or the other regarding building from source; we leave it up to each image maintainer to make the appropriate judgement on what's going to be the best representation / most supported solution for the upstream project they're representing.

[tianon]

My own concern with this PR is that the package being installed is not provided by the project, so updates to it are somewhat outside the project's control.

[xemuliam]

My own concern with this PR is that the package being installed is not provided by the project, so updates to it are somewhat outside the project's control.

Which one package did you mean?

[yosifkit]

@xemuliam, what @tianon is saying is that the RethinkDB package is pulled from Alpine Linux packaging and so any version bumps or other updates will have to go through Alpine's packaging process. This usually means it will have to wait for up to 6 months for the next OS release. This isn't great when trying to closely represent upstream (RethinkDB org) and stay as close to their supported releases as possible.

See openjdk for an example where we rely on Alpine and Debian packages and are thus almost always behind the bleeding edge releases: docker-library/openjdk#150 (comment) (we rely on the packages because of the jdk build complexity as outlined in the linked comment).

[xemuliam]

@yosifkit thanks for clarification.
However why we can't have at least two images: stable one (based on packages) and bleeding edge one (based on latest build from scratch)?
Alpine has musl instead of glibc thus not all "common" linux packages works fine.
But we can use glibc library from third parties to build Rethink if required.
Is this approach good for you?

[daveisfera]

Supporting two separate types of build adds complexity and work for the maintainers. It also means that stable releases (which most people will be using) will have a delay when point releases happen and then the availability of the stable versions is tied to the release schedule of Alpine (as yosifkit pointed out).
Basically, if you have builds from scratch working and don't have "official repos" that can be updated outside of release schedule of an OS, then just doing everything from scratch is the simplest way to go.
Also, I personal feel that installing packages was preferred in the past because multi-stage builds weren't supported and it resulted in smaller images, but now that multi-stage builds can be used, small images can be built from scratch, so I think it should be more strongly considered because of the flexibility and control that it provides.

[yosifkit]

Quick note that official images builds do not support multi-stage builds: docker-library/official-images#3383.

[davidwincent]

When can we expext a new official docker image for rethinkdb?

[stuartpb]

Not until I can get a satisfactory answer for all the concerns raised in #44.

[stuartpb]

Also, this isn't strictly a blocker, but there isn't much motivation for anybody to put together a new release image when there hasn't been a new release of RethinkDB for almost two years.

[stuartpb]

Closing this PR, too - we need a version that does its own build instead of depending on Alpine's packaging. See #44 (comment).

[stuartpb]

Reopening per #44 (comment)