dragonfly/tools/docker
Roman Gershman cec3659b51
fix: named volume permissions in docker (#3518)
Fixes #2917

The problem is described in this "working as intended" issue https://github.com/moby/moby/issues/3124
So the advised approach of using "USER dfly" directive does not really work because it requires
that the host will also define 'dfly' user with the same id. It's unrealistic expectation.

Therefore, we revert the fix done in #1775 and follow valkey approach:
https://github.com/valkey-io/valkey-container/blob/mainline/docker-entrypoint.sh#L12

1. we run the entrypoint in the container as root which later spawns the dragonfly process
2. if we run as root:
   a. we chmod files under /data to dfly.
   b. use setpriv to exec ourselves as dfly.
3. if we do not run as root we execute the docker command.

So even though the process starts as root, the server runs as dfly and only the bootstrap
part has elevated permissions is used to fix the volume access.

While we are at it, we also switched to setpriv following the change of https://github.com/valkey-io/valkey-container/pull/24/files

Signed-off-by: Roman Gershman <roman@dragonflydb.io>
2024-08-22 11:33:29 +03:00
..
entrypoint.sh fix: named volume permissions in docker (#3518) 2024-08-22 11:33:29 +03:00
fetch_release.sh docker-release pipeline now uses release assets for building dockers 2022-05-30 11:24:56 +03:00
healthcheck.sh fix: healthcheck for docker containers (#2853) 2024-04-07 10:49:00 +03:00