web-dev-qa-db-ja.com

Amazon cloudformationでEC2 :: InstanceまたはRDS :: DBInstanceの再作成を強制することは可能ですか？

Cloudformationスタックを使用して、EC2またはRDSインスタンスの再作成を強制することは可能ですか？

私のスタックは、単にリソースを破棄して作成するだけで修正できるところに行き詰まり、作業を続けるにはスタック全体を削除する必要がありました。

編集：

この問題は私を2回襲った。最初にAWS :: RDS :: Instanceをいくつかのデフォルトで作成し、それを "EngineVersion"： "5.5"にダウングレードしようとしました。これを変更すると、中断が発生する可能性がありますが、mysqlインスタンスを5.6から5.5にダウングレードできないため、スタックがUPDATE_FAILED状態のままになり、厄介なトリックなしではRDSを再作成できません。

もう1つは、「AWS :: EC2 :: Instance」がいくつかあり、「UserData」からスクリプトをダウンロードして実行することです。ダウンロードしたスクリプトを変更した場合、インスタンスを再作成する必要があり、その方法はありません。もう一度、同じ厄介なトリックを使用して、マシンを再作成します。

厄介なトリック：

1台のマシンの自動スケーリンググループを使用する代わりに、プロパティのアベイラビリティーゾーンを変更する両方の問題を解決しましたが、味が悪いままでした

amazon-ec2amazon-rdsamazon-cloudformation
17
theist

インスタンスストアでサポートされるEC2インスタンスの場合、1つのトリックは、バージョン番号、日付などを含むユーザーデータスクリプトにコメントを追加し、インスタンスを再作成するときに変更します。

{
    "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-backedインスタンスでは機能しないことに注意してください。

RDSの場合、現在のRDSインスタンスの DBスナップショット を取得し、DBSnapshotIdentifierでそのスナップショットを使用するようにテンプレートを変更できます。

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

DBSnapshotIdentifierが変更されるたびに、データベースインスタンスが置き換えられます。スナップショットを使用すると、スナップショットが作成されたときからのデータも保持できます。 （wantでデータを消去する場合、空のスナップショットを作成して入力として渡すことができます。または、CloudFormationスタック全体を削除して再作成することもできます。）

より一般的なアプローチは、リソースの論理名を変更することです。 CloudFormationドキュメントの スタックテンプレートの変更 から：

ほとんどのリソースでは、リソースの論理名を変更することは、そのリソースを削除して新しいものに置き換えることと同じです。名前が変更されたリソースに依存する他のリソースも更新する必要があり、リソースが置き換えられる可能性があります。その他のリソースでは、更新をトリガーするために、論理名だけでなくプロパティを更新する必要があります。

11
markusk

AutoScalingGroupに配置する場合は、AutoScalingGroupのmin/max/defaultを0に編集できます。その後、古いインスタンスが破棄され始めるとすぐに、min/max/defaultを1/1/1にして、 presto：新しいインスタンス。

1
Tim Bassett

EC2がAutoScalingGroupに属している場合は、AutoScalingGroupNameプロパティにバージョン番号を設定できます。

バージョン番号を変更するたびに、CFNは次のことを行います。1.新しい自動スケーリンググループを作成し、目的のインスタンスを起動します2.古い自動スケーリンググループのインスタンスを強制終了して削除します

これは私のスタックのコードの一部です。この手法を使用して、多数のEC2マシンに強制的にS3から新しいソフトウェアを再作成させ、自動的にプルします。

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