Etapas pré-migração

Para garantir a migração bem-sucedida de uma instalação de plataforma independente para o Automation Suite, siga as etapas descritas nas seções a seguir. As etapas pré-migração são obrigatórias.

Etapa 1: salvar os dados de configuração do Identity Server

Certifique-se de salvar os seguintes dados de configuração do Identity Server:

Nome de usuário e senha do administrador do host

Salve o nome de usuário e senha do administrador do host.

Certificados de assinatura do token

O Identity Server usa certificados .pfx para assinar tokens OAuth. Se você usa seus próprios tokens na implantação autônoma, vocêvprecisa convertê-los para .pfx e atualizá-los no(s) segredo(s) correspondente(s) do cluster do Automation Suite.

Observação: você também pode seguir esta etapa durante a configuração inicial do cluster se quiser usar os mesmos certificados de assinatura na implantação do Automation Suite: kubectl edit secret identity-token-signing-certificate -n uipath.

Certificados SAML

A configuração do provedor de identidade SAML emprega armazenamentos de certificados para ler certificados de cliente e servidor. Você precisa atualizar qualquer certificado usado anteriormente na implantação independente no(s) segredo(s) correspondente(s) do cluster do Automation Suite: kubectl edit secret identity-saml-certificates -n uipath.

Configurações do aplicativo Identity Server

Salve as seguintes configurações do aplicativo Identity Server:

• DatabaseProtectionSettings de appsetting.production.json na pasta /identity da implantação independente.
• DatabaseProtectionSettings.EncryptionKey2021 a configuração é usada para criptografar dados confidenciais em repouso. Você deve replicar esse valor na implantação do Automation Suite durante a fase de pós-migração: kubectl edit secret identity-generated-secrets -n uipath.

Exportar certificados

Se você estiver usando o Azure Key Vault ou o Windows Certificate Store, exporte os certificados para o formato .pfx.

Etapa 2: criação de pares organização-tenant

Para cada tenant da implantação independente, crie um par organização-tenant no ambiente do Automation Suite.

Exemplo: se na instalação independente do Orchestrator houver um tenant chamado Tenant1, no Automation Suite você deve criar uma organização Tenant1 e um tenant dentro dessa organização também nomeado como Tenant1. Depois de criar o tenant, verifique se o serviço do Orchestrator está habilitado para ele.

Observação: um tenant “Default” é criado automaticamente para cada organização. Você não precisa excluí-lo, mas precisa adicionar outro tenant com um nome exatamente igual ao de sua organização. Por exemplo, no exemplo anterior, ao criar uma organização Tenant1, você também acaba tendo um tenant com o nome Default nessa organização. A etapa final é adicionar outro tenant chamado Tenant1 a essa organização. Em seguida, você pode passar para a criação do próximo par organização-tenant.

Etapa 3: salvando as strings de conexão e os nomes de tenants

Salve as informações a seguir para uso posterior:

• A string de conexão com o banco de dados do Orchestrator na implantação autônoma;
• A string de conexão com o banco de dados AutomationSuite_Platform na implantação do Automation Suite;
• Os nome(s) do tenant da implantação independente; você pode procurá-lo(s) na interface gráfica do Orchestrator ou usar a coluna TenancyName na tabela de tenants do Orchestrator;
• String de conexão do Insights.

Etapa 4: preparando o Orchestrator

Visão geral da migração

Para migrar o Orchestrator da licença independente para o Automation Suite, você deve reunir definições e vários arquivos da instalação independente e aplicá-los à instalação do Automation Suite.

Embora apenas parte das definições seja configurável no momento da instalação, todas devem estar disponíveis para configuração pós-instalação.

• Para configurar as definições no momento da instalação, adicione-as no arquivo cluster_config.json;
• A atualização das definições após a conclusão da instalação depende de qual é o escopo da configuração e se uma funcionalidade está disponível para configuração a partir dos parâmetros de aplicativo-de-aplicativos ou não.

Você pode armazenar arquivos personalizados necessários dentro dos pods do Orchestrator, como assemblies ou outros arquivos de armazenamento, no armazenamento de objetos do Ceph integrado. Os arquivos de armazenamento são armazenados em um bucket para cada tenant. Os plug-ins são armazenados no bucket uipath em orchestrator/plugins/nlog ou orchestrator/plugins/securestore.

Você pode adicionar configuração personalizada da seguinte maneira:

• editando os parâmetros da aplicação no ArgoCD (substituições de parâmetros);
• editando os arquivos dentro do ConfigMap do Kubernetes orchestrator-customconfig a partir do namespace uipath.

Preparando web.config

A maioria das configurações web.config não tem um equivalente ou é implementada no Automation Suite usando outros mecanismos.

