As a refresher, VMware Tanzu RabbitMQ is based on the hugely popular open source technology RabbitMQ, which is a message broker with event streaming capabilities that connects multiple distributed applications and processes high-volume data in real-time and at scale.

Tanzu RabbitMQ is a curated RabbitMQ experience from VMware experts that builds on RabbitMQ to allow modern organizations with an extensive number of interconnected data sources and microservices to build enterprise-grade event-driven applications, as well as integrate distributed applications to accelerate digital transformation, while promoting business continuity and resiliency.

Ever since Tanzu RabbitMQ became generally available in 2021, we’ve added a host of new functionality to the product in an effort to continuously delight our customers. Today, we are excited to announce our latest Tanzu RabbitMQ for Kubernetes release 1.3.

Announcing VMware Tanzu RabbitMQ for Kubernetes 1.3: What’s in it?

This release extends the reach of the Warm Standby Replication while automatically upgrading open source components to their most recent version, including RabbitMQ 3.10, providing a tested and validated up-to-date package.

Key benefits

  • Warm Standby Replication can now be implemented for RabbitMQ instances not managed by the Cluster Operator.
  • The Messaging Topology Operator can now orchestrate RabbitMQ instances not managed by the Cluster Operator, as well as periodically ensure the topology remains in the correct state.
  • Support for Kubernetes 1.23.
  • Ships with the latest RabbitMQ 3.10.

Upgraded VMware Tanzu Standby Replication Operator to version 0.6.2 (Release notes)

  • This operator is responsible for the Warm Standby Replication Tanzu-exclusive feature, not available in the open source RabbitMQ distribution.
  • Version 0.6.2 adds support for Non-operator managed RabbitMQ, so customers can benefit from Warm Standby Replication even for RabbitMQ instances not managed by the Kubernetes Cluster Operator.

Upgraded VMware Tanzu Kubernetes Cluster Operator to version 1.13.1 (Release notes)

  • This open source operator provides a consistent and easy way to deploy, manage, and run RabbitMQ clusters to Kubernetes.
  • Version 1.13.1 adds support for Kubernetes 1.23, so operating teams can now upgrade to Kubernetes 1.23. The operator requires Kubernetes 1.19 or later.
  • The operator now deploys RabbitMQ 3.10.2 by default, and supports versions 3.8.8 or later.

Upgraded VMware Tanzu Messaging Topology Operator to version 1.6.0 (Release notes)

  • This open source operator supports managing RabbitMQ messaging topology objects through Kubernetes declarative API.
  • Version 1.6.0 adds support for RabbitMQ not managed by an operator, so now customers can benefit from this topology operator even for RabbiMQ instances deployed  without  the Kubernetes Cluster Operator.
  • Version 1.6.0 also improves time-based reconciliation. By default, Messaging Topology Operator reconciles topology objects when there are create/update/delete events for that particular custom resource. Version 1.6.0 expands on that, allowing reconciliation for all topology objects in a specified frequency.

Upgraded RabbitMQ to version 3.10 (Release notes)

Tanzu RabbitMQ ships with RabbitMQ open source software (OSS), ensuring that it is tested and validated alongside required dependencies. This guarantees that when you use Tanzu RabbitMQ, you are using a validated install, therefore VMware can provide security fixes to any of the included components.

Below we’ve listed the main improvements in OSS RabbitMQ 3.10.

  • Quorum queues – Dead lettering is now safe.  Dead lettering is a process by which some messages stored in RabbitMQ queues that would otherwise expire or be negatively acknowledged by consumers are republished to a special-purpose exchange. However, prior to RabbitMQ 3.10, those messages were not guaranteed to be delivered to the correct queues. RabbitMQ 3.10 introduces “at-least-once” dead lettering to ensure that all dead-lettered messages in the source quorum queue will arrive at the target queues.
  • Classic queues (CQv2) – With CQv2, new message stores and queue index implementations result in a more predictable memory footprint and efficient consumer delivery.
  • Streams – Support for replication over transport layer security (TLS), which is based on an inter-node TLS configuration, allows customers to fully secure the communication between the nodes of their RabbitMQ clusters.
  • Find out more about the impact of the above changes in the RabbitMQ 3.10 performance improvements blog.

The Tanzu RabbitMQ container image also includes:

  • Erlang/OTP 24.3.4
  • OpenSSL 1.0.2ze-fips 3 May 2022

Documentation changes

  • Definitions can be exported to a file and then imported into another cluster, or used for schema backup or data seeding. We have documented some instructions here.
  • The VMware Tanzu Cluster Essentials package now needs to be installed before Tanzu RabbitMQ for Kubernetes V1.3 is installed. This is a requirement as it provides dependencies for kapp-controller and secretgen-controller. We have documented the instructions for installation here.

Learn more

For a deeper dive, check out the VMware Tanzu RabbitMQ for Kubernetes  1.3 release notes. For installation instructions, go to Installing VMware Tanzu RabbitMQ for Kubernetes. For other questions, reach out to the product team directly through our product marketing webpage.

 

 

Paula Stack and Roser Blasco co-wrote this post.
Source CNCF

Previous Rackspace Technology And oak9 Secure Infrastructure As Code And Cloud Operations
Next Digital Realty Strengthens Its Global Platform With Launch Of New Interconnectivity Solution

Suggested Posts