【New Relic】プライベート環境にあるURLの監視方法 (Dockerコンテナ編)

記事タイトルとURLをコピーする

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

前回こちらの記事でプライベートサブネットにあるWebシステムの監視についての話をしましたが、今回はもう少しだけNew Relicの公式ドキュメントに寄り添った形の話になります。

blog.serverworks.co.jp

URL監視をおこなうアプリケーション自体がコンテナだから、無理やりAWSのコンテナ環境をフルに使おうぜという趣旨で前回の記事は作成しましたが、やはり公式ドキュメントに「使えるような仕様になっていません」と書かれている以上はちゃんと動いたとしてもあまり本番環境では使いたくないですよね。実際のところ前回の記事では「動作すること」がゴールだったため、運用面を考慮すると「ちょっとな~」ということを考えられた方もいらっしゃったのではないでしょうか。今回は公式ドキュメントに沿った設定や、その際の注意点、もう少し運用面を改善するとどうなる?というところまで踏み込んだ記事になります。

目次

想定読者

New Relicを使って、プライベートサブネットにあるURL監視をしたい方

プライベートロケーションとは

詳しくはこちらの記事に記載しておりますが、概要としてはプライベートサブネットに所属しているWebサーバなどを監視するための仕組みとご理解いただければと思います。

blog.serverworks.co.jp

プライベートロケーションを展開する場合、公式ドキュメント上では大きく2パターンの展開方法があり、Synthetics ジョブ マネージャーとプライベートミニオンのパターンとなります。このうちプライベートミニオンについてはEOL予定となっていますので、基本的にはSynthetics ジョブ マネージャーを展開すると理解いただければと思います。

またSynthetics ジョブ マネージャーを使った展開もDocker 環境またはKubernetes環境での展開パターンがあり、コンテナ環境を主にKubernetesで展開していない限りはDocker環境での展開を推奨いたします。理由としては、EC2などのインスタンス以外にコンテナオーケストレーションの仕組みなども別途管理する必要があり、既存環境がKubernetesだけで動作しているような状況でない限りは通常のDocker環境より管理工数が余計にかかってしまうことなどの理由であまりメリットがないからです。

種類 概要
Syntheticsジョブマネージャー CPMの新しいバージョン。Docker 環境またはKubernetes環境で展開可能
コンテナ化されたプライベートミニオン(CPM) レガシーな環境。2024 年 10 月 22 日にEOLになります。

Docker環境の環境要件

Syntheticsジョブマネージャーを利用する場合の環境要件は下記の通りです。 この要件で特に注意していただきたいのが、メモリ要件でCPUあたりコア3.256GiBを専用で確保するという点になります。

もちろんプライベート環境のURLを監視するシステムとなりますので冗長性を考慮する必要もありますので、 本番環境での運用ではこのあたりの条件を考慮した上でシステム設計をした方がよさそうですね。

項目 条件
OS Linux kernel: 3.10以降
プロセッサ 最新のマルチコアAMD64またはx86_64 CPU
メモリ CPU コアあたり 3.256 GiB の RAM (専用)
ディスク ホストあたり最低50GiB
ファイルシステム(オプション要件) NFSv4.1以降(NFSを使用する場合)
Dockerバージョン Docker 17.12.1-ce以上
プライベートロケーションキー New Relicのサイトから取得

docs.newrelic.com

やってみた

EC2環境の設定

ここでは特定のEC2上でDockerを動作させ、そこからプライベート環境のURL監視をおこなう構成を想定しているため、そのベースとなるEC2を立ち上げます。

AWS環境の設定

下記内容でEC2を起動する
  • 名前
    • 任意の名前を命名
  • Amazon マシンイメージ (AMI)
    • Amazon Linux 2023 (x86 64ビット)
  • インスタンスタイプ
    • t2.large (詳細は下記インスタンスタイプを参照のこと)
  • ネットワーク設定
    • NAT配下、またはパブリックサブネットで、New Relicのエンドポイントに関しデータを送信できる環境
  • ストレージを設定
    • 51GiB
  • IAM インスタンスプロフィール(必要に応じて)
    • 今回の検証ではSSM経由でログインして操作する想定のため、EC2に適用するIAMロールにAmazonSSMManagedInstanceCoreを適用
    • SSMパラメータストアを使用したい場合は、対象のパラメータストアのリソースに対して ssm:GetParameter の権限を追加する
    • SSH経由で接続する場合は、IAM インスタンスプロフィールの適用は任意でもOK

