It should be sentinel.conf not the redis.conf over here :https://github.com/OT-CONTAINER-KIT/redis/pull/35/files#diff-c3c0dcf3892b7d0c37d75bd5bf1865954c6839821f93b27c7083f9cd97011eb6R66

We should fix commands in README.md, like:

make build-redis-image

make build-redis-exporter-image

We should fix to:

make build-redis

make build-redis-exporter

To fix corrupted aof files this is nice to have.

bash-5.1$ redis-check-aof
bash: redis-check-aof: command not found

There are few improvement that can be done here.

1. Docker file linter: https://github.com/hadolint/hadolint
2. Bash script linter: https://github.com/koalaman/shellcheck

For the given Dockerfile and Scripts available in the repo.

Hi,
Starting from this change (7459d11) we have been facing issues with node configuration consistency.
Followers failed to reconnect back to the cluster once their pod had been replaced. The followers couldn't find the node configuration since it did not persist after the restart.
As a temporary fix we moved the /node-conf into /data, which fixed the issue since /data was a mounted volume.

Kind Regards,
Guy

Currently, we use opstree/redis:1.0 as the example image.

It's too old version, we should upgrade to latest support version which as describe in https://github.com/OT-CONTAINER-KIT/redis#image-compatibility.

files:

• https://github.com/OT-CONTAINER-KIT/redis/blob/master/docker-compose-standalone.yaml
• https://github.com/OT-CONTAINER-KIT/redis/blob/master/docker-compose.yaml

This image is based on Apline 3.9 which is unsupported as of Nov. 2020.

While starting this container as non root user (eg. 65532:65532) the entrypoint.sh is failing to configure redis:

mkdir: can't create directory '/opt/redis': Permission denied
/usr/bin/entrypoint.sh: line 21: /etc/redis/redis.conf: Permission denied
/usr/bin/entrypoint.sh: line 32: /etc/redis/redis.conf: Permission denied
sed: /data/nodes.conf: No such file or directory
/usr/bin/entrypoint.sh: line 52: /etc/redis/redis.conf: Permission denied

It would be nice to be able to run this container in rootles mode, since our K8 enforces securityContext.runAsNonRoot=true. Also in combination with the helm chart it would be nice to be able to set securityContext.readOnlyRootFilesystem=true.

#################### KERNEL transparent hugepage CONTROL ######################

Usually the kernel Transparent Huge Pages control is set to "madvise" or

or "never" by default (/sys/kernel/mm/transparent_hugepage/enabled), in which

case this config has no effect. On systems in which it is set to "always",

redis will attempt to disable it specifically for the redis process in order

to avoid latency problems specifically with fork(2) and CoW.

If for some reason you prefer to keep it enabled, you can set this config to

"no" and the kernel global to "always".

disable-thp yes

It's very useful

Signals like SIGTERM are being ignored and containers eventually gets killed abruptly. Potential fix is running redis with exec as seen in bitnami image.

https://github.com/bitnami/containers/blob/main/bitnami/redis/7.0/debian-11/rootfs/opt/bitnami/scripts/redis/run.sh#L29

Hi! Love yall's work.
Any plans for Redis 7 or for pushing the most recent version to quay that supports TLS?

