Introducing changes in tags in nginx official docker images

[thresheek]

latest: based on debian 8 jessie with a current build from mainline
branch (stays the same as it was)

stable: based on debian 8 jessie with a current build from stable branch

mainline-$distro: based on $distro with a current build from mainline
branch

stable-$distro: based on $distro with a current build from stable branch

$distro: based on $distro with a current build from mainline branch

Obviously this scheme promotes usage of mainline branch and Debian 8,
but the user can choose the preferred distro and use stable version if
preferred.

The list of supported distros for now is:

• Alpine
• CentOS 5
• CentOS 6
• CentOS 7
• Debian 7 "Wheezy"
• Debian 8 "Jessie"
• Ubuntu 12.04 "Precise"
• Ubuntu 14.04 "Trusty"

The plan is to add Debian and Ubuntu LTS releases as they are
introduced.

[tianon]

While I can appreciate where this is coming from, I'm definitely concerned about the maintenance burden this might have, and wonder whether the benefits it potentially brings to users don't justify it (since in deployments I've seen, changing the base doesn't really change much in a Docker environment given that we only run the NGINX binary and don't deal with much of the rest of the distro underneath). Do you have some thoughts on that front?

I can definitely see benefits to giving users a choice between a "standard" and a "minimal" version (ie Debian vs Alpine), as well as "stable" vs "mainline", but I don't quite grok exactly what's gained by having so much choice in the exact base. Won't most folks be connecting this container to other containers, not necessarily using this one as a base?

I went through the first 10 pages of https://github.com/search?l=dockerfile&q=%22FROM+nginx%22&type=Code and couldn't find any solid examples of anyone doing much more than adding modified configuration and/or copying in static files to serve up. 😕

[ujovlado]

Hi guys, I think it's a good idea to have choice. For example I'm a big fan of Alpine variant, because of its size, which is about 10MB (comparing to ~130MB). And it speeds up deployments.

IMHO there will be much more usages of smaller containers. Currently there's not, because those smaller containers aren't available and everybody is creating own images (me too). Search https://hub.docker.com/search/?isAutomated=0&isOfficial=0&page=1&pullCount=0&q=nginx+http2&starCount=0 or similar.

Also, I'm seeing same problem as @tianon (with maintenance) and maybe separate repositories can solve this (but I don't know how to achieve it - since nginx is available in "global" namespace).

Thx.

[thresheek]

Sorry for not replying earlier.

@tianon, what kind of maintenance are you worried about? It does not seem like a big deal nor very time consuming to update the hashes once in a while on our side.

I've actually went a bit of berserk adding all the supported packages we currently build on our infrastructure, I admit that. From our experience, our centos packages are really popular, so I thought it would be a good idea to promote them here as well. I can easily imagine some corporate policies requiring an employee to use only approved distributions, be it physical machines, VMs or containers.

I can remove, say, centos5, wheezy and precise from the images with no hard feelings about them - after all, encouraging people to build the new infrastructure on those distributions in 2016 is.. well.. weird.

Let me know what you think, thanks!

[wernight]

TL;DR I'd welcome a really small (Alpine?) base image additional to the current one; the rest feels like not necessary (Ubuntu, CentOS, or other releases of Debian).

I feel it's also a bit too much choice. The current relatively small Debian base is pretty good as most people can extend it and it provides a good "latest" Nginx.

Having a smaller alternative would however be very welcome. Alpine makes the base image a lot smaller (130 to 7 MB normally). This is a huge gain and very good for things like Kubernetes where you'd like to pull images fast if possible. It cannot easily replace the default Debian base because Alpine is so trimmed that many things don't run properly by default on it (including Kubernetes for example).

For that reason I wonder if a small Nginx based on Busybox wouldn't be actually better. Why? First because Alpine does not run on Kubernetes properly without tweaks, and second because having a small image like on Busybox with a recent Nginx isn't trivial. That said, Alpine is still a very welcome option and it may be that Kubernetes learns to live with it one day.

[justincormack]

