Since many of our applications will likely wish to use RabbitMQ for private things like work queues, using separate vhosts is a good idea. This sets up a single vhost to act as a fedmsg replacement (called pubsub) and configures it for high availability.
The HA policy mirrors queues to all nodes in the cluster and enables automatic synchronization with a batch size of 10K messages. Automatic synchronization means that when a new node joins the cluster, all messages from existing nodes are pushed to the new node, blocking queue activity until mirroring is complete.
Signed-off-by: Jeremy Cline jcline@redhat.com --- roles/rabbitmq_cluster/files/enabled_plugins | 1 - roles/rabbitmq_cluster/tasks/main.yml | 38 +++++++++++++++----- 2 files changed, 29 insertions(+), 10 deletions(-) delete mode 100644 roles/rabbitmq_cluster/files/enabled_plugins
diff --git a/roles/rabbitmq_cluster/files/enabled_plugins b/roles/rabbitmq_cluster/files/enabled_plugins deleted file mode 100644 index 6a9f28b93..000000000 --- a/roles/rabbitmq_cluster/files/enabled_plugins +++ /dev/null @@ -1 +0,0 @@ -[rabbitmq_management,rabbitmq_auth_mechanism_ssl]. diff --git a/roles/rabbitmq_cluster/tasks/main.yml b/roles/rabbitmq_cluster/tasks/main.yml index 468cbc5ac..1781eb2c4 100644 --- a/roles/rabbitmq_cluster/tasks/main.yml +++ b/roles/rabbitmq_cluster/tasks/main.yml @@ -52,15 +52,6 @@ - rabbitmq_cluster - config
-- name: enable plugins - copy: src=enabled_plugins dest=/etc/rabbitmq/enabled_plugins owner=root group=root mode=0644 - with_items: - - rabbitmq.config - - enabled_plugins - tags: - - rabbitmq_cluster - - config - - name: deploy configuration template: src={{item}} dest=/etc/rabbitmq/{{item}} owner=root group=root mode=0644 with_items: @@ -96,6 +87,13 @@ - rabbitmq_cluster - config
+- name: Enable the HTTP management console and SSL authentication plugins + rabbitmq_plugin: + names: rabbitmq_management,rabbitmq_auth_mechanism_ssl + tags: + - rabbitmq_cluster + - config + - name: start rabbitmq service: name=rabbitmq-server state=started enabled=yes tags: @@ -106,3 +104,25 @@ tags: - rabbitmq_cluster - config + +- name: Configure the pubsub virtual host + rabbitmq_vhost: + name: /pubsub + state: present + tags: + - rabbitmq_cluster + - config + +- name: Configure the HA policy for queues on the pubsub virtual + rabbitmq_policy: + name: HA + apply_to: queues + pattern: .* + tags: + ha-mode: all + ha-sync-mode: automatic # Auto sync queues to new cluster members + ha-sync-batch-size: 10000 # Larger is faster, but must finish in 1 net_ticktime + vhost: /pubsub + tags: + - rabbitmq_cluster + - config
+1, but should we name that queue something like 'fedora-messaging' to be more descriptive? Or does that matter much?
kevin
On 09/28/2018 07:15 PM, Kevin Fenzi wrote:
+1, but should we name that queue something like 'fedora-messaging' to be more descriptive? Or does that matter much?
A virtual host in RabbitMQ is like a namespace for AMQP that you can apply permissions to. The "pubsub" virtual host will contain all the exchanges and queues we use to replace general fedmsg usage. There could be others for individual applications that want to use AMQP for, say, Celery tasks.
My thinking was that "pubsub" was more descriptive for a newcomer than "fedmsg" or something since it's general publishing and subscribing for apps and services.
That being said, names are hard and I welcome alternatives, so if people think something else is more descriptive now's the best time to voice your opinion.
infrastructure@lists.fedoraproject.org
-
Jeremy Cline -
Jeremy Cline -
Kevin Fenzi