Instalación de Sherpa Orchestrator en Linux#

Esta guía está dirigida al administrador de sistemas que realiza una instalación nueva de Sherpa Orchestrator en la infraestructura de la empresa. La instalación se realiza con Docker. La instalación sin Docker ya no es compatible.

La instalación de Orchestrator prepara el servidor de administración. Los Robots y el Coordinador se instalan por separado en los equipos correspondientes según las guías de implementación de la plataforma.

Preparación del servidor#

La instalación requiere un servidor Linux y una cuenta de administrador con permisos de sudo. Antes de comenzar, es necesario confirmar la compatibilidad de la distribución y el contenido del paquete suministrado. Los comandos de instalación de Docker dependen de la distribución.

Antes de obtener el paquete de distribución, es necesario preparar:

• recursos del servidor según los requisitos de la instalación con Docker: CPU con arquitectura x86-64-v2 y al menos dos núcleos, 4 GB de RAM y 20 GB de espacio libre. Se requiere capacidad adicional para imágenes, bases de datos, Almacenamiento y copias de seguridad según la carga;
• una dirección permanente del servidor y un nombre de dominio que se resuelva a esa dirección desde los equipos de los usuarios y Robots. La interfaz web requiere acceso HTTPS por el puerto 443;
• un certificado para el nombre seleccionado, su cadena de confianza y una clave privada. La obtención y ubicación de los archivos se describen en Instalación y configuración de certificados SSL;
• la opción de implementación de la base de datos. Para un servidor PostgreSQL independiente, el administrador de la base de datos prepara el acceso y los parámetros de conexión según la guía de PostgreSQL externo.

En el servidor Linux es necesario instalar e iniciar Docker Engine y el complemento Docker Compose v2 según las instrucciones de Docker para la distribución utilizada. El instalador de Sherpa requiere Bash versión 4 o posterior. Para generar certificados y la clave de cifrado se requiere openssl.

Para la comprobación preliminar se utilizan los siguientes comandos:

bash --version
sudo docker info
sudo docker compose version
openssl version
df -h
free -h

Si Docker no está disponible o falla docker compose version, primero es necesario resolver el problema de Docker. La utilidad independiente docker-compose versión 1 no sustituye a Compose v2.

Ejemplo: compruebe las versiones de Docker y Compose en el servidor preparado. El servidor de prueba Ubuntu tiene 4 GB de RAM asignada y ejecuta Docker 29.9.2 y Compose 5.6.1. El funcionamiento en este entorno no sustituye la confirmación de un sistema operativo compatible.

Preparación de los archivos suministrados#

Para la instalación es necesario obtener de soporte técnico de Sherpa el archivo de cliente docker_orchestrator_client_files_VERSION.tgz y los archivos de imágenes de la versión acordada. Las imágenes de backend, nginx, WebSocket y la base de datos seleccionada deben corresponder a los archivos de cliente. Los componentes adicionales requieren sus propias imágenes.

Es necesario extraer el archivo en un directorio independiente para la instalación nueva. La ubicación estándar es /opt/SherpaOrchestrator. En los comandos se deben sustituir /path/to y VERSION por la ruta y la versión del archivo de cliente recibido:

sudo mkdir -p /opt/SherpaOrchestrator
sudo tar -xzf /path/to/docker_orchestrator_client_files_VERSION.tgz -C /opt/SherpaOrchestrator
cd /opt/SherpaOrchestrator

La raíz del paquete extraído debe contener .env, docker-compose.yml y el directorio sh_scripts. Los archivos de imágenes de Docker también se deben colocar en ese directorio. Antes del inicio se comprueban los archivos:

sudo test -f .env
sudo test -f docker-compose.yml
sudo test -f sh_scripts/install.sh
sudo test -f sh_scripts/diagnostics.sh

Si el archivo existe, test termina sin salida y con el código 0. Si falta un archivo, es necesario comprobar el directorio de extracción y que el paquete esté completo. No se deben sustituir archivos faltantes por archivos de otra versión ni extraer una instalación nueva sobre una instalación en funcionamiento.

Ejemplo: después de extraer el paquete 5.9.5, compruebe que existen los cuatro archivos auxiliares. Para una instalación con MariaDB, compare las versiones de los archivos orchestrator, orchestrator-nginx, orchestrator-websocket y orchestrator-db. En el servidor de prueba se encuentran todos los archivos y las versiones de las imágenes coinciden.

