From 926b1c68dd1579b85806a53c20a423d576d40317 Mon Sep 17 00:00:00 2001 From: Ubuntu Date: Wed, 19 Apr 2023 14:11:49 +0000 Subject: [PATCH 1/6] promoting version 6.4.2-5 --- .gitignore | 2 +- active_active_database_readme.md | 332 +++--------------- bundle.yaml | 4 +- cluster_credentials.md | 6 +- crds/README.md | 30 ++ examples/v1alpha1/reaadb.yaml | 2 + google_private_cloud/README.md | 100 ++++++ .../bundle/kustomization.yaml | 4 + google_private_cloud/rec/kustomization.yaml | 4 + google_private_cloud/rec/kustomize_rec.yaml | 19 + google_private_cloud/rec/rec.yaml | 9 + log_collector/log_collector.py | 2 +- multi-namespace-redb/operator.yaml | 4 +- openshift.bundle.yaml | 4 +- openshift/operator_rhel.yaml | 4 +- openshift/rec_rhel.yaml | 2 +- operator.yaml | 4 +- 17 files changed, 239 insertions(+), 293 deletions(-) create mode 100644 crds/README.md create mode 100644 google_private_cloud/README.md create mode 100644 google_private_cloud/bundle/kustomization.yaml create mode 100644 google_private_cloud/rec/kustomization.yaml create mode 100644 google_private_cloud/rec/kustomize_rec.yaml create mode 100644 google_private_cloud/rec/rec.yaml diff --git a/.gitignore b/.gitignore index 485dee6..5c3bdbb 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -.idea +*bundle.yaml diff --git a/active_active_database_readme.md b/active_active_database_readme.md index 8e25d14..9cd617c 100644 --- a/active_active_database_readme.md +++ b/active_active_database_readme.md @@ -4,8 +4,9 @@ This document describes how to deploy an Active-Active database with Redis Enterprise for Kubernetes. **Disclaimer:** - This feature is in public preview. - + This feature is in private preview and is not complete for production use. + Importent - Please view the [support for only one Active-Active database with up-to three participating clusters across a set of participating clusters](#support-for-only-one-active-active-database-with-up-to-three-participating-clusters-across-a-set-of-participating-clusters) limitation. + **This document assumes the following:** - You have at least two running Redis Enterprise clusters that will be used as your participating clusters. @@ -17,11 +18,8 @@ This document describes how to deploy an Active-Active database with Redis Enter * [Create a new Active-Active database](#create-a-new-active-active-database) * [Add participating cluster to an existing Active-Active database](#add-participating-cluster-to-an-existing-active-active-database) * [Remove participating cluster from an existing Active-Active database](#remove-participating-cluster-from-an-existing-active-active-database) - * [Set the database global configurations specifications](#set-the-database-global-configurations-specifications) - * [Set global database secret](#set-global-database-secret) * [Delete an existing Active-Active database](#delete-an-existing-active-active-database) * [Update existing participating cluster (RERC) details](#update-existing-participating-cluster-rerc-details) - * [Update existing participating cluster (RERC) secret](#update-existing-participating-cluster-rerc-secret) * [Test your Active-Active database](#test-your-active-active-database) * [Limitations](#limitations) @@ -47,8 +45,8 @@ Note: 1. Apply the following CRDs: ``` - kubectl apply -f crds/reaadb_crd.yaml - kubectl apply -f crds/rerc_crd.yaml + kubectl apply -f reaadb_crd.yaml + kubectl apply -f rerc_crd.yaml ``` Note: @@ -63,15 +61,12 @@ Note: 3. Configure a Ingress or Route, follow the instructions [here](setting_ingress_or_route_readme.md) -4. Configure ValidatingWebhookConfiguration, follow the instructions [here](admission/README.md) -Note: this is a must for managing Active-Active database via the operator. - #### Part 2: participating cluster info preparation setup Note: - * This part should be done always, even if the cluster is already configured to run the Redis Enterprise Operator managed Active-Active databases. + * This part should be done always, even if the cluster is already configured to run the Redis Enterprise Operator managed active-active databases. -1. Collect the REC credentials secret from all of the participating clusters, replace `` with the local REC name: +1. Collect the REC credentials secret from all of the participating clusters, replase `` with the local REC name: ``` kubectl get secret -o yaml ``` @@ -79,7 +74,7 @@ For example, collecting the secret of a Redis Enterprise Cluster named "rec1" t ``` kubectl get secret rec1 -o yaml ``` -Following is an example of a REC credentials secret named "rec1" with namespace "ns1": +Following is an example of a REC crdentials secret named "rec1" with namespace "ns1": ``` apiVersion: v1 data: @@ -105,8 +100,8 @@ metadata: type: Opaque ``` -2. For each of the secrets you collected, generate a new secret with the credentials data and name it with the following convention: `redis-enterprise-`, replace the `` with the RERC name. -The new secret generated from the previous example of Redis Enterprise cluster named "rec1" that resides in "ns1" namespace that will be used for the RERC name: "rerc1" should look as follows: +2. For each of the secrets you collected, generate a new secret with the credentials data and name it with the following convention: `redis-enterprise--`, replace the `` and the `` with the Redis Enterprise cluster name and the namespace where it resides in respectively. +The new secret generated from the previous example of Redis Enterprise cluster named "rec1" that resides in "ns1" namespace should look as follows: ``` apiVersion: v1 data: @@ -114,7 +109,7 @@ data: username: PHNvbWUgdXNlcj4 kind: Secret metadata: - name: redis-enterprise-rerc1 + name: redis-enterprise-rec1-ns1 type: Opaque ``` @@ -134,29 +129,25 @@ a. The example for a REC named "rec1" in the namespace "ns1": apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseRemoteCluster metadata: - name: rerc1 + name: rec1.ns1 spec: - recName: rec1 - recNamespace: ns1 apiFqdnUrl: test-example-api-rec1-ns1.redis.com dbFqdnSuffix: -example-cluster-rec1-ns1.redis.com - secretName: redis-enterprise-rerc1 + secretName: redis-enterprise-rec1-ns1 ``` b. The example for a REC named "rec2" in the namespace "ns2": ``` apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseRemoteCluster metadata: - name: rerc2 + name: rec2.ns2 spec: - recName: rec2 - recNamespace: ns2 apiFqdnUrl: test-example-api-rec2-ns2.redis.com - dbFqdnSuffix: -example-cluster-rec2-ns2.redis.com - secretName: redis-enterprise-rerc2 + dbFqdnSuffix: -example-cluster-rec2.ns2.redis.com + secretName: redis-enterprise-rec2-ns2 ``` -Notes: +Note: * View the Redis Enterprise Remote Cluster custom resource definition or the API doc for more details regarding the RERC fields. 2. Create the RERC custom resources you generated in the previous step and follow their statuses to verify the 'SPEC STATUS' is 'valid' and the 'STATUS' is 'active'. @@ -168,32 +159,32 @@ To follow the statuses of the applied RERC custom resources, run the following: ``` kubectl get rerc ``` -For example to view the status of the RERC named "rerc1": +For example to view the status of the RERC named "rec1.ns1": ``` - kubectl get rerc rerc1 + kubectl get rerc rec1.ns1 ``` The output should be as below: ``` NAME STATUS SPEC STATUS LOCAL - rerc1 Active Valid true + rec1.ns1 Active Valid true ``` Note: * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error, view the RERC custom resource events and the Redis Enterprise operator logs. 3. Generate the REAADB custom resource. -Following is an example of a REAADB custom resource named "example-aadb-1" that is linked to the REC named: "rec1" with two participating clusters and database global configurations with shard count set to 3. +Following is an example of a REAADB custom resource named "example-aadb-1" that is linked to the REC named: "rec1" with two participating clusters. ``` apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseActiveActiveDatabase metadata: name: example-aadb-1 spec: + redisEnterpriseCluster: + name: rec1 participatingClusters: - - name: rerc1 - - name: rerc2 - globalConfigurations: - shardCount: 3 + - name: rec1.ns1 + - name: rec2.ns2 ``` Notes: @@ -234,7 +225,7 @@ In addition, to view the RERCs for each RERC please run the following: ## Add participating cluster to an existing Active-Active database -**On the participating cluster you want to add in the namespace where the Redis Enterprise operator resides, please do the following:** +**On the participating cluster you want to add in the namespace where the Redis Enterprise operator resides resides, please do the following:** 1. Follow the instructions under: [Participating cluster preparation setup](#participating-cluster-preparation-setup). @@ -272,7 +263,7 @@ metadata: type: Opaque ``` -3. For the secret you collected generate a new secret with the credentials data and name it with the following convention: `redis-enterprise-`, replace the `` with the RERC name. +3. For the secret you collected generate a new secret with the credentials data and name it with the following convention: `redis-enterprise--`, replace the `` and the `` with the Redis Enterprise Cluster name and the namespace where it resides in respectively. The new example credentials secret generated from the Redis Enterprise cluster named "rec3" that resides in "ns3" namespace would look like this: ``` apiVersion: v1 @@ -281,7 +272,7 @@ data: username: PHNvbWUgdXNlcj4 kind: Secret metadata: - name: redis-enterprise-rerc3 + name: redis-enterprise-rec3-ns3 type: Opaque ``` @@ -298,13 +289,11 @@ Following is an example of a RERC custom resource to add that contains the parti apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseRemoteCluster metadata: - name: rerc3 + name: rec3.ns3 spec: - recName: rec3 - recNamespace: ns3 apiFqdnUrl: test-example-api-rec3-ns3.redis.com dbFqdnSuffix: -example-cluster-rec3-ns3.redis.com - secretName: redis-enterprise-rerc3 + secretName: redis-enterprise-rec3-ns3 ``` Note: @@ -320,23 +309,23 @@ To follow the statuses of the created rerc custom resources run the following: ``` kubectl get rerc ``` -For example, to view the status of the RERC named "rerc3": +For example, to view the status of the RERC named "rec3.ns3": ``` - kubectl get rerc rerc3 + kubectl get rerc rec3.ns3 ``` The output should be as below: ``` NAME STATUS SPEC STATUS LOCAL - rerc3 Active Valid true + rec3.ns3 Active Valid true ``` Note: * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct, in case of an error please view the RERC custom resource events and/ or the Redis Enterprise Operator logs. 3. Add and patch with the RERC name you created in the previous step on the 'participatingClusters' list in the REAADB spec. Follow the statuses to verify the 'SPEC STATUS' is 'valid' and the 'STATUS' is 'active'. -For example, adding to the REAADB named: "example-aadb-1" the RERC name: "rerc3": +For example, adding to the REAADB named: "example-aadb-1" the RERC name: "rec3.ns3": ``` - kubectl patch reaadb example-aadb-1 --type merge --patch '{"spec": {"participatingClusters": [{"name": "rerc3"}]}}' + kubectl patch reaadb example-aadb-1 --type merge --patch '{"spec": {"participatingClusters": [{"name": "rec3.ns3"}]}}' ``` 4. View the REAADB 'participatingClusters' status and verify that the added participating cluster exists with it's corresponding ID. @@ -350,7 +339,7 @@ For example, to get the REAADB named: "example-aadb-1" participating clusters st ``` Following is the output of the example above: ``` - [{"id":1,"name":"rerc1"},{"id":2,"name":"rerc2"},{"id":3,"name":"rerc3"}] + [{"id":1,"name":"rec1.ns1"},{"id":2,"name":"rec2.ns2"},{"id":3,"name":"rec3.ns3"}] ``` ## Remove participating cluster from an existing Active-Active database @@ -370,13 +359,13 @@ To follow the statuses of the REAADB custom resource run the following: ``` kubectl get reaadb -o=jsonpath='{.status}' ``` -For example, to view the status of the REAADB named "example-aadb-1" after remove the "rerc3": +For example, to view the status of the REAADB named "example-aadb-1" after remove the "rec3.ns3": ``` kubectl get reaadb example-aadb-1 -o=jsonpath='{.status}' ``` the output should be as below: ``` - {... ,"participatingClusters":[{"id":1,"name":"rerc1"},{"id":2,"name":"rerc2"}],"redisEnterpriseCluster":"rec1","specStatus":"Valid","status":"active"} + {... ,"participatingClusters":[{"id":1,"name":"rec1.ns1"},{"id":2,"name":"rec2.ns2"}],"redisEnterpriseCluster":"rec1","specStatus":"Valid","status":"active"} ``` **On the participating cluster that you removed do the following:** @@ -387,115 +376,6 @@ To get all the REAADB custom resources that exist, run the following: kubectl get reaadb -o=jsonpath='{range .items[*]}{.metadata.name}' ``` -## Set the database global configurations specifications - -Note: -the REAADB contains the field: '.spec.globalConfigurations' and through this the database configurations are set, for example the memory size and shard count. -For more information and all the fields please view the [REAADB API readme](redis_enterprise_active_active_database_api.md) - -**On one of the participating clusters that already exists do the following:** - -1. Set the global configurations on a REAADB. -For example, to patch a REAADB with global configurations with memory size set to 200 MB run the following: -``` - kubectl patch reaadb example-aadb-1 --type merge --patch '{"spec": {"globalConfigurations": {"memorySize": "200mb"}}}' -``` - -2. Follow the statuses of the created REAADB custom resource run the following: -``` - kubectl get reaadb -``` -For example, to view the status of the REAADB named "example-aadb-1": -``` - kubectl get reaadb example-aadb-1 -``` -The output should be as below: -``` - NAME STATUS SPEC STATUS GLOBAL CONFIGURATIONS REDB LINKED REDBS - example-aadb-1 active Valid -``` - -Note: - * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error status, view the REAADB custom resource events and the Redis Enterprise operator logs. - -5. View the global configurations that is synced on the REAADB on each of the participating clusters. -To get the REAADB run the following: -``` - kubectl get reaadb -o yaml -``` - -## Set global database secret - -Notes: -* the REAADB contains the field: '.spec.globalConfigurations' and through this the database secret is configured. -For more information and all the fields please view the [REAADB API readme](redis_enterprise_active_active_database_api.md) -* The database secret sync with the correct password on all of the participating clusters is the users' responsibility. - -**On one of the participating clusters that already exists do the following:** - -1. Generate the yaml containing the secret with the password data. -For example a secret named 'my-db-secret' with the password 'my-pass' as base 64 encoded: -``` -apiVersion: v1 -data: - password: bXktcGFzcw -kind: Secret -metadata: - name: my-db-secret -type: Opaque -``` - -2. Apply the generated secret from the previous step, replace `` with a file containing each new secret you generated in the previous step. -``` - kubectl apply -f -``` - -3. Set the database secret name on the REAADB spec (if not exist yet). -For example, to patch a REAADB named 'example-aadb-1' with the database secret from the previous steps on the global configurations run the following: -``` - kubectl patch reaadb example-aadb-1 --type merge --patch '{"spec": {"globalConfigurations": {"databaseSecretName": "my-db-secret"}}}' -``` - -4. Follow the statuses of the REAADB custom resource run the following: -``` - kubectl get reaadb -``` -For example, to view the status of the REAADB named "example-aadb-1": -``` - kubectl get reaadb example-aadb-1 -``` -The output should be as below: -``` - NAME STATUS SPEC STATUS GLOBAL CONFIGURATIONS REDB LINKED REDBS - example-aadb-1 active Valid -``` - -Note: - * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error status, view the REAADB custom resource events and the Redis Enterprise operator logs. - -**On the other participating clusters that already exists do the following:** - -1. View the secret status on the REAADB (on the other participating clusters). -To get the REAADB secrets status run the following: -``` - kubectl get reaadb -o=jsonpath='{.status.secretsStatus}' -``` -For example, to view the status of the REAADB named "example-aadb-1": -``` - kubectl get reaadb example-aadb-1 -o=jsonpath='{.status.secretsStatus}' -``` -The output should be as below (with the secret used in previous steps): -``` - [{"name":"my-db-secret","status":"Invalid"}] -``` - Note: as the secret status is 'Invalid' it means that the secret isn't synced yet on the participating cluster. - -2. Sync the secret on the other participating clusters. -Apply the generated secret from the previous steps, replace `` with a file containing the secret you generated in the previous step. -``` - kubectl apply -f -``` - ## Delete an existing Active-Active database **On one of the participating clusters that already exists do the following:** @@ -519,22 +399,22 @@ To get all the REAADB that exists run the following: **On the participating cluster you want to modify (with the local RERC) do the following:** 1. Patch the participating cluster corresponding local RERC that you want to update. -For example updating the DB FQDN suffix of an RERC named: "rerc1": +For example updating the DB FQDN suffix of an RERC named: "rec1.ns1": ``` - kubectl patch rerc rerc1 --type merge --patch '{"spec": {"dbFqdnSuffix": "-example2-cluster-rec1-ns1.redis.com"}}' + kubectl patch rerc rec1.ns1 --type merge --patch '{"spec": {"dbFqdnSuffix": "-example2-cluster-rec1-ns1.redis.com"}}' ``` To follow the statuses of the updated RERC custom resources run the following: ``` kubectl get rerc ``` -For example to view the status of the RERC named "rerc1": +For example to view the status of the RERC named "rec1.ns1": ``` - kubectl get rerc rerc1 + kubectl get rerc rec1.ns1 ``` The output should be as below: ``` NAME STATUS SPEC STATUS LOCAL - rerc1 Active Valid true + rec1.ns1 Active Valid true ``` Note: @@ -559,106 +439,6 @@ The output should be as below: Note: * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error status, view the REAADB custom resource events and the Redis Enterprise operator logs. -## Update existing participating cluster (RERC) secret - -Note: -* this is part of the "Changing the Redis Enterprise Cluster Credentials" that can be found [here](cluster_credentials.md) - -**On the participating cluster that you changed the REC secret (with the local RERC) do the following:** - -1. update the secret with the new credentials data and name it with the following convention: `redis-enterprise-`, replace the `` with the RERC name. -For example, a secret generated with the RERC name 'rerc1': -``` -apiVersion: v1 -data: - password: PHNvbWUgcGFzc3dvcmQ+ - username: PHNvbWUgdXNlcj4 -kind: Secret -metadata: - name: redis-enterprise-rerc1 -type: Opaque -``` - -2. Apply the generated secrets from the previous step, replace `` with a file containing each new secret you generated in the previous step. -``` - kubectl apply -f -``` - -3. Follow the RERC status and verify it is 'Active'. -To follow the statuses of the updated RERC custom resources run the following: -``` - kubectl get rerc -``` -For example to view the status of the RERC named "rerc1": -``` - kubectl get rerc rerc1 -``` -The output should be as below: -``` - NAME STATUS SPEC STATUS LOCAL - rerc1 Active Valid true -``` - -Note: - * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct, in case of an error please view the RERC custom resource events and/ or the Redis Enterprise operator logs. - -4. follow the REAADB custom resources statuses that are using this RERC to verify the 'SPEC STATUS' is 'valid' and the 'STATUS' is 'active'. -To view the statuses of the REAADB custom resources that is using this RERC run the following, replace `` with the list of REAADB that is using this RERC separated via spaces: -``` - kubectl get reaadb -``` -For example, to view the status of the REAADB named "example-aadb-1" and "example-aadb-2": -``` - kubectl get reaadb example-aadb-1 example-aadb-2 -``` -The output should be as below: -``` - NAME STATUS SPEC STATUS GLOBAL CONFIGURATIONS REDB LINKED REDBS - example-aadb-1 active Valid - example-aadb-2 active Valid -``` - -Note: - * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error status, view the REAADB custom resource events and the Redis Enterprise operator logs. - -**On the other clusters that are participating in the Active-Active database do the following:** - -1. update the secret with the new credentials data and name it with the following convention: `redis-enterprise-`, replace the `` with the RERC name. -For example, a secret generated with the RERC name 'rerc1': -``` -apiVersion: v1 -data: - password: PHNvbWUgcGFzc3dvcmQ+ - username: PHNvbWUgdXNlcj4 -kind: Secret -metadata: - name: redis-enterprise-rerc1 -type: Opaque -``` - -2. Apply the generated secrets from the previous step, replace `` with a file containing each new secret you generated in the previous step. -``` - kubectl apply -f -``` - -3. Follow the RERC status and verify it is 'Active'. -To follow the statuses of the updated RERC custom resources run the following: -``` - kubectl get rerc -``` -For example to view the status of the RERC named "rerc1": -``` - kubectl get rerc rerc1 -``` -The output should be as below: -``` - NAME STATUS SPEC STATUS LOCAL - rerc1 Active Valid true -``` - -Note: - * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct, in case of an error please view the RERC custom resource events and/ or the Redis Enterprise operator logs. - ## Test your Active-Active database The easiest way to test your Active-Active database is to set a key-value pair in one database and retrieve it from the other. @@ -688,21 +468,21 @@ From the output fetch the redis 'targetPort': ## Limitations +### Support for only one Active-Active database with up-to three participating clusters across a set of participating clusters +Currently, there is only support for one managed Active-Active database, REAADB custom resource, with up-to three participating clusters across a set of participating clusters. -### No migration from the previous AA method -migrating Active-Active database with non-operator managed Active-Active database is currently not supported. +### No data path level configurations +Creating and updating the Active-Active database data level configurations (i.e. updating the DB size) is currently not supported via custom resources. +Updating an already created Active-Active database may be done through the RS API directly. -### HashiCorp Vault secret storage -Storing the secrets in HashiCorp Vault is currently not supported for operator managed Active-Active database . - -### database version is currently not supported -Setting database specific version is currently not supported for operator managed Active-Active database . +### Updating participating cluster secret +Updating the secret of a participating cluster is currently not supported via the operator, you may update it through the RS API directly and then modify the RERC secrets on all of the participating clusters. -### Modules are currently not supported -Redis modules are currently not supported for operator managed Active-Active database . +### Unique participating clusters REC name.namespace +The participating clusters `` must be different accross all of them. -### Backup are currently not supported -Database backups are currently not supported for operator managed Active-Active database . +### No REC upgrade +Upgrading Redis Enterprise cluster with operator managed Active-Active database is currently not supported. -### client authentication certificates are currently not supported -client authentication certificates are currently not supported for operator managed Active-Active database . +### HashiCorp Vault secret storage +Storing the secrets in HashiCorp Vault is currently not supported for operator managed Active-Active database . diff --git a/bundle.yaml b/bundle.yaml index a4b3aad..ab9474f 100644 --- a/bundle.yaml +++ b/bundle.yaml @@ -15443,7 +15443,7 @@ spec: serviceAccountName: redis-enterprise-operator containers: - name: redis-enterprise-operator - image: redislabs/operator:6.4.2-4 + image: redislabs/operator:6.4.2-5 command: - redis-enterprise-operator imagePullPolicy: Always @@ -15485,7 +15485,7 @@ spec: port: 8080 scheme: HTTP - name: admission - image: redislabs/operator:6.4.2-4 + image: redislabs/operator:6.4.2-5 command: - /usr/local/bin/admission imagePullPolicy: Always diff --git a/cluster_credentials.md b/cluster_credentials.md index 7aa459a..e024bf7 100644 --- a/cluster_credentials.md +++ b/cluster_credentials.md @@ -39,8 +39,7 @@ Please follow the following steps: kubectl create secret generic --from-file=./username --from-file=./password --dry-run -o yaml | kubectl apply -f - ``` 5. Wait 5 minutes to make sure all components have read the new password from the updated secret -6. in case this cluster is participating in Active-Active database via REAADB follow the instructions [here](active_active_database_readme.md) under `Update existing participating cluster (RERC) secret`. -7. Exec into a Redis Enterprise Cluster node pod (see above) and run the following command to remove the previous password so only the new one applies. Important: replace OLD PASSWORD with the one being replaced, see step 1 above. +6. Exec into a Redis Enterprise Cluster node pod (see above) and run the following command to remove the previous password so only the new one applies. Important: replace OLD PASSWORD with the one being replaced, see step 1 above. ``` REC_USER="`cat /opt/redislabs/credentials/username`"; REC_PASSWORD="`cat /opt/redislabs/credentials/password`";curl -k --request DELETE --url https://localhost:9443/v1/users/password -u "$REC_USER:$REC_PASSWORD" --header 'Content-Type: application/json' --data "{\"username\":\"$REC_USER\",\"old_password\":\" Note: the username to be used with the K8s secret is the email displayed on the Redis Enterprise UI 5. Wait 5 minutes to make sure all components have read the new password from the updated secret -6. in case this cluster is participating in Active-Active database via REAADB follow the instructions [here](active_active_database_readme.md) under `Update existing participating cluster (RERC) secret`. -7. Delete the previous admin user using the Redis Enterprise Cluster UI +6. Delete the previous admin user using the Redis Enterprise Cluster UI > Note: this procedure is only supported for version 6.0.20-5 or above > Note: the operator might log errors in the time period between updating the username in the REC spec and the secret update diff --git a/crds/README.md b/crds/README.md new file mode 100644 index 0000000..542f90e --- /dev/null +++ b/crds/README.md @@ -0,0 +1,30 @@ +## CRD's Schema
+ + +Purpose: +The schema is meant to ease the use of CRDs by restricting the fields to defined types and providing relevant description. + + +### Work Flow - How add a new field: +* Not all steps are always required + +#### 1. Update Tags: +In the files ++ `pkg/apis/app/v1alpha1/redisenterprisedatabase_types.go`
++ `pkg/apis/app/v1alpha1/redisenterprisecluster_types.go`
+add tags on top of variables to mark allowed types (Enum)
+(see: https://book.kubebuilder.io/reference/markers/crd-validation.html).
+They will be used by the operator sdk when creating the scheme.
+**Default values** do not appear in the schema since the operator has its own default mechanism. + + +#### 2 .Create the schema: +1) Install operator-sdk version 0.17.2.
+See: https://sdk.operatorframework.io/docs/installation/install-operator-sdk/#install-from-github-release +2) Run `operator-sdk generate crds` + +#### 3. Update the schema: +- Edit the current schema in all of the relevant CRD yamls with the new section that was generated
+- Note that fields which are k8s objects might be very long - e.g. `SideContainersSpec` +in this case -
it appears in the schema but with no description in the fields since it extends the schema and is not unique for Redis Enterprise. + diff --git a/examples/v1alpha1/reaadb.yaml b/examples/v1alpha1/reaadb.yaml index d0e5289..fdc59bb 100644 --- a/examples/v1alpha1/reaadb.yaml +++ b/examples/v1alpha1/reaadb.yaml @@ -2,6 +2,8 @@ apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseActiveActiveDatabase metadata: name: reaadb-1 + labels: + app: redis-enterprise spec: # The Redis Enterprise Cluster Object this Resource is associated with redisEnterpriseCluster: diff --git a/google_private_cloud/README.md b/google_private_cloud/README.md new file mode 100644 index 0000000..4fd2d4f --- /dev/null +++ b/google_private_cloud/README.md @@ -0,0 +1,100 @@ + +# Deploying Redis Enterprise on Google Private Cloud + +This page describes how to deploy Redis Enterprise on Google Private Cloud Kubernetes solution using the Redis Enterprise Operator. + +### Prerequisites + +- A Kubernetes cluster version of 1.20 or higher, with a minimum of 3 worker nodes. +- A Kubernetes client (kubectl) with a matching version. +- Access to DockerHub, Harbor or a private repository that can serve the required images. + + + +The following are the images and tags for this release: + +| Component | k8s | +| --- | --- | +| Redis Enterprise | `redislabs/redis:6.4.2-61` | +| Operator | `redislabs/operator:6.4.2-5` | +| Services Rigger | `redislabs/k8s-controller:6.4.2-5` | + + +### Installation +The "Basic" installation deploys the operator (from the current release) from DockerHub and default settings. +This is the fastest way to get up and running with a new Redis Enterprise on Kubernetes. + +1. We will need to clone the yamls from [github](https://github.com/RedisLabs/redis-enterprise-k8s-docs/releases) to your local directory. + +2. Create a new namespace: + > Note: + For the purpose of this doc, we'll use the name "demo" for our cluster's namespace. + + ```bash + kubectl create namespace demo + ``` + + Switch context to the newly created namespace: + + ```bash + kubectl config set-context --current --namespace=demo + ``` +*** +For deploying the bundle and the Redis Enterprise Cluster custom resource we will use the [Kustomize](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/). +3. Customize the operator deployment - + + Before deploying the bundle.yaml we will need to customize it . + edit the `bundle\kustomize_bundle.yaml` file : + > Note: + Replace the [User Private repo] with your private images repository location. + +4. Deploy the operator bundle + + with `kubectl`, the following command will deploy a bundle of all the yaml declarations required for the operator: + + ```bash + kubectl apply -k bundle + ``` + + Run `kubectl get deployment` and verify redis-enterprise-operator deployment is running. + + A typical response may look like this: + + ```bash + NAME READY UP-TO-DATE AVAILABLE AGE + redis-enterprise-operator 1/1 1 1 2m + ``` + +5. Customize the Redis Enterprise Cluster custom resource - + + Before deploying the rec.yaml we will need to customize it . + edit the `rec\kustomize_rec.yaml` file : + > Note: + Replace the [User Private repo] with your private images repository location. + + The kustomize_rec.yaml configure the Redis Enterprise Cluster custom resource with the default configuration, + which is suitable for development type deployments and works in typical scenarios. + The full list of attributes supported through the Redis Enterprise Cluster (REC) API can be found [HERE](redis_enterprise_cluster_api.md). + + +6. Redis Enterprise Cluster custom resource - `RedisEnterpriseCluster` + + Create a `RedisEnterpriseCluster`(REC) using the kustomize capability, + + ```bash + kubectl apply -k rec + ``` + + > Note: + The Operator can only manage one Redis Enterprise Cluster custom resource in a namespace. To deploy another Enterprise Clusters in the same Kubernetes cluster, deploy an Operator in an additional namespace for each additional Enterprise Cluster required. Note that each Enterprise Cluster can effectively host hundreds of Redis Database instances. Deploying multiple clusters is typically used for scenarios where complete operational isolation is required at the cluster level. + +7. Run ```kubectl get rec``` and verify creation was successful. `rec` is a shortcut for RedisEnterpriseCluster. The cluster takes around 5-10 minutes to come up. + A typical response may look like this: + ``` + NAME AGE + rec 5m + ``` + > Note: Once the cluster is up, the cluster GUI and API could be used to configure databases. It is recommended to use the K8s REDB API that is configured through the following steps. To configure the cluster using the cluster GUI/API, use the ui service created by the operator and the default credentials as set in a secret. The secret name is the same as the cluster name within the namespace. + + +*** For advanced configuration and more info you can visit our formal documentation [here](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/README.md). \ No newline at end of file diff --git a/google_private_cloud/bundle/kustomization.yaml b/google_private_cloud/bundle/kustomization.yaml new file mode 100644 index 0000000..d0304c1 --- /dev/null +++ b/google_private_cloud/bundle/kustomization.yaml @@ -0,0 +1,4 @@ +resources: +- bundle.yaml +patchesStrategicMerge: +- kustomize_bundle.yaml \ No newline at end of file diff --git a/google_private_cloud/rec/kustomization.yaml b/google_private_cloud/rec/kustomization.yaml new file mode 100644 index 0000000..619df3f --- /dev/null +++ b/google_private_cloud/rec/kustomization.yaml @@ -0,0 +1,4 @@ +resources: +- rec.yaml +patchesStrategicMerge: +- kustomize_rec.yaml \ No newline at end of file diff --git a/google_private_cloud/rec/kustomize_rec.yaml b/google_private_cloud/rec/kustomize_rec.yaml new file mode 100644 index 0000000..4b9d430 --- /dev/null +++ b/google_private_cloud/rec/kustomize_rec.yaml @@ -0,0 +1,19 @@ +apiVersion: app.redislabs.com/v1alpha1 +kind: RedisEnterpriseCluster +metadata: + name: rec + labels: + app: redis-enterprise +spec: + persistentSpec: + storageClassName: standard + volumeSize: 20Gi + redisEnterpriseImageSpec: + repository: [User redis Private repo] + versionTag: 6.4.2-61 + redisEnterpriseServicesRiggerImageSpec: + repository: [User service rigger Private repo] + versionTag: 6.4.2-5 + bootstrapperImageSpec: + repository: [User operator Private repo] + versionTag: 6.4.2-5 \ No newline at end of file diff --git a/google_private_cloud/rec/rec.yaml b/google_private_cloud/rec/rec.yaml new file mode 100644 index 0000000..3565a0f --- /dev/null +++ b/google_private_cloud/rec/rec.yaml @@ -0,0 +1,9 @@ +apiVersion: app.redislabs.com/v1 +kind: RedisEnterpriseCluster +metadata: + name: rec + labels: + app: redis-enterprise +spec: + # Add fields here + nodes: 3 diff --git a/log_collector/log_collector.py b/log_collector/log_collector.py index d0d91aa..6e025a3 100644 --- a/log_collector/log_collector.py +++ b/log_collector/log_collector.py @@ -29,7 +29,7 @@ logger = logging.getLogger(__name__) logger.setLevel(logging.INFO) logging.basicConfig(format='%(asctime)s - %(levelname)s - %(message)s') -VERSION_LOG_COLLECTOR = "6.4.2-4b" +VERSION_LOG_COLLECTOR = "6.4.2-5" TIME_FORMAT = time.strftime("%Y%m%d-%H%M%S") diff --git a/multi-namespace-redb/operator.yaml b/multi-namespace-redb/operator.yaml index 6e8c6c2..9738dc0 100644 --- a/multi-namespace-redb/operator.yaml +++ b/multi-namespace-redb/operator.yaml @@ -18,7 +18,7 @@ spec: serviceAccountName: redis-enterprise-operator containers: - name: redis-enterprise-operator - image: redislabs/operator:6.4.2-4 + image: redislabs/operator:6.4.2-5 command: - redis-enterprise-operator imagePullPolicy: Always @@ -60,7 +60,7 @@ spec: port: 8080 scheme: HTTP - name: admission - image: redislabs/operator:6.4.2-4 + image: redislabs/operator:6.4.2-5 command: - /usr/local/bin/admission imagePullPolicy: Always diff --git a/openshift.bundle.yaml b/openshift.bundle.yaml index 92eb9d1..9e42ecf 100644 --- a/openshift.bundle.yaml +++ b/openshift.bundle.yaml @@ -15485,7 +15485,7 @@ spec: serviceAccountName: redis-enterprise-operator containers: - name: redis-enterprise-operator - image: registry.connect.redhat.com/redislabs/redis-enterprise-operator:6.4.2-4 + image: registry.connect.redhat.com/redislabs/redis-enterprise-operator:6.4.2-5 securityContext: runAsUser: 1001 command: @@ -15531,7 +15531,7 @@ spec: port: 8080 scheme: HTTP - name: admission - image: registry.connect.redhat.com/redislabs/redis-enterprise-operator:6.4.2-4 + image: registry.connect.redhat.com/redislabs/redis-enterprise-operator:6.4.2-5 command: - /usr/local/bin/admission imagePullPolicy: Always diff --git a/openshift/operator_rhel.yaml b/openshift/operator_rhel.yaml index b5f5975..2cb0f66 100644 --- a/openshift/operator_rhel.yaml +++ b/openshift/operator_rhel.yaml @@ -18,7 +18,7 @@ spec: serviceAccountName: redis-enterprise-operator containers: - name: redis-enterprise-operator - image: registry.connect.redhat.com/redislabs/redis-enterprise-operator:6.4.2-4 + image: registry.connect.redhat.com/redislabs/redis-enterprise-operator:6.4.2-5 securityContext: runAsUser: 1001 command: @@ -64,7 +64,7 @@ spec: port: 8080 scheme: HTTP - name: admission - image: registry.connect.redhat.com/redislabs/redis-enterprise-operator:6.4.2-4 + image: registry.connect.redhat.com/redislabs/redis-enterprise-operator:6.4.2-5 command: - /usr/local/bin/admission imagePullPolicy: Always diff --git a/openshift/rec_rhel.yaml b/openshift/rec_rhel.yaml index f103bc7..35391ef 100644 --- a/openshift/rec_rhel.yaml +++ b/openshift/rec_rhel.yaml @@ -9,7 +9,7 @@ spec: nodes: 3 redisEnterpriseImageSpec: repository: registry.connect.redhat.com/redislabs/redis-enterprise - versionTag: 6.4.2-43.rhel8-openshift + versionTag: 6.4.2-61.rhel8-openshift redisEnterpriseServicesRiggerImageSpec: repository: registry.connect.redhat.com/redislabs/services-manager bootstrapperImageSpec: diff --git a/operator.yaml b/operator.yaml index 6e8c6c2..9738dc0 100644 --- a/operator.yaml +++ b/operator.yaml @@ -18,7 +18,7 @@ spec: serviceAccountName: redis-enterprise-operator containers: - name: redis-enterprise-operator - image: redislabs/operator:6.4.2-4 + image: redislabs/operator:6.4.2-5 command: - redis-enterprise-operator imagePullPolicy: Always @@ -60,7 +60,7 @@ spec: port: 8080 scheme: HTTP - name: admission - image: redislabs/operator:6.4.2-4 + image: redislabs/operator:6.4.2-5 command: - /usr/local/bin/admission imagePullPolicy: Always From c831a09df6eaff2cf81767b5c4a30f01269cb52c Mon Sep 17 00:00:00 2001 From: almoggue <87272937+almoggue@users.noreply.github.com> Date: Wed, 19 Apr 2023 17:13:40 +0300 Subject: [PATCH 2/6] Update .gitignore --- .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 5c3bdbb..485dee6 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -*bundle.yaml +.idea From 9d7aac4af3599558c2fc4ffebd6cb7155772a2f7 Mon Sep 17 00:00:00 2001 From: almoggue <87272937+almoggue@users.noreply.github.com> Date: Wed, 19 Apr 2023 17:16:10 +0300 Subject: [PATCH 3/6] Update active_active_database_readme.md --- active_active_database_readme.md | 332 +++++++++++++++++++++++++------ 1 file changed, 276 insertions(+), 56 deletions(-) diff --git a/active_active_database_readme.md b/active_active_database_readme.md index 9cd617c..8e25d14 100644 --- a/active_active_database_readme.md +++ b/active_active_database_readme.md @@ -4,9 +4,8 @@ This document describes how to deploy an Active-Active database with Redis Enterprise for Kubernetes. **Disclaimer:** - This feature is in private preview and is not complete for production use. - Importent - Please view the [support for only one Active-Active database with up-to three participating clusters across a set of participating clusters](#support-for-only-one-active-active-database-with-up-to-three-participating-clusters-across-a-set-of-participating-clusters) limitation. - + This feature is in public preview. + **This document assumes the following:** - You have at least two running Redis Enterprise clusters that will be used as your participating clusters. @@ -18,8 +17,11 @@ This document describes how to deploy an Active-Active database with Redis Enter * [Create a new Active-Active database](#create-a-new-active-active-database) * [Add participating cluster to an existing Active-Active database](#add-participating-cluster-to-an-existing-active-active-database) * [Remove participating cluster from an existing Active-Active database](#remove-participating-cluster-from-an-existing-active-active-database) + * [Set the database global configurations specifications](#set-the-database-global-configurations-specifications) + * [Set global database secret](#set-global-database-secret) * [Delete an existing Active-Active database](#delete-an-existing-active-active-database) * [Update existing participating cluster (RERC) details](#update-existing-participating-cluster-rerc-details) + * [Update existing participating cluster (RERC) secret](#update-existing-participating-cluster-rerc-secret) * [Test your Active-Active database](#test-your-active-active-database) * [Limitations](#limitations) @@ -45,8 +47,8 @@ Note: 1. Apply the following CRDs: ``` - kubectl apply -f reaadb_crd.yaml - kubectl apply -f rerc_crd.yaml + kubectl apply -f crds/reaadb_crd.yaml + kubectl apply -f crds/rerc_crd.yaml ``` Note: @@ -61,12 +63,15 @@ Note: 3. Configure a Ingress or Route, follow the instructions [here](setting_ingress_or_route_readme.md) +4. Configure ValidatingWebhookConfiguration, follow the instructions [here](admission/README.md) +Note: this is a must for managing Active-Active database via the operator. + #### Part 2: participating cluster info preparation setup Note: - * This part should be done always, even if the cluster is already configured to run the Redis Enterprise Operator managed active-active databases. + * This part should be done always, even if the cluster is already configured to run the Redis Enterprise Operator managed Active-Active databases. -1. Collect the REC credentials secret from all of the participating clusters, replase `` with the local REC name: +1. Collect the REC credentials secret from all of the participating clusters, replace `` with the local REC name: ``` kubectl get secret -o yaml ``` @@ -74,7 +79,7 @@ For example, collecting the secret of a Redis Enterprise Cluster named "rec1" t ``` kubectl get secret rec1 -o yaml ``` -Following is an example of a REC crdentials secret named "rec1" with namespace "ns1": +Following is an example of a REC credentials secret named "rec1" with namespace "ns1": ``` apiVersion: v1 data: @@ -100,8 +105,8 @@ metadata: type: Opaque ``` -2. For each of the secrets you collected, generate a new secret with the credentials data and name it with the following convention: `redis-enterprise--`, replace the `` and the `` with the Redis Enterprise cluster name and the namespace where it resides in respectively. -The new secret generated from the previous example of Redis Enterprise cluster named "rec1" that resides in "ns1" namespace should look as follows: +2. For each of the secrets you collected, generate a new secret with the credentials data and name it with the following convention: `redis-enterprise-`, replace the `` with the RERC name. +The new secret generated from the previous example of Redis Enterprise cluster named "rec1" that resides in "ns1" namespace that will be used for the RERC name: "rerc1" should look as follows: ``` apiVersion: v1 data: @@ -109,7 +114,7 @@ data: username: PHNvbWUgdXNlcj4 kind: Secret metadata: - name: redis-enterprise-rec1-ns1 + name: redis-enterprise-rerc1 type: Opaque ``` @@ -129,25 +134,29 @@ a. The example for a REC named "rec1" in the namespace "ns1": apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseRemoteCluster metadata: - name: rec1.ns1 + name: rerc1 spec: + recName: rec1 + recNamespace: ns1 apiFqdnUrl: test-example-api-rec1-ns1.redis.com dbFqdnSuffix: -example-cluster-rec1-ns1.redis.com - secretName: redis-enterprise-rec1-ns1 + secretName: redis-enterprise-rerc1 ``` b. The example for a REC named "rec2" in the namespace "ns2": ``` apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseRemoteCluster metadata: - name: rec2.ns2 + name: rerc2 spec: + recName: rec2 + recNamespace: ns2 apiFqdnUrl: test-example-api-rec2-ns2.redis.com - dbFqdnSuffix: -example-cluster-rec2.ns2.redis.com - secretName: redis-enterprise-rec2-ns2 + dbFqdnSuffix: -example-cluster-rec2-ns2.redis.com + secretName: redis-enterprise-rerc2 ``` -Note: +Notes: * View the Redis Enterprise Remote Cluster custom resource definition or the API doc for more details regarding the RERC fields. 2. Create the RERC custom resources you generated in the previous step and follow their statuses to verify the 'SPEC STATUS' is 'valid' and the 'STATUS' is 'active'. @@ -159,32 +168,32 @@ To follow the statuses of the applied RERC custom resources, run the following: ``` kubectl get rerc ``` -For example to view the status of the RERC named "rec1.ns1": +For example to view the status of the RERC named "rerc1": ``` - kubectl get rerc rec1.ns1 + kubectl get rerc rerc1 ``` The output should be as below: ``` NAME STATUS SPEC STATUS LOCAL - rec1.ns1 Active Valid true + rerc1 Active Valid true ``` Note: * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error, view the RERC custom resource events and the Redis Enterprise operator logs. 3. Generate the REAADB custom resource. -Following is an example of a REAADB custom resource named "example-aadb-1" that is linked to the REC named: "rec1" with two participating clusters. +Following is an example of a REAADB custom resource named "example-aadb-1" that is linked to the REC named: "rec1" with two participating clusters and database global configurations with shard count set to 3. ``` apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseActiveActiveDatabase metadata: name: example-aadb-1 spec: - redisEnterpriseCluster: - name: rec1 participatingClusters: - - name: rec1.ns1 - - name: rec2.ns2 + - name: rerc1 + - name: rerc2 + globalConfigurations: + shardCount: 3 ``` Notes: @@ -225,7 +234,7 @@ In addition, to view the RERCs for each RERC please run the following: ## Add participating cluster to an existing Active-Active database -**On the participating cluster you want to add in the namespace where the Redis Enterprise operator resides resides, please do the following:** +**On the participating cluster you want to add in the namespace where the Redis Enterprise operator resides, please do the following:** 1. Follow the instructions under: [Participating cluster preparation setup](#participating-cluster-preparation-setup). @@ -263,7 +272,7 @@ metadata: type: Opaque ``` -3. For the secret you collected generate a new secret with the credentials data and name it with the following convention: `redis-enterprise--`, replace the `` and the `` with the Redis Enterprise Cluster name and the namespace where it resides in respectively. +3. For the secret you collected generate a new secret with the credentials data and name it with the following convention: `redis-enterprise-`, replace the `` with the RERC name. The new example credentials secret generated from the Redis Enterprise cluster named "rec3" that resides in "ns3" namespace would look like this: ``` apiVersion: v1 @@ -272,7 +281,7 @@ data: username: PHNvbWUgdXNlcj4 kind: Secret metadata: - name: redis-enterprise-rec3-ns3 + name: redis-enterprise-rerc3 type: Opaque ``` @@ -289,11 +298,13 @@ Following is an example of a RERC custom resource to add that contains the parti apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseRemoteCluster metadata: - name: rec3.ns3 + name: rerc3 spec: + recName: rec3 + recNamespace: ns3 apiFqdnUrl: test-example-api-rec3-ns3.redis.com dbFqdnSuffix: -example-cluster-rec3-ns3.redis.com - secretName: redis-enterprise-rec3-ns3 + secretName: redis-enterprise-rerc3 ``` Note: @@ -309,23 +320,23 @@ To follow the statuses of the created rerc custom resources run the following: ``` kubectl get rerc ``` -For example, to view the status of the RERC named "rec3.ns3": +For example, to view the status of the RERC named "rerc3": ``` - kubectl get rerc rec3.ns3 + kubectl get rerc rerc3 ``` The output should be as below: ``` NAME STATUS SPEC STATUS LOCAL - rec3.ns3 Active Valid true + rerc3 Active Valid true ``` Note: * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct, in case of an error please view the RERC custom resource events and/ or the Redis Enterprise Operator logs. 3. Add and patch with the RERC name you created in the previous step on the 'participatingClusters' list in the REAADB spec. Follow the statuses to verify the 'SPEC STATUS' is 'valid' and the 'STATUS' is 'active'. -For example, adding to the REAADB named: "example-aadb-1" the RERC name: "rec3.ns3": +For example, adding to the REAADB named: "example-aadb-1" the RERC name: "rerc3": ``` - kubectl patch reaadb example-aadb-1 --type merge --patch '{"spec": {"participatingClusters": [{"name": "rec3.ns3"}]}}' + kubectl patch reaadb example-aadb-1 --type merge --patch '{"spec": {"participatingClusters": [{"name": "rerc3"}]}}' ``` 4. View the REAADB 'participatingClusters' status and verify that the added participating cluster exists with it's corresponding ID. @@ -339,7 +350,7 @@ For example, to get the REAADB named: "example-aadb-1" participating clusters st ``` Following is the output of the example above: ``` - [{"id":1,"name":"rec1.ns1"},{"id":2,"name":"rec2.ns2"},{"id":3,"name":"rec3.ns3"}] + [{"id":1,"name":"rerc1"},{"id":2,"name":"rerc2"},{"id":3,"name":"rerc3"}] ``` ## Remove participating cluster from an existing Active-Active database @@ -359,13 +370,13 @@ To follow the statuses of the REAADB custom resource run the following: ``` kubectl get reaadb -o=jsonpath='{.status}' ``` -For example, to view the status of the REAADB named "example-aadb-1" after remove the "rec3.ns3": +For example, to view the status of the REAADB named "example-aadb-1" after remove the "rerc3": ``` kubectl get reaadb example-aadb-1 -o=jsonpath='{.status}' ``` the output should be as below: ``` - {... ,"participatingClusters":[{"id":1,"name":"rec1.ns1"},{"id":2,"name":"rec2.ns2"}],"redisEnterpriseCluster":"rec1","specStatus":"Valid","status":"active"} + {... ,"participatingClusters":[{"id":1,"name":"rerc1"},{"id":2,"name":"rerc2"}],"redisEnterpriseCluster":"rec1","specStatus":"Valid","status":"active"} ``` **On the participating cluster that you removed do the following:** @@ -376,6 +387,115 @@ To get all the REAADB custom resources that exist, run the following: kubectl get reaadb -o=jsonpath='{range .items[*]}{.metadata.name}' ``` +## Set the database global configurations specifications + +Note: +the REAADB contains the field: '.spec.globalConfigurations' and through this the database configurations are set, for example the memory size and shard count. +For more information and all the fields please view the [REAADB API readme](redis_enterprise_active_active_database_api.md) + +**On one of the participating clusters that already exists do the following:** + +1. Set the global configurations on a REAADB. +For example, to patch a REAADB with global configurations with memory size set to 200 MB run the following: +``` + kubectl patch reaadb example-aadb-1 --type merge --patch '{"spec": {"globalConfigurations": {"memorySize": "200mb"}}}' +``` + +2. Follow the statuses of the created REAADB custom resource run the following: +``` + kubectl get reaadb +``` +For example, to view the status of the REAADB named "example-aadb-1": +``` + kubectl get reaadb example-aadb-1 +``` +The output should be as below: +``` + NAME STATUS SPEC STATUS GLOBAL CONFIGURATIONS REDB LINKED REDBS + example-aadb-1 active Valid +``` + +Note: + * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error status, view the REAADB custom resource events and the Redis Enterprise operator logs. + +5. View the global configurations that is synced on the REAADB on each of the participating clusters. +To get the REAADB run the following: +``` + kubectl get reaadb -o yaml +``` + +## Set global database secret + +Notes: +* the REAADB contains the field: '.spec.globalConfigurations' and through this the database secret is configured. +For more information and all the fields please view the [REAADB API readme](redis_enterprise_active_active_database_api.md) +* The database secret sync with the correct password on all of the participating clusters is the users' responsibility. + +**On one of the participating clusters that already exists do the following:** + +1. Generate the yaml containing the secret with the password data. +For example a secret named 'my-db-secret' with the password 'my-pass' as base 64 encoded: +``` +apiVersion: v1 +data: + password: bXktcGFzcw +kind: Secret +metadata: + name: my-db-secret +type: Opaque +``` + +2. Apply the generated secret from the previous step, replace `` with a file containing each new secret you generated in the previous step. +``` + kubectl apply -f +``` + +3. Set the database secret name on the REAADB spec (if not exist yet). +For example, to patch a REAADB named 'example-aadb-1' with the database secret from the previous steps on the global configurations run the following: +``` + kubectl patch reaadb example-aadb-1 --type merge --patch '{"spec": {"globalConfigurations": {"databaseSecretName": "my-db-secret"}}}' +``` + +4. Follow the statuses of the REAADB custom resource run the following: +``` + kubectl get reaadb +``` +For example, to view the status of the REAADB named "example-aadb-1": +``` + kubectl get reaadb example-aadb-1 +``` +The output should be as below: +``` + NAME STATUS SPEC STATUS GLOBAL CONFIGURATIONS REDB LINKED REDBS + example-aadb-1 active Valid +``` + +Note: + * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error status, view the REAADB custom resource events and the Redis Enterprise operator logs. + +**On the other participating clusters that already exists do the following:** + +1. View the secret status on the REAADB (on the other participating clusters). +To get the REAADB secrets status run the following: +``` + kubectl get reaadb -o=jsonpath='{.status.secretsStatus}' +``` +For example, to view the status of the REAADB named "example-aadb-1": +``` + kubectl get reaadb example-aadb-1 -o=jsonpath='{.status.secretsStatus}' +``` +The output should be as below (with the secret used in previous steps): +``` + [{"name":"my-db-secret","status":"Invalid"}] +``` + Note: as the secret status is 'Invalid' it means that the secret isn't synced yet on the participating cluster. + +2. Sync the secret on the other participating clusters. +Apply the generated secret from the previous steps, replace `` with a file containing the secret you generated in the previous step. +``` + kubectl apply -f +``` + ## Delete an existing Active-Active database **On one of the participating clusters that already exists do the following:** @@ -399,22 +519,22 @@ To get all the REAADB that exists run the following: **On the participating cluster you want to modify (with the local RERC) do the following:** 1. Patch the participating cluster corresponding local RERC that you want to update. -For example updating the DB FQDN suffix of an RERC named: "rec1.ns1": +For example updating the DB FQDN suffix of an RERC named: "rerc1": ``` - kubectl patch rerc rec1.ns1 --type merge --patch '{"spec": {"dbFqdnSuffix": "-example2-cluster-rec1-ns1.redis.com"}}' + kubectl patch rerc rerc1 --type merge --patch '{"spec": {"dbFqdnSuffix": "-example2-cluster-rec1-ns1.redis.com"}}' ``` To follow the statuses of the updated RERC custom resources run the following: ``` kubectl get rerc ``` -For example to view the status of the RERC named "rec1.ns1": +For example to view the status of the RERC named "rerc1": ``` - kubectl get rerc rec1.ns1 + kubectl get rerc rerc1 ``` The output should be as below: ``` NAME STATUS SPEC STATUS LOCAL - rec1.ns1 Active Valid true + rerc1 Active Valid true ``` Note: @@ -439,6 +559,106 @@ The output should be as below: Note: * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error status, view the REAADB custom resource events and the Redis Enterprise operator logs. +## Update existing participating cluster (RERC) secret + +Note: +* this is part of the "Changing the Redis Enterprise Cluster Credentials" that can be found [here](cluster_credentials.md) + +**On the participating cluster that you changed the REC secret (with the local RERC) do the following:** + +1. update the secret with the new credentials data and name it with the following convention: `redis-enterprise-`, replace the `` with the RERC name. +For example, a secret generated with the RERC name 'rerc1': +``` +apiVersion: v1 +data: + password: PHNvbWUgcGFzc3dvcmQ+ + username: PHNvbWUgdXNlcj4 +kind: Secret +metadata: + name: redis-enterprise-rerc1 +type: Opaque +``` + +2. Apply the generated secrets from the previous step, replace `` with a file containing each new secret you generated in the previous step. +``` + kubectl apply -f +``` + +3. Follow the RERC status and verify it is 'Active'. +To follow the statuses of the updated RERC custom resources run the following: +``` + kubectl get rerc +``` +For example to view the status of the RERC named "rerc1": +``` + kubectl get rerc rerc1 +``` +The output should be as below: +``` + NAME STATUS SPEC STATUS LOCAL + rerc1 Active Valid true +``` + +Note: + * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct, in case of an error please view the RERC custom resource events and/ or the Redis Enterprise operator logs. + +4. follow the REAADB custom resources statuses that are using this RERC to verify the 'SPEC STATUS' is 'valid' and the 'STATUS' is 'active'. +To view the statuses of the REAADB custom resources that is using this RERC run the following, replace `` with the list of REAADB that is using this RERC separated via spaces: +``` + kubectl get reaadb +``` +For example, to view the status of the REAADB named "example-aadb-1" and "example-aadb-2": +``` + kubectl get reaadb example-aadb-1 example-aadb-2 +``` +The output should be as below: +``` + NAME STATUS SPEC STATUS GLOBAL CONFIGURATIONS REDB LINKED REDBS + example-aadb-1 active Valid + example-aadb-2 active Valid +``` + +Note: + * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct. In case of an error status, view the REAADB custom resource events and the Redis Enterprise operator logs. + +**On the other clusters that are participating in the Active-Active database do the following:** + +1. update the secret with the new credentials data and name it with the following convention: `redis-enterprise-`, replace the `` with the RERC name. +For example, a secret generated with the RERC name 'rerc1': +``` +apiVersion: v1 +data: + password: PHNvbWUgcGFzc3dvcmQ+ + username: PHNvbWUgdXNlcj4 +kind: Secret +metadata: + name: redis-enterprise-rerc1 +type: Opaque +``` + +2. Apply the generated secrets from the previous step, replace `` with a file containing each new secret you generated in the previous step. +``` + kubectl apply -f +``` + +3. Follow the RERC status and verify it is 'Active'. +To follow the statuses of the updated RERC custom resources run the following: +``` + kubectl get rerc +``` +For example to view the status of the RERC named "rerc1": +``` + kubectl get rerc rerc1 +``` +The output should be as below: +``` + NAME STATUS SPEC STATUS LOCAL + rerc1 Active Valid true +``` + +Note: + * As the 'STATUS' and the 'SPEC STATUS' are 'Active' and 'Valid' respectively it means the configurations are correct, in case of an error please view the RERC custom resource events and/ or the Redis Enterprise operator logs. + ## Test your Active-Active database The easiest way to test your Active-Active database is to set a key-value pair in one database and retrieve it from the other. @@ -468,21 +688,21 @@ From the output fetch the redis 'targetPort': ## Limitations -### Support for only one Active-Active database with up-to three participating clusters across a set of participating clusters -Currently, there is only support for one managed Active-Active database, REAADB custom resource, with up-to three participating clusters across a set of participating clusters. -### No data path level configurations -Creating and updating the Active-Active database data level configurations (i.e. updating the DB size) is currently not supported via custom resources. -Updating an already created Active-Active database may be done through the RS API directly. +### No migration from the previous AA method +migrating Active-Active database with non-operator managed Active-Active database is currently not supported. -### Updating participating cluster secret -Updating the secret of a participating cluster is currently not supported via the operator, you may update it through the RS API directly and then modify the RERC secrets on all of the participating clusters. +### HashiCorp Vault secret storage +Storing the secrets in HashiCorp Vault is currently not supported for operator managed Active-Active database . -### Unique participating clusters REC name.namespace -The participating clusters `` must be different accross all of them. +### database version is currently not supported +Setting database specific version is currently not supported for operator managed Active-Active database . -### No REC upgrade -Upgrading Redis Enterprise cluster with operator managed Active-Active database is currently not supported. +### Modules are currently not supported +Redis modules are currently not supported for operator managed Active-Active database . -### HashiCorp Vault secret storage -Storing the secrets in HashiCorp Vault is currently not supported for operator managed Active-Active database . +### Backup are currently not supported +Database backups are currently not supported for operator managed Active-Active database . + +### client authentication certificates are currently not supported +client authentication certificates are currently not supported for operator managed Active-Active database . From 3619df363027f1a0b6be4609209bda0142ab1ce4 Mon Sep 17 00:00:00 2001 From: almoggue <87272937+almoggue@users.noreply.github.com> Date: Wed, 19 Apr 2023 17:16:48 +0300 Subject: [PATCH 4/6] Update cluster_credentials.md --- cluster_credentials.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/cluster_credentials.md b/cluster_credentials.md index e024bf7..7aa459a 100644 --- a/cluster_credentials.md +++ b/cluster_credentials.md @@ -39,7 +39,8 @@ Please follow the following steps: kubectl create secret generic --from-file=./username --from-file=./password --dry-run -o yaml | kubectl apply -f - ``` 5. Wait 5 minutes to make sure all components have read the new password from the updated secret -6. Exec into a Redis Enterprise Cluster node pod (see above) and run the following command to remove the previous password so only the new one applies. Important: replace OLD PASSWORD with the one being replaced, see step 1 above. +6. in case this cluster is participating in Active-Active database via REAADB follow the instructions [here](active_active_database_readme.md) under `Update existing participating cluster (RERC) secret`. +7. Exec into a Redis Enterprise Cluster node pod (see above) and run the following command to remove the previous password so only the new one applies. Important: replace OLD PASSWORD with the one being replaced, see step 1 above. ``` REC_USER="`cat /opt/redislabs/credentials/username`"; REC_PASSWORD="`cat /opt/redislabs/credentials/password`";curl -k --request DELETE --url https://localhost:9443/v1/users/password -u "$REC_USER:$REC_PASSWORD" --header 'Content-Type: application/json' --data "{\"username\":\"$REC_USER\",\"old_password\":\" Note: the username to be used with the K8s secret is the email displayed on the Redis Enterprise UI 5. Wait 5 minutes to make sure all components have read the new password from the updated secret -6. Delete the previous admin user using the Redis Enterprise Cluster UI +6. in case this cluster is participating in Active-Active database via REAADB follow the instructions [here](active_active_database_readme.md) under `Update existing participating cluster (RERC) secret`. +7. Delete the previous admin user using the Redis Enterprise Cluster UI > Note: this procedure is only supported for version 6.0.20-5 or above > Note: the operator might log errors in the time period between updating the username in the REC spec and the secret update From e59ea4c1ce9809e0aca7688fb507490b07697760 Mon Sep 17 00:00:00 2001 From: almoggue <87272937+almoggue@users.noreply.github.com> Date: Wed, 19 Apr 2023 17:17:25 +0300 Subject: [PATCH 5/6] Delete README.md --- crds/README.md | 30 ------------------------------ 1 file changed, 30 deletions(-) delete mode 100644 crds/README.md diff --git a/crds/README.md b/crds/README.md deleted file mode 100644 index 542f90e..0000000 --- a/crds/README.md +++ /dev/null @@ -1,30 +0,0 @@ -## CRD's Schema
- - -Purpose: -The schema is meant to ease the use of CRDs by restricting the fields to defined types and providing relevant description. - - -### Work Flow - How add a new field: -* Not all steps are always required - -#### 1. Update Tags: -In the files -+ `pkg/apis/app/v1alpha1/redisenterprisedatabase_types.go`
-+ `pkg/apis/app/v1alpha1/redisenterprisecluster_types.go`
-add tags on top of variables to mark allowed types (Enum)
-(see: https://book.kubebuilder.io/reference/markers/crd-validation.html).
-They will be used by the operator sdk when creating the scheme.
-**Default values** do not appear in the schema since the operator has its own default mechanism. - - -#### 2 .Create the schema: -1) Install operator-sdk version 0.17.2.
-See: https://sdk.operatorframework.io/docs/installation/install-operator-sdk/#install-from-github-release -2) Run `operator-sdk generate crds` - -#### 3. Update the schema: -- Edit the current schema in all of the relevant CRD yamls with the new section that was generated
-- Note that fields which are k8s objects might be very long - e.g. `SideContainersSpec` -in this case -
it appears in the schema but with no description in the fields since it extends the schema and is not unique for Redis Enterprise. - From 4f6c56c70867b3412b4ab73470667876dc02b47f Mon Sep 17 00:00:00 2001 From: almoggue <87272937+almoggue@users.noreply.github.com> Date: Wed, 19 Apr 2023 17:18:29 +0300 Subject: [PATCH 6/6] Delete google_private_cloud directory --- google_private_cloud/README.md | 100 ------------------ .../bundle/kustomization.yaml | 4 - google_private_cloud/rec/kustomization.yaml | 4 - google_private_cloud/rec/kustomize_rec.yaml | 19 ---- google_private_cloud/rec/rec.yaml | 9 -- 5 files changed, 136 deletions(-) delete mode 100644 google_private_cloud/README.md delete mode 100644 google_private_cloud/bundle/kustomization.yaml delete mode 100644 google_private_cloud/rec/kustomization.yaml delete mode 100644 google_private_cloud/rec/kustomize_rec.yaml delete mode 100644 google_private_cloud/rec/rec.yaml diff --git a/google_private_cloud/README.md b/google_private_cloud/README.md deleted file mode 100644 index 4fd2d4f..0000000 --- a/google_private_cloud/README.md +++ /dev/null @@ -1,100 +0,0 @@ - -# Deploying Redis Enterprise on Google Private Cloud - -This page describes how to deploy Redis Enterprise on Google Private Cloud Kubernetes solution using the Redis Enterprise Operator. - -### Prerequisites - -- A Kubernetes cluster version of 1.20 or higher, with a minimum of 3 worker nodes. -- A Kubernetes client (kubectl) with a matching version. -- Access to DockerHub, Harbor or a private repository that can serve the required images. - - - -The following are the images and tags for this release: - -| Component | k8s | -| --- | --- | -| Redis Enterprise | `redislabs/redis:6.4.2-61` | -| Operator | `redislabs/operator:6.4.2-5` | -| Services Rigger | `redislabs/k8s-controller:6.4.2-5` | - - -### Installation -The "Basic" installation deploys the operator (from the current release) from DockerHub and default settings. -This is the fastest way to get up and running with a new Redis Enterprise on Kubernetes. - -1. We will need to clone the yamls from [github](https://github.com/RedisLabs/redis-enterprise-k8s-docs/releases) to your local directory. - -2. Create a new namespace: - > Note: - For the purpose of this doc, we'll use the name "demo" for our cluster's namespace. - - ```bash - kubectl create namespace demo - ``` - - Switch context to the newly created namespace: - - ```bash - kubectl config set-context --current --namespace=demo - ``` -*** -For deploying the bundle and the Redis Enterprise Cluster custom resource we will use the [Kustomize](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/). -3. Customize the operator deployment - - - Before deploying the bundle.yaml we will need to customize it . - edit the `bundle\kustomize_bundle.yaml` file : - > Note: - Replace the [User Private repo] with your private images repository location. - -4. Deploy the operator bundle - - with `kubectl`, the following command will deploy a bundle of all the yaml declarations required for the operator: - - ```bash - kubectl apply -k bundle - ``` - - Run `kubectl get deployment` and verify redis-enterprise-operator deployment is running. - - A typical response may look like this: - - ```bash - NAME READY UP-TO-DATE AVAILABLE AGE - redis-enterprise-operator 1/1 1 1 2m - ``` - -5. Customize the Redis Enterprise Cluster custom resource - - - Before deploying the rec.yaml we will need to customize it . - edit the `rec\kustomize_rec.yaml` file : - > Note: - Replace the [User Private repo] with your private images repository location. - - The kustomize_rec.yaml configure the Redis Enterprise Cluster custom resource with the default configuration, - which is suitable for development type deployments and works in typical scenarios. - The full list of attributes supported through the Redis Enterprise Cluster (REC) API can be found [HERE](redis_enterprise_cluster_api.md). - - -6. Redis Enterprise Cluster custom resource - `RedisEnterpriseCluster` - - Create a `RedisEnterpriseCluster`(REC) using the kustomize capability, - - ```bash - kubectl apply -k rec - ``` - - > Note: - The Operator can only manage one Redis Enterprise Cluster custom resource in a namespace. To deploy another Enterprise Clusters in the same Kubernetes cluster, deploy an Operator in an additional namespace for each additional Enterprise Cluster required. Note that each Enterprise Cluster can effectively host hundreds of Redis Database instances. Deploying multiple clusters is typically used for scenarios where complete operational isolation is required at the cluster level. - -7. Run ```kubectl get rec``` and verify creation was successful. `rec` is a shortcut for RedisEnterpriseCluster. The cluster takes around 5-10 minutes to come up. - A typical response may look like this: - ``` - NAME AGE - rec 5m - ``` - > Note: Once the cluster is up, the cluster GUI and API could be used to configure databases. It is recommended to use the K8s REDB API that is configured through the following steps. To configure the cluster using the cluster GUI/API, use the ui service created by the operator and the default credentials as set in a secret. The secret name is the same as the cluster name within the namespace. - - -*** For advanced configuration and more info you can visit our formal documentation [here](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/README.md). \ No newline at end of file diff --git a/google_private_cloud/bundle/kustomization.yaml b/google_private_cloud/bundle/kustomization.yaml deleted file mode 100644 index d0304c1..0000000 --- a/google_private_cloud/bundle/kustomization.yaml +++ /dev/null @@ -1,4 +0,0 @@ -resources: -- bundle.yaml -patchesStrategicMerge: -- kustomize_bundle.yaml \ No newline at end of file diff --git a/google_private_cloud/rec/kustomization.yaml b/google_private_cloud/rec/kustomization.yaml deleted file mode 100644 index 619df3f..0000000 --- a/google_private_cloud/rec/kustomization.yaml +++ /dev/null @@ -1,4 +0,0 @@ -resources: -- rec.yaml -patchesStrategicMerge: -- kustomize_rec.yaml \ No newline at end of file diff --git a/google_private_cloud/rec/kustomize_rec.yaml b/google_private_cloud/rec/kustomize_rec.yaml deleted file mode 100644 index 4b9d430..0000000 --- a/google_private_cloud/rec/kustomize_rec.yaml +++ /dev/null @@ -1,19 +0,0 @@ -apiVersion: app.redislabs.com/v1alpha1 -kind: RedisEnterpriseCluster -metadata: - name: rec - labels: - app: redis-enterprise -spec: - persistentSpec: - storageClassName: standard - volumeSize: 20Gi - redisEnterpriseImageSpec: - repository: [User redis Private repo] - versionTag: 6.4.2-61 - redisEnterpriseServicesRiggerImageSpec: - repository: [User service rigger Private repo] - versionTag: 6.4.2-5 - bootstrapperImageSpec: - repository: [User operator Private repo] - versionTag: 6.4.2-5 \ No newline at end of file diff --git a/google_private_cloud/rec/rec.yaml b/google_private_cloud/rec/rec.yaml deleted file mode 100644 index 3565a0f..0000000 --- a/google_private_cloud/rec/rec.yaml +++ /dev/null @@ -1,9 +0,0 @@ -apiVersion: app.redislabs.com/v1 -kind: RedisEnterpriseCluster -metadata: - name: rec - labels: - app: redis-enterprise -spec: - # Add fields here - nodes: 3