FAQ Automation Anywhere Enterprise Knowledge On-Premises
- Dernière mise à jour2025/06/02
FAQ Automation Anywhere Enterprise Knowledge On-Premises
Reportez-vous à cette FAQ pour des questions courantes et des réponses détaillées concernant le déploiement On-Premises de la plateforme Automation Anywhere Enterprise Knowledge, allant de la définition et de l\'architecture de On-Premises, aux exigences d\'infrastructure, aux processus de déploiement, aux considérations de sécurité, et plus encore.
Déploiement
- L\'installation On-Premises Enterprise Knowledge offrira-t-elle une assistance pour l\'installation sur AWS, GCP, Azure ou sur des machines physiques et virtuelles telles que VMWare ?
-
Oui, nous avons les spécifications nécessaires pour les environnements de production et de développement sur ces plateformes.
- Ai-je encore besoin d\'utiliser Automation 360 Cloud même si je préfère utiliser Automation Anywhere Enterprise Knowledge On-Premises ? Ou, puis-je créer mon environnement natif Automation 360 Cloud équivalent dans des locaux entièrement fermés ?
-
Il n\'existe aucun déploiement On-Premises du cloud Automation 360 avec Kubernetes, les services de pods et les services d\'API. Enterprise Knowledge peut être déployé soit en tant qu\'On-Premises soit dans le cloud en tant que SaaS. Le produit lui-même est identique et peut être utilisé en conjonction à la fois avec un environnement cloud Automation 360 et un environnement Automation 360 On-Premises.
- Qui déploie l\'environnement On-Premises ?
-
L\'installation initiale est un effort collaboratif entre les Experts Enterprise Knowledge et vous. Vous devrez fournir un accès SSH et réseau à la ou aux machines de déploiement désignées. Si un accès direct ne peut pas être accordé, vous devrez assigner des ressources techniques qui possèdent l\'accès requis. Les Experts Enterprise Knowledge peuvent ensuite guider ces ressources à distance via le partage d\'écran. Vous êtes responsable de la mise à disposition de la ou des machine(s) nécessaires. L\'installation initiale et les mises à jour ultérieures seront effectuées par le biais d\'une série de sessions impliquant le téléchargement, le déploiement et la configuration du logiciel. Le script d\'installation incorporera des connexions CI/CD pour récupérer des ressources, effectuer l\'installation, configurer le système, déployer les composantes et activer les mises à jour futures. Il est important de noter que l\'installation et les mises à jour ne sont pas quelque chose que vous gérerez directement.
- Avez-vous des estimations sur le temps nécessaire pour déployer un système fonctionnel ?
-
Le déploiement peut varier d\'environ 4 heures à 2 semaines, selon votre environnement et vos exigences spécifiques. Parfois, nous rencontrons des obstacles comme les certificats SSL, ou quelqu\'un qui n\'a pas un accès complet au réseau pour effectuer des modifications, etc. Mais, dans un scénario idéal, environ 4 heures pour finaliser et tester.
- Quel nœud accepte les certificats SSL pour les connexions entrantes ?
-
La plupart des déploiements nécessiteront SSL, mais il se peut qu\'il ne soit pas implémenté lors du déploiement initial. Le serveur peut être déployé sans SSL et configuré plus tard. Les ports de déploiement spécifiques décrits dans le schéma d\'architecture indiquent où les certificats SSL devront être appliqués.
- Des scripts sont-ils utilisés pour installer ?
-
Oui, les scripts Terraform sont actuellement utilisés pour installer toutes les composantes. Ces scripts simplifient le processus d\'installation et garantissent des résultats cohérents et reproductibles.
- Y a-t-il des exigences en matière de stockage partagé ?
-
Non, le stockage de fichiers partagé n\'est pas requis. Les conteneurs Docker et autres services utilisent le disque scratch local et la base de données PostgreSQL pour tous les besoins de stockage.
- Un disque SSD est-il requis ?
-
Oui, un disque SSD (Solid State Drive) est obligatoire. Les bases de données, en particulier les bases de données vectorielles en raison de leur taille, sont très sensibles à la latence du disque. Tout retard dans l\'accès au disque aura un impact négatif sur les performances.
- Est-ce qu\'un NAS est possible ?
- Non, le Network Attached Storage (NAS) ne convient pas. Le NAS implique un disque partagé accessible via un réseau. Même si partitionné et approvisionné via iSCSI, la latence réseau inhérente et la latence de rotation des disques durs traditionnels (accès généralement 2,5 à 5 fois plus lent que les SSD) le rendent inadapté aux exigences de performance.
- Y a-t-il des limitations concernant les fonctionnalités pour On-Premises ?
- Il n\'y a pas de limitations de fonctionnalités inhérentes dans le déploiement On-Premises. Les fonctionnalités telles que l\'exploration et l\'authentification unique (SSO) sont entièrement prises en charge. L\'accès aux ressources internes peut nécessiter la mise sur liste blanche d\'adresses IP ou de domaines spécifiques au sein de votre réseau. L\'activation de la journalisation de l\'éditeur de documents et du support sont des configurations facultatives. La fonctionnalité « Actions » peut également être activée ou désactivée de manière sélective. Il convient de noter que les environnements hautement restreints et isolés du réseau (air-gapped) sans accès à Internet peuvent rencontrer des limitations d\'utilité au-delà des fonctionnalités du réseau local.
- Il existe plusieurs éléments facultatifs. Ne pas les utiliser réduit-il le nombre de machines nécessaires ?
- Non, l\'inclusion ou l\'exclusion de fonctionnalités facultatives ne modifie pas le nombre de machines requis.
- La machine de signalisation de sentinelle est marquée facultative, que fait-elle ?
- La machine de signalisation de sentinelle, si elle est activée, fournit des informations de débogage détaillées via la journalisation, ce qui est précieux à des fins d\'assistance. Lorsqu\'elle est utilisée, elle est généralement associée à d\'autres composantes.
- L\'éditeur de document est facultatif, que fait-il et est-il colocalisé ?
- Oui, l\'éditeur de documents est une fonctionnalité facultative, et c\'est une fonction intégrée de la console. Il fournit une fonctionnalité WebSocket pour l\'édition de documents en temps réel. Le serveur WebSocket offre cette fonctionnalité et peut être utilisé pour des actions futures basées sur WebSocket. Bien que l\'éditeur puisse ne pas être fréquemment utilisé, il permet à un utilisateur ayant des droits de saisir et de modifier directement des documents dans le système en tant qu\'activité à ajouter à la base de connaissances (Knowledge Base/KB). Si la source principale de connaissances sont des données téléchargées ou explorées, l\'éditeur de documents est généralement inutile. Le conteneur Docker hébergeant l\'éditeur peut être colocalisé avec d\'autres composantes. Cependant, une meilleure pratique pour ajouter des connaissances consiste à publier le fichier du document dans un emplacement de contenu partagé standard, puis à le télécharger dans la KB à partir de ce point connu, soit par exploration web, soit par un processus automatisé.
- Les LLM sont-ils fournis ?
- Non, les grands modèles de langage (Large Language Models/LLM) ne sont pas directement fournis avec le déploiement On-Premises. Cependant, des connexions intégrées sont incluses, permettant l\'utilisation de crédits (similaire à l\'offre cloud). Dans la plupart des déploiements On-Premises, il est prévu que vous utilisiez des connexions LLM personnalisées, en tirant parti de vos propres accords Bring Your Own Key (BYOK).
- Comment le déploiement de On-Premises affecte-t-il l\'utilisation de crédits ou la consommation GenAI BYOK ?
- Vous avez la possibilité d\'utiliser les crédits intégrés pour accéder aux LLM. Cependant, pour une utilisation rentable et évolutive des LLM, et pour tirer parti de vos relations existantes avec les hyperscalers ou d\'autres fournisseurs de LLM GenAI, la plupart utiliseront probablement un modèle Bring Your Own Key (BYOK) pour héberger les LLM. Dans de tels cas, la mise sur liste blanche des connexions sortantes vers les fournisseurs de services LLM respectifs sera nécessaire au sein de votre réseau.
- Comment la mise à l\'échelle est-elle gérée au-delà du déploiement entièrement distribué de grande taille ?
- Les déploiements entièrement distribués et mis à l\'échelle s\'appliquent actuellement uniquement à l\'offre cloud, pas à On-Premises. Alors qu\'un déploiement cloud plus important impliquerait la mise à l\'échelle des serveurs de pods et l\'itération des conteneurs Docker, les considérations suivantes s\'appliquent à On-Premises :
- Dans la majorité des cas, un déploiement On-Premises pour vous est une seule machine.
- Les composantes architecturales détaillées sont principalement destinées à comprendre la structure globale, et la plupart ne sont pas directement utilisées après le déploiement initial.
- La mise à l\'échelle au-delà du niveau entièrement distribué de grande taille n\'est actuellement pas prise en charge pour les déploiements On-Premises.
- La haute disponibilité (High Availability/HA) et la reprise après sinistre (Disaster Recovery/DR) ne sont pas prises en charge par défaut pour On-Premises.
Architecture
- Quelle est l\'architecture pour On-Premises ?
- L\'architecture On-Premises est basée sur Dockers et une base de données. Elle n\'utilise pas d\'images Docker statiques pré-construites mais utilise à la place Docker et docker-compose pour l\'orchestration.
- Quelle est la base de données utilisée ?
-
La base de données utilisée est PostgreSQL, qui a été modifiée pour fonctionner comme un magasin d\'index vectoriel, connu sous le nom de Supabase. Cette base de données personnalisée sera construite selon les exigences spécifiées en utilisant le script d\'installation fourni.
- Le serveur de base de données est-il autonome ou peut-il être RDS, Azure ou autrement approvisionné dans le cloud ?
-
La base de données doit être un serveur autonome et doit être lancée en tant que machine virtuelle (Virtual Machine/VM). Elle ne peut pas être remplacée par des services de base de données cloud gérés tels que AWS RDS Aurora, Azure Database for PostgreSQL, ou des offres similaires approvisionnées par le cloud. Le serveur de base de données est une composante centrale de l\'ensemble du déploiement et nécessite une configuration pratique pour devenir un nœud Supabase pleinement fonctionnel.
- Comment faisons-nous pour que PostgreSQL devienne Supabase ? Nous n\'avons pas entendu parler de Supabase
-
Oui, la base de données doit résider sur son propre serveur dédié au sein de l\'architecture. Supabase peut être compris comme PostgreSQL avec des capacités améliorées. Par conséquent, vous ne pouvez pas convertir directement une instance PostgreSQL gérée existante ou tout autre type de base de données en Supabase. Cependant, migrer des données de l\'une à l\'autre est possible. L\'instance Supabase nécessite une gestion complète et pratique.
- Les bases de données PostgreSQL approvisionnées par hyperscaler sont-elles un bon point de départ ?
-
Non. La base de données a besoin de modifications spécifiques qui nécessitent un accès et un contrôle directs. Les services gérés comme AWS RDS offrent une utilisation plus abstraite et segmentée du déploiement PostgreSQL, et ne fournissent pas le niveau de personnalisation requis pour être transformés en Supabase. Supabase doit être déployé sur une VM, qu\'elle soit hébergée sur une plateforme hyperscaler ou sur une infrastructure locale.
- Quels sont les ports d\'accès utilisés ?
-
Les ports suivants doivent être ajoutés à la liste blanche pour vos utilisateurs et automatisations accédant au serveur Enterprise Knowledge : 80 (HTTP), 443 (HTTPS), 8000 (WebSockets HTTP/HTTPS), 8443 (WebSockets HTTP/HTTPS), et 1234 (WebSockets). Il est crucial de s\'assurer qu\'aucun pare-feu au niveau de l\'application (couche 7) ne bloque l\'accès pour les utilisateurs ou les robots au sein de votre réseau. Notez que dans les déploiements sur une seule machine, la VM Supabase et les conteneurs Docker doivent pouvoir communiquer pleinement. De même, dans les déploiements plus grands et distribués, toutes les machines doivent avoir une communication interne sans restriction.
- SSL est-il pris en charge ?
-
Oui, SSL (Secure Sockets Layer) est pris en charge. Un certificat SSL associé au nom d\'hôte ou de domaine est requis. Voici les étapes générales pour la configuration SSL dans votre environnement :
- Ajoutez un enregistrement dans votre DNS qui résout le nom de domaine complet (Fully Qualified Domain Name/FQDN) de l\'hôte à l\'adresse IP désignée.
- Vous pouvez générer un certificat SSL auto-signé temporaire en utilisant des outils comme certbot pour les tests initiaux. Cependant, pour les environnements de production, nous recommandons fortement de fournir un certificat SSL valide et une clé privée pour le nom d\'hôte FQDN.
- Placez le certificat SSL et les fichiers de clé sur cette machine dans le dossier
/nginx-proxy/ssl/. - Une fois ces étapes terminées, informez l\'équipe Experts Enterprise Knowledge afin qu\'elle puisse finaliser les configurations nécessaires sur le proxy Nginx pour pointer vers les Fichiers SSL corrects.
- Si le conteneur Docker front-end est déployé séparément de la VM Supabase, un ensemble distinct de fichiers de certificat et de clé doit être créé pour le front-end.
- Quels sont les ports utilisés dans les composantes de la solution ?
-
Tableau 1. Objet Chemin Paramètre Interne* Externe HTTP HTTPS WSS/WS Interface front-end /app FRONTEND_SUFFIX 3000 X X Nginx 80, 443 X X Back-end /api BACKEND_SUFFIX 8001 X x Automator /automator AUTOMATOR_SUFFIX 8002 x X Redis 6379 x X RabbitMQ 5672, 15672 x x Éditeur de document /ws WEBSOCKET_SUFFIX 1234 1234 x x x Passerelle API Supabase Kong /supabase SUPABASE_SUFFIX 8000, 8443 8000**, 8443** x x Supabase Postgres 6543 x x PostgreSQL (automator) 5433 x x Redis (automator) 6380 x x Ollama 11434 x x **** * Toutes les machines internes doivent pouvoir communiquer librement entre elles
** administrateur seulement
*** Nous recommandons d\'utiliser des connexions SSL (https), mais nous pouvons prendre en charge les connexions http pour les PoC.
**** S\'applique uniquement si vous déployez Ollama localement
- Quels sont les ports utilisés par les clients (humains, robots, API) ?
-
Les clients utilisent uniquement 80/443. D\'autres ports sont destinés à la communication interne, à l\'administration et au déploiement. Nginx sert de proxy pour toutes les entrées et sorties.
- Quels sont les méthodes autorisées qui doivent être activées dans mon réseau ?
- Certaines réseaux activent le filtrage APP avec la couche application de couche 7 via des pare-feu, des accélérateurs d\'applications et certains commutateurs. Il est important d\'autoriser les méthodes suivantes pour la solution au sein de votre réseau :
- GET
- POST
- PUT
- SUPPRIMER
- OPTIONS
- Si le système utilise SSO, automator, ou le crawling, de quel nœud l\'appel est-il initié ?
- SSO, comme l\'accès client, est un service front-end. Avec SSO, ce processus se poursuit avec le service d\'authentification, et si la demande d\'authentification est réussie, il se connecte ensuite via webhook, complétant l\'authentification et générant un jeton pour une utilisation ultérieure.
- Enterprise Knowledge peut-elle utiliser des proxys directs ?
-
Oui. Nginx sert de proxy à tout le trafic entrant et sortant. C\'est votre réseau, alors configurez-le pour autoriser et permettre le trafic de bout en bout pour que cela fonctionne.
- Qu\'en est-il de la gestion SSH ?
- L\'accès SSH à la boîte de déploiement (machine principale de la base de données) sera nécessaire pour que nos ressources techniques puissent réaslier l\'installation, les mises à jour et tout dépannage requis.
- Les données sont-elles chiffrées au repos et en transit ?
- Oui, SSL et TLS 1.2 sont utilisés pour les données en transit.
- Comment la SSO peut-elle être appliquée ?
- La SSO est prise en charge via des protocoles tels que Okta, Azure AD et SAML 2.0.
- Comment la haute disponibilité (HA) est-elle fournie ?
- Une considération clé pour les déploiements OnPrem est que votre équipe informatique est responsable de la gestion des pannes de réseau et d\'une haute disponibilité (HA) garantie. L\'installation d\'Enterprise Knowledge, en particulier pour les configurations dépassant un seul serveur, n\'inclut pas de tolérance aux pannes intégrée. Par conséquent, un exercice de dimensionnement est essentiel pour concevoir une architecture appropriée qui s\'adapte et répond à vos exigences en matière de HA.
- Qu\'est-ce qui doit être sauvegardé ?
- Tout est stocké dans la base de données, la configuration comme les paramètres. Une sauvegarde planifiée de la base de données gérera à la fois les opérations de sauvegarde et de restauration.
- Les images Docker sont-elles utilisées actuellement ?
- Les images Docker ne sont pas utilisées directement actuellement. Cependant, les images Docker peuvent être assemblées car les fichiers docker-compose sont disponibles.
- Qu\'est-ce qui permet les mises à l\'échelle Docker automatiques ?
- Les conteneurs Docker sont utilisés pour les déploiements, nécessitant Docker v27.1.1 ou supérieur. L\'exercice de dimensionnement avec l\'équipe Experts déterminera si la solution nécessite un dimensionnement avec mise à l\'échelle automatique pour l\'API et les workers, ainsi que toute distribution de serveurs vers un déploiement entièrement distribué.
- Les clients ont-ils besoin d\'un registre Docker ?
- Non.