Alpine Dockerfile advantages of --no-cache vs. rm /var/cache/apk/*

Question

When creating Dockerfiles using an Alpine image, I have often seen the use of either

• apk add --no-cache, or
• apk add followed by an rm /var/cache/apk/* statement.

I am curious to know whether making use of the --no-cache flag eliminates the need to manually clear the package cache using rm /var/cache/apk/*. I would also like to know which style is considered best practice.

Bibi

My understanding is that, the --no-cache is there so you don't have to do rm /var/cache/apk/* later on – Open

As an update, using Buildkit you can now let your APK, etc. caches run wild without needing to repeat downloads or increasing your image size by mounting those caches to your host with RUN --mount=type=cache.... apt example here – Stridulous

Any newcomers to this thread should look at @esmail's comment, it really lets you eat the cake and have it too. The docs have also been updated to include info on the subject: docs.docker.com/build/building/cache/… – Gomar

Answer 1

The --no-cache option allows to not cache the index locally, which is useful for keeping containers small.

Literally it equals apk update in the beginning and rm -rf /var/cache/apk/* in the end.

Some example where we use --no-cache option:

$ docker run -ti alpine:3.7
/ # apk add nginx
WARNING: Ignoring APKINDEX.70c88391.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.5022a8a2.tar.gz: No such file or directory
ERROR: unsatisfiable constraints:
  nginx (missing):
    required by: world[nginx]
/ # 
/ # apk add --no-cache nginx
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
(1/2) Installing pcre (8.41-r1)
(2/2) Installing nginx (1.12.2-r3)
Executing nginx-1.12.2-r3.pre-install
Executing busybox-1.27.2-r7.trigger
OK: 6 MiB in 13 packages
/ # 
/ # ls -la /var/cache/apk/
total 8
drwxr-xr-x    2 root     root          4096 Jan  9 19:37 .
drwxr-xr-x    5 root     root          4096 Mar  5 20:29 ..

Another example where we don't use --no-cache option:

$ docker run -ti alpine:3.7
/ # apk add nginx
WARNING: Ignoring APKINDEX.70c88391.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.5022a8a2.tar.gz: No such file or directory
ERROR: unsatisfiable constraints:
  nginx (missing):
    required by: world[nginx]
/ # 
/ # apk update
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
v3.7.0-107-g15dd6b8ab3 [http://dl-cdn.alpinelinux.org/alpine/v3.7/main]
v3.7.0-105-g4b8b158c40 [http://dl-cdn.alpinelinux.org/alpine/v3.7/community]
OK: 9048 distinct packages available
/ # 
/ # apk add nginx
(1/2) Installing pcre (8.41-r1)
(2/2) Installing nginx (1.12.2-r3)
Executing nginx-1.12.2-r3.pre-install
Executing busybox-1.27.2-r7.trigger
OK: 6 MiB in 13 packages
/ # 
/ # ls -la /var/cache/apk/
total 1204
drwxr-xr-x    2 root     root          4096 Mar  5 20:31 .
drwxr-xr-x    6 root     root          4096 Mar  5 20:31 ..
-rw-r--r--    1 root     root        451508 Mar  3 00:30 APKINDEX.5022a8a2.tar.gz
-rw-r--r--    1 root     root        768680 Mar  5 09:39 APKINDEX.70c88391.tar.gz
/ # 
/ # rm -vrf /var/cache/apk/*
removed '/var/cache/apk/APKINDEX.5022a8a2.tar.gz'
removed '/var/cache/apk/APKINDEX.70c88391.tar.gz'

As you can see both cases are valid. As for me, using --no-cache option is more elegant.

Peacemaker

I agree that --no-cache is more elegant. But with multiple apk add --no-cache commands, the index files get downloaded every time. In this case it's less network chatter to do apk update at the top, then rm -rf /var/cache/apk/* near the bottom. This really matters when some packages are added with --virtual and some are not. – Liscomb

@Liscomb Couldn't you just consolidate multiple apk add commands into one command? – Carafe

@PaulCalabro Our Dockerfiles at my job always use a single apk add. But the --virtual option is kind of neat, and it really shines with multiple apk add calls. However in the long run, we'd probably move to multistage Dockerfiles before --virtual would really benefit us. – Liscomb

what's the equivalent of --no-cache if I am using apt-get on a debian image? – Darmit

The major catch with @Liscomb suggestion is that rm -rf ... DOES NOT reduce your image size when executed as a separate Dockerfile RUN statements. You MUST executed it in the same run statement or the cache will be buried in an image layer despite not being available to access in the final image. – Usually

Yep it's true, the usual layer size optimizations always apply: always remove as much as you can from each layer within each set of RUN commands. – Liscomb

Answer 2

I think this is a design style. The essence of cache is to reuse, for example, multiple containers can mount the same cached file system without repeatedly downloading it from the network.

Can view the Alpine wiki: https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Local_Cache

Hut

apk manifests are so efficient, I'd argue the effort to share a cache is not worth it, especially because you'd have to update the cache every time to get most recent versions anyway. May as well just not cache at all in docker – Roulers

if you are using docker, better to use no-cache option in every apk add and not at the end, better if you have a single to install all you need to avoid create docker layers – Thirst