Continuar revertendo uma atualização
Às vezes, quando o CloudFormation tenta reverter uma atualização de pilha, ele não consegue reverter todas as alterações feitas durante o processo de atualização. Isso é chamado de estado UPDATE_ROLLBACK_FAILED
. 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.
Uma pilha no estado UPDATE_ROLLBACK_FAILED
não pode ser atualizada, mas pode ser revertida para um estado funcional (UPDATE_ROLLBACK_COMPLETE
). Após retornar a pilha às suas configurações originais, você pode 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)
Faça login no AWS Management Console e abra o console AWS CloudFormation em https://console.aws.amazon.com/cloudformation
. -
Na barra de navegação na parte superior da tela, escolha a Região da AWS em que a pilha está localizada.
-
Na página Pilhas, escolha a pilha que você deseja atualizar, escolha Ações da pilha e selecione Continuar reversão da atualização.
Se nenhuma das soluções no Solucionar de problemas de erros 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 oUpdateRollback
, 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:
. Se você deseja especificar o ID lógico de uma pilha de recursos (NestedStackName
.ResourceLogicalID
Type: AWS::CloudFormation::Stack
) na listaResourcesToSkip
então sua pilha incorporada correspondente deve estar em um dos seguintes estados:DELETE_IN_PROGRESS
,DELETE_COMPLETE
ouDELETE_FAILED
.
Para continuar revertendo uma atualização (AWS CLI)
-
Use o comando continue-update-rollback com a opção
--stack-name
para especificar o ID da pilha que você deseja continuar revertendo.
Continue revertendo de atualizações de pilhas aninhadas que falharam
Se você tiver várias pilhas aninhadas umas com as outras, talvez seja necessário pular recursos em vários níveis aninhados para que a hierarquia full-stack volte a funcionar.
Por exemplo, você tem uma pilha raiz chamada WebInfra
que contém duas pilhas menores dentro dela: WebInfra-Compute
e WebInfra-Storage
. Essas duas pilhas também têm suas próprias pilhas aninhadas dentro delas.
Se algo errado ocorrer durante uma atualização e o processo de atualização falhar, toda a hierarquia da pilha poderá acabar no estado UPDATE_ROLLBACK_FAILED
, conforme mostrado no diagrama a seguir.
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 colocar a pilha raiz em um estado operável usando o comando continue-update-rollback
, é necessário usar a opção --resources-to-skip
para ignorar os recursos que falharam na reversão.
O exemplo continue-update-rollback a seguir retoma uma operação de reversão de uma atualização de pilha anterior em que houve falha. Neste exemplo, a opção --resources-to-skip
inclui os seguintes itens:
-
myCustom
-
WebInfra-Compute-Asg.myAsg
-
WebInfra-Compute-LB.myLoadBalancer
-
WebInfra-Storage.DB
Para os recursos da pilha raiz, basta fornecer o ID lógico, por exemplo,
. No entanto, para os recursos contidos em pilhas aninhadas, é necessário fornecer o nome da pilha aninhada e seu ID lógico separados por um ponto. Por exemplo, myCustom
.WebInfra-Compute-Asg.myAsg
aws cloudformation continue-update-rollback --stack-name
WebInfra
\ --resources-to-skipmyCustom WebInfra-Compute-Asg.myAsg WebInfra-Compute-LB.myLoadBalancer WebInfra-Storage.DB
Para localizar o nome da pilha de uma pilha aninhada
É possível localizá-lo no ID da pilha ou no nome do recurso da Amazon (ARN) da pilha filha.
O exemplo de ARN a seguir refere-se a uma pilha chamada WebInfra-Storage-Z2VKC706XKXT
.
arn:aws:cloudformation:us-east-1:123456789012:stack/WebInfra-Storage-Z2VKC706XKXT/ea9e7f90-54f7-11e6-a032-028f3d2330bd
Para 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 filha WebInfra-Storage-DB
é DB
em sua pilha 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. Para ter mais informações, consulte Visualizar informações da pilha no console do CloudFormation.