Usando a AWS OpsWorks Stacks ferramenta Detach in Place - AWS OpsWorks
Como o processo funcionaLimitaçõesConceitos básicos

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á.

Usando a AWS OpsWorks Stacks ferramenta Detach in Place

Importante

O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível.

Esta seção descreve como usar a ferramenta AWS OpsWorks Stacks Detach in Place para separar suas OpsWorks instâncias do serviço OpsWorks Stacks.

As instâncias que você desanexar permanecerão na sua Conta da AWS, mas você não poderá mais gerenciá-las usando OpsWorks. Em vez disso, você usará a Amazon EC2 ou qualquer abordagem EC2 compatível para configurar e gerenciar as instâncias. AWS Systems Manager

Em um alto nível, o processo de desapego envolve as seguintes etapas:

  1. A ferramenta realiza verificações de validação para garantir que os recursos estejam prontos para serem separados.

  2. A ferramenta exporta o JSON personalizado da sua OpsWorks pilha e o armazena como um objeto no Amazon S3.

  3. A ferramenta cria documentos do Systems Manager Automation representando cada evento do ciclo de vida do OpsWorks Stacks.

  4. A ferramenta cria um AWS Service Catalog AppRegistry catálogo para todas as instâncias que estão sendo desanexadas e separa quaisquer balanceadores de carga do Elastic Load Balancing (ELB) das camadas. OpsWorks

  5. Por fim, a ferramenta separa e cancela o registro de outros recursos, incluindo instâncias do Amazon Relational Database Service (Amazon RDS).

Como o processo funciona

A ferramenta Detach In Place fornece os três comandos a seguir e uma experiência semelhante à de um assistente que orienta você por uma série de etapas para verificar e configurar suas instâncias antes de prosseguir com a separação da camada.

Comando Descrição

handle-prerequisites

Esse comando analisa se todas as instâncias em uma camada são elegíveis para desanexação e resolve os pré-requisitos. As instâncias devem estar em um estado íntegro OpsWorks, não podem ter escaladores automáticos baseados em tempo ou carga e devem ter a versão mais recente do OpsWorks Agente instalada.

Além disso, o comando verifica se todas as instâncias têm as permissões necessárias para oferecer suporte ao SSM Agent e se a versão mais recente do SSM Agent está instalada. O comando instalará o SSM Agent se ele não estiver presente e atualizará o SSM Agent se ele não estiver usando a versão mais recente. O comando também adicionará todas as permissões necessárias.

detach

Esse comando separa todas as OpsWorks instâncias da camada especificada.

Primeiro, o comando executará uma verificação de pré-requisitos para garantir que a camada se qualifique para desanexação. Se você não quiser resolver os pré-requisitos, você tem a opção de forçar a separação.

Em seguida, o comando indicará que todas as tags adicionadas às suas instâncias por meio de OpsWorks marcação APIs ou propagação de tags de suas camadas e pilhas serão mantidas. Você pode remover qualquer uma dessas etiquetas usando as relevantes EC2 APIs após a conclusão da separação.

Em seguida, o comando verificará se você deseja exportar a configuração relacionada ao Chef para os parâmetros SSM.

Se você tiver um Classic Load Balancer anexado à camada, o comando perguntará se ele pode desconectar o balanceador de carga para evitar qualquer tempo de inatividade.

cleanup

Esse comando exclui todas as entidades OpsWorks da sua conta. Isso encerrará as instâncias e excluirá todas as pilhas. Isso deve ser usado para recursos que não são mais necessários como última etapa para limpar a conta.

nota

Recomendamos que você execute a nova configuração por alguns dias antes de executar o cleanup comando. Isso garante que todas as configurações necessárias da pilha estejam prontamente disponíveis, se necessário.

Limitações

O objetivo principal da ferramenta Detach In Place é separar com segurança as instâncias do OpsWorks Stacks. Esta seção resume as limitações da ferramenta.

  • Agente SSM do Windows — Se o agente SSM não estiver instalado na instância, você precisará instalá-lo manualmente. O mesmo se aplica se o Agente não estiver atualizado para a versão mais recente.

  • Instâncias do Auto Scaling de tempo/carga — A ferramenta de desvinculação não é compatível com instâncias com o Auto Scaling ativado. Você deve desativar o Auto Scaling nas instâncias que você deseja separar.

  • Permissões — A ferramenta de desanexação não cria nem gera entidades do IAM especificadas na página de Permissões do OpsWorks console.

  • Aplicativos — A ferramenta de separação não cria nem gera aplicativos fora do OpsWorks.

