Share via

Conexión del conector en la nube MQ de la versión preliminar de MQTT de Azure IoT MQTT a otros agentes de MQTT

  • Artículo

Importante

Operaciones de IoT de Azure, habilitado por Azure Arc, está actualmente en VERSIÓN PRELIMINAR. No se debería usar este software en versión preliminar en entornos de producción.

Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Puede usar el puente MQ Preview MQTT de Azure IoT para conectarse a Azure Event Grid u otros brokers MQTT. El puente MQTT es el proceso de conectar dos agentes MQTT juntos para que puedan intercambiar mensajes.

  • Cuando se puentean dos agentes, los mensajes publicados en un agente se desvían automáticamente al otro y viceversa.
  • El puente MQTT ayuda a crear una red de agentes MQTT que se comunican entre sí, y a expandir la infraestructura MQTT agregando agentes adicionales según sea necesario.
  • El puente MQTT es útil para varias ubicaciones físicas, compartir mensajes y temas MQTT entre el borde y la nube, o cuando desea integrar MQTT con otros sistemas de mensajería.

Para conectar con otro agente, Azure IoT MQ debe conocer la dirección URL del punto de conexión del agente remoto, qué versión de MQTT, cómo autenticarse y qué temas se van a asignar. Para maximizar la capacidad de composición y la flexibilidad de forma nativa de Kubernetes, estos valores se configuran como recursos personalizados de Kubernetes (CRD) llamados MqttBridgeConnector y MqttBridgeTopicMap. En esta guía se explica cómo crear el conector de puente MQTT mediante estos recursos.

  1. Crear un archivo YAML que defina el recurso MqttBridgeConnector. Puede usar el código YAML de ejemplo, pero asegúrese de cambiar para namespace que coincida con el que tiene Azure IoT MQ implementado, y elremoteBrokerConnection.endpoint para que coincida con la dirección URL del punto de conexión del agente remoto.

  2. Crear un archivo YAML que defina el recurso MqttBridgeTopicMap. Puede usar YAML de ejemplo, pero asegúrese de cambiar el namespace para que coincida con el que tiene implementado Azure IoT MQ y el mqttBridgeConnectorRef para que coincida con el nombre del recurso MqttBridgeConnector que creó en el paso anterior.

  3. Implemente el conector de puente MQTT y el mapa de temas con kubectl apply -f <filename>.

    $ kubectl apply -f my-mqtt-bridge.yaml 
mqttbridgeconnectors.mq.iotoperations.azure.com my-mqtt-bridge created
$ kubectl apply -f my-topic-map.yaml
mqttbridgetopicmaps.mq.iotoperations.azure.com my-topic-map created

Una vez implementado, use kubectl get pods para comprobar que los mensajes comienzan a fluir hacia y desde el punto de conexión.

Configuración de MqttBridgeConnector

El recurso MqttBridgeConnector define el conector del puente MQTT que puede comunicarse con un agente remoto. Incluye los siguientes componentes:

  • Una o más instancias del conector puente MQTT. Cada instancia es un contenedor que ejecuta el conector del puente MQTT.
  • Una conexión de agente remoto.
  • Una conexión de agente local opcional.

En el ejemplo siguiente se programa una configuración de ejemplo para el puente a un agente MQTT de Azure Event Grid. Usa la identidad administrada asignada por el sistema para la autenticación y el cifrado TLS.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: MqttBridgeConnector
metadata:
  name: my-mqtt-bridge
  namespace: azure-iot-operations
spec:
  image: 
    repository: mcr.microsoft.com/azureiotoperations/mqttbridge 
    tag: 0.4.0-preview
    pullPolicy: IfNotPresent
  protocol: v5
  bridgeInstances: 1
  clientIdPrefix: factory-gateway-
  logLevel: debug
  remoteBrokerConnection:
    endpoint: example.westeurope-1.ts.eventgrid.azure.net:8883
    tls:
      tlsEnabled: true
    authentication:
      systemAssignedManagedIdentity:
        audience: https://eventgrid.azure.net
  localBrokerConnection:
    endpoint: aio-mq-dmqtt-frontend:8883
    tls:
      tlsEnabled: true
      trustedCaCertificateConfigMap: aio-ca-trust-bundle-test-only
    authentication:
      kubernetes: {}

En la tabla siguiente se describen los campos del recurso MqttBridgeConnector:

