Чи можна змусити відновити EC2 :: Instance або RDS :: DBInstance в амазонській хмарній формі?

Можна змусити відновити екземпляр EC2 або RDS, використовуючи стеки хмарної інформації?

Мій стек застряг у точці, коли просто знищення та створення ресурсу виправить це, замість цього мені довелося видалити весь стек, щоб продовжувати роботу.

редагувати:

Це питання мене вразило двічі. Спочатку я створив AWS :: RDS :: Instance з деякими за замовчуванням, а потім спробував зменшити його до "EngineVersion": "5.5". Якщо це змінити, можливо, це відбудеться з деяким перериванням, але екземпляри mysql не можуть бути зменшені з 5,6 до 5,5, тому стек залишився в стані UPDATE_FAILED, і я не зможу відтворити RDS без неприємного фокусу.

Іншим явищем було те, що у мене є декілька "AWS :: EC2 :: Instance", який завантажує і виконує сценарій з його "UserData", очевидно, якщо Y змінити завантажений сценарій, я мушу повторити екземпляр, і немає способу зробити це. Ще раз я використовую той же неприємний трюк, щоб відтворити машину.

Неприємний трюк:

Замість того, щоб використовувати групу автоматичного масштабування на одній машині, я вирішив обидві проблеми, змінивши зону доступності у властивостях ... але залишив у мене поганий смак

Наприклад, підтримувані в магазині екземпляри EC2, одна хитрість полягає в тому, щоб додати коментар до сценарію даних про користувача, що містить номер версії, дату чи подібне, а потім змінити це, коли ви хочете відтворити екземпляр:

{
    "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 ...
                    ]]}
            }
        }
    }
}

Будь-яка зміна на UserDataпризведе до заміни примірника (тобто відновлення). Поведінка сценарію даних користувачів повинна бути однаковою, оскільки єдиною зміною є коментар. Зауважте, що це не працює для захищених EBS екземплярів.

Для RDS ви можете зробити знімок БД поточного екземпляра RDS, а потім змінити шаблон, щоб використовувати цей знімок із DBSnapshotIdentifier:

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

Щоразу, коли DBSnapshotIdentifierбуде змінено, екземпляр бази даних буде замінено. Використання знімків також дозволить зберегти дані, коли зроблено знімок. (Якщо ви хочете стерти дані, ви можете створити порожній знімок і передати його як введення. Або видалити та відтворити весь стек CloudFormation.)

Більш загальний підхід полягає у зміні логічної назви ресурсу. Від зміни шаблону стека в документах CloudFormation:

Для більшості ресурсів зміна логічного імені ресурсу еквівалентно видаленню цього ресурсу та заміні його новим. Будь-які інші ресурси, які залежать від перейменованого ресурсу, також потребують оновлення та можуть призвести до їх заміни. Інші ресурси вимагають оновити властивість (не лише логічне ім'я), щоб викликати оновлення.

Якщо ви помістите його в групу AutoScalingGroup, ви можете відредагувати min / max / за замовчуванням AutoScalingGroup до 0, а як тільки він почне знищувати старий екземпляр, ви можете потім поставити min / max / за замовчуванням до 1/1/1 і presto: новий екземпляр.

Якщо ваш EC2 перебуває в групі автоматичного масштабування, ви можете встановити AutoScalingGroupNameвластивість з номером версії.

Щоразу, коли ви зміните номер версії, CFN: 1. створить нову групу автоматичного масштабування та розпочнеть бажані екземпляри;

Ось фрагмент коду з мого стеку, де я використовую цю техніку, щоб змусити велику кількість машин EC2 відновлювати та автоматично витягувати нове програмне забезпечення з S3.

AutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
        AutoScalingGroupName: !Sub "${StackName}-${ServiceName}-${ServiceVersion}"