As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Gerenciamento de scripts
A solução Cloud Migration Factory na AWS permite que os usuários gerenciem totalmente a biblioteca de scripts ou pacotes de automação na interface do usuário. Você pode fazer upload de novos scripts personalizados, bem como de novas versões do script, usando a interface de gerenciamento de scripts. Quando várias versões estão disponíveis, um administrador pode alternar entre essas versões, permitindo testar as atualizações antes de torná-las padrão. A interface de gerenciamento de scripts também permite que os administradores baixem pacotes de scripts para atualizar ou revisar o conteúdo.
Um pacote de script compatível é um arquivo zip compactado contendo os seguintes arquivos obrigatórios na raiz:
+ **package-structure.yml** - Usado para definir os argumentos do script e outros metadados, como descrição e nome padrão. Consulte [Composição de um novo pacote de scripts](#composing-a-new-script-package) para obter mais detalhes.
+ **[script python personalizado] .py** - Esse é o script inicial que será executado quando um trabalho for enviado. Esse script pode chamar outros scripts e módulos e, em caso afirmativo, eles devem ser incluídos no arquivo. O nome desse script deve corresponder ao valor especificado na `MasterFileName` chave no `Package-Structure.yml`.
## Configuração da plataforma de computação
Duas plataformas de computação estão disponíveis para a execução de scripts de automação: \$1 “Documento de automação SSM” - executa o script diretamente como um documento de automação do AWS Systems Manager sem precisar de um servidor de automação \$1 “Servidor de automação” - Executa o script em uma instância dedicada do servidor de automação (essa é a plataforma padrão se não for especificada)
A plataforma computacional para execução de scripts está definida no `Package-Structure.yml` arquivo. Para automações diretas baseadas em SSM, adicione a seguinte linha após: `MasterFileName` `ComputePlatform: "SSM Automation Document"`
## Carregar novo pacote de scripts
**nota**
Um pacote de scripts deve estar em conformidade com o formato compatível. Consulte [Composição de um novo pacote de scripts](#composing-a-new-script-package) para obter mais detalhes.
1. Escolha **Adicionar** na tabela **Scripts de automação**.
1. Selecione o arquivo do pacote que você deseja carregar.
1. Insira um nome exclusivo para o script. Os usuários referenciarão o script com esse nome para iniciar trabalhos.
## Baixar pacotes de script
Você pode baixar pacotes de scripts do console para ativar as atualizações e a verificação de conteúdo.
1. Selecione **Automação** e, em seguida, **Scripts**.
1. Selecione o script que você deseja baixar da tabela, selecione **Ações** e escolha **Baixar versão padrão** ou **Baixar versão mais recente**.
Você pode baixar versões específicas de um script. Para fazer isso, selecione o script, depois **Ações** e escolha **Alterar versão padrão.** Na lista **Versão padrão do script**, escolha **Baixar a versão selecionada**.
## Adicionar nova versão de um pacote de scripts
As atualizações dos pacotes de scripts do AWS Cloud Migration Factory podem ser carregadas na seção **Automação** > **Scripts** seguindo estas etapas:
1. Selecione **Automação** e, em seguida, **Scripts**.
1. Selecione o script existente para adicionar uma nova versão, selecione **Ações** e escolha **Adicionar nova versão**.
1. Selecione o arquivo compactado do pacote atualizado que deseja carregar e escolha **Avançar**. A nova versão do script manterá o nome existente por padrão. Insira um nome de script exclusivo. Qualquer alteração de nome só será aplicada a essa versão do script.
1. Você pode tornar a nova versão do script a versão padrão selecionando **Tornar versão padrão**.
1. Escolha **Carregar**.
## Excluindo pacotes e versões de scripts
Você não pode excluir scripts ou versões de um script para fins de auditoria. Isso permite revisar o script exato que foi executado em um sistema em um determinado momento. Cada versão de script tem uma assinatura e um ID exclusivos quando carregada, que são registrados no histórico de tarefas em que o script e a versão foram usados.
## Composição de um novo pacote de scripts
Os pacotes de scripts do Cloud Migration Factory na AWS oferecem suporte ao Python como a principal linguagem de script. Você pode iniciar outras linguagens de script de shell, conforme necessário, de dentro de um programa principal ou wrapper do Python. Para criar um novo pacote de scripts rapidamente, recomendamos baixar uma cópia de um dos scripts pré-empacotados e atualizá-lo para realizar a tarefa necessária. Primeiro, você deve criar um script Python mestre que executará a funcionalidade principal do script. Em seguida, crie um `Package-Structure.yml` arquivo para definir os argumentos e outros metadados que o script exige. Consulte `Package-Structure.yml` as opções para obter mais detalhes.
### Script Python principal
Esse é o script principal inicial que é executado quando um trabalho é iniciado. Quando a execução do script for concluída, a tarefa será concluída e o código de retorno final determinará o status do trabalho. Toda a saída desse script é capturada quando executada remotamente e passada para o registro de auditoria de saída do trabalho para referência. Esse registro também é armazenado na Amazon CloudWatch.
#### Acessando o Cloud Migration Factory em dados da AWS e APIs a partir de um script
Para fornecer acesso ao Cloud Migration Factory na AWS APIs e aos dados, você pode usar o módulo auxiliar de python incluído. O módulo fornece as principais funções. Abaixo estão algumas das principais funções para começar:
`factory_login`
Retorna um token de acesso que pode ser usado para chamar o Cloud Migration Factory na AWS APIs. Essa função tentará fazer login no CMF usando várias tentativas de credenciais:
1. Ao tentar acessar o segredo padrão contendo o ID de usuário e a senha da conta de serviço, se existirem e o acesso for permitido. Esse nome secreto [**MFServiceConta-`userpool id`]** será verificado.
1. Se a Etapa 1 não for bem-sucedida e o usuário estiver executando o script na linha de comando, o usuário será solicitado a fornecer um ID de usuário e uma senha de fábrica do AWS Cloud Migration. Se executado a partir de uma tarefa de automação remota, a tarefa falhará.
`get_server_credentials`
Retorna as credenciais de login de um servidor armazenado no AWS Cloud Migration Factory no Credentials Manager ou por meio da entrada do usuário. Essa função verificará várias fontes diferentes para determinar as credenciais de um servidor específico, a ordem das fontes é:
1. Se local\$1username e local\$1password estiverem definidos e válidos, serão retornados.
1. Se secret\$1overide estiver definido, isso será usado para recuperar o segredo especificado do AWS Secret Manager, caso contrário, verifica se o registro do servidor contém a chave **secret\$1name e se ela não está vazia, então esse nome** secreto será usado.
1. Se houver uma falha ao localizar ou acessar os segredos especificados, a função voltará a solicitar as credenciais ao usuário, mas somente se o **no\$1user\$1prompts** estiver definido como **False**, caso contrário, retornará uma falha.
**Parâmetros**
local\$1username - Se aprovado, será retornado.
local\$1password - Se aprovada, será retornada.
server - CMF Server dict, conforme retornado por get\$1factory\$1servers. na AWS Cloud Migration Factory.
Secret\$1overide - Se passado, isso definirá o nome secreto a ser recuperado do Secrets Manager para este servidor.
No\$1user\$1prompts - Diz à função que não solicite ao usuário um ID de usuário e uma senha se não forem armazenados. Isso deve ser verdadeiro para qualquer script de automação remota.
`get_credentials`
Obtém as credenciais armazenadas usando o AWS Cloud Migration Factory Credentials Manager do Secrets Manager.
**Parâmetros**
secret\$1name - nome do segredo a ser recuperado.
get\$1factory\$1servers
Retorna uma matriz de servidores do armazenamento de dados do AWS Cloud Migration Factory com base no waveid fornecido.
**Parâmetros**
waveid - ID do registro Wave dos servidores que serão retornados.
token - Token de autenticação obtido da função FactoryLogin Lambda.
app\$1ids - Lista opcional de IDs de aplicativos dentro da onda a serem incluídos.
server\$1ids - Lista opcional de IDs de servidor dentro da onda e aplicativos a serem incluídos.
os\$1split - Se definido como`true`, duas listas serão retornadas, uma para Linux e outra para servidores Windows; se for False, uma única lista combinada será retornada.
rtype - String opcional para filtrar somente para uma estratégia de migração específica de servidores, ou seja, passar o valor “Rehost” retornará somente servidores com Rehost.
#### Resumo da mensagem final
É recomendável fornecer uma mensagem resumida do resultado do script como saída final para a tela ou sysout. Isso será mostrado no console na propriedade **Última mensagem**, que fornece um status rápido do resultado do script sem que o usuário precise ler o log de saída completo.
#### Código de retorno
O script python principal deve retornar um código de retorno diferente de zero na saída se a função do script não for totalmente bem-sucedida. Ao receber um código de retorno diferente de zero, o status do trabalho será mostrado como **Falha** no log de trabalhos, indicando ao usuário que ele deve revisar o log de saída para obter detalhes sobre a falha.
### Opções YAML package-structure.yml
#### Exemplo de arquivo YAML
```
Name: "0-Check MGN Prerequisites"
Description: "This script will verify the source servers meet the basic requirements for AWS MGN agent installation."
MasterFileName: "0-Prerequisites-checks.py"
UpdateUrl: ""
Arguments:
-
name: "ReplicationServerIP"
description: "Replication Server IP."
long_desc: "IP Address of an AWS MGN Replication EC2 Instance."
type: "standard"
required: true
-
name: "SecretWindows"
long_desc: "Windows Secret to use for credentials."
description: "Windows Secret"
type: "relationship"
rel_display_attribute: "Name"
rel_entity: "secret"
rel_key: "Name"
-
name: "SecretLinux"
long_desc: "Linux Secret to use for credentials."
description: "Linux Secret"
type: "relationship"
rel_display_attribute: "Name"
rel_entity: "secret"
rel_key: "Name"
-
name: "Waveid"
description: "Wave Name"
type: "relationship"
rel_display_attribute: "wave_name"
rel_entity: "wave"
rel_key: "wave_id"
validation_regex: "^(?!\\s*$).+"
validation_regex_msg: "Wave must be provided."
required: true
SchemaExtensions:
-
schema: "server"
name: "server_pre_reqs_output"
description: "Pre-Req Output"
type: "string"
```
#### Descrições de chaves do YAML
Obrigatório
**Nome** - Nome padrão que o script usará na importação.
**Descrição** - Descrição do uso do script.
**MasterFileName**- Este é o ponto de partida para a execução do script. Ele deve ser um nome de arquivo python incluído no arquivo do pacote de scripts.
**Argumentos** - Uma lista de argumentos que o script MasterFileName Python aceita. Cada argumento especificado está no formato de definição de atributos do AWS Cloud Migration Factory. As propriedades obrigatórias para cada argumento são **Nome** e **Tipo**, todas as outras propriedades são opcionais.
Opcional
**ComputePlatform**- Essa chave define onde o script será executado. Defina como “Documento de automação SSM” para ser executado diretamente no AWS Systems Manager sem um servidor de automação. Se omitido, o padrão é a execução no servidor de automação.
**UpdateUrl**- Forneça uma URL em que a fonte do pacote de scripts esteja disponível para fornecer atualizações. Atualmente, isso é apenas para referência.
**SchemaExtensions**- Uma lista de atributos que o script Python exige que estejam no esquema para armazenar a saída ou recuperar dados adicionais. Cada atributo deve ser especificado no formato de definição de atributos do AWS CMF. As propriedades obrigatórias para cada atributo são **Esquema**, **Nome, Descrição** e **Tipo**. Todas as outras propriedades são opcionais. Quaisquer novos atributos serão adicionados automaticamente ao esquema quando o script for carregado inicialmente, e as alterações feitas não SchemaExtensions serão processadas para novas versões do script. Se isso for necessário para que um novo script seja adicionado, atualizações manuais no esquema devem ser feitas.