[bitnamy/mysql] make env DB_DATA_DIR configurable

[27149chen]

Description of the change

make env DB_DATA_DIR configurable

Benefits

without this fix, env DB_DATA_DIR is not configurable, you can set datadir in mysql config file or command args, but some scripts are still using this env.

Possible drawbacks

Applicable issues

• fixes https://github.com/bitnami/charts/issues/22821

Additional information

[juan131]

Hi @27149chen

As you can see in the link below, the DB_DATA_DIR environment variable is used in the postunpack.sh script:means,

• https://github.com/bitnami/containers/blob/main/bitnami/mysql/8.0/debian-11/rootfs/opt/bitnami/scripts/mysql/postunpack.sh#L24-L27

This means it's used while building the container image, see:

• https://github.com/bitnami/containers/blob/main/bitnami/mysql/8.0/debian-11/Dockerfile#L49

Therefore, it implies it's a "hardcoded" values that shouldn't be modified during the container initialization.

[27149chen]

Hi @27149chen

As you can see in the link below, the DB_DATA_DIR environment variable is used in the postunpack.sh script:means,

• https://github.com/bitnami/containers/blob/main/bitnami/mysql/8.0/debian-11/rootfs/opt/bitnami/scripts/mysql/postunpack.sh#L24-L27

This means it's used while building the container image, see:

• https://github.com/bitnami/containers/blob/main/bitnami/mysql/8.0/debian-11/Dockerfile#L49

Therefore, it implies it's a "hardcoded" values that shouldn't be modified during the container initialization.

@juan131 The postunpack.sh script only sets up the default DB_DATA_DIR directory, but that doesn't mean it can't be changed during the container initialization. If it is a "hardcoded" value, I think it is a limitation

[27149chen]

I changed the DB_DATA_DIR by mounting my own mysql-env.sh as a volume to the container, it works. So I think it is configurable

[juan131]

Hi @27149chen

that doesn't mean it can't be changed during the container initialization.

I'm not saying you cannot change it during the initialization but please note that postunpack.sh prepares the directory with the expected ownership/permissions configuration to ensure there are no issues when the container is initialized.

If it is a "hardcoded" value, I think it is a limitation

It's indeed a limitation but there's no alternative since the actions taken place at postunpack.sh script require "root" privileges and we change the user to a non-root user (1001) after performing them.

[27149chen]

Hi @juan131 , Thank you for your explanation. I have to change the data dir since I want to switch from official mysql to bitnami mysql. Maybe there are alternatives, like changing the ownership/permissions in an initcontainer. Currently there is an initcontainer which run as root as does the similar things

[juan131]

Hi @27149chen

I have to change the data dir since I want to switch from official mysql to bitnami mysql

I guess you were mounting the data from a Persistent Volume in the MySQL container on a mount path /foo (consider /foo whatever mount path the image you're migrating from recommended you to use). You just need to reuse your persistent volume adapting the mount path to the one expected by Bitnami MySQL container:

    volumeMounts:
    - mountPath: /bitnami/mysql
      name: data

In case the MySQL data dir is in a subdirectory in your existing Persistent Volume, consider using pod.spec.containers.volumeMounts.subPath:

$ kubectl explain pod.spec.containers.volumeMounts.subPath
KIND:       Pod
VERSION:    v1

FIELD: subPath <string>

DESCRIPTION:
    Path within the volume from which the container's volume should be mounted.
    Defaults to "" (volume's root).

Maybe there are alternatives, like changing the ownership/permissions in an init-container. Currently there is an init-container which run as root as does the similar things

I guess you're referring to the init-container below:

• https://github.com/bitnami/charts/tree/main/bitnami/mysql#volume-permissions-parameters

Yes, this could be an alternative for fixing permissions issues.

[27149chen]

@juan131 subpath does not work in this case. subpath is use to mount a sub path of existing pvc to bitnami mount point, but there is no sub paths, mysql data are stored in the root path of the mount point. For example, my pvc was mount to /foo, mysql stored its dbs in /foo/db1, /foo/db2, ... Then I mount the pvc to /bitnami/mysql，bitnami creates new path /bitnami/mysql/data, and stores dbs in /bitnami/mysql/data/db1, /bitnami/mysql/data/db2. Now I have /bitnami/mysql/db1 and /bitnami/mysql/data/db1.

[juan131]

Hi @27149chen

Thanks for providing the whole context, I understand your issue now. The problem is that Bitnami image uses the Persistent Volume's "root" for other stuff and it's required that MySQL data directory is moved to a subdirectory, for instance take a look to the logic below:

• https://github.com/bitnami/containers/blob/main/bitnami/mysql/8.3/debian-11/rootfs/opt/bitnami/scripts/libmysql.sh#L839-L855

With this in mind, I see two alternatives to guarantee a smooth migration:

1. Adding a custom init-container that moves MySQL data under a "data" subdirectory as expected by Bitnami image. Please note this init-container should detect whether this operation was already performed and skipped it in that case.
2. Adding a custom pre-install/pre-upgrade chart hook (see https://helm.sh/docs/topics/charts_hooks) to do the same on a K8s job.

[github-actions[bot]]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[github-actions[bot]]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Pull Request. Do not hesitate to reopen it later if necessary.