- Visão geral
- Requisitos
- Instalação
- Pós-instalação
- Migração e atualização
- Atualização do Automation Suite no EKS/AKS
- Etapa 1: mover os dados da organização do Identity, de independente para o Automation Suite
- Etapa 2: restauração do banco de dados de produtos independente
- Etapa 3: backup do banco de dados da plataforma no Automation Suite
- Etapa 4: mesclando organizações no Automation Suite
- Etapa 5: atualização das strings de conexão do produto migradas
- Etapa 6: migração do Orchestrator independente
- Etapa 7: migração do Insights independente
- Etapa 8: exclusão do tenant padrão
- B) Migração de um único tenant
- Migração do Automation Suite no Linux para o Automation Suite no EKS/AKS
- Monitoramento e alertas
- Administração de cluster
- Configuração específica do produto
- Configuração de parâmetros do Orchestrator
- Configurações de aplicativo do Orchestrator
- Configuração do AppSettings
- Configuração do tamanho máximo da solicitação
- Substituição da configuração de armazenamento no nível do cluster
- Configuração dos repositórios de credenciais
- Configuração da chave de criptografia por tenant
- Limpeza do banco de dados do Orchestrator
- Solução de problemas
- A configuração de backup não funciona devido a uma falha na conexão com o Azure Government
- Pods no namespace uipath travaram ao habilitar taints de nó personalizado
- Não é possível iniciar o Automation Hub e o Apps com configuração de proxy
- Os pods não podem se comunicar com o FQDN em um ambiente de proxy
- A cadeia de caracteres de conexão SQL da Automação de Teste é ignorada
Rede
Você deve provisionar e configurar os recursos de rede do Azure ou da AWS para garantir que o Automation Suite em seu cluster tenha conectividade e acesso aos pré-requisitos de infraestrutura de nuvem (por exemplo, armazenamento, banco de dados, cache e DNS). Dependendo de sua arquitetura de rede, isso pode incluir a configuração de VNETs/VPC, DNS, subredes, NSGs/grupos de segurança, gateway NAT, IP elástico e gateway de internet. Para obter detalhes, consulte Cenários de implantação.
Observe que, com base na escalabilidade da carga de trabalho, poderão ser necessárias mais réplicas. Por padrão, o modo HA requer duas réplicas e pode ir até dez ou mais réplicas. Certifique-se de que sua rede ofereça suporte a esse nível de escalabilidade.
Você pode usar qualquer CNI desde que os pods possam comunicar-se entre si. Nossas recomendações são o Azure CNI ou Calico.
Há considerações especiais para CNIs de nuvem, como Azure CNI e Amazon VPC CNI, que não são compatíveis com sub-redes de rede de pods internos ou privados. O número de pods necessários para o Automation Suite depende da sua seleção de produtos e do dimensionamento da carga de trabalho. Por exemplo, para uma implantação com todos os serviços habilitados e em alta utilização, você pode precisar de mais de 400 IPs para suportar os requisitos de escalabilidade. Por isso, recomendamos alocar um intervalo CIDR de pelo menos /23.
O Automation Suite não é compatível com o protocolo de internet IPv6.
Se você tiver um controlador de ingresso personalizado (NGINX), consulte Configuração do Ingress do NGINX e pule o resto da página.
O Automation Suite provisiona um balanceador de carga em seu nome durante a instalação. O balanceador de carga deve ser atribuído com endereços IP públicos ou privados para rotear as solicitações de FQDN. Você tem duas opções para configurar o balanceador de carga:
-
IPs pré-alocados:aloque IPspúblicos ou privados para o balanceador de carga, configure os registros DNS para mapear os FQDNs para esses IPs e forneça esses IPs como parte da seção de entrada do
input.json
. -
IPs alocados dinamicamente: se você não fornecer um endereço IP, o Automation Suite aloca dinamicamente os IPs da sub-rede do cluster para o balanceador de carga.
Os grupos de segurança de rede no balanceador de carga devem permitir o tráfego HTTPS de clientes finais via porta 443. Por padrão, configuramos o balanceador de carga para realizar verificações regulares de integridade do TCP.
Se estiver usando seu próprio ingresso como o NGINX, certifique-se de atender aos requisitos de rede documentados em Configuração do controle de ingresso do NGINX . Ao usar o Istio que implanta um NLB, observe que ele normalmente cria três ouvintes, que incluem as portas 80, 443 e 15021. No entanto, essa é uma configuração típica, e seus requisitos reais podem diferir com base em suas circunstâncias exatas, portanto, ajuste conforme necessário.
ingress
do input.json
.
Para uma lista de anotações de serviço no EKS, consulte a documentação do AWS Load Balancer.
Para obter uma lista de anotações de serviço no AKS, consulte a documentação do Azure Load Balancer.
ingress.service_annotations
em input.json
. Você deve implantar um controlador de balanceador de carga da AWS em seu cluster do EKS antes da instalação para que os exemplos funcionem corretamente.
O exemplo a seguir mostra como alocar IPs elásticos da AWS e provisionar um balanceador de carga público. Se você usar este exemplo como um ponto de partida para sua configuração, certifique-se de substituir os IPs por valores reais.
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-eip-allocations": "<elastic_ip_id_0>,<elastic_ip_id_1>",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
}
}
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-eip-allocations": "<elastic_ip_id_0>,<elastic_ip_id_1>",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
}
}
O exemplo a seguir mostra como alocar IPs privados para um balanceador de carga interno das sub-redes do cluster EKS. Se você usar esse exemplo como um ponto de partida para sua configuração, certifique-se de atualizar os IPs e sub-redes com valores reais.
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses":"<IP_0>,<IP_1>",
"service.beta.kubernetes.io/aws-load-balancer-subnets": "<SUBNET_ID_0>,<SUBNET_ID_1>",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
"service.beta.kubernetes.io/aws-load-balancer-target-group-attributes": "preserve_client_ip.enabled=false"
}
}
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses":"<IP_0>,<IP_1>",
"service.beta.kubernetes.io/aws-load-balancer-subnets": "<SUBNET_ID_0>,<SUBNET_ID_1>",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
"service.beta.kubernetes.io/aws-load-balancer-target-group-attributes": "preserve_client_ip.enabled=false"
}
}
Os IPs e sub-redes devem corresponder.
<IP_0>
está em <SUBNET_0>
e <IP_1>
em <SUBNET_1>
.
O exemplo a seguir mostra como alocar IPs públicos do Azure e provisionar um balanceador de carga público. Se você usar esse exemplo como um ponto de partida para sua configuração, certifique-se de atualizar os IPs com valores reais.
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "false",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>"
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "false",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>"
}
}
...
O exemplo a seguir mostra como alocar IPs privados a um balanceador de carga interno a partir das sub-redes do cluster do AKS. Se você usar esse exemplo como ponto de partida para sua configuração, certifique-se de atualizar os IPs e sub-redes com valores reais.
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>",
"service.beta.kubernetes.io/azure-load-balancer-internal-subnet": "<SUBNET_0>", "<SUBNET_1>"
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>",
"service.beta.kubernetes.io/azure-load-balancer-internal-subnet": "<SUBNET_0>", "<SUBNET_1>"
}
}
...
Os IPs e as sub-redes devem corresponder.
<IP_0>
está em <SUBNET_0>
e <IP_1>
em <SUBNET_1>
.
Certifique-se de que os registros de DNS estejam configurados para mapear os seguintes FQDNs da UiPath® para o balanceador de carga:
-
FQDN
-
alm.FQDN
-
Monitoramento.FQDN
-
insights.FQDN
(se estiver instalando o UiPath Insights)
O FQDN é uma das verificações de pré-requisitos antes da instalação. Se você não fornecer um endereço IP ou ainda não tiver feito o mapeamento de FQDN, a verificação será reprovada.
input.json
, o Automation Suite aloca dinamicamente os IPs privados das sub-redes do nó de trabalho. Nesse cenário, execute a instalação do Automation Suite da seguinte maneira.
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb",
"service.beta.kubernetes.io/aws-load-balancer-internal": true
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb",
"service.beta.kubernetes.io/aws-load-balancer-internal": true
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true"
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true"
}
}
...
Nesse cenário, execute o instalador da seguinte maneira:
-
Execute o instalador apenas até o provisionamento do Balanceador de carga:
uipathctl manifest apply <INPUT_JSON> --versions <VERSIONS_JSON> --override=gateway
uipathctl manifest apply <INPUT_JSON> --versions <VERSIONS_JSON> --override=gateway -
Recupere o nome do host do balanceador de carga:
kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' -
Configure seu DNS com FQDNs mapeados para o endpoint ou IPs do balanceador de carga.
-
Execute novamente o instalador para concluir a instalação:
uipathctl manifest apply input.json --versions versions.json
uipathctl manifest apply input.json --versions versions.json
Observe que, sem o mapeamento de DNS, a verificação de pré-requisitos do FQDN falhará. As verificações de pré-requisitos são feitas para dar a você a confiança de que você provisionou todos os pré-requisitos corretamente antes de instalar o Automation Suite . A verificação do FQDN não impede a instalação do Automation Suite .