As opções que você precisa configurar são as seguintes:

security.requestFiltering.requestLimits.maxAllowedContentLength

Tome nota do valor dessa configuração para uso posterior. Decida se você precisa configurá-la no Automation Suite. Seu valor padrão é 300MiB.

Preparando AppSettings

Pode ser necessário migrar as alterações personalizadas feitas na seção appSettings ou secureAppSettings do arquivo de configuração UiPath.Orchestrator.dll.config. Você pode adicionar appSettings e secureAppSettings personalizados ao mapa de configuração orchestrator-customconfig.

Na seção appSettings do arquivo de configuração UiPath.Orchestrator.dll.config, identifique qualquer configuração modificada ou adicionada. Salve essas configurações em um arquivo .json para que estejam disponíveis em etapas posteriores.

Você pode descriptografar qualquer seção de configuração de aplicativo protegida com a opção de configuração protegida da CLI do Orchestrator. Você só precisa usar as configurações que alterou ou adicionou e ainda são relevantes no Automation Suite.

Observação: você pode criar o arquivo appSettings.custom.json conforme mostrado no exemplo a seguir:

{
  "ExampleSetting.Enabled": true,
  "ExampleSetting.Type": "BasicExample",
  "ExampleSetting.Count": 3
}

Preparando armazenamento

Defina o que você precisa para a migração de armazenamento e se sua configuração de armazenamento atual permanece a mesma ou se prefere que o Automation Suite gerencie o armazenamento para você. O Automation Suite oferece a opção de armazenar os blobs no Ceph, que pode ser usado em todos os pods do Orchestrator. No caso de uma migração, você deve copiar os arquivos existentes para o armazenamento de blob atual.

Se você estiver usando armazenamento do tipo FileSystem com uma pasta local, copie os dados da pasta de armazenamento para uma pasta em um nó do Automation Suite. Em seguida, utilizando um utilitário S3, como s3cmd, você pode copiar os dados para o Orchestrator. Se você usa o Ceph, nenhuma configuração adicional será necessária, pois essa é a opção padrão.

Se você quiser usar o sistema de arquivos com um compartilhamento de rede do Windows, precisará configurar o armazenamento no aplicativo ArgoCD do Orchestrator. Recupere os dados de conexão para o compartilhamento de rede do Windows a partir da chave Storage.Location de sua configuração atual do Orchestrator. Como o Automation Suite é executado em máquinas Linux, você não pode contar com a autenticação integrada para acessar o compartilhamento de rede, portanto, precisa das credenciais de uma conta que possa acessá-lo.

Observação: atualmente, apenas compartilhamentos de rede que usam o protocolo SMB são compatíveis. Compartilhamentos de rede que empregam NFS não são compatíveis.

Se você usar opções de armazenamento remoto, como Azure, AWS ou Minio, certifique-se de adicionar as configurações Storage.Location e Storage.Type ao arquivo appSettings.custom.json.

Preparando o NLog

Você pode fazer as seguintes personalizações ao NLog:

• alterar os destinos existentes
• adicionar novos destinos
• adicionar extensões do NLog

Revise a seção NLog do arquivo de configuração e crie a configuração personalizada do NLog. Para habilitar o armazenamento de logs do robô no Elasticsearch, você pode fornecer o nome de usuário, a senha e o URI como parâmetros do Automation Suite, e o destino é configurado automaticamente. Para habilitar cenários personalizados para logs do robô, você precisa configurar o destino manualmente.

Se forem necessárias extensões NLog, crie uma pasta contendo todas as extensões e suas dependências.

Observação: por exemplo, a pasta pode ser nomeada nlogextensions. Por padrão, o Orchestrator carrega as extensões a seguir, portanto, você não precisa incluí-las na pasta ou na configuração do NLog:

NLog.Targets.ElasticSearch
UiPath.Orchestrator.Logs.Elasticsearch
Microsoft.ApplicationInsights.NLogTarget
NLog.Extensions.AzureEventHub

Crie o nlog.custom.configarquivo que contém as seções padrão: extensões, destinos e regras.

assemblyFileA seção de extensões é uma matriz de itens que especificam os conjuntos de extensão usando e o caminho do conjunto relativo à nlogextensionspasta .

O Orchestrator define destinos e regras NLog que são configurados, ou parcialmente configurados, para casos de uso comuns. Quando a personalização é necessária para esses destinos, você só precisa incluir as propriedades modificadas na configuração do NLog. Você não pode remover propriedades existentes da configuração predefinida; você pode, no entanto, alterá-las. No pod do Orchestrator, os destinos incluídos por padrão são definidos no local /opt/app-root/app/nlog.config.json.

