RabbitMQ 3.9 introduces a new type of data structure: streams. Streams unlock a set of use cases that could have been tedious to implement with "traditional" queues. Let's discover in this post how streams expand the capabilities of RabbitMQ.
We intend to release RabbitMQ 3.9.0 on 26 July 2021. While we have been testing it internally for months, with production-like workloads, we need your help to check that it is as stable and reliable as we believe it is.
If you want to be notified when your RabbitMQ deployments have a problem, now you can set up the RabbitMQ monitoring and alerting that we have made available in the RabbitMQ Cluster Operator repository. Rather than asking you to follow a series of steps for setting up RabbitMQ monitoring & alerting, we have combined this in a single command. While this is a Kubernetes-specific quick-start, and you can use these Prometheus alerts outside of Kubernetes, the setup will require more consideration and effort on your part. We share the quick & easy approach, open source and free for all.
Bintray, one of the services our team currently uses to distribute packages, is shutting down on May 1st, 2021.
This post explains what alternative services are available for the RabbitMQ community today or will be before the shutdown date.
No new releases will be published to Bintray going forward. Those who do not switch from Bintray before May 1st will see their deployments begin failing. We highly recommend making migration off of Bintray both an important and urgent task.
We have been constantly improving the monitoring capabilities that are built into RabbitMQ since shipping native Prometheus support in 3.8.0. Monitoring the broker and its clients is critically important for detecting issues before they affect the rest of the environment and, eventually, the end users.
RabbitMQ 3.8.10 exposes client authentication attempts metrics via both the Prometheus endpoint and the HTTP API.
We are pleased to announce that the RabbitMQ Operator for Kubernetes is now generally available. The RabbitMQ Operator makes it easy to provision and manage RabbitMQ clusters consistently on any certified Kubernetes distribution. Operators inform the Kubernetes container orchestration system how to provision and control specific applications. The Kubernetes (hereafter K8s) Operator pattern is a way to extend the K8s API and state management to include the provisioning and management of custom resources -- resources not provided in a default K8s deployment. In this post, we’ll discuss how the Operator enables the K8s system to control a RabbitMQ cluster.
This month in RabbitMQ features a blog from Michael Klishin on deploying RabbitMQ on Kubernetes. Also this month: RabbitMQ consumers on AWS, a three-part series on developing microservices with Lumen and RabbitMQ, and several articles on RabbitMQ and ASP.NET Core.
It’s not the holidays yet, but the RabbitMQ community has presents for you anyway! The RabbitMQ Kubernetes cluster operator is now open-sourced and developed in the open in GitHub. Also, Gavin Roy has a new Python app that migrates queues between types. Finally, a webinar on RabbitMQ consumers from Ayanda Dube, Head of RabbitMQ Engineering at Erlang Solutions.
Over time, we have seen the number of Kubernetes-related queries on our community mailing list and Slack channels soar.
In 2024, the answer to most Kubernetes-related question is: use the Kubernetes Operator built by the RabbitMQ Core Team. It incorporates all the best practices and is the strongly recommended option.
This post explains the basics of a DIY deployment of RabbitMQ on Kubernetes: what Kubernetes resources will be necessary, how to make sure RabbitMQ nodes use durable storage, how to approach configuration of sensitive values, and so on.