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:
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?
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?
mount -a [-t type] [-O optlist] (usually given in a bootscript) causes all filesystems mentioned in fstab (of the…linux.die.net
It’s that simple! Try it for yourself :)