You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several of the containers used to spin up an Alfresco install have different UID and GID from each other. It is a best practice for all containers in a stack to run with a non-root uid/gid that is consistent across containers.
It is very challenging to do re-mapping if different containers in the stack use different UID/GID.
I considered taking making a derivative container that updates the UID/GID. Unfortunately the VOLUME directive freezes part of the filesystem and it is impossible to re-id.
There is a hacky tool that can remove the VOLUME metadata so we can re-id, but that feels dangerous.
Our current approach is to re-build the containers starting from the published Dockerfiles, this is also not idea as our customer has a best practice of starting from vendor published images (I guess in a way we are because the base image is vendor supplied, but still this is yuck.)
I would suggest that all Alfresco containers use consistent UID/GID and probably that they don't us VOLUME if at all possible.
I spoke with Angel on Discord and he asked me to post this issue so he can think about this upon his return from vacation.
The text was updated successfully, but these errors were encountered:
I thought there was a limit for UID/GID to 65536. It appears that with re-mapping we can map above that... It would still be beneficial for the Alfresco containers to have consistent effective UID/GID.
Several of the containers used to spin up an Alfresco install have different UID and GID from each other. It is a best practice for all containers in a stack to run with a non-root uid/gid that is consistent across containers.
One reference: https://github.com/hexops/dockerfile#use-a-static-uid-and-gid
At my customer we actually have users/groups in the 33007 range so we will have to do re-mapping: https://docs.docker.com/engine/security/userns-remap/
It is very challenging to do re-mapping if different containers in the stack use different UID/GID.
I considered taking making a derivative container that updates the UID/GID. Unfortunately the VOLUME directive freezes part of the filesystem and it is impossible to re-id.
There is a hacky tool that can remove the VOLUME metadata so we can re-id, but that feels dangerous.
Our current approach is to re-build the containers starting from the published Dockerfiles, this is also not idea as our customer has a best practice of starting from vendor published images (I guess in a way we are because the base image is vendor supplied, but still this is yuck.)
I would suggest that all Alfresco containers use consistent UID/GID and probably that they don't us VOLUME if at all possible.
I spoke with Angel on Discord and he asked me to post this issue so he can think about this upon his return from vacation.
The text was updated successfully, but these errors were encountered: