Avoiding Docker Compose Entry-point's with Volume Driver Options

I’ve done this a hundred times myself, as I thought it was the simplest way to solve my problem; that problem is fixing the permissions of my Docker volumes for cache and logs.

This looks awesome, right? We’ve taken those pesky cache and logs and we’re storing in some ephemeral volume that, for all we care, is provided by mystical unicorns in space.

Until … we run a docker-compose up and we see this:

Unable to write to logs directory

The problem? Our volumes for our cache and logs are owned by root. D’oh!

This typically leads to people, and I include myself, writing an entry-point like this:

It’s so useless, but it works. Surely there’s a better way?

Digging into Docker Volumes

Every time we specify a Docker Volume, we provide a driver. In this case, we’re just using a local driver. It’s development; it makes sense!

The local driver allows us to provide some options, primarily: where do we store this volume and who owns it?

Our fpm container is running as user www-data, which is uid 33. Better yet, we’re keeping our logs and cache in a ram disk (tmpfs), saving some pesky I/O operations. Probably not that useful here, but I’m just showing the options you have to play with :)

If this looks familiar, that’s because it is! Ever used the mount command?

It’s that simple! Try it for yourself :)

Like what you read? Give David McKay a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.