Alpine Dockerfile Advantages of --no-cache Vs. rm /var/cache/apk/*

Question

When creating Dockerfiles using the Alpine image, I have often seen the use of the apk --no-cache and other times it is committed and instead I see rm /var/cache/apk/*.

I am curious to know making use of the --no-cache eliminates the need to later do a rm /var/cache/apk/*. I would also like to know if one style is favored over another.

Solution 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.

Solution 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 apline wiki: https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Local_Cache

Comments

[Javier Buzzi]

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

[esmail]

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

[erik258]

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

[lilole]

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.

[c4f4t0r]

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

[Paul Calabro]

@lilole Couldn't you just consolidate multiple apk add commands into one command?

[lilole]

@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.

[Vikas Prasad]

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

[Philip Couling]

The major catch with @lilole 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.

[lilole]

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.