トップ > New Relic > AWS CodePipelineでNew Relic監視設定を自動展開する - Terraform実装ガイド

AWS CodePipelineでNew Relic監視設定を自動展開する - Terraform実装ガイド

New Relic Terraform CI/CD DevOps AWS CodePipeline AWS CodeBuild
記事タイトルとURLをコピーする

みなさんこんにちは。マネージドサービス部MS課の塩野（正）です。

この記事では、AWS CodePipelineとCodeBuildを使ってNew Relic監視設定を自動展開する方法を解説します。GitHubへのマージをトリガーに、CodePipelineが起動してterraform planとapplyを順次実行する仕組みを構築します。

実装後は、アラート設定やダッシュボードの変更をコードで管理でき、AWS環境と統合した形で安全に本番環境へ展開できるようになります。GitHub ActionsとAWS CodePipelineの比較については前回の記事をご確認ください。

blog.serverworks.co.jp

目次

前提条件

  • AWSアカウント
  • GitHubアカウント
  • New Relicアカウント
  • Terraformの基本知識

事前準備

必要なもの

実装を始める前に、以下を準備します。

GitHubリポジトリ

Terraformコードを管理するリポジトリを作成します。既存のリポジトリを使う場合は、専用のディレクトリを作成すると管理しやすいでしょう。

New Relic APIキー

New Relicの管理画面から、User APIキーを取得します。APIキーは「User」タイプを選択し、適切な権限を付与してください。

AWSリソース

以下のAWSリソースを準備します。

  • S3バケット（tfstate保存用）
  • Secrets Manager（New Relic APIキー保存用）
  • IAMロール（CodeBuild用）

ディレクトリ構成

推奨するディレクトリ構成は以下の通りです。

.
├── terraform/
│   ├── main.tf
│   ├── variables.tf
│   └── alert.tf
└── buildspec.yml

Terraformコードはterraform/ディレクトリにまとめ、CodeBuildの設定はbuildspec.ymlに記述します。

Terraformコードの準備

Provider設定

New Relic Providerを設定します。APIキーは環境変数から取得する形にしておきます。

また、Provider設定でS3バケットをバックエンドとしての設定も実施します。環境ごとに異なる設定を使用できるよう、buildspec.ymlで環境変数を使って動的に設定します。

ここではbackendブロックのみを記述しますが、backend設定の詳細は terraform initコマンド実行時に-backend-configオプションで指定します。この方法により、環境ごとに異なるS3バケットやキーを使い分けられます。

terraform {
  required_version = ">= 1.8.0"
  required_providers {
    newrelic = {
      source  = "newrelic/newrelic"
      version = "~> 3.0"
    }
  }
  backend "s3" {}
}

provider "newrelic" {
  account_id = var.newrelic_account_id
  api_key    = var.newrelic_api_key
  region     = "US"
}

Variables設定

variables.tfファイルで必要な変数を定義します。

variable "newrelic_account_id" {
  description = "New Relic Account ID"
  type        = string
  sensitive   = true
}

variable "newrelic_api_key" {
  description = "New Relic User API Key"
  type        = string
  sensitive   = true
}

これらの変数は、CodeBuildのbuildspec.ymlでTF_VAR_プレフィックス付きの環境変数として設定されます。

アラート設定の例

シンプルなアラート設定の例です。

resource "newrelic_alert_policy" "example" {
  name = "Example Alert Policy"
}

resource "newrelic_nrql_alert_condition" "high_cpu_usage" {
  policy_id = newrelic_alert_policy.example.id
  name      = "High CPU Usage"
  enabled   = true

  nrql {
    query = "SELECT average(host.cpuPercent) FROM Metric"
  }

  critical {
    operator              = "above"
    threshold             = 80
    threshold_duration    = 300
    threshold_occurrences = "all"
  }
}

この例では、CPU使用率が80%を超えた状態が5分間続いた場合にアラートが発生します。実際の運用では、サーバーの特性に合わせて閾値を調整してください。

AWSリソースの準備

S3バケット作成

tfstate保存用のS3バケットを作成します。

1. S3コンソールを開く

AWSコンソールから「S3」を検索して選択します。

2. バケットの作成

  • 「バケットを作成」をクリック
  • バケット名: your-terraform-state-bucket（グローバルで一意の名前を指定）
  • AWSリージョン: アジアパシフィック（東京）ap-northeast-1
  • 「オブジェクト所有者」: デフォルトのまま（ACL無効）
  • 「このバケットのブロックパブリックアクセス設定」: すべてチェック（パブリックアクセスをブロック）

