Skip to content
This repository has been archived by the owner on Jan 24, 2023. It is now read-only.

Latest commit

 

History

History
212 lines (130 loc) · 7.89 KB

chapter4.md

File metadata and controls

212 lines (130 loc) · 7.89 KB

Attach an AMQ Broker

The previous message flow was broker-less, it requires both producer and consumer to be active for the traffic to flow. It is a very advantageous messaging pattern as it guarantees message delivery from the producer to the consumer.

The above works well for systems designed to run synchronously. You might however require to accommodate asynchronous clients in need to send messages when no active consumer is running.

You can attach an AMQ Broker to the routing layer to enable store & forward messaging. This would enable the messaging layer to persist messages and retain them until a consumer connects to the network and consumes them.

In the instructions below you will be adhering an AMQ Broker to Region-2 where messages will be persisted before they cross to Region-1. Please note that the entire Routing Mesh acts as a single logical cluster, therefore, the location of where the AMQ Broker is attached is not critical.

Good to know: Interconnect never takes ownership of a message, it only wires connectivity between ends. Furthermore, in the AMQP specification, anything can be an AMQP client, that includes Brokers, meaning Interconnect could enable a transition path from one broker to another, as if one was an AMQP producer and the other an AMQP consumer.


  1. Install AMQ's Broker Operator

    As a standard user, ensure you're working in Cluster-2 where we will deploy the broker.

    Note: the broker could be connected anywhere in the Interconnect layer.

    oc project amq-cluster2
    

    Install AMQ's Broker Operator:

    • Web Console ➡ Operators ➡ OperatorHub ➡ AMQ Broker ➡ Install

      (at the time of writing: v0.9.1)

    Select amq-cluster2 as the target namespace, and click 'Subscribe'.

    Be patient: this action may take some time as OpenShift may need to pull the Operator's image from a remote repository.

    This will trigger the Operator's installation. To view the running pod execute:

    oc get pods -n amq-cluster2
    

    You should see something similar to:

    NAME                                    READY   STATUS    RESTARTS   AGE
    amq-broker-operator-84f7fcc8b-2x225     1/1     Running   0          28s
    

  1. Deploy a Broker instance

    Once the Operator is running, deploy the Broker:

    From namespace amq-cluster2:

    • Operators ➡ Installed Operators ➡ AMQ Broker ➡ AMQ Broker ➡ Create Active MQArtemis

    Review the default YAML definition:

    metadata: name: broker1

    By default, the broker does not include an AMQP acceptor, we need to explicitly define one:

    spec:
      acceptors:
        - name: amqp
          port: 5672
          protocols: amqp

    The YAML result should look like:

    apiVersion: broker.amq.io/v2alpha1
    kind: ActiveMQArtemis
    metadata:
      name: broker1
      namespace: amq-cluster2
    spec:
      deploymentPlan:
        size: 1
        image: 'registry.redhat.io/amq7/amq-broker:7.5'
      acceptors:
        - name: amqp
          port: 5672
          protocols: amqp

    Click 'Create' to kick off the deployment.

    Be patient: this action may take some time as OpenShift may need to pull the Broker's image from a remote repository.

    The Operator will deploy the Broker as per the definition above, and also create other necessary elements. A service will be created for clients to access the broker with the following pattern:

    {broker-name}-hdls-svc
    

    If you defined the name broker1 then the service name would be:

    broker1-hdls-svc
    

    OPTIONAL: If you'd like to access the Broker's web console you can create a Route, follow the instructions below:

    • Navigate to:

      • Web Console ➡ Networking ➡ Routes ➡ Create Route
         Name:        amq-console
         Service:     broker1-hdls-svc
         Target Port: 8161 -> 8161 (TCP)
        

      Click 'Create'.

      Open the Location link in a new browser tab. It should open AMQ's Broker Management console. Default credentials are admin/admin.


  1. Attach the broker to the routing layer

    At this stage you should have an AMQ Broker successfully deployed but running in isolation. Now it needs to be attached Interconnect. Follow the instructions below.

    From namespace amq-cluster2 navigate to:

    • Web Console ➡ Operators ➡ Installed Operators ➡ AMQ Interconnect ➡ AMQ Interconnect ➡ cluster2-router-mesh ➡ YAML

    Include the following elements:

    spec:
      connectors:
        - name: my-broker
          host: broker1-hdls-svc.amq-cluster2.svc.cluster.local
          port: 5672
          routeContainer: true
      linkRoutes:
        - prefix: test
          direction: in
          connection: my-broker
        - prefix: test
          direction: out
          connection: my-broker

    Note: the field host represents the fully service DNS address pointing to the broker's service.

    In the YAML portion above you will notice a connector is being defined pointing to the newly deployed broker. Also, the test prefix indicates for which addresses the Routing layer should forward messages to the broker. The address test matches the address our Fuse AMQP clients are using to produce/consume messages.

    Click 'Save'. The Operator watching the cluster will reconfigure Interconnect and restart the router nodes to open connections to the defined broker.

    Once Interconnect reset, if you re-open its web console you'll find the AMQ Broker (Artemis symbol) attached to both routing nodes running in Region-2. Inteconnect's Operator applies the same configuration to both routers.



Test Brokered Interconnect flow:

Since we've attached a Broker to Interconnect, the messaging flow run earlier will now go through the broker. To demonstrate it, execute the following steps:

  1. Run the producer

    Ensure both the producer and consumer are stopped. Then start only the producer.

    You will observe this round the producer immediately starts sending messages, the attached broker is providing credits to the client.

    After some messages are sent, stop the producer.

  2. Run the consumer

    Now, start the consumer. You will observe how it is able to consume all the messages stored in the Broker until there's none left.

  3. Run both

    If you run both, a constant flow of messages will traverse the following instances:

    Producer ➡ Router (region-1) ➡ Broker ➡ Router (region-1) ➡ Router (region-2) ➡ Consumer

    Note: depending on which routings nodes the AMQP clients are connected to, the flow might hop some more routing nodes.

    All parties involved can be visualised in the web console as shown below:

    Notice in the picture above how the AMQ Broker has an active link in use (solid black line) that illustrates messages are being inserted and extracted from the broker.



Well done! you've reached the end of the tutorial and you should have successfully deployed a full Federated multi-cluster Messaging layer.


Final words

This tutorial has introduced you to a proposed topology that was targeted for a federation use case. This scenario of course is only one of many.

Messaging allows many different interaction patterns (eg. one-to-one, one-to-many, etc), and many different topologies to address very different needs.

The combination of AMQ Interconnect with AMQ Broker is very powerful, and valid for most messaging use cases. You can discover more possibilities by exploring features and capabilities of these technologies.

OpenShift can help you to greatly reduce administrative tasks but don't forget AMQ can also be deployed and used outside OpenShift.


From here you can return to the main Introduction page and start all over again !