--- title: "[driftctlに触れる] 漂流しているリソースを探せ！ | grasys blog" url: "https://blog.grasys.io/post/shirota/driftctl/" description: "はじめまして、shirotaです。 本記事では、 IaC（Infrastructure as Code）の利用で起こりうるドリフト(drift)という課題と、解決に役立つツール「driftctl」についてご紹介します。 IaCのメリットと課題 IaCとは、Infrastructure as Codeの略であり、日本語…" --- # \[driftctlに触れる\] 漂流しているリソースを探せ！ - ![](/_astro/noicon.CTHOhNiB_1HMs6A.webp)[shirota](/authors/shirota/) - 公開日：2023年12月19日 - カテゴリー：[Tech](/categories/tech/) - タグ：[#Google Cloud](/tags/google-cloud/)[#Infrastructure as Code](/tags/infrastructure-as-code/) ![\[driftctlに触れる\] 漂流しているリソースを探せ！](/_astro/hero.CaTi9t8b_JcgK3.webp) はじめまして、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を使用するためには、以下の設定[1](#user-content-fn-1)が必要になります。 - Google Asset APIの有効化 - Cloud Asset Viewerのロールの付与 driftctlをインストールする Macをお使いの場合、Homebrewで簡単にインストールすることができます。 Plain textcontent\_copy ``` brew install driftctl ``` ### 現在のFirewall Ruleを確認する 弊社の検証環境には現在、99個のFireWall Ruleが存在していました。 driftctlがスキャン時に使用する、Terraformのstateファイルの保存場所はローカルまたはGCSバケットを指定することができます。 今回は私個人のローカルを指定するため、この99個のFireWall Rule全てが管理できていないことになります。 Plain textcontent\_copy ``` gcloud compute firewall-rules list | sed '1d' | wc 99 594 27422 ``` ### Terraformでリソースを作成する。 検証用のFirewall RuleをTerraformで作成しました。 Plain textcontent\_copy ``` % 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が出来ました。 Plain textcontent\_copy ``` % 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」ファイルを作成して、それ以外のリソースを全てスキャン対象外に指定します。 Plain textcontent\_copy ``` #.driftignoreを作成して以下を記述する。 * !google_compute_firewall ``` ### スキャンを実行する Plain textcontent\_copy ``` driftctl scan --to gcp+tf --from tfstate://terraform.tfstate ``` デフォルトではAWSに対してスキャンを行うためフラグを使用してコマンドを実行します。 \[–to\]でGCPに対してのスキャンを指定、\[–from\]でローカルのstateファイルを読み込むように指定しています。 出力結果を見てみます。 Plain textcontent\_copy ``` 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です。 サポートするプロバイダーやリソースについては公式のドキュメントをご参照ください。[2](#user-content-fn-2) 最後までお読みいただき、ありがとうございました。 ## Footnotes 1. [https://docs.driftctl.com/0.40.0/providers/google/authentication](https://docs.driftctl.com/0.40.0/providers/google/authentication) [↩](#user-content-fnref-1) 2. [https://docs.driftctl.com/0.40.0](https://docs.driftctl.com/0.40.0) [↩](#user-content-fnref-2) ## この記事を書いた人 [![](/_astro/noicon.CTHOhNiB_Z24aAgM.webp)](/authors/shirota/) ### [shirota](/authors/shirota/) shirotaのプロフィールと執筆記事をご覧いただけます。 [プロフィールと記事一覧](/authors/shirota/)