Campo Obligatorio Descripción
image Sí La imagen del conector Kafka. Puede especificar los, pullPolicyrepositoryy tag de la imagen. Los valores adecuados se programan en el ejemplo anterior.
protocol Sí Versión del protocolo MQTT. Puede ser v5 o v3. Consulte soporte con MQTT v3.1.1.
bridgeInstances No Número de instancias del conector de puente. El valor predeterminado es 1. Consulte número de instancias.
clientIdPrefix No El prefijo para el id. de cliente generado dinámicamente. El valor predeterminado no es prefijo. Consulte configuración de id. de cliente.
logLevel No Nivel de registro. Puede ser debug o info. El valor predeterminado es info.
remoteBrokerConnection Sí Detalles de conexión del agente remoto al que se va a conectar. Consulte conexión de agente remoto.
localBrokerConnection No Detalles de conexión del agente local al que se va a conectar. El valor predeterminado es el valor mostrado. Consulte conexión de agente local.

Soporte de MQTT v3.1.1

El conector de puente se puede configurar para usar MQTT v3.1.1 con la conexión de agente local para Azure IoT MQ y la conexión de agente remoto. Sin embargo, esto interrumpe las suscripciones compartidas si el agente remoto no lo admite. Si planea usar suscripciones compartidas, déjela como predeterminada v5.

Número de instancias

Para lograr una alta disponibilidad y escala, configure el conector de puente MQTT para usar varias instancias. El flujo de mensajes y las rutas se equilibran automáticamente entre diferentes instancias.

spec:
  bridgeInstances: 2

Configuración del Id. de cliente

Azure IoT MQ genera un Id. de cliente para cada cliente MqttBridgeConnector, mediante un prefijo que especifique, en el formato de {clientIdPrefix}-{routeName}. Este Id. de cliente es importante para Azure IoT MQ para mitigar la pérdida de mensajes y evitar conflictos o colisiones con identificadores de cliente existentes, ya que la especificación MQTT solo permite una conexión por Id. de cliente.

Por ejemplo, si clientIdPrefix: "client-", y hay dos routes en el mapa de temas, los Id. de cliente son: cliente-ruta1 y cliente-ruta2.

Conexión de agente remoto

El remoteBrokerConnection campo define los detalles de conexión que se van a conectar al agente remoto. Contiene los siguientes campos:

Campo Obligatorio Descripción
endpoint Sí Dirección URL del punto de conexión del agente remoto con el puerto. Por ejemplo, example.westeurope-1.ts.eventgrid.azure.net:8883.
tls Sí Especifica si la conexión se cifra con TLS y el certificado de entidad de certificación de confianza. Consulte soporte de TLS
Autenticación Sí Detalles de autenticación de Azure IoT MQ para usarlos con el agente. Debe ser uno de los siguientes valores: identidad administrada asignada por el sistema o X.509. Consulte Autenticación.
protocol No Valor de cadena que define para usar MQTT o MQTT a través de WebSockets. Puede ser mqtt o webSocket. El valor predeterminado es mqtt.

Autenticación

El campo de autenticación define el método de autenticación para que Azure IoT MQ lo use con el agente remoto. Contiene los siguientes campos:

Campo Obligatorio Descripción
systemAssignedManagedIdentity No Autenticarse con la identidad administrada asignada por el sistema. Consulte identidad administrada.
x509 No Detalles de autenticación mediante certificados X.509. Consulte X.509.

Identidad administrada

El campo systemAssignedManagedIdentity incluye los siguientes campos:

Campo Obligatorio Descripción
audiencia Sí Audiencia para el token. Obligatorio si se usa la identidad administrada. Para Event Grid, es https://eventgrid.azure.net.

Si Azure IoT MQ se implementa como una extensión de Azure Arc, obtiene una identidad administrada de asignación del sistema de manera predeterminada. Debe usar una identidad administrada para Azure IoT MQ para interactuar con los recursos de Azure, incluido el agente MQTT de Event Grid, ya que permite evitar la administración de credenciales y conservar la alta disponibilidad.

Para usar la identidad administrada para la autenticación con recursos de Azure, asigne primero un rol RBAC de Azure adecuado, como Publicador de EventGrid TopicSpaces a la identidad administrada de Azure IoT MQ proporcionada por Arc.

A continuación, especifique y MQTTBridgeConnector con identidad administrada como método de autenticación:

spec:
  remoteBrokerConnection:
    authentication:
      systemAssignedManagedIdentity:
        audience: https://eventgrid.azure.net

Cuando se usa la identidad administrada, el Id. del cliente no es configurable y equivale al Id. del recurso Azure Resource Manager de la extensión Azure Arc de Azure IoT MQ dentro de Azure.

Azure Arc proporciona la identidad administrada asignada por el sistema. El certificado asociado a la identidad administrada debe renovarse al menos cada 90 días para evitar un proceso de recuperación manual. Para más información, consulte ¿Cómo me dirijo a los recursos de Kubernetes habilitados para Azure Arc expirados?

