Skip to content

Update rabbitmq docs examples to latest supported version (4.2.4) #930

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tamalsaha wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Update rabbitmq docs examples to latest supported version (4.2.4) #930

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
1c35ae7
Update rabbitmq docs examples to latest supported version (4.2.4)
tamalsaha Jun 30, 2026
55bff87
update version and init-container image
biswasurmi Jul 1, 2026
1870ba5
Merge branch 'master' into update-rabbitmq-docs-version
biswasurmi Jul 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/examples/rabbitmq/cluster/rabbit-custom-config.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ metadata:
name: rm-cluster
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
storageType: Durable
storage:
storageClassName: "standard"
Expand Down
2 changes: 1 addition & 1 deletion docs/examples/rabbitmq/cluster/rabbitmq-cluster.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ metadata:
name: rabbitmq
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 3
storage:
accessModes:
Expand Down
2 changes: 1 addition & 1 deletion docs/examples/rabbitmq/quickstart/quickstart.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ metadata:
name: rm-quickstart
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 3
storage:
accessModes:
Expand Down
1 change: 1 addition & 0 deletions docs/guides/rabbitmq/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,7 @@ KubeDB supports the following RabbitMQ Versions.
- `3.12.12`
- `3.13.2`
- `4.0.4`
- `4.2.4`

## Life Cycle of a RabbitMQ Object

Expand Down
6 changes: 3 additions & 3 deletions docs/guides/rabbitmq/autoscaler/compute/compute-autoscale.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ namespace/demo created

## Autoscaling of RabbitMQ

In this section, we are going to deploy a RabbitMQ with version `3.13.2` Then, in the next section we will set up autoscaling for this RabbitMQ using `RabbitMQAutoscaler` CRD. Below is the YAML of the `RabbitMQ` CR that we are going to create,
In this section, we are going to deploy a RabbitMQ with version `4.2.4` Then, in the next section we will set up autoscaling for this RabbitMQ using `RabbitMQAutoscaler` CRD. Below is the YAML of the `RabbitMQ` CR that we are going to create,

```yaml
apiVersion: kubedb.com/v1alpha2
Expand All @@ -50,7 +50,7 @@ metadata:
name: rabbitmq-autoscale
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 1
storage:
accessModes:
Expand Down Expand Up @@ -90,7 +90,7 @@ Now, wait until `rabbitmq-autoscale` has status `Ready`. i.e,
```bash
$ kubectl get rm -n demo
NAME TYPE VERSION STATUS AGE
rabbitmq-autoscale kubedb.com/v1alpha2 3.13.2 Ready 22s
rabbitmq-autoscale kubedb.com/v1alpha2 4.2.4 Ready 22s
```

Let's check the Pod containers resources,
Expand Down
6 changes: 3 additions & 3 deletions docs/guides/rabbitmq/autoscaler/storage/storage-autoscale.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,7 +58,7 @@ Now, we are going to deploy a `RabbitMQ` cluster using a supported version by `K

#### Deploy RabbitMQ Cluster

In this section, we are going to deploy a RabbitMQ cluster with version `3.13.2`. Then, in the next section we will set up autoscaling for this database using `RabbitMQAutoscaler` CRD. Below is the YAML of the `RabbitMQ` CR that we are going to create,
In this section, we are going to deploy a RabbitMQ cluster with version `4.2.4`. Then, in the next section we will set up autoscaling for this database using `RabbitMQAutoscaler` CRD. Below is the YAML of the `RabbitMQ` CR that we are going to create,

> If you want to autoscale RabbitMQ `Standalone`, Just remove the `spec.Replicas` from the below yaml and rest of the steps are same.

Expand All @@ -69,7 +69,7 @@ metadata:
name: rabbitmq-autoscale
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 3
storage:
accessModes:
Expand Down Expand Up @@ -109,7 +109,7 @@ Now, wait until `rabbitmq-autoscale` has status `Ready`. i.e,
```bash
$ kubectl get rabbitmq -n demo
NAME VERSION STATUS AGE
rabbitmq-autoscale 3.13.2 Ready 3m46s
rabbitmq-autoscale 4.2.4 Ready 3m46s
```

