Improve documentation on non-root container usage #194
Conversation
|
|
||
| Sometimes, even with inside-the-docker routing, it makes sense to disable the docker provider and setup rules with either static or file provider. All the containers running within a compose sharing the same network and accessible via local DNS. User can have a rule like this to avoid docker discovery: `- STATIC_RULES=*,/api/email/(.*),http://email-sender:8080/$$1`. This rule expects `email-sender` container defined inside the same compose. Please note: users can achieve the same result by using the docker network even if the destination service was defined in a different compose file. This way reproxy configuration can stay separate from the actual services. | ||
|
|
||
| There is nothing except reproxy binary inside the reproxy container, as it builds on top of an empty (scratch) image. | ||
|
|
||
| ### How to set up non-root user with docker access and use it with reproxy container |
There was a problem hiding this comment.
I think this is too much instruction for the task, which is not really related to the Reproxy itself but rather to the general question "how do I map host uid/gid to container". It is also not a universal recipe, as it won't work on some flavors of Linux (Alpine, for example) and it's not sure if it will work on macOS.
In addition, I think this is not the only way to run the Reproxy container under a non-root account. It is possible to map the uid/gid from any existing user to app inside the container.
My suggestion is to leave only the part describing what user already exists in the container and add a general statement like "you may need to set up uid/gid mapping at the Docker level and ensure the user has permission to access the Docker socket, in case the Docker provider is used". A link to the Docker documentation explaining uid mapping would also be helpful.
There was a problem hiding this comment.
For a better suggestion, extend that section with an explanation on how to map the existing UID/GID without adding a new user to the host machine. One of our other projects may have a similar solution already, though I can't recall which one. Additionally, the details after the basic information on existing UID/GID should be collapsed by default, as users who need this information likely already know how to achieve the mapping, while the rest of the users may not understand the purpose of these details.
Also, switch the base image to the latest, as there is no point in pinpointing it, and remove the unused, deprecated golangci.yml setting.