Observação: exemplo: arquivo nlog.custom.config que escreve logs no Azure Blob:

{   "NLog": {
        "extensions": [
            { "assemblyFile": "NLog.Extensions.AzureBlobStorage.dll" }
        ],
        "targets": {
            "azureBlob": {
                "type": "AzureBlobStorage",
                "connectionString": "DefaultEndpointsProtocol=https;AccountName=test;AccountKey=key;EndpointSuffix=core.windows.net",
                "container": "orchestratorlogs",
                "blobName": "${date:format=yyyy-MM-dd hh.mm}",
                "layout": {
                  "type": "JsonLayout",
                  "includeAllProperties": true,
                  "Attributes": [
                    {"name": "ts","layout": "${longdate}"},
                    {"name": "level","layout": "${level:upperCase=true}"},
                    {"name": "logger","layout": "${logger}"},
                    {"name": "message","layout": "${message}"},
                    {"name": "exception","layout": "${onexception:${ui-pretty-exception}}"}
                  ]
                }
            }
        },
        "rules": { "70_Final": { "writeTo": "stdout,azureBlob" } }
    }
}

Observação: para substituir o destino de logs do robô, substitua 70_final por 20_robot_primary no exemplo acima.

Observação: a pasta de extensões nlogextensions é copiada no armazenamento de objeto no local de plug-ins conhecidos. A Ferramenta de Configuração do Orchestrator pode fazer isso automaticamente atualizando, simultaneamente, a configuração do NLog. O script altera nlog.custom.config automaticamente para prefixar cada assemblyFile da matriz de extensões com /var/orchestrator/plugins/nlog/ se ainda não estiver prefixado.

Preparando armazenamentos de credenciais

Você pode migrar plug-ins personalizados de armazenamentos de credenciais para o Automation Suite. Para fazer isso, atualize a configuração no mapa de configuração e copie os conjuntos de plug-ins para o bucket de armazenamento de objetos correspondente.

Observação:

• Os plug-ins devem funcionar no Linux.
• Os plugins não devem gravar em nenhum armazenamento além de /tmp.

Os seguintes plug-ins de armazenamento de credenciais são implantados automaticamente no Orchestrator via Automation Suite:

• UiPath.Orchestrator.AzureKeyVault.SecureStore.dll

• UiPath.Orchestrator.SecureStore.CyberArkCCP.dll

Observação: o Automation Suite não oferece suporte ao CyberArk AIM, portanto, você não pode migrá-lo. Recomendamos migrar para o armazenamento de credenciais CyberArkCCP.

Se você usar qualquer outro plug-in dos Armazenamentos de Credenciais, copie-o em uma pasta, como securestoreplugins.

Adicione as configurações do Armazenamento de Credenciais no arquivo appSettings.custom.json da seguinte maneira:

• para desabilitar os plug-ins padrão, adicione a configuração Plugins.SecureStores.Default com um valor vazio de string em appSettings.custom.json;
• adicione todos os plug-ins personalizados à configuração Plugins.SecureStores, separados por ; em appSettings.custom.json;
• adicione qualquer configuração de plug-in personalizado da seguinte maneira: Plugins.SecureStores.<<FriendlyName>>.<<SettingName>>.

Observação:

A pasta do plug-in securestoreplugins é copiada no armazenamento de objetos no local conhecido de plug-ins.

Os assemblies em Plugins.SecureStores são carregados a partir desta pasta.

Os assemblies de Plugins.SecureStore.Default são carregados a partir da pasta de plug-ins na pasta do aplicativo Orchestrator.

Preparando a chave de criptografia

Por padrão, no momento da instalação, o Orchestrator gera uma Chave de Criptografia a ser usada para as informações confidenciais no banco de dados. Você deve migrar essa chave se quiser reutilizar um banco de dados em uma nova implantação do Orchestrator.

A partir da seção secureAppSettings da configuração, recupere o valor de EncryptionKey e armazene-o com segurança para uso posterior.

Preparando a chave de criptografia por Tenant

O certificado de chave de criptografia é instalado no repositório de certificados do Windows. Você deve fornecer o certificado ao ambiente do Automation Suite para que esteja disponível para os pods do Orchestrator.

As configurações CertificatesStoreLocation e Azure.KeyVault.CertificateThumbprint não são mais necessárias no Automation Suite, mas você pode usar CertificatePassword se necessário.

Siga as seguintes etapas:

1. Revise o appSettings e obtenha as configurações AzureKeyVault.*.
2. Armazene Azure.KeyVault.VaultAddress, Azure.KeyVault.ClientId e Azure.KeyVault.DirectoryId para uso posterior.
3. Recupere o certificado e, se necessário, a senha do certificado.