Conceitos básicos

Etapa 1: Verificar se os pré-requisitos foram atendidos

Todos os três comandos da ferramenta Detach In Place são scripts Python, que você pode executar localmente, EC2 por exemplo ou usando. AWS CloudShell

AWS CloudShell é um shell baseado em navegador que fornece acesso por linha de comando aos AWS recursos selecionados. Região da AWS AWS CloudShell vem pré-instalado com ferramentas populares (como AWS CLI Python). Ao usar AWS CloudShell, você usa as mesmas credenciais que usa para entrar no console.

Este passo a passo pressupõe que você esteja usando. AWS CloudShell

Etapa 2: Baixe o script

  1. Faça o download do arquivo zip que contém o script de migração e todos os arquivos relevantes executando o seguinte comando:

    aws s3api get-object \
--bucket detach-in-place-bucket-prod-us-east-1 \
--key detach_in_place_script.zip detach_in_place_script.zip

  2. Descompacte o arquivo executando o comando a seguir.

    unzip detach_in_place_script.zip

    Depois que o arquivo for descompactado, os seguintes arquivos estarão disponíveis:

    • README.md

    • LICENSE

    • NOTICE

    • requirements.txt

    • TODO.py

  3. Se necessário, instale pipenv executando o comando a seguir.

    pip install pipenv

Etapa 3: executar o script

Primeiro, configure seu ambiente para que você possa executar o script executando os comandos a seguir.

pipenv install -r requirements.txt
pipenv shell

Em seguida, revise os parâmetros do script.

Command Parameter Descrição Tipo Obrigatório Padrão

handle-prerequisites

--layer-id

O ID da camada que você deseja desanexar.

String

Sim

-

--region

A região da OpsWorks pilha. Se a região da OpsWorks pilha e a região do endpoint da API forem diferentes, use a região da pilha. Essa é a mesma região que os outros recursos que fazem parte da sua OpsWorks pilha (por exemplo, EC2 instâncias e sub-redes).

String

Não

us-east-1

detach

--layer-id

ID da camada que você deseja desanexar.

String

Sim

-

--batch-size

Número de instâncias a serem separadas de uma camada (por exemplo, 5).

String

Não

-

--region

A região da OpsWorks pilha. Se a região da OpsWorks pilha e a região do endpoint da API forem diferentes, use a região da pilha. Essa é a mesma região que os outros recursos que fazem parte da sua OpsWorks pilha (por exemplo, EC2 instâncias e sub-redes).

String

Não

us-east-1

cleanup

--stack-id

ID da pilha que você deseja excluir.

String

Não

Mutuamente exclusivo, você deve especificar um ID de camada ou um ID de pilha

--layer-id

ID da camada que você deseja excluir

String

Não

--region

A região da OpsWorks pilha. Se a região da OpsWorks pilha e a região do endpoint da API forem diferentes, use a região da pilha. Essa é a mesma região que os outros recursos que fazem parte da sua OpsWorks pilha (por exemplo, EC2 instâncias e sub-redes).

String

Não

us-east-1

Você pode ver as opções disponíveis para os cleanup comandosdetach, handle-prerequisites e executando os comandos com a --help opção da seguinte forma:

python3 layer_detacher.py detach --help
python3 layer_detacher.py handle-prerequisites --help
python3 layer_detacher.py cleanup --help

Agora você está pronto para começar. Os exemplos a seguir mostram como você pode executar os comandos para diferentes casos de uso.

Exemplo 1: Verifique se uma camada preenche todos os pré-requisitos e está qualificada para desanexação

O comando a seguir lê as informações sobre uma OpsWorks camada (e as instâncias que ela inclui) e verifica se os seguintes pré-requisitos foram atendidos:

  • Todas as instâncias estão online.

  • Não há instâncias do Auto Scaling de Carga/Tempo.

  • Todas as instâncias têm o OpsWorks Agente mais recente.

  • Todas as instâncias têm o agente SSM mais recente instalado e configurado.

  • Todas as instâncias têm um par de chaves SSH.

  • Cada instância pertence a exatamente uma camada.

