- Visão geral
- Requisitos
- Instalação
- Perguntas e respostas: modelos de implantação
- Baixando pacotes de instalação
- Parâmetros do install-uipath.sh
- Como habilitar o High Availability Add-on do Redis para o cluster
- Arquivo de configuração do Document Understanding
- Adicionando um nó de agente dedicado com suporte a GPU
- Conexão do aplicativo Task Mining
- Adição de um nó de agente dedicado ao Task Mining
- Pós-instalação
- Acessando o Automation Suite
- Gerenciamento dos certificados
- Redimensionamento de PVC
- Administração de cluster
- Monitoramento e alertas
- Migração e atualização
- Modo online de avaliação de nó único
- Modo offline de avaliação de nó único
- Modo de produção online pronto para alta disponibilidade de vários nós
- Modo de produção offline pronto para alta disponibilidade de vários nós
- Migrando o disco físico do Longhorn para o LVM
- Fazendo downgrade do Ceph de 16.2.6 para 15.2.9
- Opções de migração
- B) Migração de um único tenant
- Configuração específica do produto
- Melhores práticas e manutenção
- Solução de problemas
- Como solucionar problemas dos serviços durante a instalação
- Como desinstalar o cluster
- Como limpar os artefatos offline para melhorar o espaço em disco
- How to disable TLS 1.0 and 1.1
- Como habilitar o registro em log do Istio
- Como limpar logs manualmente
- Como limpar logs antigos armazenados no bucket do sf-logs
- Como depurar instalações do Automation Suite com falha
- Como desabilitar o descarregamento de soma de verificação do TX
- Não é possível executar uma instalação offline no SO RHEL 8.4
- Erro ao baixar o pacote
- A instalação offline falha devido a um binário ausente
- Problema de certificado na instalação offline
- Erro de validação da string de conexão ao SQL
- Falha após a atualização do certificado
- O Automation Suite requer que Backlog_wait_time seja definido como 1
- Não é possível fazer login após a migração
- Configurando um intervalo de tempo limite para os portais de gerenciamento
- Atualizar as conexões de diretório subjacentes
- kinit: não é possível encontrar o KDC para o realm <AD Domain> ao obter credenciais iniciais
- kinit: o Keytab não contém chaves adequadas para *** ao obter credenciais iniciais
- A operação do GSSAPI falhou com erro: um código de status inválido foi fornecido (as credenciais do cliente foram revogadas).
- Falha do login para o usuário <ADDOMAIN><aduser> Motivo: a conta está desabilitada.
- Alarme recebido para tarefa Kerberos-tgt-update com falha
- Provedor SSPI: servidor não encontrado no banco de dados Kerberos
- Falha ao obter a imagem do sandbox
- Os pods não são exibidos na UI do ArgoCD
- Falha de teste do Redis
- O servidor RKE2 falha ao iniciar
- Segredo não encontrado no namespace da UiPath
- O ArgoCD entra em estado Em andamento após a primeira instalação
- Inconsistência inesperada; execute o fsck manualmente
- Operador de autocura ausente e repositório Sf-k8-utils ausente
- MongoDB degradado ou aplicativos de negócios após a restauração do cluster
- Serviços não íntegros após restauração ou reversão do cluster
- O Document Understanding não está no menu de navegação esquerdo do Automation Suite
- Status de Falha ao criar uma sessão de rotulagem de dados
- Status de Falha ao tentar implantar uma habilidade de ML
- Trabalho de migração falha no ArgoCD
- Reconhecimento de escrita com o Extrator de formulários inteligente não está funcionando
- Usando a ferramenta de diagnóstico do Automation Suite
- Usando o pacote de suporte do Automation Suite
- Exploração de logs

