Este conteúdo não está disponível no idioma selecionado.
Chapter 6. Connecting clients to the router network
After creating a router network, you can connect clients (messaging applications) to it so that they can begin sending and receiving messages.
By default, the Red Hat Integration - AMQ Interconnect Operator creates a Service for the router deployment and configures the following ports for client access:
-
5672
for plain AMQP traffic without authentication -
5671
for AMQP traffic secured with TLS authentication
To connect clients to the router network, you can do the following:
- If any clients are outside of the OpenShift cluster, expose the ports so that they can connect to the router network.
- Configure your clients to connect to the router network.
6.1. Exposing ports for clients outside of OpenShift Container Platform
You expose ports to enable clients outside of the OpenShift Container Platform cluster to connect to the router network.
Procedure
Start editing the
Interconnect
Custom Resource YAML file that describes the router deployment for which you want to expose ports.$ oc edit -f router-mesh.yaml
In the
spec.listeners
section, expose each port that you want clients outside of the cluster to be able to access.In this example, port
5671
is exposed. This enables clients outside of the cluster to authenticate with and connect to the router network.Sample
router-mesh.yaml
fileapiVersion: interconnectedcloud.github.io/v1alpha1 kind: Interconnect metadata: name: router-mesh spec: ... listeners: - port: 5672 - authenticatePeer: true expose: true http: true port: 8080 - port: 5671 sslProfile: default expose: true ...
The Red Hat Integration - AMQ Interconnect Operator creates a Route, which clients from outside the cluster can use to connect to the router network.
6.2. Authentication for client connections
When you create a router deployment, the Red Hat Integration - AMQ Interconnect Operator uses the Red Hat Integration - AMQ Certificate Manager Operator to create default SSL/TLS certificates for client authentication, and configures port 5671
for SSL encryption.
6.3. Configuring clients to connect to the router network
You can connect messaging clients running in the same OpenShift cluster as the router network, a different cluster, or outside of OpenShift altogether so that they can exchange messages.
Prerequisites
- If the client is outside of the OpenShift Container Platform cluster, a connecting port must be exposed. For more information, see Section 6.1, “Exposing ports for clients outside of OpenShift Container Platform”.
Procedure
To connect a client to the router network, use the following connection URL format:
<scheme>://[<username>@]<host>[:<port>]
- <scheme>
Use one of the following:
-
amqp
- unencrypted TCP from within the same OpenShift cluster -
amqps
- for secure connections using SSL/TLS authentication -
amqpws
- AMQP over WebSockets for unencrypted connections from outside the OpenShift cluster
-
- <username>
- If you deployed the router mesh with user name/password authentication, provide the client’s user name.
- <host>
- If the client is in the same OpenShift cluster as the router network, use the OpenShift Service host name. Otherwise, use the host name of the Route.
- <port>
If you are connecting to a Route, you must specify the port. To connect on an unsecured connection, use port
80
. Otherwise, to connect on a secured connection, use port443
.NoteTo connect on an unsecured connection (port
80
), the client must use AMQP over WebSockets (amqpws
).
The following table shows some example connection URLs.
URL | Description |
---|---|
|
The client and router network are both in the same OpenShift cluster, so the Service host name is used for the connection URL. In this case, user name/password authentication is implemented, which requires the user name ( |
|
The client is outside of OpenShift, so the Route host name is used for the connection URL. In this case, SSL/TLS authentication is implemented, which requires the |
|
The client is outside of OpenShift, so the Route host name is used for the connection URL. In this case, no authentication is implemented, which means the client must use the |