UiPath Documentation
automation-suite
2.2510
true
Guía de instalación de Automation Suite en EKS/AKS
Importante :
Este contenido se ha localizado parcialmente a partir de un sistema de traducción automática. La localización de contenidos recién publicados puede tardar entre una y dos semanas en estar disponible.

Escenarios de implementación

Arquitecturas de implementación en línea, sin conexión y en varios sitios para Automation Suite en EKS/AKS.

Implementación en línea​

Una implementación en línea de Automation Suite es aquella que requiere acceso a Internet durante la instalación y el tiempo de ejecución. Todos los productos de UiPath® y las bibliotecas compatibles se alojan bien en el registro de UiPath® o bien en el almacén de terceros de confianza de UiPath.

Puedes limitar el acceso a Internet con la ayuda de un cortafuegos restringido o un servidor proxy bloqueando todo el tráfico de Internet que no sea el requerido por Automation Suite. Para obtener más información sobre las reglas de firewall o proxy, consulta Configurar el proxy.

Implementación sin conexión​

Una implementación sin conexión (aislada) es una configuración completamente aislada sin acceso a Internet. Este tipo de configuración requiere la instalación de un registro adicional para almacenar todas las imágenes de contenedor y binarios de los productos UiPath®, que se envían en forma de tarball.

Nota:

No se le permite cambiar el método de implementación después de la instalación. Esto significa que no puede cambiar a la instalación sin conexión si la instalación se realiza en línea y viceversa. Le recomendamos elegir su estrategia de implementación después de una consideración detenida.

Automation Suite en la implementación de EKS​

Arquitectura de implementación​

Puedes hacer referencia a los siguientes diagramas de arquitectura para implementar Automation Suite en EKS.

Implementación en línea​

Implementación sin conexión​

Información general​

El diagrama de arquitectura anterior muestra cómo se puede configurar Automation Suite en el clúster de AWS EKS.

Un clúster de EKS se implementa en una sola región de AWS, donde los nodos de trabajo de EC2 están en un grupo de autoescalado distribuido en tres zonas de disponibilidad. La distribución de nodos a través de las zonas de disponibilidad es lo que aporta resistencia al fallo completo de la zona.

Zonas de disponibilidad y redes​

Cada zona tiene una subred privada y una subred pública. Los nodos de trabajo EC2 se alojan en una subred privada, mientras que la subred pública aloja una dirección IP elástica y una puerta de enlace Nat. La puerta de enlace Nat es necesaria para conectarse a Internet mientras se accede al plano de control de EKS desde los nodos de trabajo y se conecta al registro de Docker para obtener las imágenes del contenedor para la implementación de Automation Suite .

Las direcciones IP elásticos alojadas en cada subred pública se pasan a Automation Suite durante la instalación para registrarla como un punto final en el que Istio debe escuchar el tráfico entrante. Por la misma razón, el equilibrador de carga de red (NLB) debe usar estos puntos finales para reenviar cualquier solicitud realizada a Automation Suite .

Orígenes de datos​

Los orígenes de datos como Amazon RDS para Microsoft SQL Server, el depósito S3, el sistema de archivos elástico y la caché elástica deben configurarse para tener suficiente redundancia en caso de error y se deben acceder desde la subred privada donde se alojan las instancias de trabajo EC2.

El clúster de Kubernetes debe tener conectividad de red y acceso al almacén de secretos para recuperar las credenciales.

Nota:
  • Automation Suite no tiene reglas de afinación para garantizar que los pods de trabajadores se distribuyan por igual en la zona. Si hay algún error a nivel de zona, puede haber una degradación momentánea del servicio, que se resolvería cuando el plano de control de EKS mueva automáticamente ese servicio a una nueva zona.
  • Insights requiere que los volúmenes de EBS almacenen el panel y los otros metadatos. En AWS, los volúmenes de EBS están vinculados a la zona en la que están presentes y no se mueven cuando la zona está inactiva. Las estadísticas no estarán disponibles hasta que se recupere la zona en la que se programaron.
  • EKS no permite el autoescalado por defecto, a diferencia de AKS. Para activar esta característica, normalmente debes instalar y configurar software adicional como Metrics Server y Cluster-Autoscaler, o soluciones alternativas que ofrezcan capacidades de autoescala similares.

Automation Suite en la implementación de AKS​

Arquitectura de implementación​

Puedes hacer referencia a los siguientes diagramas de arquitectura para implementar Automation Suite en AKS.

Implementación en línea​

Implementación sin conexión​

Información general​

Un clúster de AKS se implementa en una sola región donde los nodos de trabajo se distribuyen en los grupos de nodos de sistema y de usuario. Los componentes básicos de AKS (excepto el plano de control) se alojan en el grupo de nodos del sistema, como CNI, CoreDNS, etc. Además, los servicios básicos de UiPath® también se alojan en el mismo grupo de nodos. Los grupos de nodos de usuario adicionales pueden alojar los nodos de trabajo para Automation Suite Robots y GPU.

Grupos de nodos y redes​

Cada grupo de nodos aloja el conjunto de escalado de máquinas virtuales (VMSS), lo que garantiza que los nodos trabajadores se distribuyan en varias zonas para proporcionar resistencia a errores de zona y escalar cuando sea necesario.

