Migração do Automation Suite no Linux para o Automation Suite no EKS/AKS

Você pode migrar do Automation Suite implantado em uma máquina Linux para o Automation Suite no EKS/AKS. Para fazer isso, você deve mover seus dados de uma versão do Automation Suite para outra usando o uipathctl.

Uma das vantagens desse processo de migração é que você pode tentar executá-lo várias vezes sem impacto em seu cluster existente.

Importante:

Essa opção de migração permite que você mude do Automation Suite no Linux para uma nova instalação do Automation no EKS/AKS.

Os seguintes cenários de migração não são compatíveis:

• A migração do Automation Suite no Linux para uma instalação existente do Automation no EKS/AKS não é compatível no momento.

• A migração de um Automation Suite no cluster EKS/AKS para outro Automation Suite no cluster EKS/AKS não é compatível no momento.

Requisitos

Para migrar do Automation Suite no Linux para o Automation Suite no EKS/AKS, você deve atender aos seguintes requisitos:

• Você deve estabelecer conectividade entre os dois ambientes.

• Você deve ter um objectstore externo configurado em seu cluster de origem. Se você usa armazenamento em cluster, consulte Migrando objectstore no cluster para objectstore externo.

• A versão do seu Automation Suite no Linux deve ser a 2022.10 ou mais recente.

• Requisitos apenas offline: você deve hidratar o cluster de destino.

Visão geral do processo

#	Etapa de migração
1.	Obrigatório. Baixe uipathctl. Para obter instruções de download, consulte uipathctl.
2.	Obrigatório. Baixe versions.json. Para obter instruções de download, consulte version.json.
3.	Prepare as imagens do Docker para o cluster de origem e de destino. Opcional. Se sua implantação estiver offline ou se você usar um registro de OCI privado, certifique-se de que as imagens necessárias estejam disponíveis.
4.	Prepare o cluster de destino: Crie o arquivo input.json . Execute a verificação de pré-requisitos.
5.	Execute a migração e mova os dados. A migração executa pods nos clusters de origem e destino. O armazenamento de objetos externo configurado para o cluster de origem, especificamente o bucket de plataforma, é usado como um local de armazenamento de migração intermediário. Cluster de origem: Os pods general-migration-* são responsáveis por exportar objetos do Kubernetes do cluster de origem para o cluster de destino. Os pods volume-migration-* são responsáveis por copiar dados de PVC para o armazenamento externo intermediário. Cluster de destino: Os pods inbound-pvc-migration-* são responsáveis por criar PVCs no cluster de destino e copiar os dados de origem para eles.
6.	Execute a instalação do Automation Suite no AKS ou EKS.

Migração de dados e responsabilidades

Dados	Mecanismo de migração
	Status	Responsabilidade
Sql	Mantido Você tem duas opções: Reutilize os mesmos bancos de dados para a nova instalação. Aponte as strings de conexão do SQL da configuração do cluster para o servidor de banco de dados existente. Clone seus bancos de dados e use os clones.	Cliente
Registro do Docker	Não migrado Se você usar um registro privado, você deve hidratar o registro de destino. Se você usar registry.uipath.com para o cluster de destino, nenhuma etapa adicional será necessária.)	Cliente
FQDN	Opcional Você deve escolher um novo FQDN para o novo cluster. Opcionalmente, você pode reverter para o FQDN anterior se necessário.	Cliente
Certificados	Não migrado Você deve trazer certificados como parte da nova instalação do cluster.	Cliente
Configuração de cluster	Não migrado Você deve gerar o novo input.json aplicável ao tipo de cluster de destino (AKS ou EKS).	Cliente
Alertas e painéis personalizados criados pelos usuários	Não migrado Você deve reconfigurar os alertas e painéis personalizados após a migração.	Cliente
Logs do aplicativo/configuração de streaming do Prometheus criada por usuários	Não migrado Você deve reconfigurar o log do aplicativo e o streaming do Prometheus.	Cliente
Cargas de trabalho dinâmicas	Depende do aplicativo Os trabalhos de treinamento do AI Center são perdidos; As habilidades são mantidas.	Habilidades (o script precisava ser executado após a atualização): UiPath® Trabalhos de treinamento: cliente
Armazenamento de objeto	Objectstore externo: Retido Para o Objectstore externo, você tem duas opções: Reutilize o armazenamento de objetos externo existente e conecte-o ao novo ambiente. Crie uma réplica do seu armazenamento de objetos atual e use-a para a nova configuração. Importante: se você estiver usando um armazenamento de objetos no cluster, você deve executar uma migração do Ceph-para-externo antes da atualização.	Migração de no cluster para o Objectstore externo: Cliente Objectstore externo: UiPath®
Insights	Mantido	UiPath®
Dados do MongoDB	Mantido Os dados do MongoDB são movidos para o SQL de destino.	UiPath®
RabbitMQ	Não é necessário	UiPath®
Monitoramento (dados)	Não é necessário Os dados de monitoramento não se aplicam ao novo cluster.	N/A

