みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。
プライベートサブネットの通信がうまくいかない場合に色々切り分けが大変なことはありますが、 今回はプライベートサブネットでNew Relicの外形監視（Synthetics Monitor）をおこなうというケースで Dockerアプリケーションを使用したプライベートサブネット向けの通信制御のハマりポイントを解説してみます。
過去にプライベート環境でNew Relicの通信を行う場合の注意点は下記記事にまとめていますので、合わせてご確認ください。
目次
概要
New Relicの外形監視（Synthetics Monitor）とは
New Relic Syntheticsモニターは、アプリケーションの可用性とパフォーマンスを監視するための強力なツールで、ウェブサイト、アプリケーション、APIエンドポイントなどを世界各地に配置されたパブリックロケーションから定期的にテストを実行することで、ユーザーがアプリケーションをどのように体験しているかを把握するためのサービスです。
Syntheticモニターの概要については下記公式サイトをご参照ください。 docs.newrelic.com
New Relicのプライベートロケーション監視とは
基本的にはパブリックとなっているインターネットから監視を行うことでアプリケーションの健全性を把握するものですが、アプリケーションの中にはファイアウォールの内側にある内部アプリケーションやリソースを監視する必要があるケースも多いと思います。このような場合にファイアウォールの内側に監視用のエンドポイントサーバを設置することで、インターネットと直接通信ができないファイアウォールの内側にある内部アプリケーションやリソースを監視することができるようになります。
プライベートロケーションの概要については下記公式サイトをご参照ください。 docs.newrelic.com
システム構成
さて、今回の監視環境の構成ですが、下記の通りプライベートサブネットに設置してあるnginxサーバに対してNew Relicのプライベートロケーション用のコンテナから監視をする構成としております。また、プライベートサブネットからインターネットへのアクセスは、多くの組織で利用されているであろうProxyサーバを使用した構成としています。
プライベートロケーション設定の注意点
プロキシサーバーを経由してプライベートロケーションからNew Relicのサービスへ通信する場合、プライベートサブネットに設置してあるサーバーからのすべての通信をプロキシサーバーを経由させる必要がでてくるため適切な通信設定が不可欠となります 。プロキシの設定だけでなくプロキシ配下のシステムの通信設計が不適切であると、プライベートロケーションがNew Relicのホストと通信できず、監視ジョブの受信や結果の報告が行えなくなる可能性があります。
New Relicのプライベートロケーション用コンテナの挙動
New Relicのプライベートロケーション用コンテナ自体はパブリックサブネットにもプライベートサブネットにもどちらにも設置することが可能です。しかしながらプライベートロケーション用コンテナ自体がDockerで動作しているため、基本的には内部から外部に向けてのインターネットアクセスは必須となっています。
また、公式の起動コマンドでは newrelic/synthetics-job-manager だけを立ち上げる設定をしますが、このコンテナが起動してNew Relicに対して疎通確認を行った後に、実際にサーバーを監視するために使用する newrelic/synthetics-ping-runtime が自動起動されます。つまり、イメージをローカルに持っていたとしても newrelic/synthetics-ping-runtime がないと監視ができません。またイメージ自体は頻繁に更新されるものとなりますので、なるべくProxyサーバなどを介したインターネットアクセス経由でイメージ取得することをオススメいたします。
$ sudo docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES cd6b7eff5e5d newrelic/synthetics-ping-runtime:latest "/data/synthetics-pi…" 56 minutes ago Up 56 minutes 8080-8082/tcp PING de503d46051c newrelic/synthetics-job-manager "/data/synthetics-jo…" 56 minutes ago Up 56 minutes 8080-8082/tcp zen_neumann
プロキシサーバーを経由したdockerなどの通信の注意点
プロキシサーバーを経由したdockerなどの通信を行う場合はそれぞれのレイヤーに分けて考える必要があり、基本的には下記のレイヤーで考えればいいでしょう。
- コンテナを管理している基盤側（docker）のレイヤー
- コンテナとして動作しているアプリケーション側のレイヤー
Dockerなどのコンテナ技術を使うと、アプリケーションはホストOS上で動く別の『隔離されたプロセス』として扱われます。そのため、コンテナ内のアプリケーションが外部と通信する際にはアプリケーション自体にプロキシ設定が必要です。それとは別に、DockerエンジンがDocker Hubなどからイメージを取得する際には、Dockerエンジン自体にプロキシ設定が必要です。
つまり、コンテナ環境でのProxyサーバーを介した通信障害の場合は、どのレイヤーで問題が発生しているのかしっかり認識した上で対応が必要になるということです。
通信設計
ここで検証環境の構成に話を戻しますが、今回は監視側の通信はNew Relicが提供しているVPCエンドポイントに流す想定としています。図には記載していませんが、VPCエンドポイント以外にRoute53 プライベートホストゾーンの設定も一緒に必要となりますので、ホストゾーンの設定にSyntheticsジョブマネージャーの接続先である synthetics-horde.nr-data.net の設定が別に必要になることにご留意ください。
dockerエンジン側の設定
基本的には下記公式ドキュメントに沿って設定を行うことで、dockerエンジン自体の通信をProxy経由として通信させることができるはずです。
今回使用した Amazon Linux 2023 では、一部設定が異なっておりましたので、dockerエンジンのProxy周りの設定を中心にお伝えします。
docker engineのインストール
dockerのインストールは標準的な下記コマンドを使用しました。
sudo dnf install docker -y sudo systemctl start docker sudo systemctl enable docker
docker engineのProxy設定
次に環境変数にProxyサーバーを登録します。
一般的な話として /etc/systemd/system/docker.service などのファイルにdockerに関連する設定が書き込まれている認識でしたが、今回の検証時に対象ファイルを見つけられませんでした。
調べてみた結果、公式ドキュメントの参照バージョンが古いことが起因している可能性がありそうですので、下記公式ドキュメントに沿って設定を実施します。
１．docker.service.d フォルダがない場合は作成する
sudo mkdir -p /etc/systemd/system/docker.service.d
２．先ほど作成したフォルダに http-proxy.conf を作成し編集用として開く
sudo touch /etc/systemd/system/docker.service.d/http-proxy.conf sudo vi /etc/systemd/system/docker.service.d/http-proxy.conf
３．Proxy設定を書き込んでファイルを保存する
[Service] Environment="HTTP_PROXY=http://10.234.10.234:3128" Environment="HTTPS_PROXY=https://10.234.10.234:3129"
余談な話ですが、認証プロキシの場合は認証情報をURLに記載します。もし、パスワードに起動を含んでいたり、Active Directoryのユーザーなどで認証を行っている場合は、記号などを含む文字列にURLエンコードを施したものをそれぞれユーザー名やパスワードの箇所に記載ください。
[Service] Environment="HTTP_PROXY=username:password@http://10.234.10.234:3128" Environment="HTTPS_PROXY=username:password@https://10.234.10.234:3129"
４．サービス再起動をおこなう
sudo systemctl daemon-reload sudo systemctl restart docker
New Relic側の通信設定
今回はVPC内にエンドポイントを設置するということになりますが、以前に記載したこちらのブログが参考になりますので詳細の手順はこちらの記事をご確認ください。
下記ポイントに注意しながら設定を行ってください。
- プライベートサブネットの通信ができる場所にVPCエンドポイントを設置する
- New Relicが提供しているリージョン以外の場合は、クロスリージョン設定が必要です
- Route 53 プライベートホストゾーンで名前解決の設定をおこなう
- 設定の際は nr-data.net や newrelic.com という切り方ではなく、サブドメインも含めた synthetics-horde.nr-data.net という形でホストゾーンの登録をおこない、Aレコードにエンドポイントに割り当てられたIPアドレスを設定します
まとめ
Dockerエンジン自体のProxy設定に少しハマってしまいましたが、設定内容としてはそれぞれ動いている場所が違うのでその場所毎に必要な設定をしましょうねという内容でしたので、そんなに難しくはないかと思います。Dockerエンジンやコンテナの通信をProxy経由にするのかそうでないのかなど、個別要件によって変わってくる箇所かと思いますので、要件に応じて設定していただければ幸いです。
この記事がどなたかのお役に立てれば幸いです。
宣伝
オブザーバビリティをもっと活用してみたい、オブザーバビリティを始めてみたいけど何から取り組んでいったらいいんだろうという方に向けたオブザーバビリティの導入を促進するサービスのご紹介をおこなっております。オブザーバビリティを始めるには専用のツールを使う必要があり、弊社ではアカウント開設などを含めた伴走型支援サービスをご用意しておりますので、もしオブザーバビリティの活用にご興味がある方は、こちらのお問合せフォームよりお申し付け頂けましたら幸いでございます。
