Add support for config fragments

[LaurentGoderre]

Using this approach, you can easily override our custom settings or add your own like this:

services:
  redis:
    image: redis:test
    configs:
      - source: redis_config
        target: /usr/local/etc/redis/conf.d/my.conf

configs:
  redis_config:
    content: |
      port 8000

Which yields

[+] Running 2/0
 ✔ Network redis_default    Created                                                                                                                                                                        0.0s 
 ✔ Container redis-redis-1  Created                                                                                                                                                                        0.0s 
Attaching to redis-1
redis-1  | 1:C 06 Feb 2025 21:16:42.399 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis-1  | 1:C 06 Feb 2025 21:16:42.399 * Redis version=7.4.2, bits=64, commit=00000000, modified=0, pid=1, just started
redis-1  | 1:C 06 Feb 2025 21:16:42.399 * Configuration loaded
redis-1  | 1:M 06 Feb 2025 21:16:42.399 * monotonic clock: POSIX clock_gettime
redis-1  | 1:M 06 Feb 2025 21:16:42.399 * Running mode=standalone, port=8000.
redis-1  | 1:M 06 Feb 2025 21:16:42.400 * Server initialized
redis-1  | 1:M 06 Feb 2025 21:16:42.400 * Ready to accept connections tcp

[LordRobinCbz]

Hello @LaurentGoderre , first of all thanks for your work here.

I am wrinting to you because for a Kube deployement I will need a Redis instance with configuration "as code".
for the moment, Redis's Docker image doesnt support configuration as settings: as you know we have to map/bind volume to the configuration and that's the probel you just solved.

But, with this implementation we need to define the configs.redis_config.content property as à clear string inside the compose file.
Its a good idea but for Kube and other scalled deployment maybe this approach is not the perfect one.

So, I am here to ask you a question: what do you think about base64 encoded file as ENV vars ? this ways you donc have to map external YAML properties, you can handle strings as secrets and so protect your instance with a security level, no special chars, etc.

I have impleted this solution for the PhpMyAdmin's Docker Image and add support for mTLS certs this ways.

What do you think about this idea ?

[LaurentGoderre]

Having a env var be a base64 encoded string would have some limits to how long it can be. The solution proposed her works for secrets as well because you can mount a secret as a file in Kubernetes so you could have a ConfigMap for non-secrets config and mount multiple secrets as separate files.

[LordRobinCbz]

Okay, with this view, I agree.
Many thanks.

Do you know when this will be merged ?

[LaurentGoderre]

I am sadly not a maintainer of this image so it would be up to the redis team to review it

[LaurentGoderre]

@LordRobinCbz however having someone else test it and confirm that it is a working solution is helpful!

[LordRobinCbz]

Ok @LaurentGoderre , I will build your image, publish into my personnal Nexus et try to use it in a mTLS secured way.

If I do not come back in, few days, its will because I failed and I will implement my solution.