automation-suite
2.2510
true
- Información general
- Requisitos
- Preinstalación
- Preparar la instalación
- Descarga de los paquetes de instalación
- Configurar el registro compatible con OCI
- Conceder permisos de instalación
- Instalar y configurar la malla de servicio
- Instalar y configurar la herramienta GitOps
- Instalar el operador de secretos externos
- Implementar Redis a través de OperatorHub
- Aplicar configuraciones varias
- Ejecutar uipathctl
- Instalación
- Después de la instalación
- Migración y actualización
- Supervisión y alertas
- Administración de clústeres
- Configuración específica del producto
- Configurar parámetros de Orchestrator
- Configurar AppSettings
- Configurar el tamaño máximo de la solicitud
- Anular la configuración de almacenamiento a nivel de clúster
- Configurar NLog
- Guardar los registros del robot en Elasticsearch
- Configurar almacenes de credenciales
- Configurar clave de cifrado por tenant
- Limpiar la base de datos de Orchestrator
- Solución de problemas
- Cómo desinstalar Automation Suite
- Cómo resolver el fallo de comprobación de conectividad prerrequisito en OpenShift 4.16–4.18
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.

Guía de instalación de Automation Suite en OpenShift
Última actualización 5 de dic. de 2025
Al ejecutar los requisitos previos de Automation Suite (
uipathctl prereq run) en un clúster de OpenShift (versiones 4.16–4.18), la comprobación de la conectividad del clúster puede fallar en determinados nodos con el siguiente error:
time="2025-07-22T13:51:02Z" level=info msg="Wizard is running on :8080"
Error: listen failed with error: listen tcp :8080: bind: address already in use
time="2025-07-22T13:51:02Z" level=info msg="Wizard is running on :8080"
Error: listen failed with error: listen tcp :8080: bind: address already in use
El error suele producirse solo en los nodos del plano de control.
Para solucionar este problema, puedes utilizar una de las siguientes opciones:
-
Ejecuta los requisitos previos solo en los nodos trabajadores.
Para evitar programar pods de requisitos previos en nodos del plano de control, debes aplicar etiquetas de nodo solo a los nodos trabajadores de destino. Debes actualizarinput.jsonpara incluir la secciónnode_labels, como se muestra en el siguiente ejemplo:Esto garantiza que todas las comprobaciones de requisitos previos, incluida la conectividad, se ejecuten solo en los nodos de trabajo y no en los nodos del plano de control donde se produce el conflicto."node_labels": { "node-role.kubernetes.io/worker": "" }"node_labels": { "node-role.kubernetes.io/worker": "" } -
Omite la comprobación de conectividad.
Si no es posible apuntar a roles de nodo específicos (cuando los nodos están configurados con múltiples roles), debes ejecutar el comando prereq excluyendo la comprobación de conectividad:
uipathctl prereq run --excluded CONNECTIVITYuipathctl prereq run --excluded CONNECTIVITY