1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Glacier Expressヤクの毛刈り(CloudFormation CLI tool) メモ (2018/02/03) (未整理)

Last updated at Posted at 2018-02-04
  • Glacier Expressのヤクの毛刈りとしてCloudFormation 用のCLI toolの作成を行う
  • ただ、現状ではTool の作成どころか設計のための情報も足りず、検証段階と言える
  • 今日の検証はStackのイベントの追跡
    • いままでの検証で
    • describe_stack_eventsで追跡できそうなことはわかったため、更に検証を進めた
  • 結果としては順調に情報の取得ができた
  • イベントは時系列(降順)で取得できる
  • next_tokenで次の以降のイベントに限って取得できると考えたが、実際には"一定以上イベントが積み重なっている場合のPagerである"ことが判明したあまり使用することは想定されない
    • アウトプットが1MBを超えたときに使用する
    • カウント方法が分からないためなんとも言えないが1MBはレスポンスとしては非常に大きいため当面は対応する必要はないように感じる
  • ただ、イベントすべてを取得するため、今回適用分以外も表示されると考えた方が良い
  • client_request_tokenをeventの情報の要素に見つける、これなら今回適用分のみ判別することに使えるかもしれない
  • 再度試行してみるも、client_request_tokenの値が空白(null or 空文字列)であった
  • API Referenceを再度確認すると、どうもclient_request_token はcreate-stackを行う際に指定するようだ。
  • 指定してみたところその文字列が表示された。
  • さて、ではイベント取得の終了条件について考えてみることにする
  • create, update, delete、それぞれを確認してみたところ、どの変更であったとしても最初と最後のイベントは論理IDはstack_nameと同じものとなっている
  • そのため論理IDとステータスを見張れば終了がわかると考える
  • 試行してみたところ概ね成功
    • ただし、削除の場合は失敗
      • どうもDELETE_COMPLETEはstack_nameが論理IDの場合はない模様
      • 終了はスタックが存在するかどうかで判断する必要があるらしい
    • あと実際にはstack_nameだけじゃなくてリソースタイプがAWS::CloudFormation::Stackであるかも条件に加えた方がいいと思われる
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?