Should to avoid to use public docker image on productions straightly

Oct 17, 2020 · 2 min read · alpine docker docker-compose dockerfile golang kubernetes nginx  ·
Share on:

There are a lot of samples of Kubernetes and Docker Compose which define public images like nginx:alpine, golang php-fpm and so on. However even though it’s easy to use, it’s not good for production environments because there's a possibility that they are not up-to-date.

For example, I’m trying with one of the famous official docker images "nginx:alpine" which is a lightweight NGINX image. I ran the image and executed the "apk upgrade" command, there were 10 packages that should be updated.

 1$ docker run -it --rm nginx:alpine sh -c "apk upgrade --update --no-cache"
 2
 3fetch https://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
 4fetch https://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
 5(1/10) Upgrading musl (1.1.24-r8 -> 1.1.24-r9)
 6(2/10) Upgrading busybox (1.31.1-r16 -> 1.31.1-r19)
 7Executing busybox-1.31.1-r19.post-upgrade
 8(3/10) Upgrading alpine-baselayout (3.2.0-r6 -> 3.2.0-r7)
 9Executing alpine-baselayout-3.2.0-r7.pre-upgrade
10Executing alpine-baselayout-3.2.0-r7.post-upgrade
11(4/10) Upgrading ca-certificates-bundle (20191127-r2 -> 20191127-r4)
12(5/10) Upgrading ssl_client (1.31.1-r16 -> 1.31.1-r19)
13(6/10) Upgrading libcurl (7.69.1-r0 -> 7.69.1-r1)
14(7/10) Upgrading curl (7.69.1-r0 -> 7.69.1-r1)
15(8/10) Upgrading musl-utils (1.1.24-r8 -> 1.1.24-r9)
16(9/10) Upgrading brotli-libs (1.0.7-r5 -> 1.0.9-r1)
17(10/10) Upgrading libxml2 (2.9.10-r4 -> 2.9.10-r5)
18Executing busybox-1.31.1-r19.trigger
19Executing ca-certificates-20191127-r4.trigger
20OK: 24 MiB in 42 packages

So, even though it’s unnecessary to add any packages and copy files, I usually create a Dockerfile like this.

1FROM nginx:alpine
2RUN apk upgrade --update --no-cache

And then, build and register it to my private image registry and all pods use this.

On the other hand, I don’t use the "latest" tag because of the following reasons.

  • It will be updated unexpectedly
  • It’s hard to decide which version which I have to roll back when some troubles happen

There’s one more thing which I usually pay attention to is the variations of base distribution. For example, the default base image of the Golang official image is Debian and also there are tags which are based on Alpine Linux. When using the Alpine based images, should to pay attention to tags because there are tags which Alpine’s version is included and not included one as follows.

  • NOT Included：1.14.10-alpine, 1.14-alpine
  • Included：1.14.10-alpine3.11, 1.14-alpine3.11, 1.14.10-alpine3.12, 1.14-alpine3.12

In this case, should use the included one because if it’s not, one day the base image will be updated unexpectedly and it will be cause of build failure or execution failure of applications.