3. バージョニングと暗号化の有効化

  • 「バケットのバージョニング」セクションで「有効にする」を選択
  • 「デフォルトの暗号化」セクションで「有効にする」を選択
  • 暗号化タイプ: 「Amazon S3 マネージドキー (SSE-S3)」を選択
  • その他の設定はデフォルトのまま
  • 「バケットを作成」をクリック

バージョニングを有効化しておくと、万が一の際にtfstateファイルをロールバックできます。暗号化により、tfstateファイルに含まれる機密情報が保護されます。

Secrets Managerへのキー登録

New Relic APIキーとアカウントIDをSecrets Managerに登録します。

1. Secrets Managerコンソールを開く

AWSコンソールから「Secrets Manager」を検索して選択します。

2. シークレットの作成

  • 「新しいシークレットを保存」をクリック
  • シークレットのタイプ: 「その他のシークレットのタイプ」を選択
  • キー/値のペア: 「プレーンテキスト」タブを選択
  • 以下のJSON形式で入力します
{
  "NEWRELIC_API_KEY": "YOUR_NEWRELIC_API_KEY",
  "NEWRELIC_ACCOUNT_ID": "YOUR_NEWRELIC_ACCOUNT_ID"
}
  • 暗号化キー: デフォルトのまま（aws/secretsmanager）
  • 「次へ」をクリック

3. シークレット名の設定

  • シークレット名: NewRelicSecretKey
  • 説明: New Relic API Key and Account ID（任意）
  • 「次へ」をクリック

4. ローテーション設定

  • 「自動ローテーションを無効にする」を選択
  • 「次へ」をクリック

5. 確認と作成

  • 設定内容を確認
  • 「保存」をクリック

IAMロール作成

CodeBuild用のIAMロールを作成します。

1. IAMロールの作成

AWSコンソールから「IAM」→「ロール」→「ロールを作成」を選択します。

2. 信頼されたエンティティタイプの選択

  • 「AWSのサービス」を選択
  • ユースケースで「CodeBuild」を選択
  • 「次へ」をクリック

3. 許可ポリシーのアタッチ

以下のAWSマネージドポリシーをアタッチすると素早く検証できます。

  • AmazonS3FullAccess
  • SecretsManagerReadWrite
  • CloudWatchLogsFullAccess

重要

  • 上記のマネージドポリシーは検証用です。本番環境では必ず最小権限の原則に従い、必要なリソースとアクションのみに絞ったカスタムポリシーを作成してください。
  • CodeBuildに強い権限を与えすぎるとサプライチェーン攻撃のリスクになるため、本番環境では Secrets Manager の特定ARNへの secretsmanager:GetSecretValue のみを許可するインラインポリシーを使用してください

4. ロール名の設定

  • ロール名: codebuild-newrelic-terraform-role
  • 説明: New Relic Terraform展開用のCodeBuildロール

5. ロールの作成完了

「ロールを作成」をクリックして完了します。作成したロールのARNは後ほど使用するため、メモしておいてください。

buildspec.ymlの作成

CodeBuildで実行する処理をbuildspec.ymlに定義します。

version: 0.2

phases:
  install:
    commands:
      - wget https://releases.hashicorp.com/terraform/1.13.5/terraform_1.13.5_linux_amd64.zip
      - unzip terraform_1.13.5_linux_amd64.zip
      - mv terraform /usr/local/bin/
      - terraform --version

  pre_build:
    commands:
      # Secrets Managerから認証情報を取得
      - export SECRET_NAME="NewRelicSecretKey"
      - export TF_VAR_newrelic_api_key=$(aws secretsmanager get-secret-value --secret-id $SECRET_NAME --query SecretString --output text | jq -r .NEWRELIC_API_KEY)
      - export TF_VAR_newrelic_account_id=$(aws secretsmanager get-secret-value --secret-id $SECRET_NAME --query SecretString --output text | jq -r .NEWRELIC_ACCOUNT_ID)
      
      # Terraform初期化
      - cd terraform
      - |
        if [ "$ENVIRONMENT" = "prod" ]; then
          terraform init \
            -backend-config="bucket=your-terraform-state-bucket-prod" \
            -backend-config="key=newrelic/prod/terraform.tfstate" \
            -backend-config="region=ap-northeast-1" \
            -backend-config="encrypt=true"
        else
          terraform init \
            -backend-config="bucket=your-terraform-state-bucket-dev" \
            -backend-config="key=newrelic/dev/terraform.tfstate" \
            -backend-config="region=ap-northeast-1" \
            -backend-config="encrypt=true"
        fi

  build:
    commands:
      - terraform plan -out=tfplan
      - terraform show -no-color tfplan > plan_output.txt
      - terraform apply -auto-approve tfplan

  post_build:
    commands:
      - echo "Terraform apply completed"