インスタンスタイプ - Amazon EC2 | AWS

OS環境の設定

1.起動したEC2にログインしてDocker環境を構築する
起動したEC2にSSHまたはSSMでログインする
パッケージのアップデート

システムのパッケージを最新の状態に更新します

sudo dnf update -y
Dockerのインストール

Dockerパッケージをインストールします

sudo dnf install -y docker
Dockerサービスの起動と有効化

Dockerサービスを起動し、システム起動時に自動的に開始されるように設定します

sudo systemctl start docker
sudo systemctl enable docker
ユーザーをdockerグループに追加

ec2-userをdockerグループに追加し、SSM環境及びSSH環境でsudo無しでDockerコマンドを実行できるようにします

sudo usermod -aG ec2-user
設定の反映

変更を反映させるために、以下のコマンドを実行します

newgrp docker
インストールの確認

Dockerが正しくインストールされたことを確認します

sudo su ec2-user
docker --version
docker info

※下記は出力例になります

$ docker --version
Docker version 25.0.5, build 5dc9bcc

$ docker info
Client:
 Version:    25.0.5
 Context:    default
 Debug Mode: false
 Plugins:
    :
2.New Relic管理画面にて Syntheticsジョブマネージャー起動用のコマンドを取得
新規PrivateLocationの作成

New Relicの管理画面にログインし、Synthetics Monitoring > Private locations > Create privavte location を開きます

任意の名前を入力し、Generate keyをクリックします

Dockerの欄のコマンドコピーボタンをクリックします

Dockerコンテナの起動

EC2にec2-userでログインし、New Relicの管理画面で取得したコマンドを実行します

※下記例はSSMにてログインしている関係上、ec2-userにスイッチしています
※プライベートロケーションキーはNew Relicの管理画面で取得したコマンドに記載されています

sudo su ec2-user
$ docker run -e PRIVATE_LOCATION_KEY=<プライベートロケーションキー>  -d --restart unless-stopped -v /var/run/docker.sock:/var/run/docker.sock:rw newrelic/synthetics-job-manager

コマンド出力結果

$ docker run -e PRIVATE_LOCATION_KEY=<KeyValue> -d --restart unless-stopped \
 -v /var/run/docker.sock:/var/run/docker.sock:rw newrelic/synthetics-job-manager
Unable to find image 'newrelic/synthetics-job-manager:latest' locally
latest: Pulling from newrelic/synthetics-job-manager
9b857f539cb1: Pull complete
29a521bc3218: Pull complete
   :
Status: Downloaded newer image for newrelic/synthetics-job-manager:latest
Dockerコンテナの起動状況確認

下記コマンドでコンテナの状況を確認します

$ docker ps -a

確認ポイントは、STATUS が UP になっているかどうかです

New Relic 管理画面上での状況確認

New Relicの管理画面にログインし、Synthetics Monitoring > Private locations > 新規作成した privavte location をクリックします

SummaryページのMinionsの数字が0でないこと、Reporting Minionsに記載されているミニオンからの情報がActiveになっていることを確認します

New Relic Job Managerの停止

基本的にはDockerコンテナの停止の手順と同じになります

EC2にec2-userでログインし、現在のコンテナの状況を確認します

$ docker ps -a
CONTAINER ID   IMAGE                                     COMMAND                  CREATED         STATUS         PORTS           NAMES
ec2380d77fa2   newrelic/synthetics-ping-runtime:latest   "/data/synthetics-pi…"   3 minutes ago   Up 3 minutes   8080-8082/tcp   PING
b44a9de314cf   newrelic/synthetics-job-manager           "/data/synthetics-jo…"   5 minutes ago   Up 5 minutes   8080-8082/tcp   beautiful_shirley

停止する際に必要な情報は、コンテナIDまたはコンテナ名になります。 基本的にどちらを使ってもコンテナの状態を操作することが可能ですが、今回はコンテナIDを使用して操作していきます。 コンテナが2つ起動していますので、それぞれのコンテナに対して停止コマンドを発行していきます。 注意点としてはイメージ名が newrelic/synthetics-job-manager となっているコンテナから先に停止します。

docker stop <コンテナID>

docker ps で確認したステータスが Exited (143) から始まっていればコンテナは意図したとおり停止されています。

