Use anonymous volume for build cache instead of requiring projects to volume mount

[grayside]

Many tools use ~/.cache for caching, and many other tools can be configured to do so. Should we automatically support persisting build caches by making this an anonymous volume?

[grayside]

In addition to #32, we would want to move npm and composer:

ENV NPM_CONFIG_CACHE /root/.cache/npm
ENV COMPOSER_CACHE_DIR: /root/.cache/composer

[tekante]

Do you see this as being a project specific or global volume that is used? Also, what is your proposed mechanism for automatically mounting it and having it persist between runs? I did some testing with the VOLUME directive in a Dockerfile and while it seems to create the volume doesn't persist between container invocations (at least when I tried using what I think is our typical use case of using the run command).

[febbraro]

@cj does it persist if you remove --rm in your run command?

[febbraro]

According to this, https://docs.docker.com/engine/reference/run/#clean-up-rm, anon volumes are removed if you use --rm

[grayside]

Our current handling of this by project per host. The idea there is so any cache issues in one project do not poison other projects. For a global cache solution something like a Squid-based reverse proxy would make more sense.

We could also try the approach of a named volume, but that doesn't address #32 and would require more named volume wrangling a la unison.

[tekante]

I couldn't get it (an anonymous volume) to persist given any combination of up/run and --rm or not so I'm not sure what the magic is to get it to stick around when using docker-compose.

[febbraro]

@tekante you'd need to add a VOLUMES section in the Dockerfile, then it will persist as long as --rm is not specified. If I am understanding it all correctly.

[tekante]

That's what I tried but it doesn't seem to work.

Dockerfile used with docker build -t anonvolume

FROM phase2/servicebaselight

VOLUME /root/.cache

ENTRYPOINT ["/init"]

docker-compose.yml

version: '3.2'
services:
  cli:
    container_name: cjanon
    image: anonvolume
    command: /bin/sh

I then try docker-compose run cli and create a test file: /root/.cache/test.txt. Exit the container and then see if it's still around on the next docker-compose run cli and it isn't.

[grayside]

When I connect your findings to my readings on anonymous volumes, it finally clicked: anonymous volumes are for forensic inspection of container data after crashes or shutdowns. When you restart the container, it makes sense that it would wipe the volume, or generate a new volume ID.

Between this behavior and how we would support cache persistence in a cluster environment, it seems clear that we need to go with a more explicitly defined volume -- effectively we need to replace all /data/... volume mounts in our docker-compose config with something else.

After playing a little bit with how rig wrangles unison for projects, I don't like the idea of adding more containers external to the docker-compose. So it seems that the main idea here (automatic build cache persistence) is a no-go.