ai-center
2020.10
false
UiPath logo, featuring letters U and I in white
AI Center
Automation CloudAutomation SuiteStandalone
Last updated 2024年6月6日

5. 运行 AI Fabric 应用程序安装程序

运行应用程序安装程序。 这将安装 AI Fabric 和开箱即用模型,以防离线安装。

访问管理控制台

导航到管理控制台,其地址始终为 <machine-ip>:8800。应用程序安装程序将在此处进行配置。导航到该地址时,将显示以下页面。


单击“继续设置”。系统将显示以下窗口。



配置 DNS(可选)

如果 Linux 计算机已配置 DNS,并且您希望在通过完全限定域名访问 AI Fabric 应用程序时使用自己的证书,则可在此配置屏幕中执行此操作。

输入主机名并上传私钥和 SSL 证书。确保可您要通过端口 8800、31443 和 31390 访问 AI Fabric 的网络中访问该域。对于域证书,请确保证书捆绑文件包含此特定顺序的所有链元素:根证书、中间证书和服务器证书。此外,如果公钥证书不是以至少 2048 位大小的公共 RSA 密钥颁发的,则验证将失败。

证书的格式为 .pem 文件,私钥为 .key 文件。可以从 .pfx 证书中获取文件。

登录到管理控制台

在上述步骤中配置 DNS(或单击“跳过并继续”以跳过该步骤)后,将显示以下页面:



输入“步骤 4:运行 AI Fabric 基础架构安装程序”中的密码。成功登录后,系统会提示您上传许可证文件:



上传具有您的 AI Fabric 许可证的 yaml 文件(如果您没有 AI Fabric 许可证,请联系 AI Fabric 代表)。

选择安装类型

实体隔离安装

如果您采用实体隔离安装,则必须在此步骤中上传安装包。

单击“选择要上传的包”按钮,然后选择上一步中提取的“aif_services”文件。



在线安装

如果您正在关注在线安装,请单击页面底部指出 download AI Fabric from the internet 的链接

配置安装程序

下一步是使用以下屏幕配置安装程序:



需要填写此页面中的字段。请参考以下说明

入口

“主机(IP 或 FQDN)”:Linux 计算机的 IP。如果您已为此计算机配置 DNS 并完成上述“配置 DNS”步骤,则输入此计算机的完全限定域名。

单数据库与多数据库

只需根据您在步骤 2 中执行的操作选择正确的选项即可。

SQL

  • “主机”:输入在步骤 2.“配置 SQL”中创建的 SQL 数据库的 IP 地址。
  • “用户名”:输入 SQL 数据库所有者的用户名。
  • “密码”:输入 SQL 数据库的密码。
    注意:如果您使用的是 Azure 数据库,请确保使用 FQDN 连接到数据库。它可以是公共域名,也可以是私有域名(只要已配置 DNS),但如果您使用的是私有 IP,则无法正常工作,请参阅此处:https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns

Orchestrator

“端点”:输入 Orchestrator 地址和端口 443。不要包含 http 或 https。Orchestrator 端点必须是域名 <domain-name>:443
重要事项:确保在域名后添加端口 443。不包括端口是安装过程中常见的用户错误原因。

请参阅下面的示例,了解应避免的陷阱。

输入的 Orchestrator 端点正确
aicenter.orchestrator.cloudapp.azure.com:443
https://aicenter.orchestrator.cloudapp.azure.com
https://23.96.154:443
23.96.154:443

身份服务器

只有在 UiPath Identity Server 与 Orchestrator 端点不同时,才需要执行此操作。

Identity Server 访问令牌

这是来自 Orchestrator 的身份令牌。要生成此令牌,请在浏览器中导航到 <orchestrator-address>/identity。确保已登录到主机租户(与“默认”租户相反)。系统将显示以下页面:


如果您看到的页面没有上述的左侧导航栏,则可能是您已登录默认租户。确保以主机租户身份登录。

现在,单击“安装访问令牌”,再单击“生成令牌”,然后使用两张卡图标将此令牌复制到剪贴板。



将此令牌粘贴到“身份访问令牌”字段中。

重要事项:此令牌在一小时后过期。生成令牌后,应立即部署配置,以减少出现问题的风险。如果必须编辑配置并重新部署,请务必生成新令牌。

预检

单击配置页面中的“继续”。系统会将您定向到标题为“预检”的页面。如果所有预检均通过,您将看到如下所示的页面:



唯一可以谨慎忽略的预检为Total Memory。保守来说,计算机应至少具有 52GB RAM,以了解配置更少的内存会如何限制 AI Fabric 的功能,请参阅硬件要求页面。

对预检进行故障排除

如果在预检时没有看到绿色复选标记,请按照本指南修复错误。

预检 
Orchestrator 检查验证:
  • 我们可以在路径 /api/auth 上连接到 Orchestrator 域
  • 验证 Web.config 是否已正确设置。
解决方案:确保网络规则设置为允许 Linux 计算机连接到 Orchestrator。验证在“3. 配置 Orchestrator”中正确设置了 Web.config。
Identity Server 检查验证是否可以连接到路径 /identity 上的身份服务器。

解决方案:确保网络规则设置为允许 Linux 计算机连接到 Identity Server(如果与 Orchestrator 不同)。

Identity Server 访问令牌验证验证访问令牌是否有效。

解决方案:如果通过 Identity Server 检查,请确保您有一个新令牌,因为令牌的有效期为 1 小时。

Orchestrator 和 Identity Server 检查失败,并且您没有外部 DNS

如果您没有可用于解析 Orchestrator 域名或 Identity Server 域名的外部 DNS,则需要额外应用配置文件。请参阅“高级故障排除 -DNS 解析”

数据库检查验证:
  • SQL Server 连接和凭据有效。
  • 检查数据库是否存在
  • 检查是否为每个数据库的用户分配了 db_owner 角色。
解决方案:确保 SQL Server 允许在其端口上建立传入连接,并且已启用 SQL Server 身份验证。数据库创建和正确的角色创建由 2. 配置数据库中的脚本自动处理。
Disk Space下的所有检查均失败。 如果您已验证 Orchestrator 和 SQL Server 的网络规则/防火墙规则,但仍看到与连接相关的所有检查均失败,则可能是由于一个更细微的网络配置问题,称为“IP 伪装”。这通常是由于 Linux 计算机和 Orchestrator/SQL Server 位于不同子网引起的。如果发生这种情况,请运行以下命令:

sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

在 Linux 计算机上,重试预检。

如果您无法解决预检失败,请联系支持团队并将支持包发送给他们。有关如何创建支持包的说明,请参阅“高级故障排除 -支持包”

验证应用程序安装程序

如果所有预检均通过,请单击“Continue”:您将看到以下页面:


此页面表示 AI Fabric 应用程序安装程序已启动。如果所有配置的设置都正确,则执行此操作应能在 20 到 30 分钟内完成。请参阅下文,输出将显示安装是否成功的日志。

对应用程序安装程序进行故障排除

提示:

总体而言,自己对应用程序安装进行故障排除(注意,您也可以将支持包发送给 UiPath 技术支持,如下所示)涉及以下步骤:

  • 查看配置日志以确定所发生的情况。运行 kubectl logs -f provision-* 以查看最新的配置日志。
  • 从日志中得知错误后,修复/编辑配置。
  • 重新触发配置,方法是保存配置,单击“Go to new new version”,然后单击“Deploy

运行日志

要查看运行日志,您可以使用 kubernetes 命令行接口,因为应用程序安装程序在 kubernetes 之上运行。

要运行任何 kubernetes 命令,请通过运行 bash -l 来重新加载 bash shell(每个终端会话一次)。

每次更改和部署配置时(对于第一次配置,系统会自动完成部署,对于后续配置,您必须保存配置并单击“部署”),系统将执行新作业以安装应用程序。

要查看 Linux 计算机上的运行日志,请运行以下命令:

bash -l
kubectl get podsbash -l
kubectl get pods

您将看到如下所示的内容:

aif-admin@aifabric-onprem-int0:~$ kubectl get pods
NAME                                  READY   STATUS             RESTARTS   AGE
...
...
provision-rmvfg                       0/1     Running            0          1maif-admin@aifabric-onprem-int0:~$ kubectl get pods
NAME                                  READY   STATUS             RESTARTS   AGE
...
...
provision-rmvfg                       0/1     Running            0          1m

输出显示名称,其格式类似于 provision-<identifier>。要查看正在运行的应用程序安装程序,请执行以下操作:

kubectl logs -f provision-rmvfgkubectl logs -f provision-rmvfg
将其中的“rmvgf”替换为终端中显示的任何标识符(或者只需键入 kubectl logs -f provision,然后按 Tab 键,这将自动填写标识符)。

这将显示运行日志(如果进程尚未结束),以及有关进程时已成功还是终止的日志。大多数(如果不是全部)用户都可以使用上述命令进行故障排除,而不必使用任何其他方法。

