sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

Systems Manager でスナップショット作成のついでにタグもつける

Systems Manager の便利さにやっと気がつきました、那須です。

Systems Manager ほんとにいいですね。今まで頑張って Lambda で作ってたものがコード書かずにできるのが嬉しいです。 例えばバックアップとか。AMI 作成とかスナップショット作成とかをよしなにやってくれます。

 

完璧ではなかった

一例ですが、Systems Manager Automation のドキュメントに AWS-CreateSnapshot というドキュメントがあります。 名前の通りで、EBS の ボリューム ID を指定すれば EBS スナップショットを取ってくれます。 ただこのドキュメント、実行すると確かに EBS スナップショットは作成してくれるんですが残念なんですよね…

スナップショット作成する対象のボリュームはこれなんですが
f:id:nasrinjp1:20180816141706p:plain

実際に AWS-CreateSnapshot Automation を実行してみると…
f:id:nasrinjp1:20180816133212p:plain

 

f:id:nasrinjp1:20180816135940p:plain:w150タグ全くついてないやん!!

でも安心してください! Systems Manager ドキュメントは JSONYAML で書かれているんです。ということは、自分で調整しちゃえばいいんですよ! Lambda みたいにがっつりコードを書くことなく、シンプルに運用自動タスクを実装できます(シンプルにできるかどうかは内容によります

 

AWS-CreateSnapshot でやってること

コンテンツを見てみると、大きく以下の流れになっています。

  1. CloudFormation スタックを作成する(中身は IAM ロール作成と Lambda 関数作成)
  2. Lambda 関数実行
  3. 確認して OK なら CloudFormation スタック削除

 

AWS で始まるドキュメントは編集できないのでドキュメント新規作成

ドキュメントを作成します。
f:id:nasrinjp1:20180816140624p:plain

ドキュメント名はただの名前なので好きにしてください。
コンテンツのところは、AWS-CreateSnapshot のコンテンツ内容をそのままコピペしてください。 まだ「ドキュメントの作成」ボタンは押しません。

 

コンテンツで変更するポイント(IAM ロール)

まずタグ付けするにも権限が必要です。一時的な IAM ロールを作成するところ(ec2: で検索するとすぐでてきます)で、下記の 3 つのアクションを追加します。

'ec2:DescribeTags', 'ec2:CreateTags', 'ec2:DescribeVolumes'

 

コンテンツで変更するポイント(Lambda 関数)

以下のスナップショットを作成するところで、

\\tsnapshot = volume.create_snapshot(Description=description)\\n\\n

こんな風にタグ付けする行を追加します。

\\tsnapshot = volume.create_snapshot(Description=description)\\n\\tsnapshot.create_tags(Tags=volume.tags)\\n

これだけです。必要に応じて try/catch 等の処理は入れてくださいね。 これでドキュメントの作成ボタンを押して完了です。

 

実行してみよう

こんな感じでステータスが成功になれば OK です!
f:id:nasrinjp1:20180816141341p:plain

スナップショットのコンソールでも確認してみましょう。作成された EBS スナップショットのタグを見ると…
f:id:nasrinjp1:20180816141455p:plain

ばっちりですね。

 

公開されているドキュメントを参考に自分好みのドキュメントを作ろう

いろんなドキュメントを見ていただければわかると思いますが、できることとできないことがなんとなく見えてきて、ここをこうすればたぶんできるな、みたいな感覚がつかめると思います。 環境によってやりたいことも異なると思うので、公開されているドキュメントを少しだけ変更して、自分の環境に適した Automation ドキュメントを作成して運用を少しでも楽にできるようにしていきましょう!

CloudFormation で作成したリソースの変更や削除の制御方法をまとめた

また json をガシガシ書く日が始まりそうです。那須です。

CloudFormation 便利ですね。ある程度決まった形の構成を作る時なんかはテンプレート準備しておけばすぐにその構成を作れます。 まあ作るのは簡単なんですが、更新や削除ってすでに運用に入っていると心理的にやりにくかったりしますよね。 たとえば、このリソースだけは絶対変更させたくない!とか、削除されたら困る!とか。

というわけで、CloudFormation で作成したリソースの更新や削除についてどんな制御ができるのか、自分の頭の整理を兼ねてまとめてみました。

 

スタックポリシーで更新&削除させない

docs.aws.amazon.com

スタック作成時にスタックポリシーを設定しておくと、指定された更新アクションができなくなります。 例えば、下記のように何も更新させないスタックポリシーを設定したとします。

{
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "Update:*",
            "Principal": "*",
            "Resource": "*"
        }
    ]
}

