Redis config customizations superseded by builtin environment variables

Describe your Issue

In my example I want to use TLS with the builtin redis. Config overrides get provisioned, but environmnet variables take precedence not allowing my config to use the tls:// prefix. Instead, the default tcp:// prefix is used.

Housekeeping

Clean setup, PVCs deleted

Config

nextcloud:
  defaultConfigs:
    redis.config.php: false
  configs:
    redis.config.php: |-
      <?php
      $CONFIG = array (
        'memcache.distributed' => '\OC\Memcache\Redis',
        'memcache.locking' => '\OC\Memcache\Redis',
        'redis' => array(
          'host' => "tls://nextcloud-wrapper-redis-master.default.svc.cluster.local",
          'port' => getenv('REDIS_HOST_PORT') ?: 6379,
          'password' => getenv('REDIS_HOST_PASSWORD'),
          'ssl_context' => [
              'verify_peer_name' => false
          ],
        ),
      );

redis:
  architecture: standalone
  enabled: true
  
  auth:
    enabled: true
    existingSecret: nextcloud-redis
    existingSecretPasswordKey: redisPw
  
  tls:
    enabled: true
    authClients: true
    autoGenerated: true

  metrics.enabled: true

Error

Error from /var/www/html/data/nextcloud.log (removed "Trace" and "Previous" to save space)

Notice tcp:// instead of tls://

{
  "reqId": "7zewVy1y4TPodURLtaNj",
  "level": 3,
  "time": "2024-05-08T02:16:04+00:00",
  "remoteAddr": "10.42.0.1",
  "user": "--",
  "app": "remote",
  "method": "GET",
  "url": "/status.php",
  "message": "read error on connection to tcp://nextcloud-wrapper-redis-master:6379",
  "userAgent": "kube-probe/1.29",
  "version": "29.0.0.19",
  "exception": {
    "Exception": "RedisException",
    "Message": "read error on connection to tcp://nextcloud-wrapper-redis-master:6379",
    "Code": 0,
    "Trace": [],
    "File": "/var/www/html/lib/private/Session/Internal.php",
    "Line": 213,
    "Previous": {},
    "message": "read error on connection to tcp://nextcloud-wrapper-redis-master:6379",
    "exception": {},
    "CustomMessage": "read error on connection to tcp://nextcloud-wrapper-redis-master:6379"
  }
}

Provisioned configs

Configs look good (not sure why doubled, but OK)

root@nextcloud-wrapper-6bd7885d8d-r7j5f:/var/www/html# grep -RIi redis /var/www/html/config

Output:

/var/www/html/config/redis.config.php:  'memcache.distributed' => '\OC\Memcache\Redis',
/var/www/html/config/redis.config.php:  'memcache.locking' => '\OC\Memcache\Redis',
/var/www/html/config/redis.config.php:  'redis' => array(
/var/www/html/config/redis.config.php:    'host' => "tls://nextcloud-wrapper-redis-master.default.svc.cluster.local",
/var/www/html/config/redis.config.php:    'port' => getenv('REDIS_HOST_PORT') ?: 6379,
/var/www/html/config/redis.config.php:    'password' => getenv('REDIS_HOST_PASSWORD'),
/var/www/html/config/config.php:  'memcache.distributed' => '\\OC\\Memcache\\Redis',
/var/www/html/config/config.php:  'memcache.locking' => '\\OC\\Memcache\\Redis',
/var/www/html/config/config.php:  'redis' => 
/var/www/html/config/config.php:    'host' => 'tls://nextcloud-wrapper-redis-master.default.svc.cluster.local',

Environment variables

Environment variables seem to have precedence over configs, rendering configs useless.

root@nextcloud-wrapper-6bd7885d8d-r7j5f:/var/www/html# env | grep -i redis

Output (notice tcp://)

NEXTCLOUD_WRAPPER_REDIS_MASTER_SERVICE_HOST=10.43.248.145
NEXTCLOUD_WRAPPER_REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_HOST=nextcloud-wrapper-redis-master
NEXTCLOUD_WRAPPER_REDIS_MASTER_PORT=tcp://10.43.248.145:6379
REDIS_HOST_PASSWORD=REDACTED_REDACTED
NEXTCLOUD_WRAPPER_REDIS_MASTER_SERVICE_PORT_TCP_REDIS=6379
NEXTCLOUD_WRAPPER_REDIS_MASTER_PORT_6379_TCP=tcp://10.43.248.145:6379
NEXTCLOUD_WRAPPER_REDIS_MASTER_SERVICE_PORT=6379
NEXTCLOUD_WRAPPER_REDIS_MASTER_PORT_6379_TCP_ADDR=10.43.248.145
NEXTCLOUD_WRAPPER_REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_HOST_PORT=6379

Probable culprit

First, the env variables are populated in the helpers file
Then, nextcloud.env is used in nextcloud containers

If I am correct in saying that nextcloud favors env variables, then this helm chart approach probably has to be reworked so these customizations can actually take place.

Workaround

I thought I could just provision redis separately and just make sure to have the REDIS_HOST_PASSWORD in extraEnv. Unfortunately, this doesn't work either (different error - Redis went away). The workaround might be possible, but I have given up on it for now and will just go without TLS for now.

Conclusion

Would be nice if helm logic would allow us to override certain aspects of the redis config.

It would be even nicer if I'm completely wrong here and missing like one line of config :)

Start with charts/nextcloud/templates/_helpers.tpl and deployment.yaml, then trace how nextcloud.env is populated and applied alongside the provisioned redis.config.php. Reproduce the TLS configuration and verify which values win; done means supported Redis customizations such as the tls:// host are honored without breaking the existing password and port settings.