python3 layer_detacher.py handle-prerequisites \
--layer-id opsworks-layer-id \
--region opsworks-stack-region

Exemplo 2: Desanexar todas as instâncias de uma camada

O comando a seguir repetirá todas as instâncias da camada, verificará se as instâncias atendem aos pré-requisitos e tentará separar paralelamente todas as instâncias que atendam aos pré-requisitos. Se um ou mais pré-requisitos não forem atendidos, o comando fornecerá uma opção de desconexão forçada para as demais instâncias não compatíveis.

Antes de desanexar qualquer instância, o comando irá:

  1. Salve o JSON personalizado e faça o upload para o S3.

  2. Crie documentos de automação SSM para cada evento OpsWorks do ciclo de vida da camada e carregue os registros de execução dos documentos de automação no S3.

  3. Crie um AppRegistry aplicativo para todas as instâncias que serão desanexadas. O aplicativo tem um grupo de recursos associado que contém todas as instâncias e recursos separados. Os recursos incluem documentos de automação de SSM e parâmetros de SSM que contêm informações sobre eventos do ciclo de vida e receitas personalizadas do Chef.

  4. Separa o Classic Load Balancer da camada, se houver.

Esse comando modificará somente OpsWorks os recursos. O status das EC2 instâncias permanecerá o mesmo.

python3 layer_detacher.py detach \
--layer-id opsworks-layer-id \
--region opsworks-stack-region

Exemplo 3: Separar todas as instâncias de uma camada em lotes

O comando a seguir faz o mesmo que o exemplo anterior. A única diferença é que ele separa as instâncias em lotes.

Esse comando modificará somente OpsWorks os recursos. O status das EC2 instâncias permanecerá o mesmo.

python3 layer_detacher.py detach \
--layer-id opsworks-layer-id \
--region opsworks-stack-region \
--batch-size 5

Exemplo 4: Limpe todos os recursos de uma camada e exclua a camada

O comando a seguir repetirá todos os recursos de uma camada e os excluirá. Mais detalhadamente, ele interromperá e excluirá todas as instâncias OpsWorks e desconectará o balanceador de carga e cancelará o registro de instâncias EC2, elásticas e volumes do Amazon RDS. IPs Depois de limpar os recursos, a camada será excluída.

Esse comando excluirá OpsWorks recursos e EC2 instâncias. Se você quiser que suas EC2 instâncias permaneçam intocadas, use o detach comando antes de usar o cleanup comando. Dessa forma, o cleanup comando excluirá todos os recursos restantes.

python3 layer_detacher.py cleanup \
--layer-id opsworks-layer-id \
--region opsworks-stack-region

Exemplo 5: Limpe todos os recursos de uma pilha e exclua a pilha

O comando a seguir iterará em todas as camadas e, em seguida, nos recursos de cada camada. Para cada camada, o comando interromperá e excluirá todas as instâncias em OpsWorks e EC2, desconectará os balanceadores de carga e cancelará o registro de instâncias, elásticas e volumes do Amazon RDS. IPs Em seguida, o comando excluirá a camada. O mesmo processo será executado em todas as camadas pertencentes a essa pilha. Finalmente, depois que todas as camadas forem excluídas, a pilha será removida.

Esse comando excluirá OpsWorks recursos e EC2 instâncias. Se você quiser que suas EC2 instâncias permaneçam intocadas, use o detach comando antes de usar o cleanup comando. Dessa forma, o cleanup comando excluirá todos os recursos restantes.

python3 layer_detacher.py cleanup \
--stack-id opsworks-stack-id \
--region opsworks-stack-region

Etapa 4: continue operando seus recursos após se desconectar do OpsWorks

Depois de executar o detach comando, a ferramenta cria um novo AWS Service Catalog AppRegistry aplicativo correspondente à camada separada. O nome do aplicativo segue o formatolayer-name---layer-id. Ele também adiciona a OpsWorksLayerId tag para identificar de forma exclusiva o aplicativo correspondente à camada separada.

