`docker-compose.yml` for `postgresql` specifies a local volume that ends up being owned by `root` on the host about dockerfile-rails HOT 11 OPEN

When I run demo 3 from https://github.com/rubys/dockerfile-rails/blob/main/DEMO.md on a Mac, I'm not seeing that. I'm only seeing files owned by me. Can you try that demo?

% ls -ld tmp/db
drwx------@ 26 rubys  staff  832 Apr  8 07:09 tmp/db

from dockerfile-rails.

Running that demo on Ubuntu 20.04 via WSLv2 + Docker for Windows gives me a folder owned by root:

demo on  main [?] via 💎 v3.1.2
❯ ll tmp
total 28
drwxr-xr-x  6 gareth gareth 4096 Apr  9 05:33 ./
drwxr-xr-x 14 gareth gareth 4096 Apr  9 05:32 ../
-rw-r--r--  1 gareth gareth    0 Apr  9 05:31 .keep
drwxr-xr-x  4 gareth gareth 4096 Apr  9 05:32 cache/
drwx------ 19    999 root   4096 Apr  9 05:34 db/
-rw-r--r--  1 gareth gareth  128 Apr  9 05:32 development_secret.txt
drwxr-xr-x  2 gareth gareth 4096 Apr  9 05:31 pids/
drwxr-xr-x  2 gareth gareth 4096 Apr  9 05:31 storage/

Versions:

from dockerfile-rails.

I've reproduced the problem. this post suggests a workaround. I'm traveling this week so it may be a few days before I am able to fully test a few.

from dockerfile-rails.

dockremap also looks promising

from dockerfile-rails.

hmm both of those sound like they could be pretty finicky, though probably worth at least documenting for advanced users.

I'm not sure if we need a local named volume (that's probably the wrong name) for db containers at least though?

On other projects I think I've not had this problem because we're doing something like:

services:
    mysql:
        image: 'mariadb:10.4'
        ports:
            - '3306:3306'
        environment:
            MYSQL_ROOT_PASSWORD: drupal
            MYSQL_DATABASE: drupal
        volumes:
            - 'mysql_data:/var/lib/mysql'
            - "./data/:/docker-entrypoint-initdb.d/"
volumes:
    mysql_data:

I wouldn't be surprised if the actual directories on disk is still owned by root, but it's out of sight in a way that doesn't (seem) to impact our builds.

I also find it interesting that building with docker compose doesn't have this issue.

from dockerfile-rails.

If volumes are better, then I'm fine with switching to volumes. If the answer is "it depends", I'm fine with it being an option.

It seems to me that with volumes, either a name prefix or a mapping would make sense to avoid to separate applications from attempting to use the same volume?

from dockerfile-rails.

I think named volumes are what I've experienced more often, and I guess unless/until someone else gives some counter points it's probably best to just go with them for now 🤔

to avoid to separate applications from attempting to use the same volume

I don't think that's the problem here - that is something that stuck out to me in the links you gave: they seem to be about applications sharing volumes which I don't think is the case here, but I think the underlying problem is about the same - because the volume data is being owned by root on the host, anything trying to access that data who isn't root gets an error so it impacts both when you try to build an image and when you try to share a volume with two applications.

from dockerfile-rails.

I don't think that's the problem here

My apologies. I was unclear. What happens if you generate a docker compose file for one app, and later generate a docker compose file for a separate app. Will they interfere with each other if they both use the same type of database?

from dockerfile-rails.

Assuming you don't mean in the same app directory / docker-compose.yml file, no there isn't any issue - my understanding is that is what docker compose is managing for you (i.e. most stuff ends up being namespaced with the service name) so you should be safe to assume there won't be any issues unless you start referencing paths outside of the root directory the docker-compose file is in (and in the case of named volumes where you don't set a path, it's handled by docker compose)

from dockerfile-rails.

Would you consider making a pull request?

The tmplate can be found here: https://github.com/rubys/dockerfile-rails/blob/main/lib/generators/templates/docker-compose.yml.erb

Running rake test:capture will update the expected test results to match your changes. Run git diff to visual inspect the changes.

Commit and push the changed templates and test results together.

from dockerfile-rails.

Yup, I'll do that when I next have some free time :)

(I've got a few other things I'll probably open issues and PRs for, but am waiting until I've properly finished things off so I can be sure what I'm saying is right etc)

from dockerfile-rails.