Amazon CodeCatalystでAWS環境を気軽にお掃除!「バルスボタン」を作ってみた

本記事は TechHarmony Advent Calendar 2024 12/23付の記事です

こんにちは。ひるたんぬです。

2024年も残すところ約1週間。今年も色々なことがありましたね。。
皆さんは年末年始をどのようにお過ごしになりますか?
昨年のとあるアンケートの結果によりますと、年末年始は「自宅・自宅周辺で過ごす」という方がおよそ6割だったようです。
しかも5年連続で最も多かったということなので、お家で過ごす年末年始が定番となりつつあるのですかね。
出典:日本生命保険相互会社「ニッセイ インターネットアンケート ~「2023年の振り返りと新年への期待」について~」

そんな年末年始に行うことの一例として、大掃除が挙げられるのではないでしょうか。
今回は、そんな大掃除の中でも「AWS環境における大掃除」を行う機会があったので、記事にしようと思います。

AWSにおける大掃除の定番ツール

家の大掃除に様々な便利ツールがあるように、AWSの大掃除にも目的や用途によって多種多様な大掃除ツールがあります。
例えば、AWS CloudFormationのスタックを何が何でも削除してくれる「delstack」、S3バケットの中身やバケット本体の削除を容易にする「cls3」など…

上記に挙げたツールはAWS HEROに選出された後藤さんが開発に携わられているようです!すごい…
参考:後藤さんの紹介記事
特定の用途において使えるツールもとても魅力的ですが、今回は何でも消しちゃうよ!!でおなじみの「aws-nuke」を使ってみようと思います。
aws-nukeについては初代Jr. Championsの方々も多く記事を執筆されています。
私も二代目としてその流れを継いだ…というのは後付けの理由です。
私が観測した初代Jr. Championsの皆様のaws-nukeに関する記事の一部
aws-nukeで作るマルチアカウントのお掃除機能
aws-nukeとBubbleで「リソース全削除ボタン」を作る

先人の知恵を借りてaws-nukeを使おう!…?

上記の通り、aws-nukeは既に多くの方が利用しており、日本語でも数多くの記事がありました。
それらの記事も参考にさせていただいていると、ほとんどの記事は下記GitHubのリポジトリのソースコードを使っていたので、「さすが有名なOSSだなぁ〜」と何気なく見てみることに。

…すると、上部に??と思う表記を見つけました。そう、「Public archive」です。
AWSは更新が活発である上、他のブログ記事ではこのaws-nukeも活発に更新が行われている…と思ったのでアーカイブなのはなにか妙だと思い読み進めると、

This repository for aws-nuke is no longer being actively maintained. We recommend users to switch to the actively maintained fork of this project at ekristen/aws-nuke. We appreciate all the support and contributions we’ve received throughout the life of this project. We believe that the fork will continue to provide the functionality and support that you have come to expect from aws-nuke. Please note that this deprecation means we will not be addressing issues, accepting pull requests, or making future releases from this repository. Thank you for your understanding and support.
引用元:README.md

なんとaws-nukeがフォークされ、以降はそちらでメンテナンス(更新など)がされると記載されております。
つまり、今まで多くの方が愛用されてきたrebuy-de氏によるaws-nukeはもう更新されることはなく、以降はekristen氏によるaws-nukeを使ってね!ということのようです。

Public archiveとなったのは 2024年10月15日です。

新しい「aws-nuke」

では、ekristen氏によるaws-nukeは何が変わったのでしょうか?
大きな内部の変化の一つとして「libnuke」という共通モジュールを使用するようになった点が挙げられます。
このlibnukeの開発にはrebuy氏、rebuy氏のaws-nukeの存在がなければできなかったようです。感慨深いですね…
libnukeの共通モジュールを用いることにより、AWSのリソース削除「aws-nuke」はもちろん、Azureのリソース削除「azure-nuke」が短期間で実装できたと書かれています。

Google Cloud向けの削除ツールについては現時点で開発中のようです。
参考:https://github.com/ekristen/gcp-nuke
使い方の観点で見た違いですが、こちらについては以下の記事で既に分かりやすくまとめられていましたので、参考記事として掲載させていただきます。

使ってみよう!!

というわけで早速使ってみました。
今回は偶然にも合法的に大掃除を許可された環境を提供されたので、そこで検証をしてみました。

AWS版「バルスボタン」をつくろう

「バルスコマンド」と言えばピンとくる方もいらっしゃるのでは無いでしょうか?

ご存じない方は是非検索してみてください。ただし興味深くても実行するのはおすすめしません。

今回は、手軽にAWS環境のお掃除(大掃除)ができるように、Amazon CodeCatalystのワークフローを用いて実装してみました。

Amazon CodeCatalystの本来の用途とは異なっているような気もしますが…私がAmazon CodeCatalyst好きなので。
以降で紹介するものはAWSの環境を大きく変更(破壊)しうるものが含まれます。
実際に使用される際には慎重に行ってください。私は責任を取れません。。
今回は新規プロジェクトを作成しました。
またSource repositoryも新規で作成し、その中にaws-nukeのconfigファイルを「nuke-config.yaml」という名前で配置します。ファイルの内容については下記公式ドキュメントを参考に、掃除したい範囲(リージョン)や種類(リソース)を記入してください。
なお、公式ドキュメントにはある程度整理された雛形もあるので、こちらをベースに作成しても良いと思います。
次にWorkflowです。こちらが今回のメインとなります。
内容としてはシンプルで、まず「nuke-dry-run」にて、削除候補のリソースを抽出します。
次にApprovalにてその内容を確認し、承認するかどうか判断します。
承認された場合は、「nuke-run」により、リソースの削除が実施される、といった流れとなっています。
このフローのYAMLファイルを以下に示します。
Name: Workflow_8340
SchemaVersion: "1.0"