Guia de instalação do Automation Suite
O pacote de instalação fornece uma ferramenta de gerenciamento de cluster que permite atualizar certificados após a instalação. Para acessar a ferramenta, navegue até o local do pacote do instalador:
cd /opt/UiPathAutomationSuite/cd /opt/UiPathAutomationSuite/Para gerar o CSR e a chave privada, execute o seguinte comando:
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csrSua equipe de TI usa os valores obtidos para gerar um certificado assinado. A chave privada gerada permanece local.
Para visualizar mais informações sobre certificados de servidor, execute o seguinte comando:
sudo ./configureUiPathAS.sh tls-cert --helpsudo ./configureUiPathAS.sh tls-cert --helpSaída:
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************./configureUiPathAS.sh tls-cert .
Atualização do certificado do servidor
Instalação online: como encontrar o certificado do servidor
istio-ingressgateway-certs no namespace istio-system.
Consulte os arquivos de certificado na lista a seguir:
- O certificado do servidor TLS é armazenado como
tls.crt - A chave privada TLS do servidor como
tls.key - O pacote do CA é armazenado como
ca.crt
Você pode verificar os segredos usando o seguinte comando:
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yamlkubectl -n istio-system get secrets istio-ingressgateway-certs -o yamlOs certificados também são armazenados no namespace da UiPath. Isso é aplicável a todos os produtos UiPath que precisam de informações de certificado para confiar nas solicitações recebidas. Para obter detalhes, consulte Sobre a arquitetura de contêiner relacionada a certificados.
Instalação offline: como encontrar o certificado do servidor
rootCA.crt e tls.crt: ArgoCD e Docker Registry. Os certificados são armazenados nos namespaces Docker e ArgoCD.
Você pode verificar os segredos usando o seguinte comando:
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type httpsComo atualizar os certificados do servidor
Para descriptografar a chave de certificado, execute o seguinte comando:
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/keyconfigureUiPathAS.sh para atualizar o certificado conforme mostrado abaixo. Você precisa do caminho para cada um dos três arquivos de certificado. Todo o arquivo de certificado deve estar no formato PEM.
- Pacote de Autoridade de Certificação - Este pacote deve conter apenas os certificados de cadeia usados para assinar o certificado do servidor TLS. O limite da cadeia é de até nove certificados.
- Certificado do Servidor - Certificado de servidor público
-
Chave privada - Chave privada para o certificado de servidor
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskeysudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
/directory/path/to/store/certificatelocal .
Acessando o certificado TLS
Para imprimir os arquivos de certificado, execute o seguinte comando, especificando o diretório em que os certificados são armazenados.
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificatesudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificateAdding the CA certificate to the host trust store
Você é o responsável por garantir que os certificados gerados sejam confiáveis.
Para adicionar o certificado ao armazenamento de confiança da VM do host, execute os seguintes comandos em todos os nós no cluster:
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trustPara exibir mais informações sobre certificados de CA adicionais, execute o seguinte comando:
./configureUiPathAS.sh additional-ca-certs --help./configureUiPathAS.sh additional-ca-certs --helpSaída:
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
******************************************************************************************************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************./configureUiPathAS.sh additional-ca-certs .
Atualização dos certificados de CA
Este comando ajuda você a atualizar ou substituir os certificados de CA configurados existentes.
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs--replace na etapa final.
.pem válido e pode ter mais de um certificado presente nele.
Acessando os certificados de CA
Para baixar os certificados de CA já configurados, execute o seguinte comando:
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certsAdding the CA certificate to the host trust store
Você é o responsável por garantir que os certificados gerados sejam confiáveis.
Para adicionar o certificado ao armazenamento de confiança da VM do host, execute os seguintes comandos em todos os nós no cluster:
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trustPara visualizar mais informações sobre certificados de assinatura de token de identidade, execute o seguinte comando:
sudo ./configureUiPathAS.sh identity token-cert --helpsudo ./configureUiPathAS.sh identity token-cert --helpSaída:
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************./configureUiPathAS.sh identity token-cert .
Atualização do certificado
.pfx.
--password esteja entre aspas simples. Por exemplo: --password 'CertificatePassword!@#'.
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --password '<cert_pass>'sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --password '<cert_pass>'
Rotacionando o certificado
Isso irá rotacionar ou trocar o certificado antigo pelo novo carregado usando a atualização de certificado.
sudo ./configureUiPathAS.sh identity token-cert rotatesudo ./configureUiPathAS.sh identity token-cert rotateDeve haver um prazo de entrega de cerca de 24 a 48 horas entre a atualização e a rotação do certificado.
Precisamos desse prazo de entrega para continuar dando suporte à autenticação do token em cache assinado pelo certificado antigo.
Se você rotar o certificado muito antes da expiração do token de cache, poderá resultar em tempo de inatividade. E você pode ter que reiniciar todos os seus robôs.
Rotação emergencial de certificado
Para realizar uma atualização emergencial de certificado, execute as seguintes etapas:
Acessando o certificado
Execute o seguinte comando para baixar o certificado de assinatura de token atual:
sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificatesudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificatePor padrão, os certificados do RKE2 expiram em 12 meses. Nos 90 dias antes da data de expiração, os certificados são girados quando você reinicializa o RKE2.
Para obter mais detalhes, consulte RKE2 - Opções avançadas - Rotação do certificado.
Verificação da data de expiração do certificado do RKE2
if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
doneif [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
doneA saída que você obtém deve ser semelhante à mostrada na imagem a seguir:
Rotação do certificado RKE2
Por padrão, os certificados do RKE2 expiram em 12 meses. Nos 90 dias antes da data de expiração, os certificados são girados quando você reinicializa o RKE2. No entanto, se a validade dos certificados exceder o período de 90 dias, você deve rotacionar manualmente os certificados seguindo as etapas mencionadas em RKE2 - Opções avançadas - Rotação de certificados.
Se você quiser personalizar o período de expiração dos certificados do RKE2 para atender a requisitos específicos, poderá fazê-lo antes de reiniciar os serviços do RKE2 para nós de servidor e de agente.
Para girar os certificados do RKE2, você deve primeiro executar uma série de ações nos nós do servidor e, em seguida, prosseguir com algumas etapas nos nós do agente.
- Pare o servidor RKE2:
systemctl stop rke2-server.servicesystemctl stop rke2-server.service - Limpe quaisquer processos do RKE2 restantes:
rke2-killall.shrke2-killall.sh - Exclua o arquivo
dynamic-cert.jsonlocalizado em/var/lib/rancher/rke2/server/tls/. -
Para personalizar o período de expiração dos certificados do RKE2, use o seguinte comando. Esteja ciente de que esse exemplo define o período de validade para 1000 dias, mas você pode alterar esse valor com base em seus requisitos.
SERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reloadSERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - Reinicie o servidor RKE2:
systemctl start rke2-server.servicesystemctl start rke2-server.serviceObservação: se o cluster tiver mais de um nó do servidor, as etapas 1-4 podem não ser executadas totalmente, pois etcd pode não ser capaz de concluir a eleição do líder. Se isso acontecer, repita as etapas 1-4 em outros nós do servidor. - Exclua o segredo
rke2-servingdo namespacekube-system:kubectl delete secret -n kube-system rke2-servingkubectl delete secret -n kube-system rke2-servingObservação:Em uma implantação de vários nós, você pode não ser capaz de executar os comandoskubectlantes de concluir as quatro primeiras operações no número necessário de nós do servidor. Isso é para atender ao requisito do quorum etcd. Você pode remover o segredorke2-servingimediatamente após o início do servidor RKE2.
kubectl get nodes. Quando os nós do seu servidor estiverem prontos, você pode prosseguir para os nós do agente para regenerar os certificados.
Execute as seguintes etapas nos nós do agente:
- Pare o servidor RKE2:
systemctl stop rke2-agent.servicesystemctl stop rke2-agent.service - Limpe quaisquer processos do RKE2 restantes:
rke2-killall.shrke2-killall.sh -
Para personalizar o período de expiração dos certificados do RKE2, use o seguinte comando. Esteja ciente de que esse exemplo define o período de validade para 1000 dias, mas você pode alterar esse valor com base em seus requisitos.
SERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reloadSERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - Reinicie o servidor RKE2:
systemctl start rke2-agent.servicesystemctl start rke2-agent.service
- Gerando uma solicitação de assinatura de certificado (CSR) e uma chave privada
- Gerenciamento de certificados do servidor
- Atualização do certificado do servidor
- Acessando o certificado TLS
- Adding the CA certificate to the host trust store
- Gerenciamento de certificados de CA adicionais
- Atualização dos certificados de CA
- Acessando os certificados de CA
- Adding the CA certificate to the host trust store
- Gerenciando certificados de assinatura de token de identidade
- Atualização do certificado
- Rotacionando o certificado
- Rotação emergencial de certificado
- Acessando o certificado
- Gerenciamento de certificados do RKE2
- Verificação da data de expiração do certificado do RKE2
- Rotação do certificado RKE2