Visión general de los hosts de conectores locales

Prev Next

:::(Warning) (LTS12+ OPCH Networking Changes) Con LTS12, la forma en que OPCH se comunica con Tulip Cloud fue cambiada. Estos cambios fueron necesarios para asegurar que OPCH pudiera soportar despliegues masivos de conectores y máquinas.

Con este cambio, el OPCH pasó de mantener una conexión websocket continua con la nube, a no tener estado. Esto conllevará un aumento de las llamadas RESTful entre OPCH y Tulip Cloud. Durante las actualizaciones de OPCH, los clientes son responsables de garantizar que los proxies y cortafuegos puedan soportar esta carga adicional.
:::

Propósito

Aprenda a aprovechar los hosts de conectores locales para sus integraciones.

Requisitos previos

Para aprender sobre Connector Hosts en Tulip, primero revisa este artículo

Visión general

Este artículo pretende servir como punto de referencia para los On-Premise Connector Hosts (OPCH) en Tulip. El Connector Host es un servicio utilizado para facilitar las conexiones de Tulip a servicios web externos, bases de datos y servidores OPC UA. Todas las instancias de Tulip tienen un Cloud Connector Host por defecto.

Hay varias consideraciones a tener en cuenta a la hora de determinar si un Connector Host On-Premise es la arquitectura correcta.

Consideraciones clave para un host de conector local

Las consideraciones para un On-Premise Connector Host se pueden dividir en varias categorías:

1. 2. Gestión de la infraestructura Gestión de la infraestructura3. Rendimiento

Redes

La razón más común para desplegar un On-Premise Connector Host es por las ventajas que ofrece cuando se conecta a sistemas alojados dentro de una red local. Con la oferta on-premise, todas las conexiones de Tulip a sistemas externos comienzan dentro de su red local. Todas las conexiones desde su red son salientes a Tulip a través de un WebSocket seguro.

Esto contrasta con los Cloud Connector Hosts, que requieren acceso entrante a los servicios. Esto es típicamente una decisión de TI para permitir conexiones WebSocket seguras entrantes desde la nube de Tulip al servicio, a menudo utilizando reglas de reenvío de puertos en el router/firewall WAN.

Gestión de Infraestructura

Para desplegar un On-Premise Connector Host, hay varios componentes de infraestructura de los que el cliente es responsable. A continuación se muestra una matriz básica de funciones y responsabilidades:

Tulipán Cliente
Proporcionar recursos técnicos en OPCH X
Alojamiento y despliegue de máquinas virtuales X
Supervisión y actualizaciones de la máquina virtual X
Generación de credenciales OPCH X
Prueba de OPCH X
Despliegue de OPCH X
Actualización de OPCH X
Supervisión de OPCH X
Resolución de problemas OPCH X X

Lo ideal es que el cliente se sienta cómodo con las tecnologías que utiliza para desplegar el Connector Host, así como con el uso de tecnologías como Docker para la gestión de contenedores.

Despliegue de un host conector local

Estándares técnicos

OPCH Performance

The amount of resources needed to run OPCH will increase as its usage increases. If you consistently use it beyond 250Hz of throughput, we strongly advise allocating more resources to your virtual machines to ensure optimal performance.

Cuando se toma la decisión de desplegar una solución on-premise, Tulip recomienda una ruta de autoservicio utilizando una imagen Docker distribuida. La forma más fácil de lograr esto sería utilizar una máquina virtual con una distribución de Linux (Ubuntu es preferible).

Tulip también recomienda alojar solo un On-Premise Connector Host por máquina virtual para evitar un único punto de fallo para los sitios.

Requisitos de la máquina virtual:

  • RAM - 4 GB
  • ROM - 8-16 GB de disco
  • CPU - 2 núcleos
  • Versión de Docker - 20.10+

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

  • Una dirección IP
  • Resolución DNS a
  • Acceso saliente en el puerto 443 a Tulip (IPs listadas aquí)
  • Acceso saliente al repositorio Docker aquí
  • Acceso saliente a todos los sistemas externos relevantes con puertos

Revisa la lista completa de requisitos de red aquí

Solicitud de credenciales

Ponte en contacto con Tulip Support(support@tulip.co) para solicitar las credenciales de On-Premise Connector Host utilizando la siguiente plantilla, rellenando los datos entre paréntesis.:



Esta es una solicitud para crear un nuevo On-Premise Connector Host. 


Instancia de Tulip:   



Tulip creará y compartirá las credenciales a través de un enlace seguro de contraseña temporal. Los detalles deben transferirse a un almacenamiento de credenciales gestionado internamente e incluir lo siguiente:


* Fábrica
* UUID
* Secreto de máquina


:::(Info) (Reusing Credentials)
On-Premise Connector Host credentials should not be used to create more than one Connector Host - this would result in connectivity problems for all hosts sharing credentials.
:::  



### Versiones disponibles del Connector Host local (etiquetas)


:::(Info) (Version Compatibility)
OPCH must be kept up-to-date with the Tulip product. More [information](/r230/docs/on-prem-connector-host-version-support).
:::  