This seems like a huge burden of monitoring security updates and so on, when pretty much no one adds packages on top of nginx, especially as you have to statically link extensions. Alpine and Debian jessie seems to be sufficient.

@wernight search domains work now in alpine:edge, there may still be some issues but they are being resolved.

[thaJeztah]

Not really sold on adding all different kind of distros; in general we try to teach people to worry about the service in a container, not the distro it's based on. Having a minimal (alpine) image sounds like a nice addition to me

[wernight]

@justincormack Thanks for the tip. I tried again on alpine:edge but it seems the issue remains: Deploying the image on a Kubernetes cluster, it cannot resolve DNS correctly. I'm quite excited about having more stuff work on Alpine though.

[thresheek]

@justincormack what kind of security updates are you worried about? For all those distros (except alpine) we at NGINX provide builds on our own, so this one is irrelevant here as we're already in charge for fixing security problems in our packages / nginx image. For the distros themselves, they seem to be officially supported, too, so the work is already done as well.

It's about choice, really.

Really, deciding for users on what distro they would use seems like a bad idea to me, and if we can quite easily allow them to use whatever they're comfortable with (let's face it - there are differences between distributions and approaches in e.g. debugging what's going on in your container can be quite different), we should do that.

[wernight]

@thresheek Issues like bcrypt look more like people that really want a custom Nginx and not just a simple running Nginx service with good defaults, and for that the solution is always to fork and build yourself. So why not give too many choices? Because too many choices kill choices. It's not just harder for you to maintain but for users as well. It becomes too tiresome and difficult the choose: Why latest CentOS vs latest Debian or just latest on Alpine? IMO having a Debian base image is like a sugar candy once a good small base image is there. Once it's tested and working pretty much everywhere (I'm looking at Kubernetes here) I'd even suggest to make it the default :latest.

[thresheek]

I've just updated the official images repo and the pull request based on the discussion here. Please check! :)

[yosifkit]

Changeset: nginxinc/docker-nginx@e82e776...f48d943

LGTM, Build test of #1462; a1cbdaa (nginx):

$ bashbrew build "nginx"
Cloning nginx (git://github.com/nginxinc/docker-nginx) ...
Processing nginx:latest ...
Processing nginx:1 ...
Processing nginx:1.9 ...
Processing nginx:1.9.12 ...
Processing nginx:stable ...
Processing nginx:1.8 ...
Processing nginx:1.8.1 ...
Processing nginx:stable-alpine ...
Processing nginx:mainline-alpine ...
Processing nginx:alpine ...
$ bashbrew list --uniq "$url" | xargs test/run.sh
testing nginx:latest
    'utc' [1/4]...passed
    'cve-2014--shellshock' [2/4]...passed
    'no-hard-coded-passwords' [3/4]...passed
    'override-cmd' [4/4]...passed
testing nginx:stable
    'utc' [1/4]...passed
    'cve-2014--shellshock' [2/4]...passed
    'no-hard-coded-passwords' [3/4]...passed
    'override-cmd' [4/4]...passed
testing nginx:stable-alpine
    'utc' [1/4]...passed
    'cve-2014--shellshock' [2/4]...passed
    'no-hard-coded-passwords' [3/4]...passed
    'override-cmd' [4/4]...passed
testing nginx:mainline-alpine
    'utc' [1/4]...passed
    'cve-2014--shellshock' [2/4]...passed
    'no-hard-coded-passwords' [3/4]...passed
    'override-cmd' [4/4]...passed

[tianon]

LGTM

[sherter]

Great to see an alpine variant for this image. What I don't like is the mainline/stable tag approach. In order to get reproducible results I need to have specific, immutable version tags. Would you consider using the same versioning scheme for the alpine image as in the debian based image (alpine, 1-alpine, 1.9-alpine, 1.9.12-alpine)?

[thresheek]

@sherter fair enough. Will introduce that with 1.9.13.

[wernight]

@justincormack alpine:edge works on Kubernetes 1.2+, however the current Nginx Alpine variants use alpine:3.3 which does not work on Kubernetes. Might be worth using alpine:edge for the mainline-alpine version or an alpine-edge version.