X.509

El campo x509incluye los siguientes campos:

Campo Obligatorio Descripción
secretName Sí Secreto de Kubernetes que contiene el certificado de cliente y la clave privada. Puede usar Azure Key Vault para administrar secretos de Azure IoT MQ en lugar de secretos de Kubernetes. Para más información, consulte Administración de secretos mediante Azure Key Vault o secretos de Kubernetes.

Muchos agentes MQTT, como Event Grid, admiten la autenticación X.509. El puente MQTT de Azure IoT MQ puede presentar un certificado de cliente X.509 y negociar la comunicación TLS. Use un secreto de Kubernetes para almacenar el certificado de cliente X.509, la clave privada y la entidad de certificación intermedia.

kubectl create secret generic bridge-client-secret \
--from-file=client_cert.pem=mqttbridge.pem \
--from-file=client_key.pem=mqttbridge.key \
--from-file=client_intermediate_certs.pem=intermediate.pem

Y hacer referencia con secretName:

spec:
  remoteBrokerConnection:
    authentication:
      x509:
        secretName: bridge-client-cert

Conexión de agente local

El campolocalBrokerConnection define los detalles de la conexión para hacer puente con el agente local.

Campo Obligatorio Descripción
endpoint Sí Dirección URL del punto de conexión del agente remoto con el puerto.
tls Sí Especifica si la conexión se cifra con TLS y el certificado de entidad de certificación de confianza. Consulte soporte de TLS
Autenticación Sí Detalles de autenticación de Azure IoT MQ para usarlos con el agente. El único método admitido es el token de cuenta de servicio de Kubernetes (SAT). Para usar SAT, especifique kubernetes: {}.

De manera predeterminada, IoT MQ se implementa en el espacio de nombres azure-iot-operations con la autenticación TLS habilitada y SAT.

A continuación, se debe configurar la configuración de conexión del agente local MqttBridgeConnector para que coincida. El YAML de implementación para MqttBridgeConnector debe tener localBrokerConnection en el mismo nivel que remoteBrokerConnection. Por ejemplo, para usar TLS con autenticación SAT en orden para que coincida con la implementación predeterminada de IoT MQ:

spec:
  localBrokerConnection:
    endpoint: aio-mq-dmqtt-frontend:8883
    tls:
      tlsEnabled: true
      trustedCaCertificateConfigMap: aio-ca-trust-bundle-test-only
    authentication:
      kubernetes: {}

Aquí, trustedCaCertifcateName es el ConfigMap para la CA raíz de Azure IoT MQ, como el ConfigMap para la ca raíz del agente remoto. La CA de certificación raíz predeterminada se almacena en un objeto ConfigMap denominado aio-ca-trust-bundle-test-only.

Para más información sobre cómo obtener la CA raíz, consulte Configuración de TLS con administración automática de certificados para proteger la comunicación MQTT.

Soporte técnico de TLS

El campo tls define la configuración de TLS para la conexión de agente local o remoto. Contiene los siguientes campos:

Campo Obligatorio Descripción
tlsEnabled Sí Si TLS está habilitado o no.
trustedCaCertificateConfigMap No El certificado CA del que se va a confiar cuando se conecte al agente. Obligatorio si TLS está habilitado.

El cifrado TLS es un soporte disponible tanto para las conexiones de agentes remotos y locales.

  • Para la conexión de agente remoto: si TLS está habilitado, se debe especificar un certificado de ENTIDAD de certificación de confianza como referencia de Kubernetes ConfigMap. Si no es así, es probable que se produzca un error en el protocolo de enlace TLS a menos que el punto de conexión remoto sea de confianza Un certificado de CA de confianza ya esté en el almacén de certificados del sistema operativo. Por ejemplo, Event Grid usa una raíz de CA de certificación de confianza amplia, por lo que no es necesario especificar.
  • Para la conexión de agente local (Azure IoT MQ): si TLS está habilitado para el agente de escucha Azure IoT MQ, el certificado CA que emitió el certificado del servidor de escucha debe especificarse como referencia de Kubernetes ConfigMap.

Al especificar una CA de certificación de confianza, crear un ConfigMap que contenga la poción pública de la CA de certificación y especifique el nombre de configmap en la propiedad trustedCaCertificateConfigMap. Por ejemplo:

kubectl create configmap client-ca-configmap --from-file ~/.step/certs/root_ca.crt

Configuración de MqttBridgeTopicMap

