Можно ли форсировать воссоздание EC2 :: Instance или RDS :: DBInstance в облачном образовании амазонки?

16

Можно ли принудительно создать экземпляр EC2 или RDS, используя стеки облачной информации?

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

редактировать:

Этот вопрос ударил меня дважды. Сначала я создал AWS :: RDS :: Instance с некоторыми значениями по умолчанию, а затем попытался понизить его до «EngineVersion»: «5.5». Изменение этого параметра может произойти с некоторым прерыванием, но экземпляры mysql не могут быть понижены с 5.6 до 5.5, поэтому стек остался в состоянии UPDATE_FAILED, и я не могу восстановить RDS без неприятного трюка.

Другим случаем было то, что у меня есть несколько «AWS :: EC2 :: Instance», которые загружают и выполняют сценарий из его «UserData», очевидно, если Y изменит загруженный сценарий, я должен будет восстановить экземпляр, и нет никакого способа сделать это. Я снова использую ту же неприятную уловку, чтобы воссоздать машину.

Гадкий трюк:

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

amazon-ec2 amazon-rds amazon-cloudformation

— теист
источник

Нужно больше информации, чтобы ответить. Ваши экземпляры зависают при запуске? Служба перестает отвечать на запросы? Если вы хотите вручную создать экземпляр EC2, вы можете создать группу автоматического масштабирования с одним экземпляром. Когда вы прекратите работу экземпляра, будет создан другой.

— Эдвин

отредактировано для уточнения. Я также спросил здесь: forums.aws.amazon.com/thread.jspa?threadID=135295&tstart=0

— теист

Это не дает прямого ответа на ваш вопрос, но для повторного запуска сценариев UserData при изменении вы можете заглянуть в cfn-hup: docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/…

— Рид Крафт-Мерфи

10

Для экземпляров 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:

Для большинства ресурсов изменение логического имени ресурса эквивалентно удалению этого ресурса и замене его новым. Любые другие ресурсы, которые зависят от переименованного ресурса, также должны быть обновлены и могут привести к их замене. Другие ресурсы требуют обновления свойства (а не только логического имени) для запуска обновления.

— markusk
источник

Кажется, что единственное решение состоит в том, чтобы делать «грязные трюки». Я пришел к аналогичному решению (форсировать изменения зон доступности) через некоторое время после запроса :)

— theist

4

Просто хочу указать, что экземпляр заменен и, следовательно, UserData выполняется, когда экземпляр EC2 хранится в хранилище экземпляра. Если он поддерживается EBS, изменение UserData приведет только к перезапуску экземпляра, и UserData не будет выполнен снова. Вы можете использовать cfn-hup для повторного запуска UserData даже в этом случае, но экземпляр остается прежним.

— Каитсу

@Kaitsu: Спасибо, это очень ценное разъяснение. Я обновил свой ответ соответственно.

— Markusk

@Kaitsu, но если вы перезапустите скрипт вручную (находится в / var / lib / cloud / instance / scripts / part-001), вы должны убедиться, что скрипт

— защищает

1

Если вы поместите его в AutoScalingGroup, вы можете отредактировать AutoScalingGroup min / max / default на 0, затем, как только он начнет уничтожать старый экземпляр, вы можете установить min / max / default на 1/1/1 и Presto: новый экземпляр.

— Тим Бассетт
источник

0

Если ваш EC2 входит в AutoScalingGroup, вы можете установить AutoScalingGroupNameсвойство с номером версии в нем.

Каждый раз, когда вы меняете этот номер версии, CFN будет: 1. создавать новую группу автоматического масштабирования и раскручивать нужные экземпляры 2. убивать экземпляры в старой группе автоматического масштабирования и удалять ее

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

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

— marcopeg
источник