# Optional - Set automatic triggers.
Triggers:
  - Type: Push
    Branches:
      - main

# Required - Define action configurations.
Actions:
  nuke-dry-run:
    # Identifies the action. Do not modify this value.
    Identifier: aws/build@v1.0.0
    # Specifies the source and/or artifacts to pass to the action as input.
    Inputs:
      # Optional
      Sources:
        - WorkflowSource # This specifies that the action requires this Workflow as a source
    Outputs:
      # Optional; Automatically discover reports for popular test frameworks
      AutoDiscoverReports:
        Enabled: true
        # Use as prefix for the report files
        ReportNamePrefix: rpt
    # Defines the action's properties.
    Configuration:
      # Required - Steps are sequential instructions that run shell commands
      Steps:
        - Run: nuke_ver=`curl -s
            https://api.github.com/repos/ekristen/aws-nuke/releases/latest | jq
            -r .tag_name`
        - Run: curl -L
            https://github.com/ekristen/aws-nuke/releases/download/${nuke_ver}/aws-nuke-${nuke_ver}-linux-arm64.tar.gz
            -o aws-nuke.tar.gz
        - Run: tar -zxvf aws-nuke.tar.gz
        - Run: ./aws-nuke nuke --config nuke-config.yaml --force --quiet | tee
            nuke-list.txt
      Container:
        Registry: CODECATALYST
        Image: CodeCatalystLinuxLambda_Arm64:2024_03
    Compute:
      Type: Lambda
      Fleet: Linux.Arm64.Large
    Environment:
      Name: cleanup-resource-env
  Approval:
    # Identifies the action. Do not modify this value.
    Identifier: aws/approval@v1
    Configuration:
      ApprovalsRequired: 1
    DependsOn:
      - nuke-dry-run
  nuke-run:
    Identifier: aws/build@v1.0.0
    Inputs:
      Sources:
        - WorkflowSource
    Outputs:
      AutoDiscoverReports:
        Enabled: true
        ReportNamePrefix: rpt
    Configuration:
      Steps:
        - Run: nuke_ver=`curl -s
            https://api.github.com/repos/ekristen/aws-nuke/releases/latest | jq
            -r .tag_name`
        - Run: curl -L
            https://github.com/ekristen/aws-nuke/releases/download/${nuke_ver}/aws-nuke-${nuke_ver}-linux-arm64.tar.gz
            -o aws-nuke.tar.gz
        - Run: tar -zxvf aws-nuke.tar.gz
        - Run: ./aws-nuke nuke --config nuke-config.yaml --force --quiet --no-dry-run |
            tee nuke-result.txt
      Container:
        Registry: CODECATALYST
        Image: CodeCatalystLinuxLambda_Arm64:2024_03
    Compute:
      Type: Lambda
      Fleet: Linux.Arm64.Large
    Environment:
      Name: cleanup-resource-env
    DependsOn:
      - Approval

Workflowを作成する際に工夫した点としては、以下の二点です。

  • 常に最新のaws-nukeバージョンを取得する点
    → GitHubのAPIよりバージョンの値が格納されているタグの情報を取得し、それをcurl先のURLに代入しています
  • aws-nukeの実行環境としてLambdaを選択している点
    → EC2での実行に比べ、スタートアップにかかる時間を大きく削減することができます

ということで…バルス!!!

実際に動かしてみました。今回はConfigファイルにてシンガポールリージョンに限定し検証をしました。
実際に削除候補は下記のようなログで確認が可能です。

確認し、問題なければ承認をします。これにより本番のバルスが始まります。
最終的に実行が完了し、WorkflowがSucceededになりました。

これだけで大掃除完了です。簡単ですね!!
以降はWorkflow上の「New run(通称:バルスボタン)」を押す、もしくはConfigファイルを更新してリポジトリにプッシュすることで簡単に実行することができます。

改善したい点

現在は削除するリソースの一覧をログから確認することしかできない状況です。
そのため、リソースの量が多くなってしまった場合、確認作業が大変になってしまいます。
承認プロセスなどで簡単に確認できるようにできれば…と思いましたが、現時点では実現が難しそうです。

おわりに

今回は、年末ということでデジタル空間の大掃除グッズをご紹介しました。
アナログ空間もデジタル空間もどちらもスッキリし、新年を迎えたいですね!

著者について

2024 Japan AWS Jr. Champions
ANGEL Dojo 2024 | ベストアーキテクチャ賞 2位

ひとこと:
同期に「おじさん」とよく言われます。なぜなのでしょうか…

Yusuke HIRUTAをフォローする

クラウドに強いによるエンジニアブログです。

SCSKクラウドサービス(AWS)は、企業価値の向上につながるAWS 導入を全面支援するオールインワンサービスです。AWS最上位パートナーとして、多種多様な業界のシステム構築実績を持つSCSKが、お客様のDX推進を強力にサポートします。

AWSクラウド
シェアする
タイトルとURLをコピーしました