diff --git a/docs/guides/rabbitmq/concepts/appbinding.md b/docs/guides/rabbitmq/concepts/appbinding.md index ec49c19f59..789d2aee38 100644 --- a/docs/guides/rabbitmq/concepts/appbinding.md +++ b/docs/guides/rabbitmq/concepts/appbinding.md @@ -2,7 +2,7 @@ title: AppBinding CRD menu: docs_{{ .version }}: - identifier: rm-appbinding-concepts + identifier: rm-appbinding name: AppBinding parent: rm-concepts-guides weight: 20 @@ -32,8 +32,8 @@ kind: AppBinding metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"kubedb.com/v1alpha2","kind":"RabbitMQ","metadata":{"annotations":{},"name":"rabbitmq","namespace":"demo"},"spec":{"deletionPolicy":"WipeOut","replicas":3,"storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}},"storageClassName":"standard"},"storageType":"Durable","version":"3.13.2"}} - creationTimestamp: "2024-07-09T10:16:01Z" + {"apiVersion":"kubedb.com/v1alpha2","kind":"RabbitMQ","metadata":{"annotations":{},"name":"rabbitmq","namespace":"rabbit"},"spec":{"deletionPolicy":"WipeOut","podTemplate":{"spec":{"containers":[{"name":"rabbitmq","resources":{"limits":{"cpu":"600m","memory":"1.5Gi"},"requests":{"cpu":"500m"}}}]}},"replicas":3,"storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}},"storageClassName":"standard"},"storageType":"Durable","version":"3.13.2"}} + creationTimestamp: "2024-09-05T19:30:24Z" generation: 1 labels: app.kubernetes.io/component: database @@ -41,27 +41,28 @@ metadata: app.kubernetes.io/managed-by: kubedb.com app.kubernetes.io/name: rabbitmqs.kubedb.com name: rabbitmq - namespace: demo + namespace: rabbit ownerReferences: - apiVersion: kubedb.com/v1alpha2 blockOwnerDeletion: true controller: true kind: RabbitMQ name: rabbitmq - uid: a8c4e284-e9ec-41d1-ad5e-646e3209d3bf - resourceVersion: "289308" - uid: 55b11491-9c3b-4aaf-93a3-17deb62593f0 + uid: 5555cd04-d124-42c4-93b7-6a71f9fdd653 + resourceVersion: "262736" + uid: 95801d5d-1d25-4251-88c2-27dd2ea9860e spec: appRef: apiGroup: kubedb.com kind: RabbitMQ name: rabbitmq - namespace: demo + namespace: rabbit clientConfig: service: name: rabbitmq port: 5672 scheme: http + url: amqp://:@rabbitmq.rabbit.svc.cluster.local:5672/ secret: name: rabbitmq-admin-cred type: kubedb.com/rabbitmq diff --git a/docs/guides/rabbitmq/concepts/autoscaler.md b/docs/guides/rabbitmq/concepts/autoscaler.md index a854479d73..79d0a6c641 100644 --- a/docs/guides/rabbitmq/concepts/autoscaler.md +++ b/docs/guides/rabbitmq/concepts/autoscaler.md @@ -2,7 +2,7 @@ title: RabbitMQAutoscaler CRD menu: docs_{{ .version }}: - identifier: rm-autoscaler-concepts + identifier: rm-autoscaler name: RabbitMQAutoscaler parent: rm-concepts-guides weight: 26 @@ -24,147 +24,39 @@ Like any official Kubernetes resource, a `RabbitMQAutoscaler` has `TypeMeta`, `O Here, some sample `RabbitMQAutoscaler` CROs for autoscaling different components of database is given below: -**Sample `RabbitMQAutoscaler` for standalone database:** +**Sample `RabbitMQAutoscaler`:** ```yaml apiVersion: autoscaling.kubedb.com/v1alpha1 kind: RabbitMQAutoscaler metadata: - name: mg-as - namespace: demo + name: rabbitmq-autoscaler + namespace: rabbit spec: databaseRef: - name: mg-standalone + name: rabbitmq opsRequestOptions: - readinessCriteria: - oplogMaxLagSeconds: 20 - objectsCountDiffPercentage: 10 timeout: 3m apply: IfReady compute: - standalone: + rabbitmq: trigger: "On" - podLifeTimeThreshold: 24h + podLifeTimeThreshold: 5m + resourceDiffPercentage: 20 minAllowed: - cpu: 250m - memory: 350Mi - maxAllowed: - cpu: 1 - memory: 1Gi - controlledResources: ["cpu", "memory"] - containerControlledValues: "RequestsAndLimits" - resourceDiffPercentage: 10 - storage: - standalone: - expansionMode: "Online" - trigger: "On" - usageThreshold: 60 - scalingThreshold: 50 -``` - -**Sample `RabbitMQAutoscaler` for replicaset database:** - -```yaml -apiVersion: autoscaling.kubedb.com/v1alpha1 -kind: RabbitMQAutoscaler -metadata: - name: mg-as-rs - namespace: demo -spec: - databaseRef: - name: mg-rs - opsRequestOptions: - readinessCriteria: - oplogMaxLagSeconds: 20 - objectsCountDiffPercentage: 10 - timeout: 3m - apply: IfReady - compute: - replicaSet: - trigger: "On" - podLifeTimeThreshold: 24h - minAllowed: - cpu: 200m - memory: 300Mi - maxAllowed: - cpu: 1 - memory: 1Gi - controlledResources: ["cpu", "memory"] - containerControlledValues: "RequestsAndLimits" - resourceDiffPercentage: 10 - storage: - replicaSet: - expansionMode: "Online" - trigger: "On" - usageThreshold: 60 - scalingThreshold: 50 -``` - -**Sample `RabbitMQAutoscaler` for sharded database:** - -```yaml -apiVersion: autoscaling.kubedb.com/v1alpha1 -kind: RabbitMQAutoscaler -metadata: - name: mg-as-sh - namespace: demo -spec: - databaseRef: - name: mg-sh - opsRequestOptions: - readinessCriteria: - oplogMaxLagSeconds: 20 - objectsCountDiffPercentage: 10 - timeout: 3m - apply: IfReady - compute: - shard: - trigger: "On" - podLifeTimeThreshold: 24h - minAllowed: - cpu: 250m - memory: 350Mi - maxAllowed: - cpu: 1 - memory: 1Gi - controlledResources: ["cpu", "memory"] - containerControlledValues: "RequestsAndLimits" - resourceDiffPercentage: 10 - configServer: - trigger: "On" - podLifeTimeThreshold: 24h - minAllowed: - cpu: 250m - memory: 350Mi - maxAllowed: cpu: 1 - memory: 1Gi - controlledResources: ["cpu", "memory"] - containerControlledValues: "RequestsAndLimits" - resourceDiffPercentage: 10 - mongos: - trigger: "On" - podLifeTimeThreshold: 24h - minAllowed: - cpu: 250m - memory: 350Mi + memory: "1.5Gi" maxAllowed: - cpu: 1 - memory: 1Gi + cpu: 2 + memory: 5Gi controlledResources: ["cpu", "memory"] containerControlledValues: "RequestsAndLimits" - resourceDiffPercentage: 10 storage: - shard: - expansionMode: "Online" - trigger: "On" - usageThreshold: 60 - scalingThreshold: 50 - configServer: - expansionMode: "Online" + rabbitmq: + expansionMode: "Offline" trigger: "On" - usageThreshold: 60 - scalingThreshold: 50 + usageThreshold: 20 + scalingThreshold: 30 ``` Here, we are going to describe the various sections of a `RabbitMQAutoscaler` crd. @@ -173,25 +65,13 @@ A `RabbitMQAutoscaler` object has the following fields in the `spec` section. ### spec.databaseRef -`spec.databaseRef` is a required field that point to the [RabbitMQ](/docs/guides/RabbitMQ/concepts/RabbitMQ.md) object for which the autoscaling will be performed. This field consists of the following sub-field: +`spec.databaseRef` is a required field that point to the [RabbitMQ](/docs/guides/rabbitmq/concepts/rabbitmq.md) object for which the autoscaling will be performed. This field consists of the following sub-field: -- **spec.databaseRef.name :** specifies the name of the [RabbitMQ](/docs/guides/RabbitMQ/concepts/RabbitMQ.md) object. - -### spec.opsRequestOptions -These are the options to pass in the internally created opsRequest CRO. `opsRequestOptions` has three fields. They have been described in details [here](/docs/guides/RabbitMQ/concepts/opsrequest.md#specreadinesscriteria). +- **spec.databaseRef.name :** specifies the name of the [RabbitMQ](/docs/guides/rabbitmq/concepts/rabbitmq.md) object. ### spec.compute -`spec.compute` specifies the autoscaling configuration for the compute resources i.e. cpu and memory of the database components. This field consists of the following sub-field: - -- `spec.compute.standalone` indicates the desired compute autoscaling configuration for a standalone RabbitMQ database. -- `spec.compute.replicaSet` indicates the desired compute autoscaling configuration for replicaSet of a RabbitMQ database. -- `spec.compute.configServer` indicates the desired compute autoscaling configuration for config servers of a sharded RabbitMQ database. -- `spec.compute.mongos` indicates the desired compute autoscaling configuration for the mongos nodes of a sharded RabbitMQ database. -- `spec.compute.shard` indicates the desired compute autoscaling configuration for the shard nodes of a sharded RabbitMQ database. -- `spec.compute.arbiter` indicates the desired compute autoscaling configuration for the arbiter node. - -All of them has the following sub-fields: +`spec.compute` specifies the autoscaling configuration for the compute resources i.e. cpu and memory of the database components. It has the following sub-fields: - `trigger` indicates if compute autoscaling is enabled for this component of the database. If "On" then compute autoscaling is enabled. If "Off" then compute autoscaling is disabled. - `minAllowed` specifies the minimal amount of resources that will be recommended, default is no minimum. @@ -209,13 +89,6 @@ There are two more fields, those are only specifiable for the percona variant in `spec.compute` specifies the autoscaling configuration for the storage resources of the database components. This field consists of the following sub-field: -- `spec.compute.standalone` indicates the desired storage autoscaling configuration for a standalone RabbitMQ database. -- `spec.compute.replicaSet` indicates the desired storage autoscaling configuration for replicaSet of a RabbitMQ database. -- `spec.compute.configServer` indicates the desired storage autoscaling configuration for config servers of a sharded RabbitMQ database. -- `spec.compute.shard` indicates the desired storage autoscaling configuration for the shard nodes of a sharded RabbitMQ database. - -All of them has the following sub-fields: - - `trigger` indicates if storage autoscaling is enabled for this component of the database. If "On" then storage autoscaling is enabled. If "Off" then storage autoscaling is disabled. - `usageThreshold` indicates usage percentage threshold, if the current storage usage exceeds then storage autoscaling will be triggered. - `scalingThreshold` indicates the percentage of the current storage that will be scaled. diff --git a/docs/guides/rabbitmq/concepts/catalog.md b/docs/guides/rabbitmq/concepts/catalog.md index 0d78ff221c..3f48f46445 100644 --- a/docs/guides/rabbitmq/concepts/catalog.md +++ b/docs/guides/rabbitmq/concepts/catalog.md @@ -2,9 +2,9 @@ title: RabbitMQVersion CRD menu: docs_{{ .version }}: - identifier: mg-catalog-concepts + identifier: rm-catalog name: RabbitMQVersion - parent: mg-concepts-RabbitMQ + parent: rm-concepts-guides weight: 15 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/rabbitmq/concepts/opsrequest.md b/docs/guides/rabbitmq/concepts/opsrequest.md index 69739e286d..bb5eeaa0d5 100644 --- a/docs/guides/rabbitmq/concepts/opsrequest.md +++ b/docs/guides/rabbitmq/concepts/opsrequest.md @@ -2,9 +2,9 @@ title: RabbitMQOpsRequests CRD menu: docs_{{ .version }}: - identifier: mg-opsrequest-concepts + identifier: rm-opsrequest name: RabbitMQOpsRequest - parent: mg-concepts-RabbitMQ + parent: rm-concepts-guides weight: 25 menu_name: docs_{{ .version }} section_menu_id: guides @@ -30,484 +30,145 @@ Here, some sample `RabbitMQOpsRequest` CRs for different administrative operatio apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-update + name: rabbitmq-upgrade namespace: demo spec: type: UpdateVersion databaseRef: - name: mg-standalone + name: rabbitmq updateVersion: - targetVersion: 4.4.26 -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful + targetVersion: 3.13.2 ``` -**Sample `RabbitMQOpsRequest` Objects for Horizontal Scaling of different component of the database:** +**Sample `RabbitMQOpsRequest` Objects for Horizontal Scaling of the database Cluster:** ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-hscale-configserver - namespace: demo + name: rabbitmq-hscale-up + namespace: rabbit spec: type: HorizontalScaling databaseRef: - name: mg-sharding + name: rabbitmq horizontalScaling: - shard: - shards: 3 - replicas: 3 - configServer: - replicas: 3 - mongos: - replicas: 2 -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful + node: 3 ``` -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-hscale-down-replicaset - namespace: demo -spec: - type: HorizontalScaling - databaseRef: - name: mg-replicaset - horizontalScaling: - replicas: 3 -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful -``` - -**Sample `RabbitMQOpsRequest` Objects for Vertical Scaling of different component of the database:** +**Sample `RabbitMQOpsRequest` Objects for Vertical Scaling of the database cluster:** ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-vscale-configserver + name: rabbitmq-vscale namespace: demo spec: type: VerticalScaling databaseRef: - name: mg-sharding + name: rabbitmq verticalScaling: - configServer: - resources: - requests: - memory: "150Mi" - cpu: "0.1" - limits: - memory: "250Mi" - cpu: "0.2" - mongos: - resources: - requests: - memory: "150Mi" - cpu: "0.1" - limits: - memory: "250Mi" - cpu: "0.2" - shard: + node: resources: requests: - memory: "150Mi" - cpu: "0.1" - limits: - memory: "250Mi" - cpu: "0.2" -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful + cpu: 600m + memory: 1.2Gi ``` -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-vscale-standalone - namespace: demo -spec: - type: VerticalScaling - databaseRef: - name: mg-standalone - verticalScaling: - standalone: - resources: - requests: - memory: "150Mi" - cpu: "0.1" - limits: - memory: "250Mi" - cpu: "0.2" -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful -``` +**Sample `RabbitMQOpsRequest` Objects for Reconfiguring database cluster:** ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-vscale-replicaset - namespace: demo -spec: - type: VerticalScaling - databaseRef: - name: mg-replicaset - verticalScaling: - replicaSet: - resources: - requests: - memory: "150Mi" - cpu: "0.1" - limits: - memory: "250Mi" - cpu: "0.2" -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful -``` - -**Sample `RabbitMQOpsRequest` Objects for Reconfiguring different database components:** - -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-reconfiugre-data-replicaset + name: rabbitmq-reconfigure namespace: demo spec: type: Reconfigure databaseRef: - name: mg-replicaset + name: rabbitmq configuration: - replicaSet: - applyConfig: - mongod.conf: |- - net: - maxIncomingConnections: 30000 -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful + applyConfig: + rabbitmq.conf: |- + default_vhost = /customvhost ``` ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-reconfiugre-data-shard + name: rabbitmq-reconfigure namespace: demo spec: type: Reconfigure databaseRef: - name: mg-sharding + name: rabbitmq configuration: - shard: - applyConfig: - mongod.conf: |- - net: - maxIncomingConnections: 30000 - configServer: - applyConfig: - mongod.conf: |- - net: - maxIncomingConnections: 30000 - mongos: - applyConfig: - mongod.conf: |- - net: - maxIncomingConnections: 30000 -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful + removeCustomConfig: true ``` ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-reconfiugre-data-standalone + name: rabbitmq-reconfigure namespace: demo spec: type: Reconfigure databaseRef: - name: mg-standalone + name: rabbitmq configuration: - standalone: - applyConfig: - mongod.conf: |- - net: - maxIncomingConnections: 30000 -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful + configSecret: + name: new-custom-config ``` -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-reconfiugre-replicaset - namespace: demo -spec: - type: Reconfigure - databaseRef: - name: mg-replicaset - configuration: - replicaSet: - configSecret: - name: new-custom-config -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful -``` +**Sample `RabbitMQOpsRequest` Objects for Volume Expansion of database cluster:** ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-reconfiugre-shard - namespace: demo -spec: - type: Reconfigure - databaseRef: - name: mg-sharding - configuration: - shard: - configSecret: - name: new-custom-config - configServer: - configSecret: - name: new-custom-config - mongos: - configSecret: - name: new-custom-config -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful -``` - -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-reconfiugre-standalone - namespace: demo -spec: - type: Reconfigure - databaseRef: - name: mg-standalone - configuration: - standalone: - configSecret: - name: new-custom-config -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful -``` - -**Sample `RabbitMQOpsRequest` Objects for Volume Expansion of different database components:** - -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-volume-exp-replicaset - namespace: demo + name: rm-online-volume-expansion + namespace: rabbit spec: + ifReady: "Always" type: VolumeExpansion databaseRef: - name: mg-replicaset + name: rabbitmq volumeExpansion: mode: "Online" - replicaSet: 2Gi -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful + node: 1.5Gi ``` -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-volume-exp-shard - namespace: demo -spec: - type: VolumeExpansion - databaseRef: - name: mg-sharding - volumeExpansion: - mode: "Online" - shard: 2Gi - configServer: 2Gi -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful -``` +**Sample `RabbitMQOpsRequest` Objects for Reconfiguring TLS of the database:** ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-volume-exp-standalone + name: rabbitmq-offline-volume-expansion namespace: demo spec: + apply: "Always" type: VolumeExpansion databaseRef: - name: mg-standalone + name: rabbitmq volumeExpansion: - mode: "Online" - standalone: 2Gi -status: - conditions: - - lastTransitionTime: "2020-08-25T18:22:38Z" - message: Successfully completed the modification process - observedGeneration: 1 - reason: Successful - status: "True" - type: Successful - observedGeneration: 1 - phase: Successful + mode: "Offline" + node: 1.5Gi ``` -**Sample `RabbitMQOpsRequest` Objects for Reconfiguring TLS of the database:** - ```yaml apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-add-tls + name: rabbitmq-cert-rotate namespace: demo spec: type: ReconfigureTLS databaseRef: - name: mg-rs - tls: - issuerRef: - name: mg-issuer - kind: Issuer - apiGroup: "cert-manager.io" - certificates: - - alias: client - emailAddresses: - - abc@appscode.com -``` - -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-rotate - namespace: demo -spec: - type: ReconfigureTLS - databaseRef: - name: mg-rs + name: rabbitmq tls: rotateCertificates: true ``` @@ -516,15 +177,15 @@ spec: apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-change-issuer + name: rabbitmq-change-cert-issuer namespace: demo spec: type: ReconfigureTLS databaseRef: - name: mg-rs + name: rabbitmq tls: issuerRef: - name: mg-new-issuer + name: rabbit-new-issuer kind: Issuer apiGroup: "cert-manager.io" ``` @@ -533,12 +194,12 @@ spec: apiVersion: ops.kubedb.com/v1alpha1 kind: RabbitMQOpsRequest metadata: - name: mops-remove + name: rabbitmq-cert-remove namespace: demo spec: type: ReconfigureTLS databaseRef: - name: mg-rs + name: rabbitmq tls: remove: true ``` @@ -549,9 +210,9 @@ A `RabbitMQOpsRequest` object has the following fields in the `spec` section. ### spec.databaseRef -`spec.databaseRef` is a required field that point to the [RabbitMQ](/docs/guides/RabbitMQ/concepts/RabbitMQ.md) object for which the administrative operations will be performed. This field consists of the following sub-field: +`spec.databaseRef` is a required field that point to the [RabbitMQ](/docs/guides/rabbitmq/concepts/rabbitmq.md) object for which the administrative operations will be performed. This field consists of the following sub-field: -- **spec.databaseRef.name :** specifies the name of the [RabbitMQ](/docs/guides/RabbitMQ/concepts/RabbitMQ.md) object. +- **spec.databaseRef.name :** specifies the name of the [RabbitMQ](/docs/guides/rabbitmq/concepts/rabbitmq.md) object. ### spec.type @@ -565,56 +226,38 @@ A `RabbitMQOpsRequest` object has the following fields in the `spec` section. - `ReconfigureTLS` - `Restart` -> You can perform only one type of operation on a single `RabbitMQOpsRequest` CR. For example, if you want to update your database and scale up its replica then you have to create two separate `RabbitMQOpsRequest`. At first, you have to create a `RabbitMQOpsRequest` for updating. Once it is completed, then you can create another `RabbitMQOpsRequest` for scaling. +> You can perform only one type of operation on a single `RabbitMQOpsRequest` CR. For example, if you want to update your database and scale up its replica then you have to create two separate `RabbitMQOpsRequest`. At first, you have to create a `RabbitMQOpsRequest` for updating. Once it is completed, then you can create another `RabbitMQOpsRequest` for scaling. > Note: There is an exception to the above statement. It is possible to specify both `spec.configuration` & `spec.verticalScaling` in a OpsRequest of type `VerticalScaling`. ### spec.updateVersion -If you want to update you RabbitMQ version, you have to specify the `spec.updateVersion` section that specifies the desired version information. This field consists of the following sub-field: +If you want to update your RabbitMQ version, you have to specify the `spec.updateVersion` section that specifies the desired version information. This field consists of the following sub-field: -- `spec.updateVersion.targetVersion` refers to a [RabbitMQVersion](/docs/guides/RabbitMQ/concepts/catalog.md) CR that contains the RabbitMQ version information where you want to update. +- `spec.updateVersion.targetVersion` refers to a [RabbitMQVersion](/docs/guides/rabbitmq/concepts/catalog.md) CR that contains the RabbitMQ version information where you want to update. -Have a look on the [`updateConstraints`](/docs/guides/RabbitMQ/concepts/catalog.md#specupdateconstraints) of the RabbitMQVersion spec to know which versions are supported for updating from the current version. -```yaml -kubectl get mgversion -o=jsonpath='{.spec.updateConstraints}' | jq -``` - -> You can only update between RabbitMQ versions. KubeDB does not support downgrade for RabbitMQ. ### spec.horizontalScaling If you want to scale-up or scale-down your RabbitMQ cluster or different components of it, you have to specify `spec.horizontalScaling` section. This field consists of the following sub-field: -- `spec.horizontalScaling.replicas` indicates the desired number of nodes for RabbitMQ replicaset cluster after scaling. For example, if your cluster currently has 4 replicaset nodes, and you want to add additional 2 nodes then you have to specify 6 in `spec.horizontalScaling.replicas` field. Similarly, if you want to remove one node from the cluster, you have to specify 3 in `spec.horizontalScaling.replicas` field. -- `spec.horizontalScaling.configServer.replicas` indicates the desired number of ConfigServer nodes for Sharded RabbitMQ cluster after scaling. -- `spec.horizontalScaling.mongos.replicas` indicates the desired number of Mongos nodes for Sharded RabbitMQ cluster after scaling. -- `spec.horizontalScaling.shard` indicates the configuration of shard nodes for Sharded RabbitMQ cluster after scaling. This field consists of the following sub-field: - - `spec.horizontalScaling.shard.replicas` indicates the number of replicas each shard will have after scaling. - - `spec.horizontalScaling.shard.shards` indicates the number of shards after scaling +- `spec.horizontalScaling.node` indicates the desired number of pods for RabbitMQ cluster after scaling. For example, if your cluster currently has 4 pods, and you want to add additional 2 pods then you have to specify 6 in `spec.horizontalScaling.node` field. Similarly, if you want to remove one pod from the cluster, you have to specify 3 in `spec.horizontalScaling.node` field. ### spec.verticalScaling -`spec.verticalScaling` is a required field specifying the information of `RabbitMQ` resources like `cpu`, `memory` etc that will be scaled. This field consists of the following sub-fields: +`spec.verticalScaling` is a required field specifying the information of `RabbitMQ` resources like `cpu`, `memory` etc. that will be scaled. This field consists of the following sub-fields: -- `spec.verticalScaling.standalone` indicates the desired resources for standalone RabbitMQ database after scaling. -- `spec.verticalScaling.replicaSet` indicates the desired resources for replicaSet of RabbitMQ database after scaling. -- `spec.verticalScaling.mongos` indicates the desired resources for Mongos nodes of Sharded RabbitMQ database after scaling. -- `spec.verticalScaling.configServer` indicates the desired resources for ConfigServer nodes of Sharded RabbitMQ database after scaling. -- `spec.verticalScaling.shard` indicates the desired resources for Shard nodes of Sharded RabbitMQ database after scaling. -- `spec.verticalScaling.exporter` indicates the desired resources for the `exporter` container. -- `spec.verticalScaling.arbiter` indicates the desired resources for arbiter node of RabbitMQ database after scaling. -- `spec.verticalScaling.coordinator` indicates the desired resources for the coordinator container. +- `spec.verticalScaling.node` indicates the desired resources for PetSet of RabbitMQ after scaling. -All of them has the below structure: +It has the below structure: ```yaml requests: - memory: "200Mi" - cpu: "0.1" + memory: "600Mi" + cpu: "0.5" limits: - memory: "300Mi" - cpu: "0.2" + memory: "800Mi" + cpu: "0.8" ``` Here, when you specify the resource request, the scheduler uses this information to decide which node to place the container of the Pod on and when you specify a resource limit for the container, the `kubelet` enforces those limits so that the running container is not allowed to use more of that resource than the limit you set. You can found more details from [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). @@ -623,90 +266,54 @@ Here, when you specify the resource request, the scheduler uses this information > To use the volume expansion feature the storage class must support volume expansion -If you want to expand the volume of your RabbitMQ cluster or different components of it, you have to specify `spec.volumeExpansion` section. This field consists of the following sub-field: +If you want to expand the volume of your MariaDB standalone or cluster, you have to specify `spec.volumeExpansion` section. This field consists of the following sub-field: + +- `spec.volumeExpansion.node` indicates the desired size for the persistent volume of a RabbitMQ. +- `spec.volumeExpansion.mode` indicates the mode of volume expansion. It can be `online` or `offline` based on the storage class. -- `spec.mode` specifies the volume expansion mode. Supported values are `Online` & `Offline`. The default is `Online`. -- `spec.volumeExpansion.standalone` indicates the desired size for the persistent volume of a standalone RabbitMQ database. -- `spec.volumeExpansion.replicaSet` indicates the desired size for the persistent volume of replicaSets of a RabbitMQ database. -- `spec.volumeExpansion.configServer` indicates the desired size for the persistent volume of the config server of a sharded RabbitMQ database. -- `spec.volumeExpansion.shard` indicates the desired size for the persistent volume of shards of a sharded RabbitMQ database. -All of them refer to [Quantity](https://v1-22.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#quantity-resource-core) types of Kubernetes. +All of them refer to Quantity types of Kubernetes. Example usage of this field is given below: ```yaml spec: volumeExpansion: - shard: "2Gi" + node: "2Gi" ``` -This will expand the volume size of all the shard nodes to 2 GB. +This will expand the volume size of all the RabbitMQ nodes to 2 GB. ### spec.configuration If you want to reconfigure your Running RabbitMQ cluster or different components of it with new custom configuration, you have to specify `spec.configuration` section. This field consists of the following sub-field: -- `spec.configuration.standalone` indicates the desired new custom configuration for a standalone RabbitMQ database. -- `spec.configuration.replicaSet` indicates the desired new custom configuration for replicaSet of a RabbitMQ database. -- `spec.configuration.configServer` indicates the desired new custom configuration for config servers of a sharded RabbitMQ database. -- `spec.configuration.mongos` indicates the desired new custom configuration for the mongos nodes of a sharded RabbitMQ database. -- `spec.configuration.shard` indicates the desired new custom configuration for the shard nodes of a sharded RabbitMQ database. -- `spec.verticalScaling.arbiter` indicates the desired new custom configuration for arbiter node of RabbitMQ database after scaling. - -All of them has the following sub-fields: - - `configSecret` points to a secret in the same namespace of a RabbitMQ resource, which contains the new custom configurations. If there are any configSecret set before in the database, this secret will replace it. -- `applyConfig` contains the new custom config as a string which will be merged with the previous configuration. +- `applyConfig` contains the new custom config as a string which will be merged with the previous configuration. -- `applyConfig` is a map where key supports 3 values, namely `mongod.conf`, `replicaset.json`, `configuration.js`. And value represents the corresponding configurations. -For your information, replicaset.json is used to modify replica set configurations, which we see in the output of `rs.config()`. And `configurarion.js` is used to apply a js script to configure RabbitMQ at runtime. -KubeDB provisioner operator applies these two directly while reconciling. +- `applyConfig` is a map where key supports 1 values, namely `rabbitmq.conf`. ```yaml applyConfig: - configuration.js: | - print("hello world!!!!") - replicaset.json: | - { - "settings" : { - "electionTimeoutMillis" : 4000 - } - } - mongod.conf: | - net: - maxIncomingConnections: 30000 + rabbitmq.conf: |- + default_vhost = /customvhost ``` - `removeCustomConfig` is a boolean field. Specify this field to true if you want to remove all the custom configuration from the deployed RabbitMQ server. ### spec.tls -If you want to reconfigure the TLS configuration of your database i.e. add TLS, remove TLS, update issuer/cluster issuer or Certificates and rotate the certificates, you have to specify `spec.tls` section. This field consists of the following sub-field: +If you want to reconfigure the TLS configuration of your RabbitMQ cluster i.e. add TLS, remove TLS, update issuer/cluster issuer or Certificates and rotate the certificates, you have to specify `spec.tls` section. This field consists of the following sub-field: - `spec.tls.issuerRef` specifies the issuer name, kind and api group. -- `spec.tls.certificates` specifies the certificates. You can learn more about this field from [here](/docs/guides/RabbitMQ/concepts/RabbitMQ.md#spectls). +- `spec.tls.certificates` specifies the certificates. You can learn more about this field from [here](/docs/guides/rabbitmq/concepts/rabbitmq.md#spectls). - `spec.tls.rotateCertificates` specifies that we want to rotate the certificate of this database. - `spec.tls.remove` specifies that we want to remove tls from this database. - -### spec.readinessCriteria - -`spec.readinessCriteria` is the criteria for checking readiness of a RabbitMQ pod after restarting it. It has two fields. -- `spec.readinessCriteria.oplogMaxLagSeconds` defines the maximum allowed lagging time between the primary & secondary. -- `spec.readinessCriteria.objectsCountDiffPercentage` denotes the maximum allowed object-count-difference between the primary & secondary. - -```yaml -... -spec: - readinessCriteria: - oplogMaxLagSeconds: 20 - objectsCountDiffPercentage: 10 -... -``` -Exceeding these thresholds results in opsRequest failure. One thing to note that, readinessCriteria field will make impact only if pod restarting is associated with the opsRequest type. +- `spec.tls.sslMode` specifies what will be the ssl mode of the cluster allowed values are: disable,allow,prefer,require,verify-ca,verify-full +- `spec.tls.clientAuthMode` specifies what will be the client authentication mode of the cluster allowed values are: md5,scram,cert ### spec.timeout -As we internally retry the ops request steps multiple times, This `timeout` field helps the users to specify the timeout for those steps of the ops request (in second). +As we internally retry the ops request steps multiple times, This `timeout` field helps the users to specify the timeout for those steps of the ops request (in second). If a step doesn't finish within the specified timeout, the ops request will result in failure. ### spec.apply @@ -722,8 +329,8 @@ Use IfReady, if you want to process the opsRequest only when the database is Rea `status.phase` indicates the overall phase of the operation for this `RabbitMQOpsRequest`. It can have the following three values: -| Phase | Meaning | -|-------------|------------------------------------------------------------------------------------| +| Phase | Meaning | +|-------------|-------------------------------------------------------------------------------------| | Successful | KubeDB has successfully performed the operation requested in the RabbitMQOpsRequest | | Progressing | KubeDB has started the execution of the applied RabbitMQOpsRequest | | Failed | KubeDB has failed the operation requested in the RabbitMQOpsRequest | @@ -742,36 +349,17 @@ Important: Ops-manager Operator can skip an opsRequest, only if its execution ha - `types` specifies the type of the condition. RabbitMQOpsRequest has the following types of conditions: -| Type | Meaning | -| ----------------------------- | ------------------------------------------------------------------------- | -| `Progressing` | Specifies that the operation is now in the progressing state | -| `Successful` | Specifies such a state that the operation on the database was successful. | -| `HaltDatabase` | Specifies such a state that the database is halted by the operator | -| `ResumeDatabase` | Specifies such a state that the database is resumed by the operator | -| `Failed` | Specifies such a state that the operation on the database failed. | -| `StartingBalancer` | Specifies such a state that the balancer has successfully started | -| `StoppingBalancer` | Specifies such a state that the balancer has successfully stopped | -| `UpdateShardImage` | Specifies such a state that the Shard Images has been updated | -| `UpdateReplicaSetImage` | Specifies such a state that the Replicaset Image has been updated | -| `UpdateConfigServerImage` | Specifies such a state that the ConfigServer Image has been updated | -| `UpdateMongosImage` | Specifies such a state that the Mongos Image has been updated | -| `UpdateStatefulSetResources` | Specifies such a state that the Statefulset resources has been updated | -| `UpdateShardResources` | Specifies such a state that the Shard resources has been updated | -| `UpdateReplicaSetResources` | Specifies such a state that the Replicaset resources has been updated | -| `UpdateConfigServerResources` | Specifies such a state that the ConfigServer resources has been updated | -| `UpdateMongosResources` | Specifies such a state that the Mongos resources has been updated | -| `ScaleDownReplicaSet` | Specifies such a state that the scale down operation of replicaset | -| `ScaleUpReplicaSet` | Specifies such a state that the scale up operation of replicaset | -| `ScaleUpShardReplicas` | Specifies such a state that the scale up operation of shard replicas | -| `ScaleDownShardReplicas` | Specifies such a state that the scale down operation of shard replicas | -| `ScaleDownConfigServer` | Specifies such a state that the scale down operation of config server | -| `ScaleUpConfigServer` | Specifies such a state that the scale up operation of config server | -| `ScaleMongos` | Specifies such a state that the scale down operation of replicaset | -| `VolumeExpansion` | Specifies such a state that the volume expansion operaton of the database | -| `ReconfigureReplicaset` | Specifies such a state that the reconfiguration of replicaset nodes | -| `ReconfigureMongos` | Specifies such a state that the reconfiguration of mongos nodes | -| `ReconfigureShard` | Specifies such a state that the reconfiguration of shard nodes | -| `ReconfigureConfigServer` | Specifies such a state that the reconfiguration of config server nodes | +| Type | Meaning | +|--------------------------------|---------------------------------------------------------------------------| +| `Progressing` | Specifies that the operation is now in the progressing state | +| `Successful` | Specifies such a state that the operation on the database was successful. | +| `DatabasePauseSucceeded` | Specifies such a state that the database is paused by the operator | +| `ResumeDatabase` | Specifies such a state that the database is resumed by the operator | +| `Failed` | Specifies such a state that the operation on the database failed. | +| `UpdatePetSetResources` | Specifies such a state that the PetSet resources has been updated | +| `UpdatePetSet` | Specifies such a state that the PetSet has been updated | +| `IssueCertificatesSucceeded` | Specifies such a state that the tls certificate issuing is successful | +| `UpdateDatabase` | Specifies such a state that the CR of RabbitMQ is updated | - The `status` field is a string, with possible values `True`, `False`, and `Unknown`. - `status` will be `True` if the current transition succeeded. diff --git a/docs/guides/rabbitmq/concepts/rabbitmq.md b/docs/guides/rabbitmq/concepts/rabbitmq.md index 0b138f9d37..4cdddf4212 100644 --- a/docs/guides/rabbitmq/concepts/rabbitmq.md +++ b/docs/guides/rabbitmq/concepts/rabbitmq.md @@ -2,9 +2,9 @@ title: RabbitMQ CRD menu: docs_{{ .version }}: - identifier: mg-RabbitMQ-concepts + identifier: rm-concepts name: RabbitMQ - parent: mg-concepts-RabbitMQ + parent: rm-concepts-guides weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides @@ -14,7 +14,7 @@ section_menu_id: guides # RabbitMQ -## What is RabbitMQ +## KubeDB managed RabbitMQ `RabbitMQ` is a Kubernetes `Custom Resource Definitions` (CRD). It provides declarative configuration for [RabbitMQ](https://www.RabbitMQ.com/) in a Kubernetes native way. You only need to describe the desired database configuration in a RabbitMQ object, and the KubeDB operator will create Kubernetes objects in the desired state for you. @@ -26,45 +26,45 @@ As with all other Kubernetes objects, a RabbitMQ needs `apiVersion`, `kind`, and apiVersion: kubedb.com/v1alpha2 kind: RabbitMQ metadata: - name: mgo1 - namespace: demo + name: rabbitmq + namespace: rabbit spec: - autoOps: - disabled: true - version: "4.4.26" - replicas: 3 + version: "3.13.2" authSecret: - name: mgo1-auth - externallyManaged: false - replicaSet: - name: rs0 - shardTopology: - configServer: - podTemplate: {} - replicas: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - mongos: - podTemplate: {} - replicas: 2 - shard: - podTemplate: {} - replicas: 3 - shards: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - sslMode: requireSSL + name: rabbit-auth + configSecret: + name: rabbit-custom-config + enableSSL: true + replicas: 4 + storage: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + storageClassName: "standard" + serviceTemplates: + - alias: primary + spec: + type: LoadBalancer + - alias: stats + spec: + type: LoadBalancer + podTemplate: + spec: + containers: + - name: "rabbitmq" + resources: + requests: + cpu: "500m" + limits: + cpu: "600m" + memory: "1.5Gi" tls: issuerRef: - name: mongo-ca-issuer - kind: Issuer apiGroup: "cert-manager.io" + kind: Issuer + name: rabbit-ca-issuer certificates: - alias: client subject: @@ -77,103 +77,21 @@ spec: organizations: - kubedb emailAddresses: - - abc@appscode.com - clusterAuthMode: x509 - storageType: "Durable" - storageEngine: wiredTiger - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - ephemeralStorage: - medium: "Memory" - sizeLimit: 500Mi - init: - script: - configMap: - name: mg-init-script + - dev@appscode.com monitor: agent: prometheus.io/operator prometheus: serviceMonitor: labels: - app: kubedb + release: prometheus interval: 10s - configSecret: - name: mg-custom-config - podTemplate: - metadata: - annotations: - passMe: ToDatabasePod - labels: - thisLabel: willGoToPod - controller: - annotations: - passMe: ToStatefulSet - labels: - thisLabel: willGoToSts - spec: - serviceAccountName: my-service-account - schedulerName: my-scheduler - nodeSelector: - disktype: ssd - imagePullSecrets: - - name: myregistrykey - args: - - --maxConns=100 - env: - - name: MONGO_INITDB_DATABASE - value: myDB - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" - serviceTemplates: - - alias: primary - spec: - type: NodePort - ports: - - name: primary - port: 27017 - nodePort: 300006 - terminationPolicy: Halt - halted: false - arbiter: - podTemplate: - spec: - resources: - requests: - cpu: "200m" - memory: "200Mi" - configSecret: - name: another-config - allowedSchemas: - namespaces: - from: Selector - selector: - matchExpressions: - - {key: kubernetes.io/metadata.name, operator: In, values: [dev]} - selector: - matchLabels: - "schema.kubedb.com": "mongo" - coordinator: - resources: - requests: - cpu: "300m" - memory: 500Mi - securityContext: - runAsUser: 1001 healthChecker: periodSeconds: 15 timeoutSeconds: 10 failureThreshold: 2 disableWriteCheck: false + storageType: Durable + deletionPolicy: Halt ``` ### spec.autoOps @@ -181,25 +99,14 @@ AutoOps is an optional field to control the generation of versionUpdate & TLS-re ### spec.version -`spec.version` is a required field specifying the name of the [RabbitMQVersion](/docs/guides/RabbitMQ/concepts/catalog.md) crd where the docker images are specified. Currently, when you install KubeDB, it creates the following `RabbitMQVersion` resources, +`spec.version` is a required field specifying the name of the [RabbitMQVersion](/docs/guides/rabbitmq/concepts/catalog.md) crd where the docker images are specified. Currently, when you install KubeDB, it creates the following `RabbitMQVersion` resources, -- `3.4.17-v1`, `3.4.22-v1` -- `3.6.13-v1`, `4.4.26`, -- `4.0.3-v1`, `4.4.26`, `4.0.11-v1`, -- `4.1.4-v1`, `4.1.7-v3`, `4.4.26` -- `4.4.26`, `4.4.26` -- `5.0.2`, `5.0.3` -- `percona-3.6.18` -- `percona-4.0.10`, `percona-4.2.7`, `percona-4.4.10` +- `3.12.12`, `3.13.2` ### spec.replicas `spec.replicas` the number of members(primary & secondary) in RabbitMQ replicaset. -If `spec.shardTopology` is set, then `spec.replicas` needs to be empty. Instead use `spec.shardTopology..replicas` - -If both `spec.replicaset` and `spec.shardTopology` is not set, then `spec.replicas` can be value `1`. - KubeDB uses `PodDisruptionBudget` to ensure that majority of these replicas are available during [voluntary disruptions](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#voluntary-and-involuntary-disruptions) so that quorum is maintained. ### spec.authSecret @@ -227,106 +134,29 @@ AuthSecret contains a `user` key and a `password` key which contains the `userna Example: ```bash -$ kubectl create secret generic mgo1-auth -n demo \ ---from-literal=username=jhon-doe \ ---from-literal=password=6q8u_2jMOW-OOZXk -secret "mgo1-auth" created +$ kubectl create secret generic -n demo rabbit-auth \ + --from-literal=username=rabbit-admin \ + --from-literal=password=mypassword +secret/rabbit-auth created ``` ```yaml apiVersion: v1 data: - password: NnE4dV8yak1PVy1PT1pYaw== - username: amhvbi1kb2U= + password: bXlwYXNzd29yZA== + username: cmFiYml0LWFkbWlu kind: Secret metadata: - name: mgo1-auth + creationTimestamp: "2024-09-09T03:56:36Z" + name: rabbit-auth namespace: demo + resourceVersion: "263545" + uid: 4734f693-9ff8-4f42-bcac-ab9b5ba17afd type: Opaque ``` Secrets provided by users are not managed by KubeDB, and therefore, won't be modified or garbage collected by the KubeDB operator (version 0.13.0 and higher). -### spec.replicaSet - -`spec.replicaSet` represents the configuration for replicaset. When `spec.replicaSet` is set, KubeDB will deploy a RabbitMQ replicaset where number of replicaset member is spec.replicas. - -- `name` denotes the name of RabbitMQ replicaset. -NB. If `spec.shardTopology` is set, then `spec.replicaset` needs to be empty. - -### spec.keyFileSecret -`keyFileSecret.name` denotes the name of the secret that contains the `key.txt`, which provides the security between replicaset members using internal authentication. See [Keyfile Authentication](https://docs.RabbitMQ.com/manual/tutorial/enforce-keyfile-access-control-in-existing-replica-set/) for more information. -It will make impact only if the ClusterAuthMode is `keyFile` or `sendKeyFile`. - -### spec.shardTopology - -`spec.shardTopology` represents the topology configuration for sharding. - -Available configurable fields: - -- shard -- configServer -- mongos - -When `spec.shardTopology` is set, the following fields needs to be empty, otherwise validating webhook will throw error. - -- `spec.replicas` -- `spec.podTemplate` -- `spec.configSecret` -- `spec.storage` -- `spec.ephemeralStorage` - -KubeDB uses `PodDisruptionBudget` to ensure that majority of the replicas of these shard components are available during [voluntary disruptions](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#voluntary-and-involuntary-disruptions) so that quorum and data integrity is maintained. - -#### spec.shardTopology.shard - -`shard` represents configuration for Shard component of RabbitMQ. - -Available configurable fields: - -- `shards` represents number of shards for a RabbitMQ deployment. Each shard is deployed as a [replicaset](/docs/guides/RabbitMQ/clustering/replication_concept.md). -- `replicas` represents number of replicas of each shard replicaset. -- `prefix` represents the prefix of each shard node. -- `configSecret` is an optional field to provide custom configuration file for shards (i.e. mongod.cnf). If specified, this file will be used as configuration file otherwise a default configuration file will be used. See below to know about [spec.configSecret](/docs/guides/RabbitMQ/concepts/RabbitMQ.md#specconfigsecret) in details. -- `podTemplate` is an optional configuration for pods. See below to know about [spec.podTemplate](/docs/guides/RabbitMQ/concepts/RabbitMQ.md#specpodtemplate) in details. -- `storage` to specify pvc spec for each node of sharding. You can specify any StorageClass available in your cluster with appropriate resource requests. See below to know about [spec.storage](/docs/guides/RabbitMQ/concepts/RabbitMQ.md#specstorage) in details. -- `ephemeralStorage` to specify the configuration of ephemeral storage type, If you want to use volatile temporary storage attached to your instances which is only present during the running lifetime of the instance. - -#### spec.shardTopology.configServer - -`configServer` represents configuration for ConfigServer component of RabbitMQ. - -Available configurable fields: - -- `replicas` represents number of replicas for configServer replicaset. Here, configServer is deployed as a replicaset of RabbitMQ. -- `prefix` represents the prefix of configServer nodes. -- `configSecret` is an optional field to provide custom configuration file for config server (i.e mongod.cnf). If specified, this file will be used as configuration file otherwise a default configuration file will be used. See below to know about [spec.configSecret](/docs/guides/RabbitMQ/concepts/RabbitMQ.md#specconfigsecret) in details. -- `podTemplate` is an optional configuration for pods. See below to know about [spec.podTemplate](/docs/guides/RabbitMQ/concepts/RabbitMQ.md#specpodtemplate) in details. -- `storage` to specify pvc spec for each node of configServer. You can specify any StorageClass available in your cluster with appropriate resource requests. See below to know about [spec.storage](/docs/guides/RabbitMQ/concepts/RabbitMQ.md#specstorage) in details. -- `ephemeralStorage` to specify the configuration of ephemeral storage type, If you want to use volatile temporary storage attached to your instances which is only present during the running lifetime of the instance. - -#### spec.shardTopology.mongos - -`mongos` represents configuration for Mongos component of RabbitMQ. - -Available configurable fields: - -- `replicas` represents number of replicas of `Mongos` instance. Here, Mongos is deployed as stateless (deployment) instance. -- `prefix` represents the prefix of mongos nodes. -- `configSecret` is an optional field to provide custom configuration file for mongos (i.e. mongod.cnf). If specified, this file will be used as configuration file otherwise a default configuration file will be used. See below to know about [spec.configSecret](/docs/guides/RabbitMQ/concepts/RabbitMQ.md#specconfigsecret) in details. -- `podTemplate` is an optional configuration for pods. See below to know about [spec.podTemplate](/docs/guides/RabbitMQ/concepts/RabbitMQ.md#specpodtemplate) in details. - -### spec.sslMode - -Enables TLS/SSL or mixed TLS/SSL used for all network connections. The value of [`sslMode`](https://docs.RabbitMQ.com/manual/reference/program/mongod/#cmdoption-mongod-sslmode) field can be one of the following: - -| Value | Description | -| :----------: | :----------------------------------------------------------------------------------------------------------------------------- | -| `disabled` | The server does not use TLS/SSL. | -| `allowSSL` | Connections between servers do not use TLS/SSL. For incoming connections, the server accepts both TLS/SSL and non-TLS/non-SSL. | -| `preferSSL` | Connections between servers use TLS/SSL. For incoming connections, the server accepts both TLS/SSL and non-TLS/non-SSL. | -| `requireSSL` | The server uses and accepts only TLS/SSL encrypted connections. | - ### spec.tls `spec.tls` specifies the TLS/SSL configurations for the RabbitMQ. KubeDB uses [cert-manager](https://cert-manager.io/) v1 api to provision and manage TLS certificates. @@ -366,26 +196,11 @@ The following fields are configurable in the `spec.tls` section: - `privateKey` (optional) specifies options to control private keys used for the Certificate. - `encoding` (optional) is the private key cryptography standards (PKCS) encoding for this certificate's private key to be encoded in. If provided, allowed values are "pkcs1" and "pkcs8" standing for PKCS#1 and PKCS#8, respectively. It defaults to PKCS#1 if not specified. -### spec.clusterAuthMode - -The authentication mode used for cluster authentication. This option can have one of the following values: - -| Value | Description | -| :-----------: | :------------------------------------------------------------------------------------------------------------------------------- | -| `keyFile` | Use a keyfile for authentication. Accept only keyfiles. | -| `sendKeyFile` | For rolling update purposes. Send a keyfile for authentication but can accept both keyfiles and x.509 certificates. | -| `sendX509` | For rolling update purposes. Send the x.509 certificate for authentication but can accept both keyfiles and x.509 certificates. | -| `x509` | Recommended. Send the x.509 certificate for authentication and accept only x.509 certificates. | - ### spec.storageType `spec.storageType` is an optional field that specifies the type of storage to use for database. It can be either `Durable` or `Ephemeral`. The default value of this field is `Durable`. If `Ephemeral` is used then KubeDB will create RabbitMQ database using [emptyDir](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) volume. In this case, you don't have to specify `spec.storage` field. Specify `spec.ephemeralStorage` spec instead. -### spec.storageEngine - -`spec.storageEngine` is an optional field that specifies the type of storage engine is going to be used by RabbitMQ. There are two types of storage engine, `wiredTiger` and `inMemory`. Default value of storage engine is `wiredTiger`. `inMemory` storage engine is only supported by the percona variant of RabbitMQ, i.e. the version that has the `percona-` prefix in the RabbitMQ-version name. - ### spec.storage Since 0.9.0-rc.0, If you set `spec.storageType:` to `Durable`, then `spec.storage` is a required field that specifies the StorageClass of PVCs dynamically allocated to store data for the database. This storage spec will be passed to the StatefulSet created by KubeDB operator to run database pods. You can specify any StorageClass available in your cluster with appropriate resource requests. @@ -398,71 +213,24 @@ To learn how to configure `spec.storage`, please visit the links below: - https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims -NB. If `spec.shardTopology` is set, then `spec.storage` needs to be empty. Instead use `spec.shardTopology..storage` - -### spec.ephemeralStorage -Use this field to specify the configuration of ephemeral storage type, If you want to use volatile temporary storage attached to your instances which is only present during the running lifetime of the instance. -- `spec.ephemeralStorage.medium` refers to the name of the storage medium. -- `spec.ephemeralStorage.sizeLimit` to specify the sizeLimit of the emptyDir volume. - -For more details of these two fields, see [EmptyDir struct](https://github.com/kubernetes/api/blob/ed22bb34e3bbae9e2fafba51d66ee3f68ee304b2/core/v1/types.go#L700-L715) - -### spec.init - -`spec.init` is an optional section that can be used to initialize a newly created RabbitMQ database. RabbitMQ databases can be initialized by Script. - -`Initialize from Snapshot` is still not supported. - -#### Initialize via Script - -To initialize a RabbitMQ database using a script (shell script, js script), set the `spec.init.script` section when creating a RabbitMQ object. It will execute files alphabetically with extensions `.sh` and `.js` that are found in the repository. script must have the following information: - -- [VolumeSource](https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes): Where your script is loaded from. - -Below is an example showing how a script from a configMap can be used to initialize a RabbitMQ database. - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: RabbitMQ -metadata: - name: mgo1 - namespace: demo -spec: - version: 4.4.26 - init: - script: - configMap: - name: RabbitMQ-init-script -``` - -In the above example, KubeDB operator will launch a Job to execute all js script of `RabbitMQ-init-script` in alphabetical order once StatefulSet pods are running. For more details tutorial on how to initialize from script, please visit [here](/docs/guides/RabbitMQ/initialization/using-script.md). - -These are the fields of `spec.init` which you can make use of : -- `spec.init.initialized` indicating that this database has been initialized or not. `false` by default. -- `spec.init.script.scriptPath` to specify where all the init scripts should be mounted. -- `spec.init.script.` as described in the above example. To see all the volumeSource options go to [VolumeSource](https://github.com/kubernetes/api/blob/ed22bb34e3bbae9e2fafba51d66ee3f68ee304b2/core/v1/types.go#L49). -- `spec.init.waitForInitialRestore` to tell the operator if it should wait for the initial restore process or not. - ### spec.monitor RabbitMQ managed by KubeDB can be monitored with builtin-Prometheus and Prometheus operator out-of-the-box. To learn more, -- [Monitor RabbitMQ with builtin Prometheus](/docs/guides/RabbitMQ/monitoring/using-builtin-prometheus.md) -- [Monitor RabbitMQ with Prometheus operator](/docs/guides/RabbitMQ/monitoring/using-prometheus-operator.md) +- [Monitor RabbitMQ with builtin Prometheus](/docs/guides/rabbitmq/monitoring/using-builtin-prometheus.md) +- [Monitor RabbitMQ with Prometheus operator](/docs/guides/rabbitmq/monitoring/using-prometheus-operator.md) ### spec.configSecret `spec.configSecret` is an optional field that allows users to provide custom configuration for RabbitMQ. You can provide the custom configuration in a secret, then you can specify the secret name `spec.configSecret.name`. -> Please note that, the secret key needs to be `mongod.conf`. +> Please note that, the secret key needs to be `rabbitmq.conf`. -To learn more about how to use a custom configuration file see [here](/docs/guides/RabbitMQ/configuration/using-config-file.md). - -NB. If `spec.shardTopology` is set, then `spec.configSecret` needs to be empty. Instead use `spec.shardTopology..configSecret` +To learn more about how to use a custom configuration file see [here](/docs/guides/rabbitmq/configuration/using-config-file.md). ### spec.podTemplate -KubeDB allows providing a template for database pod through `spec.podTemplate`. KubeDB operator will pass the information provided in `spec.podTemplate` to the StatefulSet created for RabbitMQ database. +KubeDB allows providing a template for pod through `spec.podTemplate`. KubeDB operator will pass the information provided in `spec.podTemplate` to the PetSet created for Pgpool. KubeDB accept following fields to set in `spec.podTemplate:` @@ -473,10 +241,9 @@ KubeDB accept following fields to set in `spec.podTemplate:` - annotations (statefulset's annotation) - labels (statefulset's labels) - spec: - - args - - env - - resources + - volumes - initContainers + - containers - imagePullSecrets - nodeSelector - affinity @@ -490,76 +257,22 @@ KubeDB accept following fields to set in `spec.podTemplate:` - readinessProbe - lifecycle -You can checkout the full list [here](https://github.com/kmodules/offshoot-api/blob/ea366935d5bad69d7643906c7556923271592513/api/v1/types.go#L42-L259). Uses of some field of `spec.podTemplate` is described below, - -NB. If `spec.shardTopology` is set, then `spec.podTemplate` needs to be empty. Instead use `spec.shardTopology..podTemplate` - -#### spec.podTemplate.spec.args - -`spec.podTemplate.spec.args` is an optional field. This can be used to provide additional arguments to database installation. To learn about available args of `mongod`, visit [here](https://docs.RabbitMQ.com/manual/reference/program/mongod/). - -#### spec.podTemplate.spec.env - -`spec.podTemplate.spec.env` is an optional field that specifies the environment variables to pass to the RabbitMQ docker image. To know about supported environment variables, please visit [here](https://hub.docker.com/r/_/mongo/). - -Note that, KubeDB does not allow `MONGO_INITDB_ROOT_USERNAME` and `MONGO_INITDB_ROOT_PASSWORD` environment variables to set in `spec.podTemplate.spec.env`. If you want to use custom superuser and password, please use `spec.authSecret` instead described earlier. - -If you try to set `MONGO_INITDB_ROOT_USERNAME` or `MONGO_INITDB_ROOT_PASSWORD` environment variable in RabbitMQ crd, Kubedb operator will reject the request with following error, - -```ini -Error from server (Forbidden): error when creating "./RabbitMQ.yaml": admission webhook "RabbitMQ.validators.kubedb.com" denied the request: environment variable MONGO_INITDB_ROOT_USERNAME is forbidden to use in RabbitMQ spec -``` - -Also, note that KubeDB does not allow updating the environment variables as updating them does not have any effect once the database is created. If you try to update environment variables, KubeDB operator will reject the request with following error, - -```ini -Error from server (BadRequest): error when applying patch: -... -for: "./RabbitMQ.yaml": admission webhook "RabbitMQ.validators.kubedb.com" denied the request: precondition failed for: -...At least one of the following was changed: - apiVersion - kind - name - namespace - spec.ReplicaSet - spec.authSecret - spec.init - spec.storageType - spec.storage - spec.podTemplate.spec.nodeSelector - spec.podTemplate.spec.env -``` - -#### spec.podTemplate.spec.imagePullSecret - -`KubeDB` provides the flexibility of deploying RabbitMQ database from a private Docker registry. `spec.podTemplate.spec.imagePullSecrets` is an optional field that points to secrets to be used for pulling docker image if you are using a private docker registry. To learn how to deploy RabbitMQ from a private registry, please visit [here](/docs/guides/RabbitMQ/private-registry/using-private-registry.md). +You can check out the full list [here](https://github.com/kmodules/offshoot-api/blob/39bf8b2/api/v2/types.go#L44-L279). Uses of some field of `spec.podTemplate` is described below, #### spec.podTemplate.spec.nodeSelector `spec.podTemplate.spec.nodeSelector` is an optional field that specifies a map of key-value pairs. For the pod to be eligible to run on a node, the node must have each of the indicated key-value pairs as labels (it can have additional labels as well). To learn more, see [here](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector) . -#### spec.podTemplate.spec.serviceAccountName - -`serviceAccountName` is an optional field supported by KubeDB Operator (version 0.13.0 and higher) that can be used to specify a custom service account to fine tune role based access control. - -If this field is left empty, the KubeDB operator will create a service account name matching RabbitMQ crd name. Role and RoleBinding that provide necessary access permissions will also be generated automatically for this service account. - -If a service account name is given, but there's no existing service account by that name, the KubeDB operator will create one, and Role and RoleBinding that provide necessary access permissions will also be generated for this service account. - -If a service account name is given, and there's an existing service account by that name, the KubeDB operator will use that existing service account. Since this service account is not managed by KubeDB, users are responsible for providing necessary access permissions manually. Follow the guide [here](/docs/guides/RabbitMQ/custom-rbac/using-custom-rbac.md) to grant necessary permissions in this scenario. - #### spec.podTemplate.spec.resources `spec.podTemplate.spec.resources` is an optional field. This can be used to request compute resources required by the database pods. To learn more, visit [here](http://kubernetes.io/docs/user-guide/compute-resources/). ### spec.serviceTemplates -You can also provide template for the services created by KubeDB operator for RabbitMQ database through `spec.serviceTemplates`. This will allow you to set the type and other properties of the services. +You can also provide template for the services created by KubeDB operator for Kafka cluster through `spec.serviceTemplates`. This will allow you to set the type and other properties of the services. KubeDB allows following fields to set in `spec.serviceTemplates`: - `alias` represents the identifier of the service. It has the following possible value: - - `primary` is used for the primary service identification. - - `standby` is used for the secondary service identification. - `stats` is used for the exporter service identification. - metadata: - labels @@ -577,51 +290,27 @@ KubeDB allows following fields to set in `spec.serviceTemplates`: See [here](https://github.com/kmodules/offshoot-api/blob/kubernetes-1.21.1/api/v1/types.go#L237) to understand these fields in detail. -### spec.terminationPolicy -`terminationPolicy` gives flexibility whether to `nullify`(reject) the delete operation of `RabbitMQ` crd or which resources KubeDB should keep or delete when you delete `RabbitMQ` crd. KubeDB provides following four termination policies: +### spec.deletionPolicy + +`deletionPolicy` gives flexibility whether to `nullify`(reject) the delete operation of `RabbitMQ` CR or which resources KubeDB should keep or delete when you delete `RabbitMQ` CR. KubeDB provides following four deletion policies: - DoNotTerminate -- Halt - Delete (`Default`) - WipeOut -When `terminationPolicy` is `DoNotTerminate`, KubeDB takes advantage of `ValidationWebhook` feature in Kubernetes 1.9.0 or later clusters to implement `DoNotTerminate` feature. If admission webhook is enabled, `DoNotTerminate` prevents users from deleting the database as long as the `spec.terminationPolicy` is set to `DoNotTerminate`. - -Following table show what KubeDB does when you delete RabbitMQ crd for different termination policies, - -| Behavior | DoNotTerminate | Halt | Delete | WipeOut | -| ----------------------------------- | :------------: | :------: | :------: | :------: | -| 1. Block Delete operation | ✓ | ✗ | ✗ | ✗ | -| 2. Delete StatefulSet | ✗ | ✓ | ✓ | ✓ | -| 3. Delete Services | ✗ | ✓ | ✓ | ✓ | -| 4. Delete PVCs | ✗ | ✗ | ✓ | ✓ | -| 5. Delete Secrets | ✗ | ✗ | ✗ | ✓ | -| 6. Delete Snapshots | ✗ | ✗ | ✗ | ✓ | -| 7. Delete Snapshot data from bucket | ✗ | ✗ | ✗ | ✓ | - -If you don't specify `spec.terminationPolicy` KubeDB uses `Delete` termination policy by default. - -### spec.halted -Indicates that the database is halted and all offshoot Kubernetes resources except PVCs are deleted. - -### spec.arbiter -If `spec.arbiter` is not null, there will be one arbiter pod on each of the replicaset structure, including shards. It has two fields. -- `spec.arbiter.podTemplate` defines the arbiter-pod's template. See [spec.podTemplate](/docs/guides/RabbitMQ/configuration/using-config-file.md) part for more details of this. -- `spec.arbiter.configSecret` is an optional field that allows users to provide custom configurations for RabbitMQ arbiter. You just need to refer the configuration secret in `spec.arbiter.configSecret.name` field. -> Please note that, the secret key needs to be `mongod.conf`. +When `deletionPolicy` is `DoNotTerminate`, KubeDB takes advantage of `ValidationWebhook` feature in Kubernetes 1.9.0 or later clusters to implement `DoNotTerminate` feature. If admission webhook is enabled, `DoNotTerminate` prevents users from deleting the database as long as the `spec.deletionPolicy` is set to `DoNotTerminate`. -N.B. If `spec.replicaset` & `spec.shardTopology` both is empty, `spec.arbiter` has to be empty too. +Following table show what KubeDB does when you delete Pgpool CR for different deletion policies, -### spec.allowedSchemas -It defines which consumers may refer to a database instance. We implemented double-optIn feature between database instance and schema-manager using this field. -- `spec.allowedSchemas.namespace.from` indicates how you want to filter the namespaces, from which a schema-manager will be able to communicate with this db instance. -Possible values are : i) `All` to allow all namespaces, ii) `Same` to allow only if schema-manager & RabbitMQ is deployed in same namespace & iii) `Selector` to select some namespaces through labels. -- `spec.allowedSchemas.namespace.selector`. You need to set this field only if `spec.allowedSchemas.namespace.from` is set to `selector`. Here you will give the labels of the namespaces to allow. -- `spec.allowedSchemas.selctor` denotes the labels of the schema-manager instances, which you want to give allowance to use this database. +| Behavior | DoNotTerminate | Delete | WipeOut | +|---------------------------| :------------: |:------------:| :------: | +| 1. Block Delete operation | ✓ | ✗ | ✗ | +| 2. Delete PetSet | ✗ | ✓ | ✓ | +| 3. Delete Services | ✗ | ✓ | ✓ | +| 4. Delete Secrets | ✗ | ✗ | ✓ | -### spec.coordinator -We use a dedicated container, named `replication-mode-detector`, to continuously select primary pod and add label as primary. By specifying `spec.coordinator.resources` & `spec.coordinator.securityContext`, you can set the resources and securityContext of that mode-detector container. +If you don't specify `spec.deletionPolicy` KubeDB uses `Delete` deletion policy by default. ## spec.healthChecker @@ -635,5 +324,5 @@ Know details about KubeDB Health checking from this [blog post](https://appscode ## Next Steps -- Learn how to use KubeDB to run a RabbitMQ database [here](/docs/guides/RabbitMQ/README.md). +- Learn how to use KubeDB to run a RabbitMQ database [here](/docs/guides/rabbitmq/README.md). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/rabbitmq/monitoring/_index.md b/docs/guides/rabbitmq/monitoring/_index.md index 990a7b893d..011204b579 100755 --- a/docs/guides/rabbitmq/monitoring/_index.md +++ b/docs/guides/rabbitmq/monitoring/_index.md @@ -2,9 +2,9 @@ title: Monitoring RabbitMQ menu: docs_{{ .version }}: - identifier: mg-monitoring-RabbitMQ + identifier: rm-monitoring-guides name: Monitoring - parent: mg-RabbitMQ-guides + parent: rm-guides weight: 50 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/rabbitmq/monitoring/overview.md b/docs/guides/rabbitmq/monitoring/overview.md index 4fe47e119b..6b255cf59d 100644 --- a/docs/guides/rabbitmq/monitoring/overview.md +++ b/docs/guides/rabbitmq/monitoring/overview.md @@ -5,7 +5,7 @@ menu: docs_{{ .version }}: identifier: mg-monitoring-overview name: Overview - parent: mg-monitoring-RabbitMQ + parent: rm-monitoring-guides weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/rabbitmq/monitoring/using-builtin-prometheus.md b/docs/guides/rabbitmq/monitoring/using-builtin-prometheus.md index d9e48c54d9..c833a52b53 100644 --- a/docs/guides/rabbitmq/monitoring/using-builtin-prometheus.md +++ b/docs/guides/rabbitmq/monitoring/using-builtin-prometheus.md @@ -2,9 +2,9 @@ title: Monitor RabbitMQ using Builtin Prometheus Discovery menu: docs_{{ .version }}: - identifier: mg-using-builtin-prometheus-monitoring + identifier: rm-using-builtin-prometheus-monitoring name: Builtin Prometheus - parent: mg-monitoring-RabbitMQ + parent: rm-monitoring-guides weight: 20 menu_name: docs_{{ .version }} section_menu_id: guides @@ -24,7 +24,7 @@ This tutorial will show you how to monitor RabbitMQ database using builtin [Prom - If you are not familiar with how to configure Prometheus to scrape metrics from various Kubernetes resources, please read the tutorial from [here](https://github.com/appscode/third-party-tools/tree/master/monitoring/prometheus/builtin). -- To learn how Prometheus monitoring works with KubeDB in general, please visit [here](/docs/guides/RabbitMQ/monitoring/overview.md). +- To learn how Prometheus monitoring works with KubeDB in general, please visit [here](/docs/guides/rabbitmq/monitoring/overview.md). - To keep Prometheus resources isolated, we are going to use a separate namespace called `monitoring` to deploy respective monitoring resources. We are going to deploy database in `demo` namespace. @@ -46,10 +46,10 @@ At first, let's deploy an RabbitMQ database with monitoring enabled. Below is th apiVersion: kubedb.com/v1alpha2 kind: RabbitMQ metadata: - name: builtin-prom-mgo + name: builtin-rabbitmq namespace: demo spec: - version: "4.4.26" + version: "3.13.2" terminationPolicy: WipeOut storage: storageClassName: "standard" @@ -69,8 +69,8 @@ Here, Let's create the RabbitMQ crd we have shown above. ```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/RabbitMQ/monitoring/builtin-prom-mgo.yaml -RabbitMQ.kubedb.com/builtin-prom-mgo created +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/rabbitmq/monitoring/builtin-prom-mgo.yaml +rabbitmq.kubedb.com/builtin-prom-mgo created ``` Now, wait for the database to go into `Running` state. @@ -84,26 +84,26 @@ builtin-prom-mgo 4.4.26 Ready 2m34s KubeDB will create a separate stats service with name `{RabbitMQ crd name}-stats` for monitoring purpose. ```bash -$ kubectl get svc -n demo --selector="app.kubernetes.io/instance=builtin-prom-mgo" +$ kubectl get svc -n demo --selector="app.kubernetes.io/instance=builtin-rabbitmq" NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -builtin-prom-mgo ClusterIP 10.99.28.40 27017/TCP 55s -builtin-prom-mgo-pods ClusterIP None 27017/TCP 55s -builtin-prom-mgo-stats ClusterIP 10.98.202.26 56790/TCP 36s +builtin-rabbitmq ClusterIP 10.99.28.40 27017/TCP 55s +builtin-rabbitmq ClusterIP None 27017/TCP 55s +builtin-rabbitmq ClusterIP 10.98.202.26 56790/TCP 36s ``` Here, `builtin-prom-mgo-stats` service has been created for monitoring purpose. Let's describe the service. ```bash -$ kubectl describe svc -n demo builtin-prom-mgo-stats -Name: builtin-prom-mgo-stats +$ kubectl describe svc -n demo builtin-rabbitmq-stats +Name: builtin-rabbitmq-stats Namespace: demo -Labels: app.kubernetes.io/name=RabbitMQs.kubedb.com - app.kubernetes.io/instance=builtin-prom-mgo +Labels: app.kubernetes.io/name=rabbitms.kubedb.com + app.kubernetes.io/instance=builtin-rabbitmq Annotations: monitoring.appscode.com/agent: prometheus.io/builtin prometheus.io/path: /metrics prometheus.io/port: 56790 prometheus.io/scrape: true -Selector: app.kubernetes.io/name=RabbitMQs.kubedb.com,app.kubernetes.io/instance=builtin-prom-mgo +Selector: app.kubernetes.io/name=rabbitmqs.kubedb.com,app.kubernetes.io/instance=builtin-rabbitmq Type: ClusterIP IP: 10.98.202.26 Port: prom-http 56790/TCP diff --git a/docs/guides/rabbitmq/monitoring/using-prometheus-operator.md b/docs/guides/rabbitmq/monitoring/using-prometheus-operator.md index 9cc03afc5e..b17f9e4e69 100644 --- a/docs/guides/rabbitmq/monitoring/using-prometheus-operator.md +++ b/docs/guides/rabbitmq/monitoring/using-prometheus-operator.md @@ -2,9 +2,9 @@ title: Monitor RabbitMQ using Prometheus Operator menu: docs_{{ .version }}: - identifier: mg-using-prometheus-operator-monitoring + identifier: rm-using-prometheus-operator-monitoring name: Prometheus Operator - parent: mg-monitoring-RabbitMQ + parent: rm-monitoring-guides weight: 15 menu_name: docs_{{ .version }} section_menu_id: guides diff --git a/docs/guides/rabbitmq/update-version/_index.md b/docs/guides/rabbitmq/update-version/_index.md index 01c1abbe9d..8e0a72b32d 100644 --- a/docs/guides/rabbitmq/update-version/_index.md +++ b/docs/guides/rabbitmq/update-version/_index.md @@ -2,9 +2,9 @@ title: Updating RabbitMQ menu: docs_{{ .version }}: - identifier: mg-updating - name: UpdateVersion - parent: mg-RabbitMQ-guides + identifier: rm-update-version + name: Update Version + parent: rm-guides weight: 42 menu_name: docs_{{ .version }} --- \ No newline at end of file diff --git a/docs/guides/rabbitmq/update-version/replicaset.md b/docs/guides/rabbitmq/update-version/cluster.md similarity index 95% rename from docs/guides/rabbitmq/update-version/replicaset.md rename to docs/guides/rabbitmq/update-version/cluster.md index a034d81556..915c87667f 100644 --- a/docs/guides/rabbitmq/update-version/replicaset.md +++ b/docs/guides/rabbitmq/update-version/cluster.md @@ -1,10 +1,10 @@ --- -title: Updating RabbitMQ Replicaset +title: Updating RabbitMQ Cluster menu: docs_{{ .version }}: - identifier: mg-updating-replicaset - name: ReplicaSet - parent: mg-updating + identifier: rm-cluster-update-version + name: Update Version + parent: rm-update-version weight: 30 menu_name: docs_{{ .version }} section_menu_id: guides @@ -23,10 +23,9 @@ This guide will show you how to use `KubeDB` Ops-manager operator to update the - Install `KubeDB` Provisioner and Ops-manager operator in your cluster following the steps [here](/docs/setup/README.md). - You should be familiar with the following `KubeDB` concepts: - - [RabbitMQ](/docs/guides/RabbitMQ/concepts/RabbitMQ.md) - - [Replicaset](/docs/guides/RabbitMQ/clustering/replicaset.md) - - [RabbitMQOpsRequest](/docs/guides/RabbitMQ/concepts/opsrequest.md) - - [Updating Overview](/docs/guides/RabbitMQ/update-version/overview.md) + - [RabbitMQ](/docs/guides/rabbitmq/concepts/rabbitmq.md) + - [RabbitMQOpsRequest](/docs/guides/rabbitmq/concepts/opsrequest.md) + - [Updating Overview](/docs/guides/rabbitmq/concepts/update-version/overview.md) To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. @@ -124,7 +123,7 @@ $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" > RabbitMQopsrequest.ops.kubedb.com/mops-replicaset-update created ``` -#### Verify RabbitMQ version updated successfully +#### Verify RabbitMQ version updated successfully If everything goes well, `KubeDB` Ops-manager operator will update the image of `RabbitMQ` object and related `StatefulSets` and `Pods`. diff --git a/docs/guides/rabbitmq/update-version/overview.md b/docs/guides/rabbitmq/update-version/overview.md index f82f62fc91..4b29c0568f 100644 --- a/docs/guides/rabbitmq/update-version/overview.md +++ b/docs/guides/rabbitmq/update-version/overview.md @@ -2,9 +2,9 @@ title: Updating RabbitMQ Overview menu: docs_{{ .version }}: - identifier: mg-updating-overview + identifier: rm-update-version-overview name: Overview - parent: mg-updating + parent: rm-update-version weight: 10 menu_name: docs_{{ .version }} section_menu_id: guides @@ -37,7 +37,7 @@ The updating process consists of the following steps: 2. `KubeDB` Provisioner operator watches the `RabbitMQ` CR. -3. When the operator finds a `RabbitMQ` CR, it creates required number of `StatefulSets` and related necessary stuff like secrets, services, etc. +3. When the operator finds a `RabbitMQ` CR, it creates required number of `PetSets` and other kubernative native resources like secrets, services, etc. 4. Then, in order to update the version of the `RabbitMQ` database the user creates a `RabbitMQOpsRequest` CR with the desired version. @@ -45,9 +45,9 @@ The updating process consists of the following steps: 6. When it finds a `RabbitMQOpsRequest` CR, it halts the `RabbitMQ` object which is referred from the `RabbitMQOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `RabbitMQ` object during the updating process. -7. By looking at the target version from `RabbitMQOpsRequest` CR, `KubeDB` Ops-manager operator updates the images of all the `StatefulSets`. After each image update, the operator performs some checks such as if the oplog is synced and database size is almost same or not. +7. By looking at the target version from `RabbitMQOpsRequest` CR, `KubeDB` Ops-manager operator updates the images of all the `PetSets`. After each image update, the operator performs some checks such as if the oplog is synced and database size is almost same or not. -8. After successfully updating the `StatefulSets` and their `Pods` images, the `KubeDB` Ops-manager operator updates the image of the `RabbitMQ` object to reflect the updated state of the database. +8. After successfully updating the `PetSets` and their `Pods` images, the `KubeDB` Ops-manager operator updates the image of the `RabbitMQ` object to reflect the updated state of the database. 9. After successfully updating of `RabbitMQ` object, the `KubeDB` Ops-manager operator resumes the `RabbitMQ` object so that the `KubeDB` Provisioner operator can resume its usual operations. diff --git a/docs/guides/rabbitmq/update-version/sharding.md b/docs/guides/rabbitmq/update-version/sharding.md deleted file mode 100644 index 61c9251342..0000000000 --- a/docs/guides/rabbitmq/update-version/sharding.md +++ /dev/null @@ -1,317 +0,0 @@ ---- -title: Updating RabbitMQ Sharded Database -menu: - docs_{{ .version }}: - identifier: mg-updating-sharding - name: Sharding - parent: mg-updating - weight: 40 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -> New to KubeDB? Please start [here](/docs/README.md). - -# Update version of RabbitMQ Sharded Database - -This guide will show you how to use `KubeDB` Ops-manager operator to update the version of `RabbitMQ` Sharded Database. - -## Before You Begin - -- At first, you need to have a Kubernetes cluster, and the `kubectl` command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). - -- Install `KubeDB` Provisioner and Ops-manager operator in your cluster following the steps [here](/docs/setup/README.md). - -- You should be familiar with the following `KubeDB` concepts: - - [RabbitMQ](/docs/guides/RabbitMQ/concepts/RabbitMQ.md) - - [Sharding](/docs/guides/RabbitMQ/clustering/sharding.md) - - [RabbitMQOpsRequest](/docs/guides/RabbitMQ/concepts/opsrequest.md) - - [Updating Overview](/docs/guides/RabbitMQ/update-version/overview.md) - -To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. - -```bash -$ kubectl create ns demo -namespace/demo created -``` - -> **Note:** YAML files used in this tutorial are stored in [docs/examples/RabbitMQ](/docs/examples/RabbitMQ) directory of [kubedb/docs](https://github.com/kube/docs) repository. - -## Prepare RabbitMQ Sharded Database Database - -Now, we are going to deploy a `RabbitMQ` sharded database with version `3.6.8`. - -### Deploy RabbitMQ Sharded Database - -In this section, we are going to deploy a RabbitMQ sharded database. Then, in the next section we will update the version of the database using `RabbitMQOpsRequest` CRD. Below is the YAML of the `RabbitMQ` CR that we are going to create, - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: RabbitMQ -metadata: - name: mg-sharding - namespace: demo -spec: - version: 4.4.26 - shardTopology: - configServer: - replicas: 2 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard - mongos: - replicas: 2 - shard: - replicas: 2 - shards: 3 - storage: - resources: - requests: - storage: 1Gi - storageClassName: standard -``` - -Let's create the `RabbitMQ` CR we have shown above, - -```bash -$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/RabbitMQ/update-version/mg-shard.yaml -RabbitMQ.kubedb.com/mg-sharding created -``` - -Now, wait until `mg-sharding` created has status `Ready`. i.e, - -```bash -$ k get RabbitMQ -n demo -NAME VERSION STATUS AGE -mg-sharding 4.4.26 Ready 2m9s -``` - -We are now ready to apply the `RabbitMQOpsRequest` CR to update this database. - -### Update RabbitMQ Version - -Here, we are going to update `RabbitMQ` sharded database from `3.6.8` to `4.0.5`. - -#### Create RabbitMQOpsRequest - -In order to update the sharded database, we have to create a `RabbitMQOpsRequest` CR with your desired version that is supported by `KubeDB`. Below is the YAML of the `RabbitMQOpsRequest` CR that we are going to create, - -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-shard-update - namespace: demo -spec: - type: UpdateVersion - databaseRef: - name: mg-sharding - updateVersion: - targetVersion: 4.4.26 - readinessCriteria: - oplogMaxLagSeconds: 20 - objectsCountDiffPercentage: 10 - timeout: 5m - apply: IfReady -``` - -Here, - -- `spec.databaseRef.name` specifies that we are performing operation on `mg-sharding` RabbitMQ database. -- `spec.type` specifies that we are going to perform `UpdateVersion` on our database. -- `spec.updateVersion.targetVersion` specifies the expected version of the database `4.0.5`. -- Have a look [here](/docs/guides/RabbitMQ/concepts/opsrequest.md#specreadinesscriteria) on the respective sections to understand the `readinessCriteria`, `timeout` & `apply` fields. - -Let's create the `RabbitMQOpsRequest` CR we have shown above, - -```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/RabbitMQ/update-version/mops-update-shard.yaml -RabbitMQopsrequest.ops.kubedb.com/mops-shard-update created -``` - -#### Verify RabbitMQ version updated successfully - -If everything goes well, `KubeDB` Ops-manager operator will update the image of `RabbitMQ` object and related `StatefulSets` and `Pods`. - -Let's wait for `RabbitMQOpsRequest` to be `Successful`. Run the following command to watch `RabbitMQOpsRequest` CR, - -```bash -$ kubectl get RabbitMQopsrequest -n demo -Every 2.0s: kubectl get RabbitMQopsrequest -n demo -NAME TYPE STATUS AGE -mops-shard-update UpdateVersion Successful 2m31s -``` - -We can see from the above output that the `RabbitMQOpsRequest` has succeeded. If we describe the `RabbitMQOpsRequest` we will get an overview of the steps that were followed to update the database. - -```bash -$ kubectl describe RabbitMQopsrequest -n demo mops-shard-update - -Name: mops-shard-update -Namespace: demo -Labels: -Annotations: -API Version: ops.kubedb.com/v1alpha1 -Kind: RabbitMQOpsRequest -Metadata: - Creation Timestamp: 2022-10-26T10:27:24Z - Generation: 1 - Managed Fields: - API Version: ops.kubedb.com/v1alpha1 - Fields Type: FieldsV1 - fieldsV1: - f:metadata: - f:annotations: - .: - f:kubectl.kubernetes.io/last-applied-configuration: - f:spec: - .: - f:apply: - f:databaseRef: - f:readinessCriteria: - .: - f:objectsCountDiffPercentage: - f:oplogMaxLagSeconds: - f:timeout: - f:type: - f:updateVersion: - .: - f:targetVersion: - Manager: kubectl-client-side-apply - Operation: Update - Time: 2022-10-26T10:27:24Z - API Version: ops.kubedb.com/v1alpha1 - Fields Type: FieldsV1 - fieldsV1: - f:status: - .: - f:conditions: - f:observedGeneration: - f:phase: - Manager: kubedb-ops-manager - Operation: Update - Subresource: status - Time: 2022-10-26T10:36:12Z - Resource Version: 610193 - UID: 6459a314-c759-4002-9dff-106b836c4db0 -Spec: - Apply: IfReady - Database Ref: - Name: mg-sharding - Readiness Criteria: - Objects Count Diff Percentage: 10 - Oplog Max Lag Seconds: 20 - Timeout: 5m - Type: UpdateVersion - UpdateVersion: - Target Version: 4.4.26 -Status: - Conditions: - Last Transition Time: 2022-10-26T10:36:12Z - Message: connection() error occurred during connection handshake: dial tcp 10.244.0.125:27017: i/o timeout - Observed Generation: 1 - Reason: Failed - Status: False - Type: UpdateVersion - Last Transition Time: 2022-10-26T10:29:29Z - Message: Successfully stopped RabbitMQ load balancer - Observed Generation: 1 - Reason: StoppingBalancer - Status: True - Type: StoppingBalancer - Last Transition Time: 2022-10-26T10:30:54Z - Message: Successfully updated statefulsets update strategy type - Observed Generation: 1 - Reason: UpdateStatefulSets - Status: True - Type: UpdateStatefulSets - Last Transition Time: 2022-10-26T10:32:00Z - Message: Successfully Updated ConfigServer Image - Observed Generation: 1 - Reason: UpdateConfigServerImage - Status: True - Type: UpdateConfigServerImage - Last Transition Time: 2022-10-26T10:35:32Z - Message: Successfully Updated Shard Image - Observed Generation: 1 - Reason: UpdateShardImage - Status: True - Type: UpdateShardImage - Last Transition Time: 2022-10-26T10:36:07Z - Message: Successfully Updated Mongos Image - Observed Generation: 1 - Reason: UpdateMongosImage - Status: True - Type: UpdateMongosImage - Last Transition Time: 2022-10-26T10:36:07Z - Message: Successfully Started RabbitMQ load balancer - Observed Generation: 1 - Reason: StartingBalancer - Status: True - Type: StartingBalancer - Last Transition Time: 2022-10-26T10:36:07Z - Message: Successfully completed the modification process. - Observed Generation: 1 - Reason: Successful - Status: True - Type: Successful - Observed Generation: 1 - Phase: Failed -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal PauseDatabase 8m27s KubeDB Ops-manager Operator Pausing RabbitMQ demo/mg-sharding - Normal PauseDatabase 8m27s KubeDB Ops-manager Operator Successfully paused RabbitMQ demo/mg-sharding - Normal StoppingBalancer 8m27s KubeDB Ops-manager Operator Stopping Balancer - Normal StoppingBalancer 8m27s KubeDB Ops-manager Operator Successfully Stopped Balancer - Normal Updating 8m27s KubeDB Ops-manager Operator Updating StatefulSets - Normal Updating 7m2s KubeDB Ops-manager Operator Successfully Updated StatefulSets - Normal Updating 7m2s KubeDB Ops-manager Operator Updating StatefulSets - Normal UpdateConfigServerImage 5m56s KubeDB Ops-manager Operator Successfully Updated ConfigServer Image - Normal Updating 5m45s KubeDB Ops-manager Operator Successfully Updated StatefulSets - Normal UpdateShardImage 2m24s KubeDB Ops-manager Operator Successfully Updated Shard Image - Normal UpdateMongosImage 109s KubeDB Ops-manager Operator Successfully Updated Mongos Image - Normal Updating 109s KubeDB Ops-manager Operator Starting Balancer - Normal StartingBalancer 109s KubeDB Ops-manager Operator Successfully Started Balancer - Normal ResumeDatabase 109s KubeDB Ops-manager Operator Resuming RabbitMQ demo/mg-sharding - Normal ResumeDatabase 109s KubeDB Ops-manager Operator Successfully resumed RabbitMQ demo/mg-sharding - Normal Successful 109s KubeDB Ops-manager Operator Successfully Updated Database -``` - -Now, we are going to verify whether the `RabbitMQ` and the related `StatefulSets` of `Mongos`, `Shard` and `ConfigeServer` and their `Pods` have the new version image. Let's check, - -```bash -$ kubectl get mg -n demo mg-sharding -o=jsonpath='{.spec.version}{"\n"}' -4.4.26 - -$ kubectl get sts -n demo mg-sharding-configsvr -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -mongo:4.0.5 - -$ kubectl get sts -n demo mg-sharding-shard0 -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -mongo:4.0.5 - -$ kubectl get sts -n demo mg-sharding-mongos -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -mongo:4.0.5 - -$ kubectl get pods -n demo mg-sharding-configsvr-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -mongo:4.0.5 - -$ kubectl get pods -n demo mg-sharding-shard0-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -mongo:4.0.5 - -$ kubectl get pods -n demo mg-sharding-mongos-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -mongo:4.0.5 -``` - -You can see from above, our `RabbitMQ` sharded database has been updated with the new version. So, the update process is successfully completed. - -## Cleaning Up - -To clean up the Kubernetes resources created by this tutorial, run: - -```bash -kubectl delete mg -n demo mg-sharding -kubectl delete RabbitMQopsrequest -n demo mops-shard-update -``` \ No newline at end of file diff --git a/docs/guides/rabbitmq/update-version/standalone.md b/docs/guides/rabbitmq/update-version/standalone.md deleted file mode 100644 index 7c1805caa9..0000000000 --- a/docs/guides/rabbitmq/update-version/standalone.md +++ /dev/null @@ -1,263 +0,0 @@ ---- -title: Updating RabbitMQ Standalone -menu: - docs_{{ .version }}: - identifier: mg-updating-standalone - name: Standalone - parent: mg-updating - weight: 20 -menu_name: docs_{{ .version }} -section_menu_id: guides ---- - -> New to KubeDB? Please start [here](/docs/README.md). - -# update version of RabbitMQ Standalone - -This guide will show you how to use `KubeDB` Ops-manager operator to update the version of `RabbitMQ` standalone. - -## Before You Begin - -- At first, you need to have a Kubernetes cluster, and the `kubectl` command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). - -- Install `KubeDB` Provisioner and Ops-manager operator in your cluster following the steps [here](/docs/setup/README.md). - -- You should be familiar with the following `KubeDB` concepts: - - [RabbitMQ](/docs/guides/RabbitMQ/concepts/RabbitMQ.md) - - [RabbitMQOpsRequest](/docs/guides/RabbitMQ/concepts/opsrequest.md) - - [Updating Overview](/docs/guides/RabbitMQ/update-version/overview.md) - -To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. - -```bash -$ kubectl create ns demo -namespace/demo created -``` - -> **Note:** YAML files used in this tutorial are stored in [docs/examples/RabbitMQ](/docs/examples/RabbitMQ) directory of [kubedb/docs](https://github.com/kube/docs) repository. - -### Prepare RabbitMQ Standalone Database - -Now, we are going to deploy a `RabbitMQ` standalone database with version `3.6.8`. - -### Deploy RabbitMQ standalone : - -In this section, we are going to deploy a RabbitMQ standalone database. Then, in the next section we will update the version of the database using `RabbitMQOpsRequest` CRD. Below is the YAML of the `RabbitMQ` CR that we are going to create, - -```yaml -apiVersion: kubedb.com/v1alpha2 -kind: RabbitMQ -metadata: - name: mg-standalone - namespace: demo -spec: - version: "4.4.26" - storageType: Durable - storage: - storageClassName: "standard" - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi -``` - -Let's create the `RabbitMQ` CR we have shown above, - -```bash -$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/RabbitMQ/update-version/mg-standalone.yaml -RabbitMQ.kubedb.com/mg-standalone created -``` - -Now, wait until `mg-standalone` created has status `Ready`. i.e, - -```bash -$ kubectl get mg -n demo - NAME VERSION STATUS AGE - mg-standalone 4.4.26 Ready 8m58s -``` - -We are now ready to apply the `RabbitMQOpsRequest` CR to update this database. - -### update RabbitMQ Version - -Here, we are going to update `RabbitMQ` standalone from `3.6.8` to `4.0.5`. - -#### Create RabbitMQOpsRequest: - -In order to update the standalone database, we have to create a `RabbitMQOpsRequest` CR with your desired version that is supported by `KubeDB`. Below is the YAML of the `RabbitMQOpsRequest` CR that we are going to create, - -```yaml -apiVersion: ops.kubedb.com/v1alpha1 -kind: RabbitMQOpsRequest -metadata: - name: mops-update - namespace: demo -spec: - type: UpdateVersion - databaseRef: - name: mg-standalone - updateVersion: - targetVersion: 4.4.26 - readinessCriteria: - oplogMaxLagSeconds: 20 - objectsCountDiffPercentage: 10 - timeout: 5m - apply: IfReady -``` - -Here, - -- `spec.databaseRef.name` specifies that we are performing operation on `mg-standalone` RabbitMQ database. -- `spec.type` specifies that we are going to perform `UpdateVersion` on our database. -- `spec.updateVersion.targetVersion` specifies the expected version of the database `4.0.5`. -- Have a look [here](/docs/guides/RabbitMQ/concepts/opsrequest.md#specreadinesscriteria) on the respective sections to understand the `readinessCriteria`, `timeout` & `apply` fields. - - -Let's create the `RabbitMQOpsRequest` CR we have shown above, - -```bash -$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/RabbitMQ/update-version/mops-update-standalone.yaml -RabbitMQopsrequest.ops.kubedb.com/mops-update created -``` - -#### Verify RabbitMQ version updated successfully : - -If everything goes well, `KubeDB` Ops-manager operator will update the image of `RabbitMQ` object and related `StatefulSets` and `Pods`. - -Let's wait for `RabbitMQOpsRequest` to be `Successful`. Run the following command to watch `RabbitMQOpsRequest` CR, - -```bash -$ kubectl get RabbitMQopsrequest -n demo -Every 2.0s: kubectl get RabbitMQopsrequest -n demo -NAME TYPE STATUS AGE -mops-update UpdateVersion Successful 3m45s -``` - -We can see from the above output that the `RabbitMQOpsRequest` has succeeded. If we describe the `RabbitMQOpsRequest` we will get an overview of the steps that were followed to update the database. - -```bash -$ kubectl describe RabbitMQopsrequest -n demo mops-update -Name: mops-update -Namespace: demo -Labels: -Annotations: -API Version: ops.kubedb.com/v1alpha1 -Kind: RabbitMQOpsRequest -Metadata: - Creation Timestamp: 2022-10-26T10:06:50Z - Generation: 1 - Managed Fields: - API Version: ops.kubedb.com/v1alpha1 - Fields Type: FieldsV1 - fieldsV1: - f:metadata: - f:annotations: - .: - f:kubectl.kubernetes.io/last-applied-configuration: - f:spec: - .: - f:apply: - f:databaseRef: - f:readinessCriteria: - .: - f:objectsCountDiffPercentage: - f:oplogMaxLagSeconds: - f:timeout: - f:type: - f:updateVersion: - .: - f:targetVersion: - Manager: kubectl-client-side-apply - Operation: Update - Time: 2022-10-26T10:06:50Z - API Version: ops.kubedb.com/v1alpha1 - Fields Type: FieldsV1 - fieldsV1: - f:status: - .: - f:conditions: - f:observedGeneration: - f:phase: - Manager: kubedb-ops-manager - Operation: Update - Subresource: status - Time: 2022-10-26T10:08:25Z - Resource Version: 605817 - UID: 79faadf6-7af9-4b74-9907-febe7d543386 -Spec: - Apply: IfReady - Database Ref: - Name: mg-standalone - Readiness Criteria: - Objects Count Diff Percentage: 10 - Oplog Max Lag Seconds: 20 - Timeout: 5m - Type: UpdateVersion - UpdateVersion: - Target Version: 4.4.26 -Status: - Conditions: - Last Transition Time: 2022-10-26T10:07:10Z - Message: RabbitMQ ops request is update-version database version - Observed Generation: 1 - Reason: UpdateVersion - Status: True - Type: UpdateVersion - Last Transition Time: 2022-10-26T10:07:30Z - Message: Successfully updated statefulsets update strategy type - Observed Generation: 1 - Reason: UpdateStatefulSets - Status: True - Type: UpdateStatefulSets - Last Transition Time: 2022-10-26T10:08:25Z - Message: Successfully Updated Standalone Image - Observed Generation: 1 - Reason: UpdateStandaloneImage - Status: True - Type: UpdateStandaloneImage - Last Transition Time: 2022-10-26T10:08:25Z - Message: Successfully completed the modification process. - Observed Generation: 1 - Reason: Successful - Status: True - Type: Successful - Observed Generation: 1 - Phase: Successful -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal PauseDatabase 2m5s KubeDB Ops-manager Operator Pausing RabbitMQ demo/mg-standalone - Normal PauseDatabase 2m5s KubeDB Ops-manager Operator Successfully paused RabbitMQ demo/mg-standalone - Normal Updating 2m5s KubeDB Ops-manager Operator Updating StatefulSets - Normal Updating 105s KubeDB Ops-manager Operator Successfully Updated StatefulSets - Normal UpdateStandaloneImage 50s KubeDB Ops-manager Operator Successfully Updated Standalone Image - Normal ResumeDatabase 50s KubeDB Ops-manager Operator Resuming RabbitMQ demo/mg-standalone - Normal ResumeDatabase 50s KubeDB Ops-manager Operator Successfully resumed RabbitMQ demo/mg-standalone - Normal Successful 50s KubeDB Ops-manager Operator Successfully Updated Database - -``` - -Now, we are going to verify whether the `RabbitMQ` and the related `StatefulSets` their `Pods` have the new version image. Let's check, - -```bash -$ kubectl get mg -n demo mg-standalone -o=jsonpath='{.spec.version}{"\n"}' -4.4.26 - -$ kubectl get sts -n demo mg-standalone -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' -mongo:4.0.5 - -$ kubectl get pods -n demo mg-standalone-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' -mongo:4.0.5 -``` - -You can see from above, our `RabbitMQ` standalone database has been updated with the new version. So, the update process is successfully completed. - -## Cleaning Up - -To clean up the Kubernetes resources created by this tutorial, run: - -```bash -kubectl delete mg -n demo mg-standalone -kubectl delete RabbitMQopsrequest -n demo mops-update -``` \ No newline at end of file