当社の合成監視ジョブ マネージャーは 、プライベート ロケーションに割り当てられた 合成監視を 受け入れて実行する Docker コンテナ ベース のリソースです。
ジョブ マネージャーは、Docker コンテナー システム環境、Podman コンテナー システム環境、または Kubernetes コンテナー オーケストレーション システム環境で動作できます。 ジョブ マネージャーは環境を自動検出し、適切な動作モードを選択します。
Synthetics ジョブ マネージャーの機能 Synthetics ジョブ マネージャーは仮想マシンではなくコンテナーとして動作するため、インストール 、開始 、およびジョブ管理とオーケストレーションの更新 を簡素化しました。また、いくつかの追加機能も備えています。
Kubernetes固有の機能 ジョブ マネージャーには、いくつかの追加の Kubernetes 固有の機能が導入されています。
Kubernetes CronJob リソースを使用して非 ping モニターを実行します Docker ソケットへの特権アクセスは必要ありません ホストされたオンプレミスのKubernetesクラスターをサポートします DockerやContainerdなどのさまざまなコンテナエンジンをサポートします Helmチャートと構成YAMLを介してデプロイ可能 最適なリソース管理のために、設定可能なジョブ ランタイム (ping、API、およびブラウザー) ベースのリソース割り当てを許可します。 NewRelicKubernetesクラスターエクスプローラーを介して提供される可観測性 システム要件と互換性 Synthetics ジョブ マネージャーをホストするには、システムが選択したシステム環境の最小要件を満たしている必要があります。
注意 Synthetics ジョブ マネージャー ファイルは変更しないでください。New Relic は、お客様が行ういかなる変更についても責任を負いません。詳細については、アカウント担当者または New Relicテクニカルセールス担当者 にお問い合わせください。
の互換性
要件
オペレーティング·システム
Linux kernel: 3.10以降macOS: 10.11 以降Windows: Windows 10 64 ビット以降
また、Synthetics ジョブ マネージャーが Windows システムで動作するようにするには、Linux コンテナーを実行するように Docker を構成する必要があります。
プロセッサー
最新のマルチコアAMD64またはx86_64 CPU
メモリー
CPU コアあたり 3.256 GiB の RAM (専用)
ディスクサイズ
ホストあたり最低50GiB
ディスクファイルシステム
NFSv4.1以降（NFSを使用している場合）
Dockerバージョン
Docker 17.12.1-ce 以上
プライベートロケーションキー
秘密のロケーションキー が必要です
注意 Docker外形監視ジョブ マネージャーは、 AWS ECS、 Docker Swarm、 Apache Mesos、 Azureコンテナー インスタンスなどのコンテナー オーケストレーターで使用するように設計されていません。 Docker外形監視ジョブ マネージャーをコンテナー オーケストレーターで実行すると、それ自体がオーケストレーターとして機能するため、予期しない問題が発生します。 コンテナー オーケストレーションを使用している場合は、 Kubernetes外形監視ジョブ マネージャーの要件」 を参照してください。
の互換性
要件
オペレーティング·システム
Linux kernel: 3.10以上
プロセッサー
最新のマルチコアAMD64またはx86_64 CPU
メモリー
CPU コアあたり 3.256 GiB の RAM (専用)
ディスクサイズ
ホストあたり最低50GiB
ディスクファイルシステム
NFSv4.1以降（NFSを使用している場合）
ポッドマンバージョン
Podman 5.0.0-ce 以上
プライベートロケーションキー
秘密のロケーションキー が必要です
注意 Podman 外形監視ジョブ マネージャーは、 AWS ECS、 Docker Swarm、 Apache Mesos、 Azureコンテナ インスタンスなどのコンテナ オーケストレーターで使用するように設計されていません。 Docker外形監視ジョブ マネージャーをコンテナー オーケストレーターで実行すると、それ自体がオーケストレーターとして機能するため、予期しない問題が発生します。 コンテナー オーケストレーションを使用している場合は、 Kubernetes外形監視ジョブ マネージャーの要件」 を参照してください。
の互換性
要件
オペレーティング·システム
Linux kernel: 3.10以上macOS: 10.11 以上
ジョブ マネージャーを含む Linux コンテナーは、Linux K8s ノード上でのみ実行されます。
プロセッサー
最新のマルチコアCPU
Synthetics ジョブ マネージャー ポッド
CPU (vCPU/Core): 0.5～0.75Memory: 800Mi ～ 1600Mi
Synthetics ジョブ マネージャー ポッドに割り当てられたリソースは、ユーザーが構成できます。
Ping ランタイム ポッド
CPU (vCPU/Core): 0.5～0.75Memory: 500Mi 最大 1Gi
追加の考慮事項：
ping ランタイム ポッドに割り当てられたリソースは、ユーザーが構成できます。 CPUとメモリの両方の最大制限要求リソース比率は2です。 Node.js API ランタイム ポッド
CPU (vCPU/Core): 0.5～0.75Memory: 1250Miから2500Miまで
追加の考慮事項：
Node.js API ランタイム ポッドに割り当てられたリソースは、ユーザーが構成できます。 CPUとメモリの両方の最大制限要求リソース比率は2です。 Node.js ブラウザー ランタイム ポッド
CPU (vCPU/Core): 1.0から1.5までMemory: 2000マイルから3000マイルまで
追加の考慮事項：
Node.js ブラウザー ランタイム ポッドに割り当てられたリソースは、ユーザーが構成できます。 CPUとメモリの両方の最大制限要求リソース比率は2です。 ディスクサイズ
Root volume: 最低50GiB
ディスクファイルシステム
NFSv4.1以降（NFSを使用している場合）
Kubernetesバージョン
Kubernetes v1.21 以降が必要です。
プライベートロケーションキー
秘密のロケーションキー が必要です
兜
お使いのOS用のHelmv3のインストール手順に 従ってください。
Kubectl
お使いのOSのKubectlのインストール手順に 従ってください。
バージョン、依存関係、各シンセティック ジョブ マネージャーで起動するランタイム ポッドの数のデフォルト値などを表示するには、以下のヘルプと例を表示する を参照してください。
プライベートロケーションキー 合成ジョブ マネージャーを起動する前に、 秘密の場所のキー が必要です。Synthetics ジョブ マネージャーはキーを使用して New Relic に対して認証し、そのプライベートな場所に関連付けられたモニターを実行します。
既存のプライベートロケーションのキーを見つけるには：
one.newrelic.com > Synthetic monitoring > Private locations Private locations インデックスで、外形監視ジョブ マネージャーを割り当てるプライベート ロケーションを見つけます。プライベートロケーションに関連付けられたキーをキーとともにメモします 合成ジョブ マネージャーのインストール、更新、および構成 同じホスト内で複数のDockerまたは Podman プライベートロケーション コンテナーを実行している場合、ポートの競合が発生します。 このポート競合を回避するには、ジョブ マネージャーの設定を開始するときに、必ず次の操作を実行してください。
異なるホストでジョブ マネージャーと CPM を実行します。 各ジョブ マネージャーを個別のホストで実行します。 各 CPM を異なるホストで実行します。 Synthetics ジョブ マネージャーのイメージは、 Docker Hub でホストされています。hub.docker.com/r/newrelic/synthetics-job-manager/tags に移動しますすべてのリリースのリストについては。
ローカル イメージ リポジトリでイメージをホストしている場合を除き、 Dockerまたは Podman が外形監視ジョブ マネージャーと合成ランタイム イメージをプルできるように、ファイア ウォールを介した docker.io への接続を許可する必要があります。 外形監視ジョブマネージャーが起動すると、ランタイムイメージが自動的に取得されます。 ローカルリポジトリとランナーレジストリエンドポイントの設定方法については、 Docker環境設定 、 Podman環境設定 、 Kubernetes環境設定 を参照してください。
高度な構成設定の詳細については、 synthetics ジョブ マネージャーの構成 を参照してください。
合成ジョブ マネージャーを開始する 以下は、ジョブ マネージャーを起動するための Docker、Podman、または Kubernetes の適用可能な手順です。
プライベートロケーションキー を見つけます。
サンドボックスのDocker依存関係 が有効になっていて、システムに外形監視ジョブ マネージャーがインストールされていること を確認してください。
システムに適したスクリプトを実行します。システムに合わせて、次の例の共通のデフォルト/var/run/docker.sockを調整します。
Linux / macOS：
> --name YOUR_CONTAINER_NAME \
> -e "PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY" \
> -v /var/run/docker.sock:/var/run/docker.sock:rw \
> --restart unless-stopped \
> newrelic/synthetics-job-manager:latest
ウィンドウズ：
$ --name YOUR_CONTAINER_NAME ^
$ -e "PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY" ^
$ -v /var/run/docker.sock:/var/run/docker.sock:rw ^
$ --restart unless-stopped ^
$ newrelic/synthetics-job-manager:latest
ミニオンコンテナのログを表示します。
$ docker logs --follow YOUR_CONTAINER_NAME
プライベートロケーションキー を見つけます。
サンドボックス用にPodman 依存関係 を有効にし、システムに外形監視ジョブ マネージャーをインストールしている ことを確認してください。
システムに対して以下のスクリプトを実行します。
Linux でポッドを作成し、ホスト マシンの IP アドレスを追加するには:
podman pod create --network slirp4netns --name YOUR_POD_NAME --add-host=podman.service:IP_ADDRESS
ジョブ マネージャーを起動するには:
--name YOUR_CONTAINER_NAME \
-e "PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY" \
-e "CONTAINER_ENGINE=PODMAN" \
-e "PODMAN_API_SERVICE_PORT=YOUR_PODMAN_API_SERVICE_PORT" \
-e "PODMAN_POD_NAME=YOUR_POD_NAME" \
--restart unless-stopped \
newrelic/synthetics-job-manager:latest
ミニオン コンテナのログを表示するには:
podman logs --follow YOUR_CONTAINER_NAME
プライベートロケーションキー を見つけます。
Kubernetes クラスターで合成ジョブ マネージャーの名前空間を設定します。
$ kubectl create namespace YOUR_NAMESPACE
NewRelicHelmリポジトリからHelmチャートをコピーします。
次の Helm コマンドを使用して、synthetics ジョブ マネージャーをインストールします。
Synthetics ジョブ マネージャー ポッドが稼働しているかどうかを確認します。
$ kubectl get -n YOUR_NAMESPACE pods
各ポッドのstatus属性がrunningとして表示されると、Synthetics ジョブ マネージャーが起動し、プライベート ロケーションに割り当てられたモニターを実行する準備が整います。
Synthetics ジョブ マネージャーを停止または削除する Dockerまたは Podman コンテナ システム環境では、それぞれの stop プロシージャを使用して外形監視ジョブ マネージャーを停止します。 Kubernetesコンテナ オーケストレーション システム環境では、 Kubernetes delete プロシージャを使用して、外形監視ジョブ マネージャーの実行を停止します。
Dockerコンテナーは、コンテナー名またはコンテナーIDのいずれかで停止 できます。
Linux、macOS、およびWindowsのコンテナー名の停止：
$ docker stop YOUR_CONTAINER_NAME
$ docker rm YOUR_CONTAINER_NAME
Linux / macOSのコンテナID停止：
例では、コンテナは停止され、削除されます。コンテナのみを停止するには、 docker rm $CONTAINER_IDを省略します。
$ CONTAINER_ID = $( docker ps -aqf name = YOUR_CONTAINER_NAME )
$ docker stop $CONTAINER_ID
WindowsのコンテナID停止：
例では、コンテナは停止され、削除されます。コンテナのみを停止するには、 docker rm $CONTAINER_IDを省略します。
$ FOR /F "tokens=*" %%CID IN ( 'docker ps -aqf name=YOUR_CONTAINER_NAME' ) do ( SET CONTAINER_ID = %%CID )
$ docker stop %CONTAINER_ID%
$ docker rm %CONTAINER_ID%
削除する外形監視ジョブ マネージャー ポッドのJOB_MANAGER_POD_INSTALLATION_NAMEを取得します。
$ helm list -n YOUR_NAMESPACE
ミニオンポッドを削除します。
$ helm uninstall -n YOUR_NAMESPACE JOB_MANAGER_POD_INSTALLATION_NAME
Kubernetes クラスターで合成ジョブ マネージャー用に設定された名前空間を削除します。
$ kubectl delete namespace YOUR_NAMESPACE
サンドボックスと依存関係 サンドボックス化と依存関係は、 Dockerまたは Podman コンテナ システム環境の外形監視ジョブ マネージャーに適用されます。
Synthetics ジョブ マネージャーは Docker で実行され、Docker をサンドボックス テクノロジとして活用できます。これにより、モニターの実行が完全に分離され、セキュリティ、信頼性、再現性が向上します。スクリプト化されたモニターまたはブラウザー モニターが実行されるたびに、synthetics ジョブ マネージャーはまったく新しい Docker コンテナーを作成し、一致するランタイムを使用してそれを実行します。
追加のランタイム コンテナーを生成するには、Docker エンジンと通信するように合成ジョブ マネージャー コンテナーを構成する必要があります。生成された各コンテナーは、synthetics ジョブ マネージャー コンテナーが関連付けられているプライベートな場所で実行されている、 synthetic モニター に関連付けられたチェックを実行するために専用に使用されます。
起動時に重要な依存関係があります。サンドボックスを有効にするには、次のことを確認してください。
書き込み可能な Docker UNIX ソケットが/var/run/docker.sockまたはDOCKER_HOST 環境変数 にマウントされています。詳細については、Docker のDaemon ソケット オプション を参照してください。
注意 ホスト上のコア数によって、外形監視ジョブ マネージャーがホスト上で同時に実行できるランタイム コンテナの数が決まります。 メモリ要件はランタイム コンテナーの予想される数に合わせて調整されるため、リソースの競合を回避するためにnot running multiple synthetics job managers on the same host を推奨します。
サンドボックス化とrootまたは非rootユーザーとしての実行の詳細については、セキュリティ、サンドボックス化、および非rootユーザーとしての実行を 参照してください。
外形監視ジョブ マネージャーは Podman で実行され、Podman をサンドボックス テクノロジーとして活用できます。 これにより、モニターの実行が完全に分離され、セキュリティ、信頼性、再現性が向上します。 スクリプトまたはbrowser監視が実行されるたびに、外形監視ジョブ マネージャーは新しい Podman コンテナを作成し、一致するランタイムを使用して実行します。
追加のランタイム コンテナを生成するには、外形監視ジョブ マネージャー コンテナを Podman エンジンと通信するように構成する必要があります。 生成された各コンテナーは、外形監視ジョブ マネージャー コンテナーが関連付けられているプライベート ロケーションで実行されている合成モニター に関連付けられたチェックを実行する専用になります。
リリースには重要な依存関係があります。 サンドボックスを有効にするには、次の点を確認してください。
Podman 5.0.0-ce 以降をインストールしました。
ルートレス実行を有効にしました:
ルート権限を必要とせずにコンテナを実行するように Podman を設定します。mkdir -p ~/.config/containers
touch ~/.config/containers/containers.conf
vi ~/.config/containers/containers.conf
containers.confファイルを編集して、Podman がcrunとsystemd使用するように設定します。cgroup_manager = "systemd"
cgroups v2 を有効にしました (RHEL のみ):
GRUB を編集して cgroups v2 を有効にします。これにより、RHEL の最新のコンテナ ランタイムとの互換性が確保されます。sudo sed -i 's/GRUB_CMDLINE_LINUX="/&systemd.unified_cgroup_hierarchy=1 /' /etc/default/grub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
システム全体の委任を有効にして、Podman サービスのcgroups委任を許可しました。
sudo mkdir -p /etc/systemd/system/user@.service.d/
echo -e "[Service]\nDelegate=yes" | sudo tee /etc/systemd/system/user@.service.d/delegate.conf > /dev/null
ユーザーレベルのsystemdサービスを設定します。
ユーザー レベルのsystemdサービス用のディレクトリを作成します。mkdir -p ~/.config/systemd/user/podman.service.d
デリゲート設定をユーザーレベルのsystemdサービスに追加します。echo -e "[Service]\nDelegate=yes" > ~/.config/systemd/user/podman.service.d/override.conf
Podman ソケットを有効にして起動しました。
systemctl --user enable podman.socket
systemctl --user start podman.socket
systemctl --user status podman.socket
Podman API サービスを作成して構成しました。
Podman API サービスを有効にして開始しました。
systemctl --user daemon-reload
systemctl --user enable podman-api.service
systemctl --user start podman-api.service
systemctl --user status podman-api.service
注意 ホスト上のコア数によって、外形監視ジョブ マネージャーがホスト上で同時に実行できるランタイム コンテナの数が決まります。 メモリ要件はランタイム コンテナーの予想される数に合わせて調整されるため、リソースの競合を回避するためにnot running multiple synthetics job managers on the same host を推奨します。
セキュリティ、サンドボックス化、および非ルートとしての実行 デフォルトでは、合成ジョブ マネージャー内で実行されているソフトウェアは、 rootユーザー権限で実行されます。実行がサンドボックス化されるため、これはほとんどのシナリオに適しています。
非ルート ユーザーとして合成ジョブ マネージャーを実行するには、追加の手順が必要です。
詳細については、セキュリティ およびAppArmorセキュリティプロファイル に関するDockerの公式ドキュメントを参照してください。
ご使用の環境で、synthetics ジョブ マネージャーを非ルート ユーザーとして実行する必要がある場合は、次の手順に従います。次の例では、root 以外のユーザーはmy_userです。
my_userがホストでDockerエンジンを使用できることを確認します。
my_userが"docker"システム グループに属して いることを確認します。ブリッジ ネットワークを作成するには、 docker.sockへの限定されたルート アクセスが引き続き必要です。
また
Docker TCP ソケット オプション を有効にし、 DOCKER_HOST環境変数 を Synthetics Job Manager に渡します。
my_userに、合成ジョブ マネージャーに渡されたすべてのディレクトリとボリュームに対する読み取り/書き込み権限があることを確認してください。これらの権限を設定するには、 chmodコマンドを使用してください。
実行コマンドで使用するmy_userのuidを取得します： id -u my_user 。
これらの条件が満たされたら、synthetics ジョブ マネージャーを起動するときにオプション"-u <uid>:<gid>"を使用します。
$ docker run .. . -u 1002 .. .
また
$ docker run .. . -u 1002 -e DOCKER_HOST = http://localhost:2375 .. .
Docker、Podman、Kubernetes環境を理解する 以下は、ジョブ マネージャーのコンテナー環境の維持と理解に関する追加情報です。ライセンス情報を表示し、ジョブ マネージャーのネットワーク設定を理解し、Docker イメージ リポジトリを確認します。
ライセンス情報を表示する 一部のオープンソースソフトウェアは複数のソフトウェアライセンスの下にリストされており、その場合は、使用することを選択したライセンスをリストしています。当社のライセンス情報は、当社のライセンスドキュメント でも入手できます。
ネットワーク設定 Docker と Kubernetes の両方で、synthetics ジョブ マネージャーとそのランタイム コンテナーはホストからネットワーク設定を継承します。Docker コンテナー システム環境でのこの例については、 Docker サイト を参照してください。
ブリッジ ネットワークは、合成ジョブ マネージャーとランタイム コンテナー間の通信用に作成されます。つまり、 --networkや--dnsなどのネットワーク コマンド オプションは、起動時に (Docker コンテナー システム環境で Docker 実行コマンドを介して) 合成ジョブ マネージャー コンテナーに渡され、ランタイム コンテナーによって継承または使用されません。
これらのネットワークが作成されると、デーモン用に構成されたデフォルトのIPアドレスプールからプルされます。Dockerコンテナシステム環境でのこの例については、 Dockerサイト を参照してください。
Podman の場合、外形監視ジョブ マネージャーとランタイム コンテナ間の通信にブリッジ ネットワークを使用せず、代わりに Podman ポッドを使用します。 Podman ポッド内のすべてのコンテナは、同じネットワーク ネームスペースを共有します。 つまり、そのポッド内で同じ IP アドレスを共有することになります。 この場合、コンテナは同じ IP を共有しますが、サービスは異なるポートで公開されます。
Synthetics ジョブ マネージャー接続に関するその他の考慮事項 繋がり
説明
インターネットにアクセスできない合成ジョブ マネージャー
Synthetics ジョブ マネージャーは、インターネットにアクセスしなくても操作できますが、いくつかの例外があります。Synthetics ジョブ マネージャーは、 "synthetics-horde.nr-data.net"ドメインに接続できる必要があります。これは、データを New Relic にレポートし、実行するモニターを受け取るために必要です。これが問題であるかどうか、および例外の設定方法については、ネットワーク管理者に問い合わせてください。
プロキシを介して合成と通信する
プロキシによる New Relic との通信をセットアップするには、次の名前の環境変数 を使用します。 HORDE_API_PROXY*.
起動時に渡された引数
これは Docker および Podman コンテナ環境にのみ適用されます。 リリース時に外形監視ジョブ マネージャー コンテナに渡された引数は、外形監視ジョブ マネージャーによって生成されたランタイム コンテナには渡されません。 Dockerや Podman にはコンテナの「継承」や「階層」の概念がなく、外形監視ジョブマネージャから渡される設定を実行時コンテナにコピーすることはありません。 ただし、Podman の場合、ポッド レベルで渡される引数は、外形監視ジョブ マネージャーとポッド内のランタイム コンテナの間で共有されます。 それら間で共有される唯一の構成は、 Docker デーモン レベルで設定される構成です。