Let's check volume size from petset, and from the persistent volume,
Expand Down
4 changes: 2 additions & 2 deletions docs/guides/rabbitmq/concepts/appbinding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ kind: AppBinding
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"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"}}
{"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":"4.2.4"}}
creationTimestamp: "2024-09-05T19:30:24Z"
generation: 1
labels:
Expand Down Expand Up @@ -64,7 +64,7 @@ spec:
secret:
name: rabbitmq-admin-cred
type: kubedb.com/rabbitmq
version: 3.13.2
version: 4.2.4
```

Here, we are going to describe the sections of an `AppBinding` crd.
Expand Down
10 changes: 5 additions & 5 deletions docs/guides/rabbitmq/concepts/catalog.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ Using a separate crd for specifying respective docker images, and pod security p
As with all other Kubernetes objects, a RabbitMQVersion needs `apiVersion`, `kind`, and `metadata` fields. It also needs a `.spec` section. Get `RabbitMQVersion` CR with a simple kubectl command.

```bash
$ kubectl get rmversion 3.13.2 -oyaml
$ kubectl get rmversion 4.2.4 -oyaml
```

```yaml
Expand All @@ -45,17 +45,17 @@ metadata:
app.kubernetes.io/name: kubedb-catalog
app.kubernetes.io/version: v2024.8.21
helm.sh/chart: kubedb-catalog-v2024.8.21
name: 3.13.2
name: 4.2.4
resourceVersion: "46385"
uid: d853aaf9-e9b8-40b8-9663-a201a5a645c1
spec:
db:
image: ghcr.io/appscode-images/rabbitmq:3.13.2-management-alpine
image: ghcr.io/appscode-images/rabbitmq:4.2.4-management-alpine
initContainer:
image: ghcr.io/kubedb/rabbitmq-init:3.13.2
image: ghcr.io/kubedb/rabbitmq-init:v2026.1.19
securityContext:
runAsUser: 999
version: 3.13.2
version: 4.2.4
```

### metadata.name
Expand Down
4 changes: 2 additions & 2 deletions docs/guides/rabbitmq/concepts/opsrequest.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ Here, some sample `RabbitMQOpsRequest` CRs for different administrative operatio

**Sample `RabbitMQOpsRequest` for updating database:**

Let's assume that you have a KubeDB managed RabbitMQ cluster named `rm-quickstart` running on your kubernetes with version `3.12.12`. Now, You can update it's version to `3.13.2` using the following manifest.
Let's assume that you have a KubeDB managed RabbitMQ cluster named `rm-quickstart` running on your kubernetes with version `4.0.4`. Now, You can update it's version to `4.2.4` using the following manifest.

```yaml
apiVersion: ops.kubedb.com/v1alpha1
Expand All @@ -39,7 +39,7 @@ spec:
databaseRef:
name: rm-quickstart
updateVersion:
targetVersion: 3.13.2
targetVersion: 4.2.4
```

**Sample `RabbitMQOpsRequest` Objects for Horizontal Scaling of the database Cluster:**
Expand Down
4 changes: 2 additions & 2 deletions docs/guides/rabbitmq/concepts/rabbitmq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ metadata:
name: rabbitmq
namespace: rabbit
spec:
version: "3.13.2"
version: "4.2.4"
authSecret:
kind: Secret
name: rabbit-auth
Expand Down Expand Up @@ -102,7 +102,7 @@ AutoOps is an optional field to control the generation of versionUpdate & TLS-re

`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.12.12`, `3.13.2`
- `3.12.12`, `3.13.2`, `4.0.4`, `4.2.4`

### spec.replicas

Expand Down
2 changes: 1 addition & 1 deletion docs/guides/rabbitmq/configuration/using-config-file.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ metadata:
name: rm-custom-config
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 1
configuration:
secretName: rm-configuration
Expand Down
14 changes: 7 additions & 7 deletions docs/guides/rabbitmq/configuration/using-podtemplate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ metadata:
name: rm-misc-config
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 1
podTemplate:
spec:
Expand Down Expand Up @@ -113,7 +113,7 @@ Now, check if the rabbitmq has started with the custom configuration we have pro

```bash
$ kubectl exec -it -n demo -- bash
## ## RabbitMQ 3.13.2
## ## RabbitMQ 4.2.4
## ##
########## Copyright (c) 2007-2024 Broadcom Inc and/or its subsidiaries
###### ##
Expand Down Expand Up @@ -168,7 +168,7 @@ metadata:
name: rabbitmq-custom-sidecar
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 1
podTemplate:
spec:
Expand Down Expand Up @@ -275,7 +275,7 @@ metadata:
name: rabbitmq-node-selector
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 1
podTemplate:
spec:
Expand Down Expand Up @@ -372,7 +372,7 @@ metadata:
name: rabbitmq-without-tolerations
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 1
storage:
accessModes:
Expand Down Expand Up @@ -418,7 +418,7 @@ IPs: <none>
Controlled By: PetSet/rabbitmq-without-tolerations
Containers:
rabbitmq:
Image: ghcr.io/appscode-images/rabbitmq:3.13.2@sha256:7f2537e3dc69dae2cebea3500502e6a2b764b42911881e623195eeed32569217
Image: ghcr.io/appscode-images/rabbitmq:4.2.4@sha256:7f2537e3dc69dae2cebea3500502e6a2b764b42911881e623195eeed32569217
Ports: 9999/TCP, 9595/TCP
Host Ports: 0/TCP, 0/TCP
SeccompProfile: RuntimeDefault
Expand Down Expand Up @@ -467,7 +467,7 @@ metadata:
name: rabbitmq-with-tolerations
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 1
storage:
accessModes:
Expand Down
2 changes: 1 addition & 1 deletion docs/guides/rabbitmq/monitoring/overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ metadata:
name: sample-rabbitmq
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
deletionPolicy: WipeOut
configuration:
secretName: config
Expand Down
4 changes: 2 additions & 2 deletions docs/guides/rabbitmq/monitoring/using-builtin-prometheus.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ metadata:
name: builtin-rabbitmq
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
deletionPolicy: WipeOut
storage:
storageClassName: "standard"
Expand Down Expand Up @@ -78,7 +78,7 @@ Now, wait for the database to go into `Running` state.
```bash
$ kubectl get rm -n demo builtin-rabbitmq
NAME VERSION STATUS AGE
builtin-rabbitmq 3.13.2 Ready 2m34s
builtin-rabbitmq 4.2.4 Ready 2m34s
```

