Continuar revertendo uma atualização - AWS CloudFormation

Continuar revertendo uma atualização

Uma pilha vai para o estado UPDATE_ROLLBACK_FAILED quando o AWS CloudFormation não pode reverter todas as alterações durante uma atualização. Por exemplo, é possível ter uma pilha que começa a reverter para uma instância antiga de banco de dados que foi excluída fora do CloudFormation. Como o CloudFormation não sabe que o banco de dados foi excluído, ele pressupõe que a instância de banco de dados ainda existe e tenta reverter para ela, fazendo com que a atualização de reversão falhe.

Quando uma pilha está no estado UPDATE_ROLLBACK_FAILED, é possível continuar a revertê-la a um estado operacional (UPDATE_ROLLBACK_COMPLETE). Não é possível atualizar uma pilha que está no estado UPDATE_ROLLBACK_FAILED. No entanto, se você pode continuar a revertê-la, é possível retornar a pilha para as configurações originais e, em seguida, tentar atualizá-la novamente.

Na maioria dos casos, é necessário corrigir o erro que faz com que a atualização de reversão falhe antes de continuar a reverter sua pilha. Em outros casos, é possível continuar a reverter a atualização sem qualquer alteração, por exemplo, quando uma operação de pilha expira.

nota

Se você usa pilhas aninhadas, ao reverter a pilha pai, ela tentará reverter todas as pilhas filhos.

Para continuar revertendo uma atualização (console)

  1. Abra o console do AWS CloudFormation em https://console.aws.amazon.com/cloudformation.

  2. Selecione a pilha que você deseja atualizar, escolha Stack actions (Ações da pilha) e selecione Continue update rollback (Continuar reversão da atualização).

    Se nenhuma das soluções no guia de solução de problemas funcionou, é possível usar a opção avançada para ignorar os recursos que o CloudFormation não pode reverter com êxito. É necessário examinar e digitar os IDs lógicos dos recursos que você deseja ignorar. Especifique somente os recursos que entraram no estado UPDATE_FAILED durante o UpdateRollback e não durante a atualização.

    Atenção

    O CloudFormation define o status dos recursos especificados como UPDATE_COMPLETE e continua a reverter a pilha. Após a reversão ser concluída, o estado dos recursos ignorados será inconsistente com o estado dos recursos no modelo de pilha. Antes de executar outra atualização da pilha, é necessário atualizar a pilha ou os recursos para que sejam consistentes entre si. Caso contrário, as atualizações de pilha subsequentes podem falhar e a pilha se tornará irrecuperável.

    Especifique o número mínimo de recursos exigidos para reverter sua pilha com êxito. Por exemplo, uma falha na atualização de recursos pode fazer com que os recursos dependentes falhem. Neste caso, não será necessário ignorar os recursos dependentes.

    Para ignorar recursos que são parte de pilhas aninhadas, use o seguinte formato: NestedStackName.ResourceLogicalID. Se você deseja especificar o ID lógico de uma pilha de recursos (Type: AWS::CloudFormation::Stack) na lista ResourcesToSkip então sua pilha incorporada correspondente deve estar em um dos seguintes estados: DELETE_IN_PROGRESS, DELETE_COMPLETE ou DELETE_FAILED.

Para continuar revertendo uma atualização (AWS CLI)

Usar o ResourcesToSkip para recuperar uma hierarquia de pilhas aninhadas

O diagrama a seguir mostra uma hierarquia de pilhas aninhadas no estado UPDATE_ROLLBACK_FAILED. Neste exemplo, a pilha de raiz WebInfra tem duas pilhas aninhadas: WebInfra-Compute e WebInfra-Storage, que, por sua vez, tem uma ou mais pilhas aninhadas.


        Um diagrama que mostra uma hierarquia de três níveis de pilhas aninhadas.
nota

Os nomes das pilhas neste exemplo são truncados para simplicidade. Os nomes das pilhas filhos geralmente são gerados pelo CloudFormation e contêm strings aleatórias exclusivas, de forma que os nomes reais podem não ser acessíveis.

Para obter a pilha de raiz com êxito em um estado operável usando continue-update-rollback, é necessário usar o parâmetro resources-to-skip para ignorar os recursos que falharam na reversão. Neste exemplo, resources-to-skip deverá incluir os seguintes itens:

  1. myCustom

  2. WebInfra-Compute-Asg.myAsg

  3. WebInfra-Compute-LB.myLoadBalancer

  4. WebInfra-Storage.DB

O exemplo a seguir é o comando da AWS CLI completo:

PROMPT> aws cloudformation continue-update-rollback --stack-name WebInfra --resources-to-skip myCustom WebInfra-Compute-Asg.myAsg WebInfra-Compute-LB.myLoadBalancer WebInfra-Storage.DB

Observe que especificamos recursos de pilhas aninhadas usando o formato NestedStackName.ResourceLogicalID, mas para os recursos da pilha de raiz, como o myCustom, especificamos apenas o ID lógico.

Localizar o nome da pilha de uma pilha aninhada

É possível encontrar o nome de uma pilha filho em seu ID de pilha ou no nome de recurso da Amazon (ARN). No exemplo a seguir, o nome da pilha é WebInfra-Storage-Z2VKC706XKXT:

arn:aws:cloudformation:us-east-1:123456789012:stack/WebInfra-Storage-Z2VKC706XKXT/ea9e7f90-54f7-11e6-a032-028f3d2330bd

Localizar o ID lógico de uma pilha aninhada

É possível encontrar o ID lógico de uma pilha filho na definição do modelo de seu pai. No diagrama, o LogicalId da pilha filho WebInfra-Storage-DB está no banco de dados de seu pai WebInfra-Storage.

No console do CloudFormation, também é possível encontrar o ID lógico na coluna ID lógico para o recurso de pilha nas guias Recursos ou Eventos.