成功安装

安装成功后,在通过预检后的 15 到 20 分钟内,将显示以下屏幕截图:



如果您看到此屏幕,则可以继续执行步骤6. 验证安装

已知问题

要等到通过预检后才能触发安装,所以在 AI Fabric 安装程序中只会发生一个已知问题。如果是这种情况,您将从日志中看到以下输出:

...
Starting ai-helper deployment ...Release "ai-helper" does not exist. 
Installing it now.
Error: etcdserver: request timed outHelm installation failed for ai-helper in namespace aifabric. 
Exiting !!!onebox provisioning failed. 
Exiting !!!...
Starting ai-helper deployment ...Release "ai-helper" does not exist. 
Installing it now.
Error: etcdserver: request timed outHelm installation failed for ai-helper in namespace aifabric. 
Exiting !!!onebox provisioning failed. 
Exiting !!!
这是一个间歇性的 etcdserver 问题。通过转到管理控制台(地址为 <ip>:8800),单击“Config”,粘贴新的 Identity Server 令牌,单击“Continue to new version”,最后单击“Deploy”,重试安装。
最多在尝试安装 5 次后,此问题应能自动解决。如果您遇到同一问题(Error: etcdserver: request timed out),但重试仍无法解决问题,请联系支持团队并创建支持包。

安装 OOB 模型(仅限实体隔离模式)

对于实体隔离安装,您需要手动下载 OOB 模型,然后在 AI Fabric 计算机上安装这些模型才能使用。对于要添加的每个模型,您需要将一个 tar 文件移动到 AI Fabric 计算机。在 AI Fabric 计算机上,只需对每个文件运行以下命令即可:

tar -zxvf formextractor-1.tar.gz
cd formextractor
nohup sudo ./setup.sh > formextractor.out 2>&1tar -zxvf formextractor-1.tar.gz
cd formextractor
nohup sudo ./setup.sh > formextractor.out 2>&1

可以在 formextract.out 文件中访问日志。我们建议对此命令使用 nohup,因为安装可能需要长达一个小时的时间,这样可以避免由于与计算机的连接断开而出现的任何问题。

高级故障排除

创建支持包

要创建支持包,请导航到管理用户界面 (<machine-ip>:8800),然后单击顶部导航栏上的“故障排除”。单击按钮以生成新的支持包,然后下载该捆绑包。联系支持团队时,请在票证中包含该文件 (support-bundle.tar.gz)。


DNS 解析

如上所述,此问题会在预检前显现。请注意,如果没有可用于解析 Orchestrator 域或 Identity Server 域的外部 DNS,便会出现此问题。

要解决此问题(请注意,如果您是经验丰富的 Linux 用户,则仅将条目添加到 /etc/hosts 中并无法解决问题),我们需要编辑集群的配置映射,以便集群知道此 DNS。为此,您需要运行以下命令:
kubectl -n kube-system edit cm corednskubectl -n kube-system edit cm coredns

它将打开一个 vi 编辑器,文件如下所示:

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
        }
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2020-11-30T12:25:28Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "17667708"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 2bde7049-eda6-46eb-b523-beb8c421085fapiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
        }
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2020-11-30T12:25:28Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "17667708"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 2bde7049-eda6-46eb-b523-beb8c421085f

需要在“Corefile”一节中的“loadbalance”后面(第 19 行)添加新节“hosts”,可以在该节中列出任意数量的 dns,并在结尾添加“fallthrough”

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
        hosts example.hosts orchestrator-dns.com {
          1.2.3.4 example.hosts
          5.6.7.8 orchestrator-dns.com
          fallthrough
        }
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2020-11-30T12:25:28Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "17667708"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 2bde7049-eda6-46eb-b523-beb8c421085fapiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
        hosts example.hosts orchestrator-dns.com {
          1.2.3.4 example.hosts
          5.6.7.8 orchestrator-dns.com
          fallthrough
        }
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2020-11-30T12:25:28Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "17667708"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 2bde7049-eda6-46eb-b523-beb8c421085f

随后,DNS 便已配置完毕并在您的集群中正常工作。

注意:编辑后,请确保 coredns 是正确的 yaml 文件,并且不要使用制表符进行缩进,而只能使用空格。

此页面有帮助吗?

获取您需要的帮助
了解 RPA - 自动化课程
UiPath Community 论坛
Uipath Logo White
信任与安全
© 2005-2024 UiPath。保留所有权利。