Is it necessary to RUN apk update && apk upgrade in a docker build stage?

Question

I'm creating a multi stage build docker file. In the deployment step that will actually run the program i'm running

RUN apk update && apk upgrade --no-cache

Should I also have this statement in my build stage?

Answer 1

First of all: the command you propose is not efficient because the --no-cache option affects the 2nd apk only.

Demonstration

/ # ls -la /var/cache/apk/
total 0
drwxr-xr-x    2 root     root             6 Mar 29 14:27 .
drwxr-xr-x    4 root     root            29 Mar 29 14:27 ..

/ # apk update && apk upgrade --no-cache
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/x86_64/APKINDEX.tar.gz
v3.16.5-131-g8a958b888f7 [https://dl-cdn.alpinelinux.org/alpine/v3.16/main]
v3.16.5-127-g643d8ee0752 [https://dl-cdn.alpinelinux.org/alpine/v3.16/community]
OK: 17042 distinct packages available
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/x86_64/APKINDEX.tar.gz
(1/5) Upgrading musl (1.2.3-r2 -> 1.2.3-r3)
(2/5) Upgrading ca-certificates-bundle (20220614-r0 -> 20230506-r0)
(3/5) Upgrading libcrypto1.1 (1.1.1t-r2 -> 1.1.1u-r1)
(4/5) Upgrading libssl1.1 (1.1.1t-r2 -> 1.1.1u-r1)
(5/5) Upgrading musl-utils (1.2.3-r2 -> 1.2.3-r3)
Executing busybox-1.35.0-r17.trigger
OK: 6 MiB in 14 packages

/ # ls -la /var/cache/apk/
total 2416
drwxr-xr-x    1 root     root            70 Jun  9 12:51 .
drwxr-xr-x    1 root     root            29 Mar 29 14:27 ..
-rw-r--r--    1 root     root        657130 Jun  9 12:51 APKINDEX.77a9a2bb.tar.gz
-rw-r--r--    1 root     root       1810672 Jun  9 12:51 APKINDEX.af244049.tar.gz

As you can see, the apk cache is not empty after the execution of your command.

The correct command is

RUN apk upgrade --no-cache

because --no-cache

allows users to install packages with an index that is updated and used on-the-fly and not cached locally

as explained at https://github.com/gliderlabs/docker-alpine/blob/master/docs/usage.md

Now, to answer your question, upgrading the image used for the build is not particularly useful. Upgrading the deployment base image makes much more sense, however I upgrade it only if trivy says that it has some CVE and Docker Hub hasn't a newer version of that base image. In this case I create an upgraded base image and reuse it for all my apps (you could also use it for build stages).

For example, at today's date, trivy says that the latest builds of Alpine Linux 3.16, 3.17 and 3.18 have some CVE that has been already fixed but the fixes are not part of an official Alpine release yet. So I have just created my own Alpine with this Dockerfile:

FROM alpine:3.16 as alpine-upgraded

RUN apk upgrade --no-cache

# Main image
FROM scratch

COPY --from=alpine-upgraded / /
CMD ["/bin/sh"]

Trivy says it is vulnerability-free and docker images says that the new image has the same size of the original (not upgraded) one: 5.54 MB.

See also the description of this Docker image.