The operator now seems to have multi arch image support (OT-CONTAINER-KIT/redis-operator#564), but the redis images currently don't work on arm64. Would love to see arm64 support through Multi arch images.

When the TLS enabled image would be pushed on quay.io ?

When I run redis on arm, the container exited with:

The issue is described at jemalloc/jemalloc#467. As mentioned in the discussion at redis/redis#11407, it is possible to build Redis on ARM using the --with-lg-page=16 option to support most scenarios.

ref:

1. https://github.com/docker-library/redis/blob/master/6.2/alpine/Dockerfile#L91-L102
2. redis-stack/redis-stack#473

➜ redis git:(master) ✗ docker run -it --name redis6.2 -d quay.io/opstree/redis:v6.2.8
78c22d5b2712de83227d0e148e8ce850cae801fa2c91f30fd681270df6b75ff7
➜ redis git:(master) ✗ docker logs redis6.2
Redis is running without password which is not recommended
Setting up redis in standalone mode
Running without TLS mode
Starting redis service in standalone mode.....
9:C 17 Jan 2023 07:12:09.936 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
9:C 17 Jan 2023 07:12:09.936 # Redis version=6.2.8, bits=64, commit=00000000, modified=0, pid=9, just started
9:C 17 Jan 2023 07:12:09.936 # Configuration loaded
9:M 17 Jan 2023 07:12:09.937 * monotonic clock: POSIX clock_gettime
9:M 17 Jan 2023 07:12:09.940 # Can't open the append-only file: Permission denied

When deploying this docker image (via Redis Operator - thanks for that one!) I get a warning:

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.

Is there a way to configure it/set THP settings by default?

I've seen a few mentions of this issue here, but all issues are closed, and creating a RedisCluster on OpenShift using this operator still doesn't seem to work.

Note that I'm using the Redis Operator 0.13.0, the latest one that is available in the Operator Hub on OpenShift.

I'm using the following Manifest to create the cluster.

kind: RedisCluster
apiVersion: redis.redis.opstreelabs.in/v1beta1
metadata:
  name: redis-cluster
spec:
  clusterSize: 2
  clusterVersion: v7
  securityContext:
    fsGroup: 1000
    runAsUser: 1000
  persistenceEnabled: true
  kubernetesConfig:
    image: 'quay.io/opstree/redis:v7.0.5'
    imagePullPolicy: IfNotPresent
  redisExporter:
    enabled: false
    image: 'quay.io/opstree/redis-exporter:v1.44.0'
    imagePullPolicy: IfNotPresent
  storage:
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi

I can see it creates a RedisCluster with a name redis-cluster, and a StatefulSet named redis-cluster-leader. However, the Statefulset doesn't contain any pods and has the following error. It seems that this is due to the runAsUser parameter in the securityContext.

create Pod redis-cluster-leader-0 in StatefulSet redis-cluster-leader failed

error: pods "redis-cluster-leader-0" is forbidden: unable to validate against any security context constraint: [
provider "anyuid": Forbidden: not usable by user or serviceaccount,
provider restricted-v2: .spec.securityContext.fsGroup: Invalid value: []int64{1000}: 1000 is not an allowed group, spec.containers[0].securityContext.runAsUser: Invalid value: 1000: must be in the ranges: [1000800000, 1000809999],
provider "restricted": Forbidden: not usable by user or serviceaccount,
provider "nonroot-v2": Forbidden: not usable by user or serviceaccount,
provider "nonroot": Forbidden: not usable by user or serviceaccount,
provider "noobaa": Forbidden: not usable by user or serviceaccount,
provider "noobaa-endpoint": Forbidden: not usable by user or serviceaccount,
provider "hostmount-anyuid": Forbidden: not usable by user or serviceaccount,
provider "machine-api-termination-handler": Forbidden: not usable by user or serviceaccount,
provider "hostnetwork-v2": Forbidden: not usable by user or serviceaccount,
provider "hostnetwork": Forbidden: not usable by user or serviceaccount,
provider "hostaccess": Forbidden: not usable by user or serviceaccount,
provider "ocs-metrics-exporter": Forbidden: not usable by user or serviceaccount,
provider "rook-ceph": Forbidden: not usable by user or serviceaccount,
provider "node-exporter": Forbidden: not usable by user or serviceaccount,
provider "rook-ceph-csi": Forbidden: not usable by user or serviceaccount,
provider "privileged": Forbidden: not usable by user or serviceaccount
]

When I set the securityContext to an empty object (like below), I can see that two pods are created, but I get the permission errors at startup.

kind: RedisCluster
apiVersion: redis.redis.opstreelabs.in/v1beta1
metadata:
  name: redis-cluster
spec:
  clusterSize: 2
  clusterVersion: v7
  securityContext: {}
...

Redis is running without password which is not recommended
/usr/bin/entrypoint.sh: line 22: /etc/redis/redis.conf: Permission denied
/usr/bin/entrypoint.sh: line 32: /etc/redis/redis.conf: Permission denied
sed: /data/nodes.conf: No such file or directory
/usr/bin/entrypoint.sh: line 72: /etc/redis/redis.conf: Permission denied
Running without TLS mode
Starting redis service in cluster mode.....
10:C 05 Apr 2023 09:36:00.658 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
10:C 05 Apr 2023 09:36:00.658 # Redis version=7.0.5, bits=64, commit=00000000, modified=0, pid=10, just started
10:C 05 Apr 2023 09:36:00.658 # Configuration loaded
10:M 05 Apr 2023 09:36:00.659 * monotonic clock: POSIX clock_gettime
10:M 05 Apr 2023 09:36:00.659 * Running mode=standalone, port=6379.
10:M 05 Apr 2023 09:36:00.660 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
10:M 05 Apr 2023 09:36:00.660 # Server initialized
10:M 05 Apr 2023 09:36:00.660 * Ready to accept connections

Inside the container, I observe these permissions:

/data $ id
uid=1000800000(1000800000) gid=0(root) groups=1000800000

/data $ ls -l /etc/redis
total 4K     
-rwxr-xr-x    1 redis    redis        114 Oct 30 13:58 redis.conf

/data $ ls -ln /etc/redis
total 4
-rwxr-xr-x    1 1000     1000           114 Oct 30 13:58 redis.conf

So it seems that this change isn't applied: #4

When I run this locally, on docker, it seems that the image isn't modified like in above PR.

$ docker run -it --entrypoint=/bin/bash quay.io/opstree/redis:v7.0.5
bash-5.1$ ls -lah /etc/redis/
total 12K
drwxr-xr-x    1 redis    redis       4.0K Oct 30 13:58 .
drwxr-xr-x    1 root     root        4.0K Apr  5 09:51 ..
-rwxr-xr-x    1 redis    redis        114 Oct 30 13:58 redis.conf
bash-5.1$

See also:

• OT-CONTAINER-KIT/redis-operator#69 (comment)
• OT-CONTAINER-KIT/redis-operator#19 (comment)

Hello,

I'm using your Redis operator (v0.14.0) on Openshift/OKD clusters and I realized that the default image (ie. quay.io/opstree/redis:v7.0.5) used by the operator and helm charts was built several months ago (November 2022). As such, it does not contain latest bug fixes from the newest Redis releases, nor the most needed write permission fix that would allow proper deployment on Openshift clusters without having to lower security (see #28).

I know I can build it myself but I believe that it would be a smoother on-boarding experience if working images were provided by default to the users of your Redis operator.

Thanks a lot for what you're doing.

Due to the group id and user id change from 1001 to 1000 that was done when redis was upgraded from v6.2.5 to v7.0.5, upgrading resid with persistence throws the below error:

Can't open or create append-only dir appendonlydir: Permission denied

fac6855#diff-dd2c0eb6ea5cfc6c4bd4eac30934e2d5746747af48fef6da689e85b752f39557R33

Currently, the redis, redis-exporter and redis-sentinel images that are pushed to quay.io do not have a corresponding tag with the explicit version.
We prefer to be able to refer to a specific to avoid unintended upgrades when a new version is published.
Please tag your images with the explicit version number, in addition to the 'latest' tag.