Implementar un host de conectores local

Descubre los pasos técnicos para implementar, configurar y mantener los hosts de conector locales (OPCH) para tus integraciones de Tulip.

Este artículo es una guía de referencia técnica dirigida a las personas responsables de la implementación física y la gestión del ciclo de vida de los OPCH. El «Connector Host» es un servicio que se utiliza para facilitar las conexiones desde

servicios web externos, bases de datos y servidores OPC UA. Todas las instancias de Tulip cuentan con un «Cloud Connector Host» de forma predeterminada.

Hay varias consideraciones que deben tenerse en cuenta a la hora de determinar si un host de conector local es la arquitectura más adecuada.

Requisitos previos

Antes de continuar, asegúrate de que conoces los conceptos básicos de los hosts de conector de Tulip:* Hosts de conector* Hosts de conector locales

Redes

La razón más habitual para implementar un host de conector local son las ventajas que ofrece a la hora de conectarse a sistemas alojados dentro de una red local. Con la opción local, todas las conexiones desde Tulip a sistemas externos se inician desde dentro de su red local. Todas las conexiones desde su red son salientes hacia Tulip a través de un WebSocket seguro.

Esto contrasta con los hosts de conector en la nube, que requieren acceso entrante a los servicios. Normalmente, se trata de una decisión del departamento de TI para permitir conexiones WebSocket seguras entrantes desde la nube de Tulip hacia el servicio, a menudo utilizando reglas de reenvío de puertos en el router o el cortafuegos de la WAN.

Implementar un host de conector local

Normas técnicas

Cuando se toma la decisión de implementar una solución local, Tulip recomienda una vía de autoservicio mediante una imagen de Docker distribuida. La forma más sencilla de hacerlo sería utilizar una máquina virtual con una distribución de Linux.

Tulip también recomienda alojar solo un host de conector local por máquina virtual para evitar un único punto de fallo en los sitios.

Requisitos de la máquina virtual:

• RAM: 4 GB
• Espacio en disco: 8-16 GB
• CPU: 2 núcleos
• Versión de Docker: 20.10 o superior

En cuanto a los requisitos de red, el host del conector local cuenta con lo siguiente:

• Una dirección IP
• Resolución DNS a
• Acceso saliente en el puerto 443 a Tulip (direcciones IP indicadas aquí)
• Acceso saliente al repositorio de Docker que se indica aquí
• Acceso saliente a todos los sistemas externos pertinentes a través de los puertos

Consulta la lista completa de requisitos de red aquí

Implementación

En la siguiente sección se describe cómo implementar un host de conector local en diversos entornos. Tanto AWS como Azure ofrecen servicios de contenedores capaces de ejecutar la imagen de Docker.

AWS

Utiliza la interfaz de usuario web y este conjunto de instrucciones: https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/

Azure (Bash): LTS16+ OPCH

az container create `-g <NOMBRE DEL GRUPO DE RECURSOS EN AZURE> `--name <NOMBRE DEL CONTENEDOR> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:<TAG>--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<TU SITIO>.tulip.co' `TULIP_MACHINE_SECRET='<SECRETO>' `TULIP_DEVICE_TYPE='onprem' `TULIP_LOGGING_TO_TULIP=true`TULIP_TELEMETRY_TO_TULIP=true`TULIP_CONNECTORS_HTTP_PROXY='' `TULIP_CONNECTORS_HTTPS_PROXY=''

Azure (Bash): OPCH anterior a LTS16