La dirección IP estática asociada con el equilibrador de carga se pasa a Automation Suite durante la instalación para registrarla como un punto final en el que Istio debe escuchar cualquier tráfico entrante. Por la misma razón, Azure Carga Equilibrador (L4) debe usar estos puntos de conexión para reenviar cualquier solicitud a Automation Suite .

Fuentes de datos y acceso​

Los orígenes de datos como Microsoft SQL Server, la cuenta de almacenamiento de Azure y la caché de Azure Redis deben configurarse para tener suficiente redundancia en caso de error y se deben acceder a ellos desde la subred donde se alojan los nodos de trabajo de AKS.

El clúster de Kubernetes debe tener conectividad de red y acceso al almacén de secretos para recuperar las credenciales.

Además, puede ser necesario un servidor de salto / bastión adicional, que puede tener todos los privilegios necesarios para operar el clúster de AKS.

Nota:

Automation Suite no tiene reglas de afinación para garantizar que los pods de trabajadores se distribuyan por igual en la zona. Si hay algún error a nivel de zona, puede haber una degradación momentánea del servicio, que se resolverá cuando el plano de control de AKS mueva automáticamente ese servicio a una nueva zona.

Modos de implementación y casos de uso​

Automation Suite admite los siguientes modos de implementación:

Modo de implementaciónDescripción
MultinodoCompatible para uso en producción. Están disponibles los siguientes modos:
- Modo Lite: implementación ligera con configuración de alta disponibilidad selectiva. Para obtener más información, consulta Instalaciones en modo Lite.
- Modo HA: alta disponibilidad totalmente habilitada. Para obtener más información, consulta Instalaciones de alta disponibilidad.

Instalaciones en modo básico​

Las instalaciones en modo Lite ofrecen un proceso de configuración simple y con pocos recursos, que incluye todas las características excepto la alta disponibilidad. De forma predeterminada, la infraestructura y los componentes compartidos se implementan en modo HA, y todos los servicios están en modo ligero (el autoescalado horizontal de pods está habilitado con un mínimo de una réplica).

El modo Lite garantiza una gestión de infraestructura flexible al permitirte habilitar la alta disponibilidad para servicios seleccionados durante o después de la instalación, según sea necesario.

Importante:

Puedes utilizar el modo lite en producción, pero debes ser consciente de las implicaciones y riesgos de tener servicios sin alta disponibilidad habilitada.

Instalaciones de alta disponibilidad​

Las instalaciones multinodo son compatibles con las implementaciones de producción, lo que proporciona una mayor escalabilidad, una mayor fiabilidad y una gestión eficiente de los recursos. Admite alta disponibilidad tanto en el clúster como externa.

Implementar Automation Suite con un almacén de secretos​

Automation Suite requiere varias credenciales de infraestructura para implementar todos sus productos.

En lugar de definir las credenciales directamente en el archivo input.json , puedes configurar un almacén de secretos para gestionar y proporcionar información confidencial de forma segura. Durante la implementación, uipathctl recupera las credenciales del almacén de secretos configurado y las aplica automáticamente.

Puedes almacenar credenciales como:

  • Credenciales SQL
    • Nombre de usuario
    • Contraseña
    • Cadenas de conexión SQL
  • Credenciales de almacenamiento
    • S3/AWS
      • Clave de acceso
      • Clave secreta
      • ARN (Nombre de recurso de Amazon)
    • Azure
      • accountKey
      • ID de cliente
      • Secreto de cliente
      • IdDeSuscripción
      • ID de tenant
  • Credenciales de Redis
    • Contraseña
    • Licencia
  • Autenticación Kerberos
    • Nombre de usuario de AD
    • Keytab de usuario
    • Dominio AD
    • Duración del ticket
Nota:

No puedes almacenar rutas de certificados o credenciales relacionadas con certificados como parte del almacén de secretos.

Secreto de Kubernetes​

Puedes utilizar un secreto de Kubernetes para proporcionar todos los datos confidenciales en lugar de incluirlos en input.json.

uipathctl utiliza las credenciales almacenadas en el secreto al implementar Automation Suite y sus productos.

Azure Key Vault​

Puedes configurar todos los datos confidenciales o credenciales en un almacén de claves de Azure.

uipathctl utiliza las credenciales almacenadas en Azure Key Vault al implementar Automation Suite.

HashiCorp Vault​

Puedes configurar todos los datos confidenciales o credenciales en una instancia de HashiCorp Vault. HashiCorp Vault admite el motor de secretos KV (Clave-Valor) v1 y v2.

uipathctl se autentica en Vault utilizando tokens de cuenta de servicio de Kubernetes o credenciales de AppRole y recupera las credenciales almacenadas al implementar Automation Suite.

AWS Secrets Manager​

Puedes configurar todos los datos confidenciales o credenciales en AWS Secrets Manager. Los secretos pueden almacenarse como pares clave-valor o cadenas de texto sin formato.

uipathctl utiliza la cadena de credenciales del SDK de AWS para autenticar y recuperar las credenciales de AWS Secrets Manager al implementar Automation Suite.

¿Te ha resultado útil esta página?

Conectar

¿Necesita ayuda? Soporte

¿Quiere aprender? UiPath Academy

¿Tiene alguna pregunta? Foro de UiPath

Manténgase actualizado