Preparação

Preparando o arquivo cluster_config.json

Observação:

Não modifique o cluster de origem após iniciar o processo de migração.

Para preparar o arquivo cluster_config.json, siga as seguintes etapas:

1. Baixe a versão de destino de uipathctl no cluster de origem e gere o arquivo input.json executando uipathctl manifest get-revision. Para obter detalhes, consulte o diagrama a seguir:
   
2. Com base no arquivo input.json gerado anteriormente, modifique o arquivo input.json do cluster de destino. Para obter instruções, consulte Configuração do input.json.

   Você deve transferir a configuração específica do Orchestrator que inclui a chave de criptografia por tenant e as configurações de buckets de armazenamento do Azure/Amazon S3 .

3. Valide os pré-requisitos no cluster de destino executando o seguinte comando:

   uipathctl prereq run input-target.json --kubeconfig kubeconfig.target --versions versions.json

4. Clone os bancos de dados SQL da implantação de origem para a implantação de destino.

Registro privado sem requisitos de acesso à internet

O processo de migração requer que a tag de imagem uipathcore Docker mais recente esteja disponível para os clusters de origem e destino. Se seu cluster de origem estiver offline, disponibilize a imagem executando as seguintes etapas:

1. Siga as etapas para hidratar o registro usado pelo cluster de destino com o pacote offline na Opção B: Hidratar o registro com o pacote offline.
2. Copie o binário uipathctl e o arquivo versions.json em uma VM com acesso ao cluster de origem.
3. Execute o seguinte comando:

   jq -r '.[][] | select(.name=="uipath/uipathcore") | .ref + ":" + .version' "/path/to/versions.json" > images.txt

4. Adicione a imagem uipathcore ao seu registro privado usando o binário uipathctl:

   ./uipathctl registry seed --tag-file ./images.txt \
               --source-registry "target.registry.fqdn.com" \
               --source-password "target-registry-username" \
               --source-username "target-registry-password" \
               --dest-registry "<source.registry.fqdn.com>" \
               --dest-username "<source-registry-username>" \
               --dest-password "<source-registry-password>"

   Observação: Certifique-se de substituir registry.fqdn, registry-username e registry-password pelos valores adequados para o registro privado usado por sua instalação offline de origem.

Registro privado com requisitos de acesso à internet

Se você usar um registro privado, você deve semeá-lo. Para obter instruções, consulteConfigurando o registro compatível com OCI.

Execução

Para migrar para o Automation Suite no EKS/AKS, execute as seguintes etapas:

1. Execute a migração executando o seguinte comando:

   uipathctl cluster migration run input-target.json --kubeconfig kubeconfig.source --target-kubeconfig kubeconfig.target --versions versions-target.json

2. Conclua a instalação do Automation Suite no AKS/EKS no cluster de destino executando o seguinte comando:

   uipathctl manifest apply input-target.json --kubeconfig kubeconfig.target --versions versions-target.json

Migração de habilidades do AI Center

As etapas nesta seção serão aplicáveis apenas se você tiver habilitado o AI Center nos clusters de origem e de destino. Observe que as instruções presumem que o AI Center no cluster de destino aponta para o banco de dados que contém os dados de habilidades para executar as habilidades.

Depois de concluir a migração, você deve sincronizar as habilidades do AI Center para que você possa usá-las novamente.

Verificação do status da migração de habilidades

Para recuperar o status das habilidades no Automation Suite de destino no cluster EKS/AKS, siga as seguintes etapas:

1. Configure as variáveis para executar os próximos comandos.

   aicJobsImage=$(kubectl -n uipath get configmap aic-jobs-config -o "jsonpath={.data['aicenter/aicenter-jobs:v23.10-10.15-rc02']}")
   podName="skillstatuspod"