El recursoMqttBridgeTopicMap define la asignación de temas entre los agentes locales y remotos. Debe usarse junto con un recurso de MqttBridgeConnector. Incluye los siguientes componentes:

  • Nombre del recurso MqttBridgeConnector al que se va a vincular.
  • Una lista de rutas para el puente.
  • Una configuración de suscripción compartida opcional.

Un MqttBridgeConnector puede usar varios MqttBridgeTopicMaps vinculados con él. Cuando se implementa un recurso MqttBridgeConnector, el operador MQ de Azure IoT comienza a examinar el espacio de nombres de los mqttBridgeTopicMaps vinculado a él y administra automáticamente el flujo de mensajes entre las instancias de MqttBridgeConnector. Después, una vez implementado, el MqttBridgeTopicMap está vinculado con MqttBridgeConnector. Cada MqttBridgeTopicMap solo se puede vincular con un MqttBridgeConnector.

En el ejemplo siguiente se muestra una configuración de MqttBridgeTopicMap para el puente de mensajes desde el tema remote-topic remoto al tema locallocal-topic:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: MqttBridgeTopicMap
metadata:
  name: my-topic-map
  namespace: azure-iot-operations 
spec:
  mqttBridgeConnectorRef: my-mqtt-bridge
  routes:
    - direction: remote-to-local
      name: first-route
      qos: 0
      source: remote-topic
      target: local-topic
      sharedSubscription:
        groupMinimumShareNumber: 3
        groupName: group1
    - direction: local-to-remote
      name: second-route
      qos: 1
      source: local-topic
      target: remote-topic

En la tabla siguiente se describen los campos del recurso MqttBridgeTopicMap:

Campos Obligatorio Descripción
mqttBridgeConnectorRef Sí Nombre del MqttBridgeConnector recurso al que se va a vincular.
rutas Sí Una lista de rutas para el puente. Para obtener más información, consulte Rutas.

Rutas

Un MqttBridgeTopicMap puede tener varias rutas. El camporoutes define la lista de rutas. Contiene los siguientes campos:

Campos Obligatorio Descripción
direction Sí Dirección del flujo de mensajes. Puede ser remote-to-localolocal-to-remote. Para obtener más información, consulteDirección.
name Sí Nombre de la ruta.
qos No Calidad de servicio de MQTT (QoS). De manera predeterminada, su valor es 1.
source Sí Tema MQTT de origen. Puede tener caracteres comodín como # y +. Consulte Caracteres comodín en el tema de origen.
Destino No Tema MQTT de destino. No se pueden tener caracteres comodín. Si no se especifica, sería el mismo que el origen. Consulte El tema de origen de referencia en el destino.
sharedSubscription No Configuración de la suscripción compartida. Activa un número configurado de clientes para escalado adicional. Para obtener más información, consulte Suscripciones compartidas.

Direction

Por ejemplo, si la dirección es de local a remoto, Azure IoT MQ publica todos los mensajes del tema local especificado en el tema remoto:

routes:
  - direction: local-to-remote
    name: "send-alerts"
    source: "alerts"
    target: "factory/alerts"

Si la dirección es inversa, Azure IoT MQ recibe mensajes de un agente remoto Aquí, el destino es omitido y todos los mensajes del commands/factory tema en el agente remoto es publicado en el mismo tema localmente.

routes:
  - direction: remote-to-local
    name: "receive-commands"
    source: "commands/factory"

Caracteres comodín en el tema de origen

Para crear puentes a partir de temas no estáticos, use comodines para definir cómo deben coincidir los patrones de temas y la regla de traducción del nombre del tema. Por ejemplo, para hacer puentes entre todos los mensajes de todos los subtemas bajotelemetry, use el carácter comodín #de varios niveles :

routes:
  - direction: local-to-remote
    name: "wildcard-source"
    source: "telemetry/#"
    target: "factory/telemetry"

En el ejemplo, si se publica un mensaje en cualquier tema en telemetry, como telemetry/furnace/temperature, Azure IoT MQ lo publica en el agente puente remoto en el tema estáticofactory/telemetry.

En el caso del carácter comodín de tema de nivel único, use + en su lugar, como telemetry/+/temperature.

El conector del puente MQTT debe conocer el tema exacto en el agente de destino, ya sea remoto o Azure IoT MQ sin ambigüedad. Los caracteres comodín solo están disponibles como parte del source tema.

Tema de origen de referencia en el destino

Para hacer referencia a todo el tema de origen, omita completamente la configuración del tema de destino en la ruta. Se admite caracteres comodín.

Por ejemplo, cualquier mensaje publicado en el tema my-topic/#, como my-topic/foo o my-topic/bar, se puente al agente remoto en el mismo tema:

