[driftctlに触れる] 漂流しているリソースを探せ！

はじめまして、shirotaです。

本記事では、 IaC（Infrastructure as Code）の利用で起こりうるドリフト(drift)という課題と、解決に役立つツール「driftctl」についてご紹介します。

IaCのメリットと課題

IaCとは、Infrastructure as Codeの略であり、日本語では「インフラのコード化」や「コードとしてのインフラ」と訳されることが多く、サーバーやネットワーク機器などのインフラ・リソースをコードで定義して構築・運用・管理を行うことを指します。

コードの作成に使用する言語はIaCツールによって異なります。grasysブログでもお馴染みのTerraformではHCLという独自の言語を使用します。(本記事ではHCLの詳しい説明は省略します。)

メリット

コードで定義するメリットには、

• テンプレートを利用して標準化ができる
• 作成したリソースの再利用が容易である
• ワークフローに組み込み自動化することができる

などが挙げられます。

課題

このようなメリットがある反面、運用する上では注意が必要です。
それは、コードでの管理状況とリソースの実態に差異が発生してしまうことがあるからです。

例えばクラウド上に構築したリソースにおいて、このような差異が生じる原因は、

1. クラウドのコンソール(ブラウザで表示する管理画面)からリソースの作成を行っていたために、コードで定義したファイルが存在しない
2. コードで管理しているリソースの設定にコンソールから変更を行ったために、定義内容とリソースの設定に差分が発生している

などが考えられます。

このような事象はドリフト(drift)と呼ばれます。
辞書をひくとdriftには「漂流する、吹き流される」という意味が載っておりました。
なるほど、リソースが手元の管理から離れて流されてしまっているイメージでしょうか。

このような課題にはどのように対応すればよいでしょうか。
今回はdriftctlというツールに触れてみます。

driftctlとは

driftctlは、コード管理ができていないリソースを教えてくれるソフトウェアです。
AWS, GitHub, Google, Azureのプロバイダーをサポートしており、クラウド上のリソースとTerraformでの管理状況において、ドリフトが発生しているリソースを検知してくれます。

driftctl は、コード カバレッジとしてインフラストラクチャを測定し、インフラストラクチャ ドリフトを追跡する CLI ツールです。

(※日本語訳にはブラウザの自動翻訳機能を使用しています。)

公式WEBページのIntroductionより　

ここからはGoogle CloudのFirewall Ruleでドリフトが発生している場合を想定して、driftctlを試してみようと思います。

Google Cloudで利用するにあたって

Google Cloudでdriftctlを使用するためには、以下の設定¹が必要になります。

• Google Asset APIの有効化
  
• Cloud Asset Viewerのロールの付与

driftctlをインストールする

Macをお使いの場合、Homebrewで簡単にインストールすることができます。

brew install driftctl

現在のFirewall Ruleを確認する

弊社の検証環境には現在、99個のFireWall Ruleが存在していました。
driftctlがスキャン時に使用する、Terraformのstateファイルの保存場所はローカルまたはGCSバケットを指定することができます。
今回は私個人のローカルを指定するため、この99個のFireWall Rule全てが管理できていないことになります。

gcloud compute firewall-rules list | sed '1d' | wc
      99     594   27422

Terraformでリソースを作成する。

検証用のFirewall RuleをTerraformで作成しました。

 % gcloud compute firewall-rules list | grep shirota-fw

To show all fields of the firewall, please show in JSON format: --format=json
To show all fields in table format, please see the examples in --help.

shirota-fw                                        default                   INGRESS    1000      tcp:80,tcp:22

記念すべき100個目のFirewall Ruleが出来ました。

% gcloud compute firewall-rules list | sed '1d' | wc

To show all fields of the firewall, please show in JSON format: --format=json
To show all fields in table format, please see the examples in --help.

     100     600   27699

こうして、Terraformで管理できているリソース1個と、管理できていないリソース99個がある状況ができました。
めっちゃドリフトしている状況です。

スキャン対象のリソースを絞る

今回調査したいのはFirewall Ruleのみのため「.driftignore」ファイルを作成して、それ以外のリソースを全てスキャン対象外に指定します。

#.driftignoreを作成して以下を記述する。
*
!google_compute_firewall

スキャンを実行する

driftctl scan --to gcp+tf --from tfstate://terraform.tfstate

デフォルトではAWSに対してスキャンを行うためフラグを使用してコマンドを実行します。
[–to]でGCPに対してのスキャンを指定、[–from]でローカルのstateファイルを読み込むように指定しています。

出力結果を見てみます。

Found 100 resource(s)
 - 1% coverage
 - 1 resource(s) managed by Terraform
 - 99 resource(s) not managed by Terraform
 - 0 resource(s) found in a Terraform state but missing on the cloud provider
Scan duration: 22s
Provider version used to scan: 5.8.0. Use --tf-provider-version to use another version.

分かりやすいですね。
省略していますが、管理されていないリソース名の一覧も表示されます。
何が管理されていないのかを明確にすることで、改善に役立てることができそうです。

まとめ

今回、実際に触れてみてインストール〜スキャンの実行までのお手軽さが印象的でした。
同時にリソース管理状況の棚卸を目的に導入しやすいツールであるとも感じました。
スキャン実行時にFilterフラグを用いてリソースのフィルタリングもできるようなので、色々と試してみたいです。
cronで定期的に実行→レポートをSlackに通知とかも構築できたら便利そう。

なお今回ブログの中で使用したdriftctlのバージョンは0.40.0です。
サポートするプロバイダーやリソースについては公式のドキュメントをご参照ください。²
最後までお読みいただき、ありがとうございました。

1. https://docs.driftctl.com/0.40.0/providers/google/authentication ↩︎
2. https://docs.driftctl.com/0.40.0 ↩︎