artifacts:
  files:
    - terraform/plan_output.txt

重要なポイントを3つ説明します。

環境変数の安全な管理

pre_buildフェーズでSecrets Managerから認証情報を取得し、環境変数として設定します。AWS CLIとjqコマンドを使ってJSON形式のシークレットから必要な値を抽出し、TF_VAR_プレフィックス付きの環境変数として設定することで、Terraformが自動的に変数として認識します。

環境別のbackend設定

ENVIRONMENT環境変数の値に応じて、適切なbackend設定ファイルを使用します。この環境変数はCodeBuildプロジェクトで設定します。

terraform planの出力保存

plan結果をplan_output.txtとして保存し、artifactsとして出力します。これにより、手動承認ステージでplan内容を確認できます。

注意: この例では自動的にterraform applyを実行します。本番環境では、後述する手動承認ステージの追加を検討してください。

CodePipelineの構築

Step 1: 作成オプションを選択する

1. パイプラインの作成開始

AWSコンソールから「CodePipeline」→「Create pipeline」を選択します。

2. 作成オプションの選択

「Step 1: Choose creation option」ページで以下を設定します。

  • 作成オプションを選択する: 「カスタムパイプラインを構築する」を選択
  • 「次へ」をクリック

Step 2: パイプラインの設定を選択する

1. パイプライン設定

「Step 2: Choose pipeline settings」ページで以下を設定します。

  • パイプライン名: newrelic-terraform-pipeline
  • サービスロール: 「新しいサービスロール」を選択（自動的に作成されます）
  • ロール名: デフォルトのまま
  • 「次へ」をクリック

Step 3: ソースステージを追加する

1. ソースプロバイダーの設定

「Step 3: Add source stage」ページで以下を設定します。

  • ソースプロバイダー: 「GitHub (GitHubアプリ経由)」を選択
  • 接続: 既存の接続がある場合はそれを選択、ない場合は「Create new connection」を選択

GitHub接続の作成（初回のみ）

新しい接続を作成する場合は以下の手順で進めます。

  • Connection name: github-connection（任意の名前）
  • 「Connect to GitHub」をクリック
  • GitHubの認証画面が開くので、AWSアカウントへのアクセスを承認
  • リポジトリへのアクセス権限を設定（すべてのリポジトリ、または特定のリポジトリのみ）
  • 「Install」をクリックしてGitHubアプリをインストール
  • AWSコンソールに戻り、「Connect」をクリック

2. リポジトリとブランチの設定

  • リポジトリ名: 対象のGitHubリポジトリを選択
  • デフォルトブランチ: main
  • 出力アーティファクト形式: 「CodePipeline のデフォルト」を選択
  • 「次へ」をクリック

Step 4: ビルドステージを追加する

※パイプラインに手動承認ステージを組み込むこともできますが、本記事では簡易化のため承認ステージの話は割愛しています

1. ビルドステージの設定

「Step 4: ビルドステージを追加する」ページで、以下の設定を行います。

  • プロバイダーを構築する: 「その他のビルドプロバイダー」から「AWS CodeBuild」を選択
  • プロジェクト名: 既存のプロジェクトがある場合は選択、ない場合は「Create project」をクリック

2. CodeBuildプロジェクトの作成

新しいプロジェクトを作成する場合、以下の設定を行います。

プロジェクトの設定

  • プロジェクト名: newrelic-terraform-build
  • プロジェクトタイプ: デフォルトプロジェクト
  • 説明 - オプショナル: New Relic Terraform設定の展開