VPC で何か変更しようとすると…
f:id:nasrinjp1:20180815003102p:plain

そのまま進めると、スタックポリシーで拒否されてるよ!ってエラーが出てロールバックされます。
f:id:nasrinjp1:20180815003110p:plain

 

スタックポリシーを変更させない

docs.aws.amazon.com

じゃスタックポリシー変更しちゃえばいいんじゃないの?ということで、スタック更新時に一時的にスタックポリシーを上書きする場合があります。 これをやられたらダメな場合は、そのユーザに下記のような IAM ポリシーを適用しましょう。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "cloudformation:SetStackPolicy",
            "Resource": "*"
        }
    ]
}

その後、スタック更新の流れで、このようにスタックポリシーを設定します。
f:id:nasrinjp1:20180815003553p:plain

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "Update:*",
            "Principal": "*",
            "Resource": "*"
        }
    ]
}

するとスタックポリシーをいじることはダメ!とエラーがでます。
f:id:nasrinjp1:20180815003602p:plain

 

スタックを削除させない

docs.aws.amazon.com

スタックポリシーはスタック内のリソースが対象でしたが、CloudFormation はスタックそのものも削除できるのでこれも気をつけないとダメですね。 スタックポリシーでいくら削除アクションを拒否してたとしても、スタックそのものの削除に対しては無力です。

まず、スタックそのものを削除させたくない場合は、スタックの削除保護を有効にします。

削除保護の変更をクリックして
f:id:nasrinjp1:20180815002259p:plain

有効化します。
f:id:nasrinjp1:20180815002308p:plain

削除保護が有効になっているのがわかりますね。
f:id:nasrinjp1:20180815002317p:plain

削除保護が有効の場合は、スタックを削除しようとしてもこのように削除させてもらえません。
f:id:nasrinjp1:20180815002324p:plain

 

スタックの削除保護を変更させない

じゃあスタックの削除保護を無効にしてしまえばいいよね?ってことで、削除保護設定を変更されるとスタックを削除されてしまう可能性がありますよね。 それを防ぐために、IAM ポリシーで削除保護の設定変更を下記のように制御します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "cloudformation:UpdateTerminationProtection"
            ],
            "Resource": "*"
        }
    ]
}

この IAM ポリシーがついているユーザで削除保護の設定を変更しようとすると、このようなエラーになって削除保護設定を変更できなくなります。
f:id:nasrinjp1:20180815002813p:plain

 

スタックが削除されてしまってもリソースは削除しない

docs.aws.amazon.com

ラクルが起きてスタック削除されてしまう可能性はないの?本当に!?と心配な方もいらっしゃるかと思います。 私もわりと心配性なので、可能性は0ですよ!って言い切る自信はまあないです。 そんな方のために DeletionPolicy があります。

例えば NACL で絶対守らせたい内容があって、それだけは削除させたくない!って場合は、下記例のように "DeletionPolicy" : "Retain" を対象リソースに追加しておきます。全部削除されたくないなら、全リソースに追加するだけです。

{
    "Type": "AWS::EC2::NetworkAcl",
    "DeletionPolicy" : "Retain",
    "Properties": {
        "VpcId": {
            "Ref": "VPC"
        },
        "Tags": [
            {
                "Key": "Name",
                "Value": "mecha-daiji"
            }
        ]
    }
}

 

頻繁に更新や削除を制御する場面はないかもしれないけど

知らないより知ってた方がいざという時にすぐ対応できるのでいいですよね。