jbergstroem / mariadb-alpine

A tiny and fast MariaDB container
MIT License
72 stars 19 forks source link

Option to pass MYSQL_UID and MYSQL_GID as parameters to the Dockerfile #121

Closed telkamp closed 2 years ago

telkamp commented 2 years ago

I guess that the user:group mysql:mysql is created during the installation of mariadb. uid:gid was 1000:1000, what was mapped to a test user on the host machine in my case. Therefore, the files in the volume folder on my machine under /var/lib/docker/volumes/../.. were owned by this test user.

To solve this, I have defined the uid:gid to be used by mysql:mysql as arguments MYSQL_UID and MYSQL_GID in the Dockerfile:

@@ -1,6 +1,8 @@
 FROM alpine:3.15

 # https://github.com/opencontainers/image-spec/blob/master/annotations.md
+ARG MYSQL_UID=1000
+ARG MYSQL_GID=1000
 ARG BUILD_DATE
 ARG VCS_REF

@@ -17,6 +19,7 @@ LABEL org.opencontainers.image.created=$BUILD_DATE \
 SHELL ["/bin/ash", "-euo", "pipefail", "-c"]

 RUN \
+  addgroup --system --gid ${MYSQL_GID} mysql && adduser --system --ingroup mysql --uid ${MYSQL_UID} mysql && \
   apk add --no-cache mariadb=10.6.4-r2 && \
   TO_KEEP=$(echo " \
     etc/ssl/certs/ca-certificates.crt$ \

These arguments may be passed by the docker-compose.yml:

    [...]
    build:
      context: mariadb-alpine
      dockerfile: ./Dockerfile
      args:
        - MYSQL_UID=${MYSQL_UID:-1000}
        - MYSQL_GID=${MYSQL_GID:-1000}
    [...]

The disadvantage of this solution is that the container has to be built on the host machine, so it can not be pulled from Docker Hub. Setting a different user for the container pulled from Docker Hub did not worked for me, because this user had no privileges to copy files to /etc/my.cnf.d/ (see run.sh:11) Maybe there are better solutions?

jbergstroem commented 2 years ago

I guess that the user:group mysql:mysql is created during the installation of mariadb. uid:gid was 1000:1000, what was mapped to a test user on the host machine in my case. Therefore, the files in the volume folder on my machine under /var/lib/docker/volumes/../.. were owned by this test user.

Yeah, it is coming from when alpine is creating the user (and the image inherits it).

Before we start thinking about solutions, I'd like t obetter understand what the issue is with ownership gid/uid on the host machine. Are you reading volume contents outside of the container?

telkamp commented 2 years ago

My concern is that this this might lead to a user/group mismatch when the folder var/lib/docker/.. is backupped and restored later to a different machine, using different uid/gids. I have to ensure that the uid:gid will be used for the backup and not the user:group. But I have not made an attempt yet.

jbergstroem commented 2 years ago

My concern is that this this might lead to a user/group mismatch when the folder var/lib/docker/.. is backupped and restored later to a different machine, using different uid/gids. I have to ensure that the uid:gid will be used for the backup and not the user:group. But I have not made an attempt yet.

The gid/uid should not change, ever, unless you for instance backup via rsync and drop them (I sometimes intentionally do that for things like logfiles). I'm guessing this will affect all your docker volumes, just not this one.

telkamp commented 2 years ago

I'm guessing this will affect all your docker volumes, just not this one. Yes, this was the reason for me to find a solution for that. But I will close this issue. Thank you!