環境

  • プロビジョニングモデル: オンデマンド
  • 環境イメージ: マネージド型イメージ
  • コンピューティング: EC2
  • 実行モード: コンテナ
  • オペレーティングシステム: Amazon Linux
  • ランタイム: Standard
  • イメージ: aws/codebuild/amazonlinux2-x86_64-standard:5.0（最新版）
  • イメージのバージョン: このランタイムバージョンには常に最新のイメージを使用してください
  • GPU 強化コンピューティングを使用: チェックなし
  • サービスロール: 「既存のサービスロール」を選択
  • ロールの ARN: 先ほど作成したcodebuild-newrelic-terraform-roleのARNを入力

追加設定（環境変数）

「追加設定」を展開し、環境変数を追加します。

  • 名前: ENVIRONMENT
  • 値: dev（開発環境の場合。本番環境用のプロジェクトではprodを設定）
  • タイプ: プレーンテキスト

Buildspec

  • ビルド仕様: 「buildspec ファイルを使用する」
  • Buildspec名 - オプショナル: buildspec.yml（デフォルト）

ログ

  • CloudWatch Logs - オプショナル: 有効化
  • グループ名 - オプショナル: /aws/codebuild/newrelic-terraform-build
  • ストリーム名のプレフィックス - オプショナル: 空欄（自動生成）

3. プロジェクト作成の完了

「Continue to CodePipeline」をクリックして、CodePipelineの設定画面に戻ります。

4. ビルドステージの設定完了

  • Build type: 「Single build」
  • 「次へ」をクリック

Step 5: テストステージを追加

1. テストステージのスキップ

「Step 5: テストステージを追加」ページで以下を設定します。

  • 「テストステージをスキップ」を選択
  • 「次へ」をクリック

Step 6: デプロイステージを追加する

1. デプロイステージのスキップ

「Step 6: デプロイステージを追加する」ページで以下を設定します。

  • 「導入段階をスキップ」を選択
  • 確認ダイアログで「スキップ」をクリック
  • 「次へ」をクリック

Step 7: レビュー

1. パイプラインの作成完了

「Step 7: Review」ページで設定内容を確認し、「パイプラインを作成する」をクリックします。作成後、自動的に最初の実行が開始されます。

手動承認ステージについて

本番環境では、terraform planの結果を確認してからapplyを実行するため、手動承認ステージを追加することを推奨します。Plan専用のCodeBuildプロジェクトを作成し、Planステージ → 手動承認ステージ → Applyステージという流れにすることで、変更内容を確認してから安全にデプロイできます。手動承認アクションではSNS通知と連携することで、承認待ちの通知をメールやSlackで受け取ることも可能です。

複数環境への対応について

開発環境と本番環境で異なるパイプラインを運用する場合は、以下の点を考慮して設定してください。

  • 環境ごとに独立したパイプラインを作成し、CodeBuildプロジェクトの環境変数ENVIRONMENTで環境を識別します
  • Secrets Managerで環境別のシークレット（NewRelicSecretKey-dev、NewRelicSecretKey-prodなど）を作成し、buildspec.ymlで${ENVIRONMENT}変数を使って動的に参照します
  • S3バケットやtfstateのキーも環境ごとに分離し、誤って別環境のstateを参照しないようにします
  • ブランチ戦略として、開発環境はdevelopブランチ、本番環境はmainブランチをトリガーにすると管理しやすくなります
  • 環境ごとに異なるNew RelicアカウントIDを使用する場合は上記の設定で対応できますが、同一アカウント内で環境を分ける場合は、アラート名やタグでリソースを区別する設計が必要です

SNS通知について

パイプラインの実行結果を通知したい場合は、SNSトピックを作成してCodePipelineの通知ルールと連携できます。メール通知やAWS Chatbotを使ったSlack通知が可能です。

まとめ

AWS CodePipelineとCodeBuildを使ったNew Relic監視設定の自動展開を実装しました。GitHubへのマージをトリガーに、自動的にterraform planとapplyが実行される仕組みにより、AWS環境と統合した形で安全な運用が可能になります。今回は記載していませんが、S3にファイルが保存されたらCI/CDパイプラインをキックするような構成をとることも可能です。

AWSからいきなりIaC管理するのもいいですが、何かあっても影響の小さいNew Relicのような監視ツールからこうした取り組みを実現してみてはいかがでしょうか。

この記事がどなたかのお役に立てれば幸いです。

宣伝

弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのお問合せフォームよりお問合せ頂けましたら幸いでございます。

関連記事

blog.serverworks.co.jp blog.serverworks.co.jp

◆　塩野　正人
◆　マネージドサービス部　所属
◆　X（Twitter）：@shioccii
◆　過去記事はこちら

前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。