KubeDB will create a separate stats service with name `{RabbitMQ crd name}-stats` for monitoring purpose.
Expand Down
4 changes: 2 additions & 2 deletions docs/guides/rabbitmq/monitoring/using-prometheus-operator.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -138,7 +138,7 @@ metadata:
name: prom-rm
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
deletionPolicy: WipeOut
storage:
storageClassName: "standard"
Expand Down Expand Up @@ -174,7 +174,7 @@ Now, wait for the database to go into `Running` state.
```bash
$ kubectl get rm -n demo prom-rm
NAME VERSION STATUS AGE
prom-rm 3.13.2 Ready 34s
prom-rm 4.2.4 Ready 34s
```

KubeDB will create a separate stats service with name `{RabbitMQ crd name}-stats` for monitoring purpose.
Expand Down
10 changes: 5 additions & 5 deletions docs/guides/rabbitmq/quickstart/quickstart.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,7 @@ metadata:
name: rm-quickstart
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 3
storage:
accessModes:
Expand Down Expand Up @@ -99,7 +99,7 @@ rabbitmq.kubedb.com/rm-quickstart created
Here,

- `.spec.replica` is used to provide the number of required replicas or, peers for intended rabbitmq cluster.
- `spec.version` is the name of the RabbitMQVersion CRD where the docker images are specified. In this tutorial, a RabbitMQ `3.13.2` database is going to be created.
- `spec.version` is the name of the RabbitMQVersion CRD where the docker images are specified. In this tutorial, a RabbitMQ `4.2.4` database is going to be created.
- `spec.storageType` specifies the type of storage that will be used for RabbitMQ database. It can be `Durable` or `Ephemeral`. Default value of this field is `Durable`. If `Ephemeral` is used then KubeDB will create RabbitMQ database using `EmptyDir` volume. In this case, you don't have to specify `spec.storage` field. This is useful for testing purposes.
- `spec.deletionPolicy` 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. If admission webhook is enabled, It prevents users from deleting the database as long as the `spec.deletionPolicy` is set to `DoNotTerminate`. Learn details of all `DeletionPolicy` [here](/docs/guides/rabbitmq/concepts/rabbitmq.md#specdeletionpolicy)
- `.spec.podTemplate` is used to provide specific pod specifications or container specification. You can override default resources, securityContext etc. set for rabbitmq container. Find details [here](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
Expand Down Expand Up @@ -134,7 +134,7 @@ rm-quickstart-pods ClusterIP None <none> 4369/T

$ kubectl get appbinding -n demo
NAME TYPE VERSION AGE
rm-quickstart kubedb.com/rabbitmq 3.13.2 23h
rm-quickstart kubedb.com/rabbitmq 4.2.4 23h
```

KubeDB operator sets the `status.phase` to `Running` once the database is successfully created. Run the following command to see the modified `RabbitMQ` object:
Expand All @@ -148,7 +148,7 @@ kind: RabbitMQ
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"kubedb.com/v1alpha2","kind":"RabbitMQ","metadata":{"annotations":{},"name":"rm-quickstart","namespace":"demo"},"spec":{"deletionPolicy":"WipeOut","podTemplate":{"spec":{"containers":[{"name":"rabbitmq","resources":{"limits":{"cpu":2,"memory":"2Gi"},"requests":{"cpu":0.5,"memory":"1Gi"}}}]}},"replicas":3,"serviceTemplates":[{"alias":"primary","spec":{"type":"LoadBalancer"}}],"storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}},"storageClassName":"linode-block-storage"},"storageType":"Durable","version":"3.13.2"}}
{"apiVersion":"kubedb.com/v1alpha2","kind":"RabbitMQ","metadata":{"annotations":{},"name":"rm-quickstart","namespace":"demo"},"spec":{"deletionPolicy":"WipeOut","podTemplate":{"spec":{"containers":[{"name":"rabbitmq","resources":{"limits":{"cpu":2,"memory":"2Gi"},"requests":{"cpu":0.5,"memory":"1Gi"}}}]}},"replicas":3,"serviceTemplates":[{"alias":"primary","spec":{"type":"LoadBalancer"}}],"storage":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}},"storageClassName":"linode-block-storage"},"storageType":"Durable","version":"4.2.4"}}
creationTimestamp: "2024-09-10T09:23:57Z"
finalizers:
- kubedb.com/rabbitmq
Expand Down Expand Up @@ -218,7 +218,7 @@ spec:
storage: 1Gi
storageClassName: standard
storageType: Durable
version: 3.13.2
version: 4.2.4
status:
conditions:
- lastTransitionTime: "2024-09-10T09:23:57Z"
Expand Down
4 changes: 2 additions & 2 deletions docs/guides/rabbitmq/reconfigure-tls/reconfigure-tls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ metadata:
name: rm
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 3
storage:
storageClassName: "standard"
Expand All @@ -71,7 +71,7 @@ Now, wait until `rm` has status `Ready`. i.e,
```bash
$ kubectl get rm -n demo
NAME VERSION STATUS AGE
rm 3.13.2 Ready 10m
rm 4.2.4 Ready 10m


```bash
Expand Down
6 changes: 3 additions & 3 deletions docs/guides/rabbitmq/reconfigure/reconfigure.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ Now, we are going to deploy a `RabbitMQ` cluster using a supported version by `

### Prepare RabbitMQ Standalone Database

Now, we are going to deploy a `RabbitMQ` cluster with version `3.13.2`.
Now, we are going to deploy a `RabbitMQ` cluster with version `4.2.4`.

### Deploy RabbitMQ standalone

Expand Down Expand Up @@ -68,7 +68,7 @@ metadata:
name: rm-cluster
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
storageType: Durable
storage:
storageClassName: "standard"
Expand All @@ -93,7 +93,7 @@ Now, wait until `rm-cluster` has status `Ready`. i.e,
```bash
$ kubectl get rm -n demo
NAME TYPE VERSION STATUS AGE
rm-cluster kubedb.com/v1alpha2 3.13.2 Ready 79m
rm-cluster kubedb.com/v1alpha2 4.2.4 Ready 79m
```

Now, we will check if the database has started with the custom configuration we have provided.
Expand Down
2 changes: 1 addition & 1 deletion docs/guides/rabbitmq/restart/restart.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ metadata:
name: rm
namespace: demo
spec:
version: "3.13.2"
version: "4.2.4"
replicas: 3
storageType: Durable
storage:
Expand Down
Loading
Loading