routes:
  - direction: local-to-remote
    name: "target-same-as-source"
    source: "my-topic/#"
    # No target

No se admiten otros métodos de referencia de temas de origen.

Suscripciones compartidas

El campo sharedSubscription define la configuración de la suscripción compartida para la ruta. Contiene los siguientes campos:

Campos Obligatorio Descripción
groupMinimumShareNumber Sí Número de clientes que se van a usar para la suscripción compartida.
groupName Sí Nombre del grupo de suscripciones compartido.

Las suscripciones compartidas ayudan a Azure IoT MQ a crear más clientes para el puente MQTT. Puede configurar una suscripción compartida diferente para cada ruta. Azure IoT MQ se suscribe a los mensajes del tema de origen y los envía a un cliente a la hora de usar round robin. A continuación, el cliente publica los mensajes en el agente puente.

Por ejemplo, si configura una ruta con una suscripción compartida y establece el groupMinimumShareNumber como 3:

routes:
    - direction: local-to-remote
      qos: 1
      source: "shared-sub-topic"
      target: "remote/topic"
      sharedSubscription:
        groupMinimumShareNumber: 3
        groupName: "sub-group"

El puente MQTT de Azure IoT MQ crea tres clientes de suscriptor sin importar cuántas instancias. Solo un cliente obtiene cada mensaje de $share/sub-group/shared-sub-topic. A continuación, el mismo cliente publica el mensaje en el agente remoto puente en el tema remote/topic. El siguiente mensaje va a un siguiente cliente.

Esto le ayuda a equilibrar el tráfico de mensajes para el puente entre múltiples clientes con diferentes Id. Esto resulta útil si el agente puente limita el número de mensajes que cada cliente puede enviar.

Soporte del agente MQTT de Azure Event Grid

Para minimizar la administración de credenciales, el uso de la identidad administrada asignada por el sistema y RBAC de Azure es la manera recomendada de puente de Azure IoT MQ con característica de agente MQTT de Azure Event Grid.

Para ver un tutorial completo, consulte Tutorial: Configuración del puente MQ entre azure IoT MQ Preview y Azure Event Grid.

Conexión al agente MQTT de Event Grid con identidad administrada

En primer lugar, con az k8s-extension show, busque el Id. de entidad de seguridad para la extensión Azure IoT MQ Arc. Tome nota del valor de salida de identity.principalId, que debería ser similar a abcd1234-5678-90ab-cdef-1234567890ab.

az k8s-extension show --resource-group <RESOURCE_GROUP> --cluster-name <CLUSTER_NAME> --name mq --cluster-type connectedClusters --query identity.principalId -o tsv

A continuación, use la CLI de Azure para asignar los roles a la identidad administrada de la extensión MQ Arc de Azure IoT. Reemplace por <MQ_ID> el Id. de la entidad de seguridad que encontró en el paso anterior. Por ejemplo, para asignar el rol publicador EventGrid TopicSpaces:

az role assignment create --assignee <MQ_ID> --role 'EventGrid TopicSpaces Publisher' --scope /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.EventGrid/namespaces/<EVENT_GRID_NAMESPACE>

Sugerencia

Para optimizar el principio de privilegios mínimos, puede asignar el rol a un espacio de temas en lugar de todo el espacio de nombres de Event Grid. Para obtener más información, consulte RBAC de Event Grid y espacios de temas.

Por último, crear un MQTTBridgeConnector y elija identidad administrada como método de autenticación. Crear MqttBridgeTopicMaps e implemente el puente MQTT con kubectl.

Número máximo de sesiones de cliente por nombre de autenticación

Si bridgeInstances se establece un valor superior a 1, configure el agente MQTT de Event GridConfiguración>máxima de sesiones de cliente por nombre de autenticación para que coincida con el número de instancias. Esta configuración evita incidencias como el error 151 de la cuota superada.

Límite por conexión

Si no es posible usar la identidad administrada, tenga en cuenta los límites por conexión del agente MQTT de Event Grid al diseñar la configuración. En el momento de la publicación, el límite es de 100 mensajes/segundo cada dirección para una conexión. Para aumentar el rendimiento del puente MQTT, use suscripciones compartidas para aumentar el número de clientes que atienden cada ruta.

Versión preliminar de Puente desde otro agente a Azure IoT MQ

Azure IoT MQ es un agente MQTT compatible y otros agentes pueden hacer puente con él con las credenciales de autenticación y autorización adecuadas. Por ejemplo, consulte la documentación del puente MQTT para HiveMQ, VerneMQ, EMQXy Mosquitto.

Contenido relacionado