Ejecución del instalador y configuración de conexiones#

Para iniciar la instalación guiada, es necesario ejecutar desde la raíz del paquete:

cd /opt/SherpaOrchestrator
sudo chmod +x sh_scripts/*.sh
sudo bash sh_scripts/install.sh

El instalador comprueba el entorno, permite seleccionar la base de datos y los componentes adicionales, verifica los archivos, carga las imágenes y prepara la configuración. Después configura .env, prepara HTTPS e inicia los servicios seleccionados.

La opción de base de datos se elige según el diseño de implementación:

• MariaDB en Docker — la base de datos se ejecuta en el servidor de Orchestrator con el perfil mariadb;
• PostgreSQL en Docker — la base de datos se ejecuta en el servidor de Orchestrator con el perfil pg;
• MySQL externo — se utiliza un servidor de base de datos independiente, sin contenedor local de base de datos;
• PostgreSQL externo — se utiliza un servidor PostgreSQL independiente, sin contenedor local de base de datos.

Para conectar los componentes del servidor, es necesario establecer estos parámetros:

• HOST_IP — dirección IP permanente del servidor de Orchestrator accesible desde los equipos cliente;
• NGINX_DOMAIN_NAME — nombre de dominio de la interfaz web cubierto por el certificado;
• ORCHESTRATOR_ENCRYPTION_KEY — clave de cifrado de datos. Para una instalación nueva, es necesario generarla mediante el instalador y conservarla con la configuración protegida y las copias de seguridad;
• DB_ENGINE — tipo de base de datos. El instalador establece mysql para MariaDB/MySQL o pgsql para PostgreSQL según la opción elegida;
• MYSQL_PASSWORD — contraseña de conexión a MariaDB/MySQL. El instalador también escribe el valor correspondiente de DB_PASSWORD para el contenedor de MariaDB;
• POSTGRES_PASSWORD — contraseña de conexión a PostgreSQL. Se completa solo cuando se selecciona PostgreSQL;
• MYSQL_HOST — dirección del servidor independiente para MySQL externo;
• POSTGRES_HOST — dirección del servidor independiente para PostgreSQL externo;
• POSTGRES_PORT — puerto del servidor PostgreSQL externo;
• POSTGRES_USER — nombre del rol de conexión a PostgreSQL externo;
• POSTGRES_DBNAME — nombre de la base de datos de destino en el servidor PostgreSQL externo.

Los parámetros de la base de datos seleccionada se completan con los valores proporcionados por su administrador. Para PostgreSQL externo también es necesario verificar que existan el rol y la base de datos. Los permisos necesarios y las opciones de preparación se describen en la guía de PostgreSQL externo. No se deben incluir contraseñas ni la clave de cifrado en capturas de pantalla o solicitudes de soporte.

En la instalación con Docker, la configuración de la aplicación procede de .env. Para esta opción no es necesario editar por separado backend/config/config.ini ni backend/config/phinx.php.

Los componentes adicionales se seleccionan según su finalidad: VNC-proxy para conexiones VNC a los Robots, Vault para almacenar secretos y SIEM para enviar eventos de auditoría a un sistema externo. Vault requiere configurar el almacenamiento de secretos. Los componentes de SIEM y la comprobación de entrega se describen en Uso de Docker.

Para HTTPS se requieren el certificado y la clave privada del dominio seleccionado. El instalador contempla la ubicación de orchestrator.crt y orchestrator.key en nginx/config/certs. Los equipos cliente también deben confiar en la autoridad de certificación corporativa.

Ejemplo: seleccione MariaDB en Docker y desactive los perfiles opcionales que no requiera la implementación elegida. Complete el asistente y valide la configuración de Compose. El registro de la instalación de prueba contiene los pasos 0–8 y el mensaje de finalización, la validación devuelve el código 0 y los cuatro contenedores están funcionando. Esto no sustituye la aceptación funcional.

Comprobación del inicio y primer acceso#

Al terminar el instalador, es necesario comprobar la configuración y el estado de los servicios desde el directorio de instalación:

cd /opt/SherpaOrchestrator
sudo docker compose config --quiet
sudo docker compose ps
sudo bash sh_scripts/diagnostics.sh

La configuración no debe presentar errores. Los servicios orchestrator, orchestrator-nginx y orchestrator-websocket deben estar en funcionamiento. La composición de la base de datos y los servicios adicionales depende de las opciones elegidas. Si la base de datos es externa, la ausencia de un contenedor local corresponde al diseño seleccionado.

El diagnóstico comprueba los componentes instalados e informa de los problemas detectados. Es necesario leer las correcciones propuestas antes de confirmarlas. Un diagnóstico satisfactorio no sustituye la comprobación del acceso, las Licencias y la ejecución de un Trabajo.

El diagnóstico finaliza con el código 0 cuando los componentes comprobados no presentan observaciones. El código 1 requiere investigar los resultados. Los registros pueden contener errores del primer inicio incluso después de corregir su causa. Es necesario comparar la fecha del mensaje con el estado actual del servicio. Antes de confirmar una corrección propuesta de los permisos de Storage, es necesario comprobar que cumple la política de acceso a los archivos.

Antes de cambiar los permisos de backend/Storage, es necesario identificar al usuario del backend que necesita acceso de escritura. El usuario de Nginx puede tener otro UID. El usuario configurado para ejecutar comandos en el contenedor se comprueba con:

sudo docker exec orchestrator id

En la imagen 5.9.5 comprobada, el comando devuelve uid=82(www-data) gid=82(www-data). Estos valores corresponden a esa imagen. Después de corregir los permisos, es necesario comprobar la carga y lectura de un archivo de prueba independiente mediante la aplicación. Comprobar solo el modo del directorio no sustituye esta prueba.

Para el primer acceso, es necesario abrir en el navegador la dirección HTTPS del dominio seleccionado, comprobar el certificado y utilizar las credenciales de administrador proporcionadas para la instalación nueva. Por ejemplo, con NGINX_DOMAIN_NAME=orchestrator.example.org, la dirección de la interfaz web es https://orchestrator.example.org. Es necesario sustituir el dominio de ejemplo por el nombre real del servidor.

Ejemplo: inicie sesión con la cuenta de administrador de la nueva instalación y abra Robots. El nombre del Usuario conectado aparece en la esquina superior derecha. En el servidor de prueba, esta sección está disponible después de una autenticación correcta.

Después del acceso, es necesario configurar las Licencias según Creación de una Licencia nueva en Orchestrator. La configuración de los Robots y la comprobación de un Trabajo de prueba se realizan después de preparar el servidor. Abrir la página de acceso no confirma por sí solo que toda la plataforma esté lista.

La aceptación funcional requiere una Licencia activa, un Robot de prueba conectado y un Proceso de prueba publicado. Consulte Creación de un Trabajo con un Robot y un Proceso seleccionados. La aceptación incluye un estado final correcto del Trabajo y la comprobación del resultado esperado del Proceso. Guardar un Trabajo o dejarlo en espera no confirma su ejecución.

Si un servicio termina o se reinicia continuamente, se utilizan los registros para buscar la causa:

sudo docker compose logs --tail 100 orchestrator orchestrator-nginx orchestrator-websocket

Ante errores de la base de datos, es necesario comprobar la opción de implementación y los parámetros de conexión. Ante errores de HTTPS, se comprueban el dominio, el certificado, la clave y la confianza del equipo cliente. Antes de enviar los registros a soporte, es necesario excluir contraseñas, claves y otros secretos.

Comprobación del inicio automático y configuración posterior#

Para restablecer el funcionamiento después de reiniciar el servidor, deben estar configurados el inicio automático de Docker y las políticas de reinicio de los contenedores. El estado del servicio Docker se comprueba en el servidor Linux:

sudo systemctl is-enabled docker
sudo systemctl is-active docker

Las políticas de los contenedores se deben comprobar con el docker-compose.yml suministrado y las reglas de reinicio de Docker. Después de un reinicio programado del servidor, es necesario repetir la comprobación de los servicios, HTTPS y el acceso.

Ejemplo: repita las comprobaciones después de un reinicio programado del servidor. En el servidor de prueba, Docker está activo, los cuatro contenedores funcionan y HTTPS devuelve 200. Esto confirma la recuperación de los componentes del servidor.

Para continuar preparando la plataforma se utilizan estos materiales:

• Autenticación de usuarios — configuración de los métodos de acceso después de la instalación;
• Copias de seguridad y recuperación — conservación de bases de datos, configuración, Almacenamiento y secretos;
• Proceso de instalación de Sherpa Orchestrator — operaciones manuales detalladas de la instalación con Docker.