$ docker stop b44a9de314cf 
b44a9de314cf
$ docker stop ec2380d77fa2
ec2380d77fa2
$ docker ps -a
CONTAINER ID   IMAGE                                     COMMAND                  CREATED              STATUS                            PORTS     NAMES
ec2380d77fa2   newrelic/synthetics-ping-runtime:latest   "/data/synthetics-pi…"   About a minute ago   Exited (143) About a minute ago             PING
b44a9de314cf   newrelic/synthetics-job-manager           "/data/synthetics-jo…"   20 minutes ago       Exited (143) About a minute ago             beautiful_shirley

次に、下記コマンドを使用してコンテナを削除します。こちらはイメージ名が newrelic/synthetics-ping-runtime:latest となっている方から削除していきます。

docker rm <コンテナID>
$ docker rm 08a61bf1e6b8
08a61bf1e6b8
$ docker rm b44a9de314cf
b44a9de314cf

コンテナの状況を確認します。一覧から削除されていれば成功です。

$ docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

運用上の考察

長い目で見て、毎回 docker runコマンドを取得して、ログインして既存コンテナを削除してまたdocker runコマンドを実行してとなると、そこそこめんどくさい作業になるかと思います。 もちろん単一コンテナになりますので、そのままdocker runを実行する運用でもいいと思いますが、docker composeを使用することでこういった作業を省力化することができるかもしれません。

docker-composeってなに?

基本的には複数コンテナ環境を構築したりCIワークフローなどを効率よく使うためのツールとなっています。

Compose とは、複数のコンテナを使う Docker アプリケーションを、定義・実行するツールです。Compose はアプリケーションのサービスの設定に、Compose ファイルを使います。そして、コマンドを1つ実行するだけで、設定した全てのサービスを作成・起動します。

Docker Compose は OS X、Windows、64-bit Linux で実行可能で、もちろん Amazon Linux 2023 でも実行可能です。

docs.docker.jp

Amazon Linux 2023環境にDocker Composeをインストールしてみた

Docker Composeのバイナリをダウンロード

下記コマンドでDocker Composeのバイナリをダウンロードします

※コマンドで使用しているバージョン番号(v2.29.2)は必要に応じて変更してください。 最新のバージョンはDocker ComposeのGitHubリリースページで確認できます。

sudo curl -L "https://github.com/docker/compose/releases/download/v2.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

実行権限の付与

ダウンロードしたDocker Composeのバイナリに実行権限を付与します

sudo chmod +x /usr/local/bin/docker-compose
シンボリックリンクの作成

バイナリを実行できるようにシンボリックリンクを作成します

sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
動作確認

設定は上記で完了となりますので、Docker Composeが正しくインストールされたか確認します

docker-compose -v

Docker Composeを使って起動した

Docker Composeファイルの内容

New Relicの管理画面で提示されたコマンドより、docker-compose.ymlファイルの中身はおおよそ以下のような内容となります。

services:
  synthetics-job-manager:
    image: newrelic/synthetics-job-manager
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:rw
    environment:
      - PRIVATE_LOCATION_KEY=${PRIVATE_LOCATION_KEY}

環境変数の設定

コンテナ側に渡す環境変数については、export関数を使用して設定します。

$ export PRIVATE_LOCATION_KEY=<プライベートロケーションキーを入力>

上記の方法以外にはPRIVATE_LOCATION_KEY自体をSSMのパラメータストアに保管して、直接キーを取得するような方法でもよいでしょう。

$ PRIVATE_LOCATION_KEY=$(aws ssm get-parameter --name "/newrelic/private-location-key" --with-decryption --query Parameter.Value --output text)
$ export PRIVATE_LOCATION_KEY

Dockerの起動

docker composeの起動は下記のコマンドから実施します。

docker-compose up -d

Dockerの停止

docker composeの停止は下記のコマンドから実施します。

docker-compose down

Dockerコマンドで個別にスタートストップするよりDocker Composeを使用する方が、運用上はだいぶシンプルになりそうですね。

まとめ

今回はプライベートサブネット監視用のEC2インスタンスを起動して、そこでDockerコンテナ起動し監視をおこなう構成の記事でした。公式ドキュメントにあまり細かく記載されていませんが、実際の本番運用ではDocker上で動作するSyntheticsジョブマネージャー自体もかなりの頻度で更新されているため、定期的にコンテナの入れ替えをおこなうような運用フローも合わせて検討したほうがよさそうです。

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

宣伝

弊社では、お客様環境のオブザーバビリティを加速するためのNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。

関連記事

blog.serverworks.co.jp

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

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