Para adicionar novos AWS recursos a esse aplicativo (por exemplo, novas EC2 instâncias), você pode fazer o seguinte:

  1. Marque o recurso com a tag de aplicativo exclusiva do AppRegistry aplicativo:

    Chave da tag: awsApplication

    Valor: arn:aws:resource-groups:region:account-id:group/application-name/application-id>

  2. Execute a associate-resourcecomando .

Além disso, para cada AppRegistry aplicativo, um grupo de recursos é criado. O Grupo de recursos contém as seguintes tags.

Chave de tag Valor

EnableAWSServiceCatalogAppRegistry

TRUE

aws:servicecatalog:applicationName

application-name

aws:servicecatalog:applicationId

application-id

aws:servicecatalog:applicationArn

arn:aws:servicecatalog:region:account-id:/applications/application-id

Executando tarefas após o desapego

A tabela a seguir fornece informações sobre como realizar tarefas após a separação:

Tarefa Descrição

Executando eventos do ciclo de vida

Depois de executar o detach comando e se você selecionou a opção, o script cria 5 documentos de automação que correspondem aos 5 eventos do OpsWorks ciclo de vida.

O nome de cada documento de automação segue este formato:layer-id_lifecycle-event_automation_document.

Para simular o OpsWorks comportamento no Systems Manager, você precisará acionar manualmente as execuções de automação ao provisionar, encerrar EC2 instâncias ou implantar/remover receitas.

Atualizando o JSON personalizado

O JSON personalizado para a pilha e a camada é armazenado em um bucket do S3 especificado durante a separação ou, alternativamente, em um novo bucket do S3 que é criado.

Os nomes dos arquivos armazenados para os arquivos JSON são os seguintes:

  • layercustomjson.json

  • stackcustomjson.json

Alterando sua lista de execução para eventos do ciclo de vida

A lista de execução para cada evento do ciclo de vida é definida no documento de automação correspondente. Para alterar a lista de execução, encontre os documentos de automação no AppRegistry aplicativo e modifique o RunList parâmetro.

O processo de atualização de receitas e livros de receitas permanece inalterado porqueAWS-ApplyChefRecipes, acionado pelos documentos de automação, suporta a mesma fonte de. OpsWorks

Gerenciando a recuperação automática/escalonamento automático

Quando você desanexa uma instância, o OpsWorks Agente é desinstalado. Sem o agente, OpsWorks não é possível reparar ou substituir automaticamente instâncias não íntegras, nem escalar automaticamente sua frota. Para continuar com o escalonamento automático e a substituição de instâncias com falha, crie um grupo Amazon EC2 Auto Scaling. O grupo lançará novas instâncias para manter a capacidade desejada quando a Amazon EC2 detectar instâncias insalubres que precisam ser substituídas.

Gerenciando o Load Balancer

Se sua camada usa um Classic Load Balancer, o detach comando o desanexará antes de cancelar o registro das instâncias. Isso é feito para garantir que todas as associações de instâncias do ELB permaneçam preservadas na Amazon EC2 durante todo o processo de separação, resultando em zero tempo de inatividade. Depois que o processo for concluído, você poderá gerenciar seu ELB em EC2.

Como estabelecer conexão com suas instâncias

Quando você executa o detach comando handle-prerequisites or, duas verificações ocorrem:

  • A versão do agente SSM e as permissões

  • Chaves SSH

Os comandos também oferecem a opção de atualizar o Agente SSM e adicionar as permissões necessárias para que você possa se conectar às instâncias usando o Gerenciador de Sessões. Se existirem chaves SSH, você também tem a opção de usar SSH na instância.

Usando a guia Systems Manager Application Manager Instances

Após a separação, você poderá visualizar e gerenciar suas instâncias na guia Instâncias do Application Manager.

A guia Instâncias fornece informações agregadas sobre as EC2 instâncias de um aplicativo, como status, estado de saúde e status do último comando. Usando essa guia, você pode visualizar informações detalhadas sobre instâncias individuais, como histórico de comandos, estados de alarme, integridade do agente do Systems Manager e muito mais. A guia Instâncias também fornece uma variedade de ações, como a capacidade de aplicar receitas do Chef, iniciar ou interromper uma instância ou adicionar ou remover uma instância de um grupo do Auto Scaling.