Changed rabbitmq user/group to be non-system

[oskapt]

I'm doing development using Vagrant, and I have /workspace mounted from my local machine (OSX). Regardless of local ownership, this directory shows up owned by vagrant:vagrant inside of the VM. Commands like chown don't change this, so if I share this directory into the rabbitmq container for persistence, it shows up owned by UID 1000. The result is that rabbitmq can't create mnesia or 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 -r parameter, they'll be created as UID 1000, which maps to the vagrant user 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 -r parameters.

[jcross-linkup]

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.

[oskapt]

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.

[yosifkit]

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.

[tianon]

The change in #60 adjusted this such that if permissions on the filesystem are set correctly, running the container with --user 999:999 (or whatever other values are desirable) should work as-is. 👍

[oskapt]

Thanks. FWIW, using a data container did not solve the issue when running under Vagrant on OSX.