- 发行说明
- 要求
- 安装
- 入门指南
- 项目
- 数据集
- ML 包
- 管道
- ML 技能
- ML 日志
- AI Fabric 中的 Document Understanding
- 基本故障排除指南
5. 运行 AI Fabric 应用程序安装程序
运行应用程序安装程序。 这将安装 AI Fabric 和开箱即用模型,以防离线安装。
如果 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 代表)。
下一步是使用以下屏幕配置安装程序:
需要填写此页面中的字段。请参考以下说明
- “主机”:输入在步骤 2.“配置 SQL”中创建的 SQL 数据库的 IP 地址。
- “用户名”:输入 SQL 数据库所有者的用户名。
- “密码”:输入 SQL 数据库的密码。
注意:如果您使用的是 Azure 数据库,请确保使用 FQDN 连接到数据库。它可以是公共域名,也可以是私有域名(只要已配置 DNS),但如果您使用的是私有 IP,则无法正常工作,请参阅此处:https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns
<domain-name>:443
。
请参阅下面的示例,了解应避免的陷阱。
输入的 Orchestrator 端点 | 正确 |
---|---|
aicenter.orchestrator.cloudapp.azure.com:443 | ✓ |
https://aicenter.orchestrator.cloudapp.azure.com | ✗ |
https://23.96.154:443 | ✗ |
23.96.154:443 | ✗ |
<orchestrator-address>/identity
。确保已登录到主机租户(与“默认”租户相反)。系统将显示以下页面:
如果您看到的页面没有上述的左侧导航栏,则可能是您已登录默认租户。确保以主机租户身份登录。
现在,单击“安装访问令牌”,再单击“生成令牌”,然后使用两张卡图标将此令牌复制到剪贴板。
将此令牌粘贴到“身份访问令牌”字段中。
单击配置页面中的“继续”。系统会将您定向到标题为“预检”的页面。如果所有预检均通过,您将看到如下所示的页面:
如果在预检时没有看到绿色复选标记,请按照本指南修复错误。
预检 | |
---|---|
Orchestrator 检查 | 验证:
|
Identity Server 检查 | 验证是否可以连接到路径 /identity 上的身份服务器。
解决方案:确保网络规则设置为允许 Linux 计算机连接到 Identity Server(如果与 Orchestrator 不同)。 |
Identity Server 访问令牌验证 | 验证访问令牌是否有效。
解决方案:如果通过 Identity Server 检查,请确保您有一个新令牌,因为令牌的有效期为 1 小时。 |
Orchestrator 和 Identity Server 检查失败,并且您没有外部 DNS |
如果您没有可用于解析 Orchestrator 域名或 Identity Server 域名的外部 DNS,则需要额外应用配置文件。请参阅“高级故障排除 -DNS 解析” |
数据库检查 | 验证:
|
Disk Space 下的所有检查均失败。
| 如果您已验证 Orchestrator 和 SQL Server 的网络规则/防火墙规则,但仍看到与连接相关的所有检查均失败,则可能是由于一个更细微的网络配置问题,称为“IP 伪装”。这通常是由于 Linux 计算机和 Orchestrator/SQL Server 位于不同子网引起的。如果发生这种情况,请运行以下命令:
在 Linux 计算机上,重试预检。 |
如果您无法解决预检失败,请联系支持团队并将支持包发送给他们。有关如何创建支持包的说明,请参阅“高级故障排除 -支持包”。
Continue
”:您将看到以下页面:
此页面表示 AI Fabric 应用程序安装程序已启动。如果所有配置的设置都正确,则执行此操作应能在 20 到 30 分钟内完成。请参阅下文,输出将显示安装是否成功的日志。
总体而言,自己对应用程序安装进行故障排除(注意,您也可以将支持包发送给 UiPath 技术支持,如下所示)涉及以下步骤:
- 查看配置日志以确定所发生的情况。运行
kubectl logs -f provision-*
以查看最新的配置日志。 - 从日志中得知错误后,修复/编辑配置。
- 重新触发配置,方法是保存配置,单击“
Go to new new version
”,然后单击“Deploy
”
要查看运行日志,您可以使用 kubernetes 命令行接口,因为应用程序安装程序在 kubernetes 之上运行。
bash -l
来重新加载 bash shell(每个终端会话一次)。
每次更改和部署配置时(对于第一次配置,系统会自动完成部署,对于后续配置,您必须保存配置并单击“部署”),系统将执行新作业以安装应用程序。
要查看 Linux 计算机上的运行日志,请运行以下命令:
bash -l
kubectl get pods
bash -l
kubectl get pods
您将看到如下所示的内容:
aif-admin@aifabric-onprem-int0:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
...
...
provision-rmvfg 0/1 Running 0 1m
aif-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-rmvfg
kubectl logs -f provision-rmvfg
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 !!!
<ip>:8800
),单击“Config
”,粘贴新的 Identity Server 令牌,单击“Continue to new version
”,最后单击“Deploy
”,重试安装。
Error: etcdserver: request timed out
),但重试仍无法解决问题,请联系支持团队并创建支持包。
对于实体隔离安装,您需要手动下载 OOB 模型,然后在 AI Fabric 计算机上安装这些模型才能使用。对于要添加的每个模型,您需要将一个 tar 文件移动到 AI Fabric 计算机。在 AI Fabric 计算机上,只需对每个文件运行以下命令即可:
tar -zxvf formextractor-1.tar.gz
cd formextractor
nohup sudo ./setup.sh > formextractor.out 2>&1
tar -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
)。
如上所述,此问题会在预检前显现。请注意,如果没有可用于解析 Orchestrator 域或 Identity Server 域的外部 DNS,便会出现此问题。
/etc/hosts
中并无法解决问题),我们需要编辑集群的配置映射,以便集群知道此 DNS。为此,您需要运行以下命令:
kubectl -n kube-system edit cm coredns
kubectl -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-beb8c421085f
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-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-beb8c421085f
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-beb8c421085f
随后,DNS 便已配置完毕并在您的集群中正常工作。