az container create `-g <NOMBRE DEL GRUPO DE RECURSOS EN AZURE> `--name <NOMBRE DEL CONTENEDOR> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:<TAG> `--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<TU SITIO>.tulip.co' `TULIP_MACHINE_SECRET='<SECRETO>' `TULIP_DEVICE_TYPE='onprem' `CONNECTORS_HTTP_PROXY='' `CONNECTORS_HTTPS_PROXY=''

Máquina virtual Linux: LTS16+ OPCH

docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e TULIP_LOGGING_TO_TULIP=true \ -e TULIP_TELEMETRY_TO_TULIP=true \ -e TULIP_CONNECTORS_HTTP_PROXY='' \ -e TULIP_CONNECTORS_HTTPS_PROXY='' \ --restart=always \ --net=host \ public.ecr.aws/tulip/connector-host:<TAG>

Máquina virtual Linux: OPCH anterior a LTS16

 --name tulip-connector-host \  
 -e TULIP\_FACTORY='https://.tulip.co' \  
 -e TULIP\_UUID='' \  
 -e TULIP\_MACHINE\_SECRET='' \  
 -e TULIP\_DEVICE\_TYPE='onprem' \  
 -e CONNECTORS\_HTTP\_PROXY='' \  
 -e CONNECTORS\_HTTPS\_PROXY='' \  
 -e EXIT\_ON\_DISCONNECT=true \ --restart=always \  
 --net=host \  
 --mount type=volume,source=tuliplog,target=/log \  
 public.ecr.aws/tulip/connector-host:

Windows (PowerShell): LTS16+ OPCH

docker run -d --name tulip-connector-host -e TULIP_FACTORY='https://<FACTORY>.tulip.co' -e TULIP_UUID='<UUID>' -e TULIP_MACHINE_SECRET='<SECRET>' -e TULIP_DEVICE_TYPE='onprem' -e TULIP_LOGGING_TO_TULIP=true -e TULIP_TELEMETRY_TO_TULIP=true -e TULIP_CONNECTORS_HTTP_PROXY='' -e TULIP_CONNECTORS_HTTPS_PROXY='' --restart=always --net=host public.ecr.aws/tulip/connector-host:<TAG>

Windows (PowerShell): OPCH anterior a LTS16

docker run -d --name tulip-connector-host -e TULIP_FACTORY='https://<FACTORY>.tulip.co' -e TULIP_UUID='<UUID>' -e TULIP_MACHINE_SECRET='<SECRET>' -e TULIP_DEVICE_TYPE='onprem' -e HTTP_PROXY='' -e HTTPS_PROXY='' -e EXIT_ON_DISCONNECT=true --restart=always --net=host --mount type=volume,source=tuliplog,target=/log public.ecr.aws/tulip/connector-host:<TAG>

Solución de problemas relacionados con los certificados

Si OPCH no se inicia y muestra errores del tipo «certificado autofirmado en la cadena de certificados», la causa principal podría ser que el proxy o el cortafuegos corporativo, con certificados personalizados, impida las conexiones seguras a Tulip Cloud.

Síntomas: - OPCH muestra el estado «Never seen» (Nunca visto). - El proceso se interrumpe durante el inicio. - Errores en la cadena de certificados SSL en los registros.

Para resolverlo, se pueden especificar autoridades de certificación adicionales durante el inicio de OPCH mediante la siguiente variable de entorno, tal y como se indica a continuación. Ten en cuenta que el archivo debe estar presente en el contenedor Docker.

Para OPCH anterior a LTS16: -e CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

Para OPCH LTS16 y posteriores: -e TULIP_CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

Actualizar un host de conector local

:::(Advertencia) (Es posible que también sea necesario actualizar su Edge IO)
OPCH puede ejecutarse en dispositivos Edge IO. Si su dispositivo no tiene habilitada la actualización automática, deberá actualizarlo manualmente.

Si este mensaje de advertencia sigue apareciendo después de haber completado todas las actualizaciones de OPCH, asegúrate de que tu Edge IO también se haya actualizado.
:::

Tulip lanza actualizaciones para el On-Premise Connector Host de acuerdo con nuestro calendario de lanzamientos de soporte a largo plazo (LTS). Para actualizar el servicio, sigue las instrucciones que se indican a continuación:

El proceso de actualización de un OPCH provocará un tiempo de inactividad mientras el pod se detiene y se vuelve a crear.

1. Consigue la última versión de la imagen Docker del On-Premise Connector Host.

   docker pull public.ecr.aws/tulip/connector-host:<TAG>2. Ejecuta el siguiente comando para obtener el ID del contenedor de Docker.

   docker ps3. Si tiene acceso a TULIP_FACTORY, TULIP_UUID y TULIP_MACHINE_SECRET, vaya al paso 4. Si no es así, ejecute el siguiente comando y guarde el resultado en un lugar seguro.

   docker exec <id-del-contenedor> env4. Detén el contenedor de Docker existente.

   docker stop <id-del-contenedor>5. Elimina el contenedor de Docker existente.

   docker rm <id-del-contenedor>6. Ejecuta el comando estándar «docker run» utilizando el conjunto de credenciales guardadas.

Para OPCH LTS16+: docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e TULIP_LOGGING_TO_TULIP=true \ -e TULIP_TELEMETRY_TO_TULIP=true \ -e TULIP_CONNECTORS_HTTP_PROXY='' \ -e TULIP_CONNECTORS_HTTPS_PROXY='' \ --restart=always \ --net=host \ public.ecr.aws/tulip/connector-host:<TAG>Para OPCH anteriores a LTS16: docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e CONNECTORS_HTTP_PROXY='' \ -e CONNECTORS_HTTPS_PROXY='' \ -e EXIT_ON_DISCONNECT=true \ --restart=always \ --net=host \ --mount type=volume,source=tuliplog,target=/log \ public.ecr.aws/tulip/connector-host:<TAG>

1. Comprueba que el nuevo contenedor de Docker esté activo.

   docker ps

Utiliza los entornos de los conectores para probar la actualización

Cada conector dispone de tres entornos diferentes (producción, preproducción y desarrollo) y cada uno de estos entornos puede tener su propio host de conector, pudiendo ser de versiones distintas. Dependiendo del estado de la aplicación (versión en desarrollo, pendiente de aprobación, publicada), se puede utilizar un entorno diferente.El proceso previsto para realizar la validación del host del conector debería ser el siguiente: 1. Actualiza tu OPCH de desarrollo. 2. Actualiza el host de validación del conector (en este caso, el entorno de preproducción apunta a «dev»). 1. Prueba tu conector en la página de conectores o en el modo de desarrollo de tu aplicación. 3. Cuando se hayan completado las pruebas de validación, actualiza el host del conector de producción.

Consulte Entornos de conectores para obtener más información.

Como alternativa, puede actualizar su OPCH en su instancia de desarrollo y, a continuación, actualizar con total confianza el entorno de producción.

Registro en herramientas externas de gestión de registros

Puede reenviar los registros del host del conector local a herramientas de terceros para la supervisión y la resolución de problemas de forma centralizada. El OPCH es compatible con Datadog, Grafana Loki y Splunk a través de variables de entorno. Los tipos de registros disponibles están relacionados con el estado de tu OPCH (especialmente en lo que respecta a su conexión con Factory), la ejecución de llamadas al conector y los registros de suscripción. Como parte del flujo de inicio del OPCH, los usuarios pueden configurar la herramienta de registro externa a la que desean que se envíen los registros. Si se añaden credenciales para varios servicios, los registros se envían a todos ellos

1. Elige tu destino
2. Datadog: punto final global; solo se requiere una clave API.
3. Grafana Loki: Loki alojado por el cliente; la URL puede incluir autenticación básica.
4. Splunk (HEC): multiinstancia; requiere tanto la URL como el token.
5. Añadir variables de entorno: añade las variables siguientes al entorno del host del conector. Utiliza únicamente las correspondientes al destino elegido.

Datadog

• TULIP_LOGGING_DATADOG_API_KEY=<tu_clave_API_de_Datadog>

Grafana Loki

• TULIP_LOGGING_LOKI_URL=https://<usuario>:<contraseña>@loki.tu-dominio.com/loki/api/v1/push
  (Se admite la autenticación básica incluyendo «usuario:contraseña» en la URL; opcional).

Splunk (HEC)

• TULIP_LOGGING_SPLUNK_URL=https://splunk.your-domain.com:8088/services/collector
• TULIP_LOGGING_SPLUNK_TOKEN=<tu_token_splunk_hec>

1. Reinicia el host del conector

Reinicia el servicio para que las nuevas variables de entorno surtan efecto.

1. Comprueba la entrega

Genera actividad (por ejemplo, ejecuta una función del conector) y comprueba que los registros aparecen en tu destino:

• Datadog: comprueba los registros recientes en busca del nombre de tu host o servicio.
• Loki: Realiza una consulta por etiqueta de host o por una subcadena de mensaje conocida en Grafana Explore.
• Splunk: busca eventos recientes de tu host (por ejemplo, index=<tu_índice> source="tulip-connector-host").
• Cambiar o desactivar el registro
• Para cambiar de destino, actualiza las variables con el nuevo proveedor (y elimina las antiguas).
• Para desactivarlo, elimina las variables de registro y reinicia el servicio.

Información adicional

Implementación basada en los exportadores de Grafana Alloy:

Exportador de Datadog:https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.datadog/

Exportador Splunk HEC: https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.splunkhec/

Carga de llamadas entrantes y salientes

En esta sección se explica cuántas solicitudes HTTP envía el OPCH a Tulip Cloud. Estas solicitudes pueden agruparse en solicitudes de frecuencia fija (siempre en ejecución) y solicitudes de frecuencia variable (dependientes de tu configuración y actividad).

Solicitudes de frecuencia fija

Estas solicitudes se producen a un ritmo constante y predecible:

Solicitudes a intervalos variables

Estas solicitudes dependen de su configuración y de la actividad.
Cuantos más cambios o eventos se produzcan, mayor será la frecuencia de las solicitudes.

Ejemplo de cálculo

Consideremos una configuración con: - 1 fuente de datos de máquina - 500 atributos de máquina, cada uno de los cuales envía datos a 1 Hz (una vez por segundo)

Tasa de solicitudes en el peor de los casos:`Tasa (peor caso) = (6 + 1 + 20) + 40 + 60 + 240 = 367 solicitudes por minuto

