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á.
# Perguntas frequentes
Veja a seguir FAQs respostas para algumas perguntas comuns.
**Topics**
+ [Quais AWS OpsWorks Stacks versões posso migrar?](#w2ab1c14c43c19b7)
+ [Quais versões do Chef minhas instâncias migradas podem usar?](#w2ab1c14c43c19b9)
+ [Quais tipos de repositório posso migrar?](#w2ab1c14c43c19c11)
+ [Posso continuar usando um repositório Git privado?](#w2ab1c14c43c19c13)
+ [Quais chaves SSH posso usar para acessar minhas instâncias?](#w2ab1c14c43c19c15)
+ [Por que minhas instâncias estão aumentando e diminuindo automaticamente?](#w2ab1c14c43c19c17)
+ [Posso desativar o ajuste de escala automático?](#w2ab1c14c43c19c19)
+ [Posso realizar atualizações de kernel e pacote em EC2 instâncias lançadas?](#w2ab1c14c43c19c21)
+ [Por que os volumes do EBS em minhas instâncias não contêm dados?](#w2ab1c14c43c19c23)
+ [Por que os volumes do EBS descritos no meu modelo de lançamento não estão montados?](#w2ab1c14c43c19c25)
+ [Onde posso encontrar receitas do Chef e registros de volume do Mount EBS?](#w2ab1c14c43c19c27)
+ [Onde posso encontrar o log de depuração do script de migração?](#w2ab1c14c43c19c29)
+ [O script de migração oferece suporte ao controle CloudFormation de versão do modelo?](#w2ab1c14c43c19c31)
+ [Posso migrar várias camadas?](#w2ab1c14c43c19c33)
+ [Como crio um parâmetro `SecureString`?](#w2ab1c14c43c19c35)
+ [Como posso proteger as instâncias do novo grupo do Auto Scaling contra eventos de encerramento?](#w2ab1c14c43c19c37)
+ [Quais balanceadores de carga estão disponíveis com o script de migração?](#w2ab1c14c43c19c39)
+ [As receitas de configuração do livro de receitas personalizado foram migradas?](#w2ab1c14c43c19c41)
+ [Posso executar receitas de implantação e desimplantação em minhas instâncias recém-criadas?](#w2ab1c14c43c19c43)
+ [Posso alterar quais sub-redes meu grupo do Auto Scaling abrange?](#w2ab1c14c43c19c45)
## Quais AWS OpsWorks Stacks versões posso migrar?
Você só pode migrar pilhas do Chef 11.10 e do Chef 12, do Amazon Linux, do Amazon Linux 2, do Ubuntu e do Red Hat Enterprise Linux 7.
## Quais versões do Chef minhas instâncias migradas podem usar?
As instâncias migradas podem usar as versões 11 a 14 do Chef.
**nota**
Não há suporte para migração de pilhas do Windows.
## Quais tipos de repositório posso migrar?
Você pode migrar os tipos de repositório S3, Git e HTTP.
## Posso continuar usando um repositório Git privado?
Sim, você pode continuar usando um repositório Git privado.
Se você usar um GitHub repositório privado, deverá criar uma nova chave de `Ed25519` host para SSH. Isso ocorre porque GitHub alterou quais chaves são suportadas no SSH e removeu o protocolo Git não criptografado. Para obter mais informações sobre a chave do `Ed25519` host, consulte a postagem do GitHub blog [Melhorando a segurança do protocolo Git](https://github.blog/2021-09-01-improving-git-protocol-security-github/) em. GitHub Depois de gerar uma nova chave de host `Ed25519`, crie um parâmetro `SecureString` do Systems Manager para essa chave SSH e use o nome do parâmetro como o valor do parâmetro `--repo-private-key`. Para obter mais informações sobre como criar um `SecureString` parâmetro do Systems Manager, consulte [Create a SecureString parameter (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring) no *Guia AWS Systems Manager do usuário*.
Para qualquer outro tipo de repositório Git, crie um parâmetro `SecureString` do Systems Manager para essa chave SSH e use o nome do parâmetro como o valor do parâmetro `--repo-private-key` do script.
## Quais chaves SSH posso usar para acessar minhas instâncias?
Quando você executa o script, o script migra as chaves SSH e as instâncias configuradas na pilha. Você pode usar as chaves SSH para acessar sua instância. Se as chaves SSH forem fornecidas para a pilha e a instância, o script usará as chaves da pilha. Se você não tiver certeza de quais chaves SSH usar, visualize as instâncias no EC2 console ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)). A página **Detalhes** no EC2 console mostra as chaves SSH da sua instância.
## Por que minhas instâncias estão aumentando e diminuindo automaticamente?
O ajuste de escala automático dimensiona as instâncias com base nas regras de escalabilidade do grupo do Auto Scaling. Você pode definir os valores de **capacidade **mínima**, **máxima** e desejada** para seu grupo. O grupo do Auto Scaling dimensiona automaticamente sua capacidade de acordo com a atualização desses valores.
## Posso desativar o ajuste de escala automático?
Você pode desativar o ajuste de escala automático definindo os valores de capacidade **mínima**, **máxima** e **desejada** do grupo do Auto Scaling para o mesmo número. Por exemplo, se você quiser sempre ter dez instâncias, defina os valores de capacidade **mínima**, **máxima** e **desejada** como dez.
## Posso realizar atualizações de kernel e pacote em EC2 instâncias lançadas?
Por padrão, as atualizações do kernel e dos pacotes ocorrem quando a EC2 instância é inicializada. Use as etapas a seguir para realizar atualizações de kernel ou pacote em uma EC2 instância iniciada. Por exemplo, talvez você queira aplicar atualizações após executar o deploy ou o configure recipes.
1. Conecte-se à sua EC2 instância.
1. Crie a função `perform_upgrade` a seguir e execute-a na sua instância.
```
perform_upgrade() {
#!/bin/bash
if [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
sudo yum -y update
elif [ -e '/etc/debian_version' ]; then
sudo apt-get update
sudo apt-get dist-upgrade -y
fi
}
perform_upgrade
```
1. Depois das atualizações do kernel e do pacote, talvez seja necessário reinicializar sua EC2 instância. Para verificar se é necessário reinicializar, crie a `reboot_if_required` função a seguir e execute-a na sua EC2 instância.
```
reboot_if_required () {
#!/bin/bash
if [ -e '/etc/debian_version' ]; then
if [ -f /var/run/reboot-required ]; then
echo "reboot is required"
else
echo "reboot is not required"
fi
elif [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
LATEST_INSTALLED_KERNEL=`rpm -q --last kernel | perl -X -pe 's/^kernel-(\S+).*/$1/' | head -1`
CURRENTLY_USED_KERNEL=`uname -r`
if [ "${LATEST_INSTALLED_KERNEL}" != "${CURRENTLY_USED_KERNEL}" ];then
echo "reboot is required"
else
echo "reboot is not required"
fi
fi
}
reboot_if_required
```
1. Se estiver executando os `reboot_if_required` resultados em uma `reboot is required` mensagem, reinicie a EC2 instância. Se você receber uma `reboot is not required` mensagem, não precisará reinicializar a EC2 instância.
## Por que os volumes do EBS em minhas instâncias não contêm dados?
Quando você executa o script, o script migra a configuração dos volumes do EBS, criando uma arquitetura substituta para sua OpsWorks pilha e sua camada. O script não migra instâncias reais nem os dados contidos nas instâncias. O script migra somente a configuração dos volumes do EBS no nível da camada e anexa os volumes vazios do EBS às instâncias iniciadas. EC2
Siga as etapas a seguir para extrair dados dos volumes do EBS de suas instâncias anteriores.
1. Crie um snapshot dos volumes do EBS de instâncias anteriores. Para obter mais informações sobre a criação de um snapshot, consulte [Criar um snapshot do Amazon EBS no Guia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html) do usuário da *Amazon EC2 *.
1. Criar um volume a partir de um snapshot. Para obter mais informações sobre a criação de um volume a partir de um snapshot, consulte [Criar um volume a partir de um snapshot no Guia EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot) *do usuário da Amazon*.
1. Anexe o volume que você criou à instância. Para obter mais informações sobre anexar volumes, consulte [Anexar um volume do Amazon EBS a uma instância no Guia EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html) *do usuário da Amazon*.
## Por que os volumes do EBS descritos no meu modelo de lançamento não estão montados?
Se você fornecer uma ID de modelo de execução para o parâmetro `--launch-template` com volumes do EBS, o script anexará os volumes do EBS, mas não montará os volumes. Você pode montar os volumes do EBS anexados executando o `MountEBSVolumes` RunCommand documento que o script criou para a EC2 instância iniciada.
Se você não definir o `--launch-template` parâmetro, o script cria um modelo e, quando o grupo Auto Scaling inicia uma nova EC2 instância, o grupo Auto Scaling anexa automaticamente os volumes do EBS e, em seguida, executa `SetupAutomation` o comando para montar os volumes anexados nos pontos de montagem definidos nas configurações da camada.
## Onde posso encontrar receitas do Chef e registros de volume do Mount EBS?
OpsWorks entrega os registros em um bucket do S3 que você pode especificar fornecendo um valor para o `--command-logs-bucket` parâmetro. O nome padrão do bucket do S3 tem o formato: `aws-opsworks-stacks-application-manager-logs-account-id`. Os registros de receitas do Chef são armazenados no prefixo `ApplyChefRecipes`. Os registros de volume do Mount EBS são armazenados no prefixo `MountEBSVolumes`. Todas as camadas que são migradas de uma pilha entregam registros para o mesmo bucket do S3.
**nota**
A configuração do ciclo de vida do bucket S3 inclui uma regra para excluir os registros após 30 dias. Se quiser manter os registros por mais de 30 dias, você deve atualizar a regra na configuração do ciclo de vida do bucket S3.
Atualmente, registra OpsWorks apenas o Chef `setup` e `terminate` as receitas.
## Onde posso encontrar o log de depuração do script de migração?
O script coloca os logs de depuração em um bucket chamado `aws-opsworks-stacks-transition-logs-account-id`. Você pode encontrar os logs de depuração pasta `migration_script` do bucket do S3 em pastas que correspondem ao nome da camada que você migrou.
## O script de migração oferece suporte ao controle CloudFormation de versão do modelo?
O script gera documentos do tipo Systems Manager CloudFormation que criam uma substituição para a camada ou pilha que você deseja migrar. Executar o script novamente, mesmo com os mesmos parâmetros, exporta uma nova versão do modelo de camada exportado anteriormente. As versões do modelo são armazenadas no mesmo bucket do S3 que os logs do script.
## Posso migrar várias camadas?
O parâmetro `--layer-id` do script passa em uma única camada. Para migrar várias camadas, execute novamente o script e passe uma diferente `--layer-id`.
As camadas que fazem parte da mesma OpsWorks pilha são listadas sob o mesmo aplicativo no Application Manager.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Na seção **Aplicativos**, escolha **Aplicativos personalizados**.
1. Escolha o aplicativo. O nome do aplicativo começa com `app-stack-name-first-six-characters-stack-id`.
1. O elemento de nível superior, começando com app, mostra todos os componentes que correspondem à sua OpsWorks pilha. Isso inclui componentes correspondentes à sua OpsWorks camada.
1. Escolha o componente correspondente à camada para visualizar os recursos da camada. Os componentes que representam OpsWorks camadas também são visíveis na seção **Aplicativos personalizados** como aplicativos individuais.
## Como crio um parâmetro `SecureString`?
Você pode usar o Systems Manager para criar um parâmetro `SecureString`. Para obter mais informações sobre como criar um `SecureString` parâmetro do Systems Manager, consulte [Create a SecureString parameter (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring) ou [Create a Systems Manager parameter (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) no *Guia do AWS Systems Manager Usuário*.
Você deve fornecer um parâmetro `SecureString` como valor para os parâmetros `--http-username`, `--http-password`, ou `--repo-private-key`.
## Como posso proteger as instâncias do novo grupo do Auto Scaling contra eventos de encerramento?
Você pode proteger as instâncias definindo o `--enable-instance-protection` parâmetro `TRUE` e adicionando uma chave de `protected_instance` tag a cada EC2 instância que você deseja proteger contra eventos de encerramento. Quando você define o parâmetro `--enable-instance-protection` para `TRUE` e adiciona uma chave de tag `protected_instance`, o script adiciona uma política de encerramento personalizada ao seu novo grupo do Auto Scaling e suspende o processo `ReplaceUnhealthy`. As instâncias com a chave de tag `protected_instance` são protegidas dos seguintes eventos de encerramento:
+ Eventos de redução de escala horizontalmente
+ Atualização de instância
+ Rebalanceamento
+ Vida útil máxima da instância
+ Permitir o término de instâncias
+ Rescisão e substituição de instâncias não íntegras
**nota**
Você deve definir a chave da tag `protected_instance` nas instâncias que deseja proteger. Observe que a chave da tag faz distinção entre maiúsculas e minúsculas. Qualquer instância com essa chave de tag é protegida, independentemente do valor da tag.
Para reduzir o tempo de execução da política de encerramento personalizada, você pode aumentar o número padrão de instâncias que a função do Lambda usa para filtrar instâncias protegidas atualizando o valor da variável de código da função `default_sample_size`. O valor padrão é 15. Se você aumentar o `default_sample_size`, talvez seja necessário aumentar a memória alocada para a função do Lambda, o que aumentaria o custo da sua função do Lambda. Para obter mais informações sobre a definição de preço do AWS Lambda , consulte [Definição de preço do AWS Lambda](https://aws.amazon.com/).
## Quais balanceadores de carga estão disponíveis com o script de migração?
O script fornece três opções de balanceador de carga.
+ (Recomendado) Crie um novo Application Load Balancer. Por padrão, o script cria um novo Application Load Balancer. Também é possível definir o parâmetro `--lb-type` para `ALB`. Para obter mais informações sobre os Application Load Balancers, consulte [O que é Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) no guia do usuário do *Elastic Load Balancing*
+ Se um Application Load Balancer não for uma opção, crie um Classic Load Balancer definindo o parâmetro `--lb-type` para `Classic`. Se você selecionar essa opção, seu Classic Load Balancer existente anexado à sua OpsWorks camada será mantido separado do seu aplicativo. Para obter mais informações sobre Application Load Balancers, consulte [O que é um balanceador de carga clássico?](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html) no *guia do usuário do Elastic Load Balancing: Classic Load Balancers*.
+ Você pode conectar um balanceador de carga existente definindo o parâmetro `--lb-type` para `None`.
**Importante**
Recomendamos criar novos balanceadores de carga do Elastic Load Balancing para suas camadas do AWS OpsWorks Stacks. Se escolher usar um balanceador de carga do Elastic Load Balancing existente, você deve primeiro confirmar que não está sendo usado para outros fins e não tem instâncias anexadas. Depois que o balanceador de carga é anexado à camada, OpsWorks remove todas as instâncias existentes e configura o balanceador de carga para lidar somente com as instâncias da camada. Apesar de ser tecnicamente possível usar o console do Elastic Load Balancing ou API para modificar a configuração do balanceador de carga após anexá-lo a camada, você não deve fazê-lo; as mudanças não serão permanentes.
**Para anexar seu balanceador OpsWorks de carga de camada existente ao seu grupo de Auto Scaling**
1. Execute o script de migração com o parâmetro `--lb-type` definido como `None`. Quando o valor é definido como `None`, o script não clona nem cria um balanceador de carga.
1. Depois que o script implantar a CloudFormation pilha, atualize os `Min` `Max` grupos `Desired capacity` e valores do Auto Scaling e teste seu aplicativo.
1. Escolha `Link to the template` mostrada na saída do script. Se você fechou seu terminal, siga estas etapas para acessar o modelo.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Escolha **CloudFormation pilhas** e, em seguida, escolha **Biblioteca de modelos**.
1. Escolha **Minha propriedade** e localize seu modelo.
1. No CloudFormation modelo, escolha **Editar** no menu **Ações**.
1. Atualize a `LabelBalancerNames` propriedade na seção de `ApplicationAsg` recursos do CloudFormation modelo.
```
ApplicationAsg:
DependsOn: CustomTerminationLambdaPermission
Properties:
#(other properties in ApplicationAsg to remain unchanged)
LoadBalancerNames:
- load-balancer-name
HealthCheckType: ELB
```
1. Se você quiser que sua verificação de integridade de instâncias de grupo do Auto Scaling também use a verificação de integridade do balanceador de carga, remova a seção `HealthCheckType` abaixo e insira `ELB`. Se você precisar apenas de verificações de EC2 saúde, não precisará alterar o modelo.
1. Salve as alterações. Salvar cria uma nova versão padrão do modelo. Se esta é a primeira vez que você executa o script para a camada e a primeira vez que você salva as alterações no console, a versão mais recente é 2.
1. Em **Ações**, escolha **Provisionar pilha**.
1. Confirme que você deseja usar a versão padrão do modelo. Certifique-se de que a **opção Selecionar uma pilha existente** esteja selecionada e escolha a CloudFormation pilha a ser atualizada.
1. Escolha **Próximo** para cada uma das páginas subsequentes até ver a página **Revisar e provisionar**. Na página **Revisar e provisionar**, escolha **Eu reconheço que AWS CloudFormation pode criar recursos do IAM com nomes personalizados** e **entendo que alterações no modelo selecionado podem AWS CloudFormation fazer com que os AWS recursos existentes sejam atualizados ou removidos.**
1. Selecione **Provision stack** (Provisionar pilha).
Se você precisar reverter as atualizações, siga as seguintes etapas:
1. Escolha **Ações** e depois escolha **Provisionar pilha**.
1. Selecione **Escolher uma das versões existentes** e, em seguida, escolha a versão anterior do modelo.
1. Escolha **Selecionar uma pilha existente** e, em seguida, escolha a CloudFormation pilha a ser atualizada.
## As receitas de configuração do livro de receitas personalizado foram migradas?
Não há suporte para execução de livros de receitas personalizados durante um evento de configuração. O script migra o livro de receitas personalizado, configura receitas e cria um runbook do Systems Manager Automation para você. No entanto, você deverá executar as receitas manualmente.
Siga as seguintes etapas para executar suas receitas de configuração.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Na seção **Aplicativos**, escolha **Aplicativos personalizados**.
1. Escolha o aplicativo. O nome do aplicativo começa com `app-stack-name`.
1. Escolha **Recursos** e, em seguida, escolha o runbook de configuração.****
1. Escolha **Executar automação**.
1. Escolha a instância IDs para a qual você deseja executar as receitas de configuração e, em seguida, escolha **Executar**.
## Posso executar receitas de implantação e desimplantação em minhas instâncias recém-criadas?
O script pode criar três possíveis runbooks de automação, dependendo da configuração da sua camada.
+ Configuração
+ Configurar
+ Encerrar
O script também pode criar os seguintes parâmetros do Systems Manager que contêm valores de entrada para o documento `AWS-ApplyChefRecipes Run Command`.
+ Configuração
+ Implantar
+ Configurar
+ Desfazer a Implementação
+ Encerrar
Quando ocorre um evento de expansão, o runbook de automação de configuração é executado automaticamente. Isso inclui a configuração e a implantação de receitas personalizadas de livros de receitas a partir de sua OpsWorks camada original. Quando um evento de aumento da escala na vertical acontece, o runbook de automação de término é executado automaticamente. O runbook terminate Automation contém as receitas de desligamento da sua camada original. OpsWorks
Se você deseja executar, desimplantar ou configurar receitas manualmente, siga as seguintes etapas.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Na seção **Aplicativos**, escolha **Aplicativos personalizados**.
1. Escolha o aplicativo. O nome do aplicativo começa com `app-stack-name-first-six-characters-stack-id`. O Application Manager abre a guia **Visão geral**.
1. Escolha **Recursos** e, em seguida, escolha o runbook de configuração de automação.
1. Escolha **Executar automação**.
1. Para o parâmetro de entrada do Automation runbook `applyChefRecipesPropertiesParameter`, consulte o parâmetro correto do Systems Manager. O nome do parâmetro Systems Manager segue o formato`/ApplyChefRecipes-Preset/OpsWorks-stack-name-OpsWorks-layer-name-first-six-characters-stack-id/event`, onde o valor para *event* está `Configure``Deploy`, ou `Undeploy` dependendo das receitas que você deseja executar.
1. Escolha a instância IDs em que você deseja executar as receitas e escolha **Executar**.
## Posso alterar quais sub-redes meu grupo do Auto Scaling abrange?
Por padrão, o grupo Auto Scaling abrange todas as sub-redes em sua VPC de pilha. OpsWorks Para atualizar as sub-redes a serem abrangidas, siga as seguintes etapas:
1. Escolha `Link to the template` mostrada na saída do script. Se você fechou seu terminal, siga estas etapas para acessar o modelo.
1. Abra o console do Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. No painel de navegação, escolha **Application Manager**.
1. Escolha **CloudFormation pilhas** e, em seguida, escolha **Biblioteca de modelos**.
1. Escolha **Minha propriedade** e localize seu modelo.
1. Em **Ações**, escolha **Provisionar pilha**.
1. Confirme que você deseja usar o modelo padrão. Escolha **Selecionar uma pilha existente** e, em seguida, escolha a CloudFormation pilha a ser atualizada.
**nota**
Se você executou o script com o `--provision-application` parâmetro definido como`FALSE`, deverá criar uma nova CloudFormation pilha.
1. Para o `SubnetIDs` parâmetro, forneça uma lista separada por vírgulas da sub-rede IDs que você deseja que seu grupo de Auto Scaling abranja.
1. Escolha **Avançar** até ver a página **Revisar e provisionar**.
1. Na página **Revisar e provisionar**, escolha **Eu reconheço que CloudFormation pode criar recursos do IAM com nomes personalizados** e **entendo que alterações no modelo selecionado podem CloudFormation fazer com que os AWS recursos existentes sejam atualizados ou removidos**.
1. Selecione **Provision stack** (Provisionar pilha).