Tulip utiliza etiquetas de imagen Docker para versionar las imágenes de Connector Host. A continuación se muestra una lista de etiquetas de host de conector local soportadas activamente que se pueden utilizar junto con los comandos de `ejecución` y `extracción` de Docker. 




| Versión LTS | Versión quincenal | Etiqueta OPCH más reciente |
| --- | --- | --- |
| LTS11 | r262 - r274 | lts11.7 |
| LTS12 | r275-r287 | lts12.10 |
| LTS13 | r288-r307 | lts13.4 |
| LTS14 | r308+ | lts14 |


### Despliegue


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


* AWS:


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


:::(Warning) (Pre-LTS12 OPCH)
Prior to LTS12, the environment variables CONNECTORS\_HTTPS\_PROXY and CONNECTORS\_HTTP\_PROXY must be replaced with HTTPS\_PROXY and HTTP\_PROXY, respectively
:::  



* Azure:

`az container create \ -g <NOMBRE DEL GRUPO DE RECURSOS EN AZURE> \ --\name <NOMBRE DEL CONTENEDOR> \ --cpu 2 \ --memory 3 \ --restart-policy Always \ --image bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:<TAG> \ -e TULIP_UUID='<UUID>' \ TULIP_FACTORY='https://<YOUR SITE>.tulip.co' \ TULIP_MACHINE_SECRET='<SECRET>' \ TULIP_DEVICE_TYPE='onprem' \ CONNECTORS_HTTP_PROXY='' \ CONNECTORS_HTTPS_PROXY=''`
* VM Linux: :::(Warning) (Pre-LTS12 OPCH)
Prior to LTS12, the environment variables CONNECTORS\_HTTPS\_PROXY and CONNECTORS\_HTTP\_PROXY must be replaced with HTTPS\_PROXY and HTTP\_PROXY, respectively
:::  


docker run -d \


## Actualización de un host de conector local


:::(Info) (Version Compatibility)
OPCH must be kept up-to-date with the Tulip product. More [information](/r230/docs/on-prem-connector-host-version-support).
:::  
:::(Info) (Recommended Upgrade Procedure for OPCH)
Tulip recommends proactively confirming the upgrade by successfully running a test OPCH connection to the development environment and/or developement instance. Once this verification is complete, the production environment can be confidently upgraded. Details on how can be found below.
:::  



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, siga las siguientes instrucciones:


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


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

`docker pull bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:<TAG>2`. Ejecute el siguiente comando para obtener el ID del contenedor Docker.

`docker ps3`. Si tienes acceso a `TULIP_FACTORY`, `TULIP_UUID`, y `TULIP_MACHINE_SECRET`, ve al paso 4. Si no, ejecute el siguiente comando y guarde la salida de este comando en una ubicación segura.

`docker exec <id-contenedor> env4`. Detenga el contenedor Docker existente.

`docker stop <id-contenedor>5`. Elimine el contenedor Docker existente.

`docker rm <id-contenedor>6`. Ejecute el comando de `ejecución` estándar de Docker aprovechando el conjunto de credenciales almacenadas.


:::(Warning) (Pre-LTS12 OPCH)
Prior to LTS12, the environment variables CONNECTORS\_HTTPS\_PROXY and CONNECTORS\_HTTP\_PROXY must be replaced with HTTPS\_PROXY and HTTP\_PROXY, respectively
:::  




docker run -d \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 \ bckca2dh98.execute-api.us-east-1.amazonaws.com/public/connector-host:


1. Confirma que el nuevo contenedor Docker está activo.

`docker ps`


### Uso de entornos de conectores para probar la actualización


Cada conector tiene tres entornos diferentes (producción, pre-producción y desarrollo) y cada uno de estos entornos puede tener su propio host de conector y pueden ser de diferentes versiones.Dependiendo del estado de la aplicación (versión de desarrollo, pendiente de aprobación, publicada) se puede utilizar un entorno diferente.El proceso esperado para hacer la validación del host de conector debería ser:1. Actualiza tu OPCH de desarrollo2. Actualice su host de conector de validación (el entorno de preproducción apunta aquí a dev) 1. Pruebe su conector en la página de conectores. Pruebe su conector en la página de conectores o en el modo de desarrollo de su aplicación3. Una vez finalizadas las pruebas de validación, actualiza el host del conector de producción


Consulte [Cómo ejecutar una función de conector en varios entornos](/r230/docs/how-to-run-a-connector-function-in-multiple-environments) para obtener más información.


Alternativamente, puedes actualizar tu OPCH en tu instancia de desarrollo, y luego actualizar con confianza el entorno de producción.


## Referencias adicionales


### Activación de Log-Rotations para Docker


Para los On-Premise Connector Hosts existentes que no utilizan las rotaciones de registro de Docker, siga las instrucciones documentadas [aquí](https://support.tulip.co/docs/enabling-log-rotations-for-existing-on-premise-connector-host-container) para garantizar que el espacio en disco se mantiene correctamente.




---

¿Has encontrado lo que buscabas?


También puedes dirigirte a [community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) para publicar tu pregunta o ver si otros se han enfrentado a una pregunta similar.