2. Limpe qualquer skillstatuspod que possa estar em execução antes de recuperar o status das habilidades novamente. O seguinte comando exclui o pod da iteração anterior; portanto, use-o com cautela.

   kubectl -n uipath delete pod "$podName" --force.

3. Crie o skillstatuspod para obter o status das habilidades. O pod pode levar algum tempo para puxar a imagem e ser executado, normalmente menos de 30 segundos.

   skill_arr="[]"
   kubectl -n uipath run "$podName" --image="$aicJobsImage" --restart=Never --labels="app.kubernetes.io/component=aicenter" --overrides='{ "metadata": { "annotations": {"sidecar.istio.io/inject": "false"}}}' --command -- /bin/bash -c "curl -sSL -XPOST -H 'Content-Type: application/json' 'ai-deployer-svc.uipath.svc.cluster.local/ai-deployer/v1/system/mlskills:restore-status' -d \"$skill_arr\" | jq -r '([\"SKILL_ID\",\"SKILL_NAME\", \"STATUS\"] | (., map(length*\"-\"))), (.data[] | [.skillId, .skillName, .syncStatus]) | @tsv' | column -ts $'\t'; exit"

   Observação:

   • Substitua $skill_arr por [] para executar todas as habilidades ou ['abcd', 'efgh'] para executar apenas as duas habilidades mencionadas.
   • A saída skills id é necessária para os próximos comandos.
4. Verifique a saída do status das habilidades.

   kubectl -n uipath logs -f "$podName" -c "$podName"

Execução da migração de habilidades

Para executar a migração de habilidades, siga as seguintes etapas:

1. Configure as variáveis para executar os próximos comandos.

   aicJobsImage=$(kubectl -n uipath get configmap aic-jobs-config -o "jsonpath={.data['AIC_JOBS_IMAGE']}")
   podName="skillsyncpod"

2. Limpe qualquer skillsyncpod que possa estar em execução antes de recuperar o status das habilidades novamente. O seguinte comando exclui o pod da iteração anterior; portanto, use-o com cautela.

   kubectl -n uipath delete pod "$podName" --force

3. Inicie a sincronização de habilidades. O pod pode levar algum tempo para puxar a imagem e ser executado, normalmente menos de 30 segundos.

   kubectl -n uipath run "$podName" --image="$aicJobsImage" --restart=Never --labels="app.kubernetes.io/component=aicenter" --overrides='{ "metadata": { "annotations": {"sidecar.istio.io/inject": "false"}}}' --command -- /bin/bash -c "curl -sSL -XPOST -H 'Content-Type: application/json' 'ai-deployer-svc.uipath.svc.cluster.local/ai-deployer/v1/system/mlskills:restore-all' -d \"[\"skill_id1\", \"skill_id2\", .... ]\"; exit"

   Observação: Substitua skill ids pelos valores copiados durante o procedimento de Verificação do status de migração de habilidades .
   Verifique o exemplo abaixo para declarar a variável skill_arr :

   skill_arr='[\"fb14154a-ce63-43ab-yyyy-xxxxxxxxxxxxxx\", \"ad58942d-e038-4d38-yyyy-xxxxxxxxxxxx\"]' # Replace them with ML skill ids in your environment
   kubectl -n uipath run "$podName" --image="$aicJobsImage" --restart=Never --labels="app.kubernetes.io/component=aicenter" --overrides='{ "metadata": { "annotations": {"sidecar.istio.io/inject": "false"}}}' --command -- /bin/bash -c -x "curl -sSL -XPOST -H 'Content-Type: application/json' '/ai-deployer/v1/system/mlskills:restore-all' -d \"$skill_arr\"; exit"

4. Verifique a saída do status da sincronização de habilidades.

   kubectl -n uipath logs -f "$podName" -c "$podName"

5. A operação pode levar um longo tempo, dependendo do número de habilidades a serem sincronizadas; portanto, você pode confiar no status da migração de habilidades para verificá-lo periodicamente até que não haja nenhuma habilidade no estado IN_PROGRESS.

Observação:

Ao verificar o status da migração de habilidades ou executar a migração de habilidades, você cobre todas as habilidades ao mesmo tempo. Ou então, você pode executar essas operações apenas para habilidades selecionadas passando -d "[skill_id1, skill_id2, .... ]" como um argumento extra para curl na etapa 3.