Changed rabbitmq user/group to be non-system#40
Changed rabbitmq user/group to be non-system#40oskapt wants to merge 1 commit intodocker-library:masterfrom
Conversation
…rks with Vagrant.
|
Have you considered using a data container (mounting volumes from another container that isn't running) instead? That should prevent any UID/GID collisions with your host and provide you with persistence. That's how we handle docker + vagrant integration on my team. |
|
In production we generally do use a data container, but this alone doesn't guarantee persistence. It only provides the convenience of having everything in one place. I don't have this in development because "persistence" is derived from having my development folder mapped through from my Mac to /workspace. I don't know if a data container will solve this, since the problem still relates to file ownership by vagrant and the inability to chown. Feel free to not merge the PR if you wish. |
|
This would work and solve it for most Mac users, but could break users that are relying on the specific UID/GID of 999. I would rather give the users the ability to choose what user and group to run the process as, so that even if they are a different UID it will work for them too. |
|
The change in #60 adjusted this such that if permissions on the filesystem are set correctly, running the container with |
|
Thanks. FWIW, using a data container did not solve the issue when running under Vagrant on OSX. |
4 participants
I'm doing development using Vagrant, and I have
/workspacemounted from my local machine (OSX). Regardless of local ownership, this directory shows up owned byvagrant:vagrantinside of the VM. Commands likechowndon't change this, so if I share this directory into therabbitmqcontainer for persistence, it shows up owned by UID 1000. The result is thatrabbitmqcan't createmnesiaor any data within that directory.The cause is that the user and group are created as system objects, with UID/GID 999. If we remove the
-rparameter, they'll be created as UID 1000, which maps to thevagrantuser within the VM and allows for the content creation.The use of system users is good in theory but may not be absolutely necessary. In this case I've identified a situation where that parameter breaks the container's usability, so I'm providing a pull request that removes the
-rparameters.