DatadogのモニターをTerraformerでインポートして感じたことなど

この記事は Enigmo Advent Calendar 2022 の13日目の記事となります。

お疲れさまです。インフラチームの山口です。

弊社では一部インフラリソースのモニタリングにDatadogを利用しています。その中で、今回はDatadogの利用開始当初にGUIで作成されたモニターをTerraformerとTerraformを使用して構成管理した際の事例について報告します。

同様の技術スタックを使用したインポートや構成管理における具体的なテンプレート等の事例には事欠かないと思いますので、作業計画を中心に説明します。要は、TerraformerやTerraformの使い方は様々良い資料があると思うため、今回固有の対応をした点を注力して説明します。

本稿の構成を以下に記載します。まず、対象とするモニターの状態などの前提を説明します。次に、作業の流れを概説し、Terraformのディレクトリ構成等を少し説明します。そして最後にまとめます。

1. 前提

まず作業の目的と対象とするモニターについて説明します。

目的

GUIで人間が手で作成したモニターをTerraformで構成管理する。

対象とするモニター

構成管理の対象とするモニターの概要を以下に記載します。あるプロジェクトでのインフラリソースの監視のために手で作成されたモニター309件を対象とします。複数種類のインフラリソースの監視のためのモニター群ですが、当該プロジェクトであることを示すタグのみが付与された泥団子状態です。対象のモニターを、サーバロールごとのタグを付与した上で、ロールごとにmodule化し取り扱いをしやすくすることを目的とします。

モニター件数	特徴
309件	・インポート対象を識別できる特定のタグが付与されている(例: project: xxx といったタグのみ) ・モニターはRailsのWebサーバや、バッチサーバ、DBサーバといったインフラリソースの監視目的

2. 作業の概要

作業の概要について説明します。今回の対応は大きく2段階に分かれます。まず、STEP1としてインポート対象のモニターをTerrformerで一旦1つのtfファイルにインポートし、その後人手でサーバのロールを表すタグをモニターに付与しapplyすることで、泥団子状態を改善させます。

次に、STEP2として、サーバのロールごとに再度Terraformerでインポートし、tfファイルをリファクタリングしapplyを行います。

以降で各STEPの内容とポイントを説明します。

STEP1: 事前準備

STEP1では泥団子状態を脱することを最優先とします。そのため、一旦Terraformerでインポートした後に、人間が大雑把にモニターにタグを付与しapplyします。その際のポイントとしては、モニターによっては「どのようなタグを付与するべきか」悩むケースもあると思いますが、Terraformで管理可能になることで泥団子状態より悪くはならないため速度優先で「エイヤ」でタグを付与しapplyしてしまいます。

実際にタグの付与は私が作業したのですが、作業当時の記録を見ると10分で25%進んだと記録があり、1時間もかからずに思いの他早く済んでいたようです。

一旦既存のモニターをTerraformerで一括で1つのtfファイルにインポートする
tfファイルのモニターの内容を精査し、各モニターの用途(サーバロール)が判別可能なようなタグを人手で付与しapplyする

STEP2: サーバロール単位でのインポートとリファクタリング

以下をサーバロール数分繰り返します。端的には、Terraformerでインポートしたtfファイルの内容を人間が読みやすいように修正し、かつ意図しないリソース再作成なども発生しないようにtfstateも修正した上でapplyします。

特定のサーバロールのモニターをterrformerでインポート
tfファイルをリファクタリングしてapplyする

3. インポート後のディレクトリ構成や修正内容

インポート後のディレクトリ構成やTerraformerが自動生成した内容からの修正ポイントを説明します。本記事は、技術的な説明を主とする記事ではないため概要のみを簡単に記載します。

ディレクトリ構成

ディレクトリ構成を以下図に記載します。複数環境に対応可能なようmodule側に主なリソースを切り出して、そのmoduleを環境ごとに呼び出しモニターを作成する構成としています。

また、terraform workspace 等は使わずに愚直に環境・サーバロール単位でtfstateを分ける構成としています。リモートバックエンドも使わずに、原始的にtfstateをリポジトリにコミットします。これは、複数人で人海戦術的な方針で分担して作業する際にリモートバックエンドを操作するためのキーの設定やミスする可能性のある箇所を極力減らすことを念頭においたというのがもっともらしい言い訳ですが、実際は横着をしたためです。

tf、tfstateのリファクタリング

Terraformerでインポートした際にリファクタリングを行った観点を以下で箇条書します。

リソース名を人間が判読可能なものにする
- resource "datadog_monitor" "tfer--monitor_1234567" といった自動生成されたリソース名を人間が判別しやすいものに修正します。
1のリソース名の修正に伴いtfstateも修正する
- これは、モニターの場合は状態を持たないリソースのため特に再作成でも大きな問題は無いですが、リファクタリング時の修正差分等を terraform plan で確認したいために tfstateも修正し極力再作成を回避します。
ヒアドキュメントを使う
- Terraformerでインポートしたモニターは message が1行で可読性が良くないためヒアドキュメントを使うよう修正します。
まとめられるリソースはfor_eachでまとめる
- for_eachでまとめられるリソースは for_eachで複数作成します。その際の2との兼ね合いは状況を見て判断します(場合によっては再作成もやむなしとする)。