É possível forçar a recriação de EC2 :: Instance ou RDS :: DBInstance em cloudformation amazon?

13

É possível forçar a recriação de uma instância do EC2 ou do RDS usando pilhas de cloudformation?

Minha pilha fica presa em um ponto em que simplesmente destruir e criar o recurso consertará, em vez disso eu tive que deletar toda a pilha para continuar o trabalho.

editar:

Esse problema me bateu duas vezes. Primeiro criei um AWS :: RDS :: Instance com alguns padrões e tentei fazer o downgrade para "EngineVersion": "5.5". Mudar isto é suposto acontecer com alguma interrupção, mas instâncias do mysql não podem ser rebaixadas de 5.6 para 5.5, então a pilha foi deixada no estado UPDATE_FAILED e eu não consigo recriar o RDS sem um truque desagradável.

A outra ocorrência foi que eu tenho vários "AWS :: EC2 :: Instance", que baixa e executa um script a partir do seu "UserData", obviamente, se Y alterar o script baixado, devo recrutar a instância, e não há como fazer assim. Mais uma vez eu uso o mesmo truque desagradável para recriar a máquina.

O truque desagradável:

Em vez de usar um grupo de autoescala de uma máquina, resolvi os dois problemas alterando a zona de disponibilidade nas propriedades ... mas deixei-me com um gosto ruim

    
por theist 18.09.2013 / 17:35

3 respostas

10

Por exemplo, instâncias do EC2 com backup de loja, um truque é adicionar um comentário ao script de dados do usuário contendo um número de versão, data ou similar e, em seguida, alterá-lo sempre que desejar que a instância seja recriada:

{
    "Resources" : {
        "MyEC2Instance" : {
            "Type" : "AWS::EC2::Instance",
            "Properties" : {
                // ... other properties ...
                "UserData": { 
                    "Fn::Base64" : {
                        "Fn::Join" : [ ":", [
                        "#!/bin/bash\n",
                        "# Version: 1.0\n",
                        // ... rest of user data ...
                    ]]}
            }
        }
    }
}

Qualquer alteração em UserData fará com que a instância seja substituída (ou seja, regenerada). O comportamento do script de dados do usuário deve ser o mesmo, no entanto, já que a única modificação é um comentário. Observe que isso não funciona para instâncias apoiadas pelo EBS.

Para o RDS, você pode fazer um instantâneo de banco de dados da instância atual do RDS, em seguida, modifique seu modelo para usar esse instantâneo com DBSnapshotIdentifier :

{
    "Resources" : {
        "MyDB" : {
        "Type" : "AWS::RDS::DBInstance",
        "Properties" : {
            // ... other properties ...
            "DBSnapshotIdentifier": "<db snapshot ID>"
        }
    }    
}

Sempre que DBSnapshotIdentifier for alterado, a instância do banco de dados será substituída. O uso de instantâneos também permitirá que você mantenha os dados de quando a captura instantânea foi feita. (Se você quiser limpar os dados, poderá criar um instantâneo vazio e passá-lo como entrada. Ou excluir e recriar toda a pilha do CloudFormation.)

Uma abordagem mais genérica é alterar o nome lógico do recurso. De Modificando um modelo de pilha no CloudFormation docs:

For most resources, changing the logical name of a resource is equivalent to deleting that resource and replacing it with a new one. Any other resources that depend on the renamed resource also need to be updated and might cause them to be replaced. Other resources require you to update a property (not just the logical name) in order to trigger an update.

    
por 27.07.2015 / 08:38
1

Se você colocá-lo em um AutoScalingGroup, você pode editar o AutoScalingGroup min / max / default para 0, então assim que ele começar a destruir a instância antiga, você pode colocar o min / max / default em 1/1 / 1 e pronto: nova instância.

    
por 06.02.2016 / 03:05
0

Se o seu EC2 estiver em um AutoScalingGroup, você poderá definir a propriedade AutoScalingGroupName com um número de versão.

Toda vez que você alterar esse número de versão, o CFN irá: 1. crie um novo grupo de escalonamento automático e gire as instâncias desejadas 2. matar instâncias no antigo grupo de escalonamento automático e excluí-lo

Aqui está uma parte do código da minha pilha onde eu uso essa técnica para forçar um grande número de máquinas EC2 a recriar e extrair automaticamente novos softwares da S3.

AutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
        AutoScalingGroupName: !Sub "${StackName}-${ServiceName}-${ServiceVersion}"
    
por 29.03.2018 / 13:11