Referencias adicionales

Habilitar la rotación de registros para Docker

Para los servidores « Connector Hosts » locales existentes que no utilicen la rotación de registros de Docker, sigue las instrucciones que se indican aquí para garantizar que el espacio en disco se gestione correctamente.

Comprueba el estado de tu OPCH

Para integrar el OPCH con su orquestador de servicios basado en Azure o Kubernetes, puede utilizar la siguiente configuración:

Para OPCH LTS16+:

Para integrar el OPCH con su orquestador de servicios basado en Azure o Kubernetes, puede utilizar la siguiente configuración: El punto final de comprobación de estado se asigna aleatoriamente a un puerto y se expone en la ruta raíz /health-check. Opcionalmente, el puerto asignado se puede anular estableciendo TULIP_HEALTH_HTTP_PORT en el puerto especificado. Por ejemplo: TULIP_HEALTH_HTTP_PORT = 80. Una respuesta correcta devolverá un código de estado HTTP 204, lo que indica que el servicio OPCH está en buen estado y operativo.

Para OPCH anterior a LTS16:

Para integrar el OPCH con su orquestador de servicios basado en Azure o Kubernetes, puede utilizar la siguiente configuración: El punto final de comprobación de estado debe habilitarse estableciendo la variable de entorno CONNECTORS_HEALTHZ_SERVER_ENABLED en «true».El punto final está disponible en el puerto 9223 y se expone en la ruta raíz /. Opcionalmente, el puerto predeterminado 9223 se puede anular estableciendo CONNECTORS_PORT en el puerto especificado. Por ejemplo: CONNECTORS_PORT = 80

Una respuesta correcta devolverá un código de estado HTTP 200 (OK), lo que indica que el servicio OPCH está en buen estado y operativo.
Opcionalmente, el puerto predeterminado 9223 se puede anular configurando CONNECTORS_PORT con el puerto especificado. Por ejemplo: CONNECTORS_PORT = 80

Una respuesta correcta devolverá un código de estado HTTP 200 (OK), lo que indica que el servicio OPCH funciona correctamente y está operativo.

{{snippet.¿Has encontrado lo que buscabas?}}