Docs » 高度なテスト設定 » プライベートロケーション

Edit this page
Learn how

---

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

プライベートロケーションとは、Splunk Synthetic Monitoringで合成テストを実行する場所となるカスタムロケーションを表すために作成する名前です。プライベートロケーションに付けた名前を使って、合成テストの Locations フィールドでその名前を指定できるようになります。プライベートロケーションから合成テストを実行するには、テストターゲットやSplunk Synthetic Monitoringとの実際の通信を行うために、プライベートロケーション内で1つ以上のプライベートランナーを設定する必要があります。

プライベートロケーションのユースケース

プライベートロケーションは、ファイアウォールの内外を問わず、あらゆる環境の内部アプリケーションのパフォーマンス問題を発見、修正、防止する方法を提供します。プライベートロケーションを使用すると、一般公開されていない内部サイトや内部アプリケーションに対して、開発サイクルの早い段階でテストを実行できます。また、プライベートロケーションを使用して、Splunk Synthetic Monitoringのパブリックロケーションリスト に含まれていないロケーションからパブリックエンドポイントをテストすることもできます。

要約として、以下にプライベートロケーションのサンプルユースケースを記します：

• 一般に公開されていないプライベートアプリケーションをテストする。

• 公開ステージングサイトを持たない本番前のアプリケーションをテストする。

• Splunk Synthetic Monitoringにアプリケーションへのアクセス権を与えることで、より高いレベルの柔軟性を獲得する。

• Splunk Synthetic Monitoring のパブリックロケーションで現在サポートされていないロケーションからテストする。

新しいプライベートロケーションをセットアップする

以下の手順に従って、新しいプライベートロケーションをセットアップしてください：

1. Splunk Synthetic Monitoring で、設定の歯車アイコン、Private locations の順に選択します。

2. Create private location を選択し、名前を追加します。

3. ガイド付きセットアップの手順に従って、そのプライベートロケーション用のプライベートランナーを1つ以上セットアップします。

4. プライベートロケーションを保存します。

プライベートロケーションIDでできること

各プライベートロケーションには、対応するプライベートロケーションIDがあります。このIDを使って、以下のことができます：

• チャートまたはダッシュボードを作成する

• プライベートロケーションごとにメトリクスを検索する

• Splunk Synthetics Monitoring API とやり取りする場合は、プライベートロケーション ID を参照してください。

トークンを管理する

トークンの更新と管理は各自の責任で行ってください。トークンは1年間有効です。セキュリティを高めるために、Dockerでトークン用のシークレット環境変数を作成してください。最初のトークンの有効期限が切れる前に、2つ目のトークンを作成することを検討してください。トークンの有効期限切れは通知されません。

プライベートロケーションの健全性を評価する

プライベートロケーションの健全性は3つの要因に左右されます：

要因	説明	解決策
アクティブなランナー	少なくとも1つのランナーがアクティブにチェックインしています。	チェックインするランナーがない場合は、プライベートロケーションに新しいランナーを設定します。
テストで使用中	プライベートロケーションは現在、1つ以上のテストで使用されています。	プライベートロケーションを削除する必要がある場合は、まずすべてのテストから削除する必要があります。
キューをクリアする	指定された場所のキューは定期的にクリアされており、バックアップされていません。	キューがバックアップされている場合は、プライベートロケーションに新しいランナーを追加します。

キューの長さとレイテンシをトラブルシューティングする

もしキューのレイテンシと長さの両方が時間の経過とともに増加するようであれば、パフォーマンスを向上させるためにランナーを追加します。

キューのレイテンシが増加しても、キューの長さが増加していない場合は、以下のトラブルシューティング方法を試してみてください：

• あるステップがテストの残り部分を遅らせていないかをチェックします。

• あなたのマシンでプライベートロケーションのランナーを実行するのに十分なリソースがあるかどうかを調査してください。

キュー内の最大実行回数は100,000回。

1時間以上前の実行はキューから削除されます。

プライベートランナー

プライベートランナーは、固有のプライベートロケーション内で実行するように構成されたテストのためにSplunk Synthetic Monitoringにクエリし、プライベートターゲット上でそのテストの手順を実行し、結果をSplunk Synthetic Monitoringに報告します。プライベートランナーはプライベートターゲットにアクセスできる必要があるため、プライベートランナーはDockerイメージであり、自分の内部ネットワーク内の独自のインフラストラクチャ上にデプロイします。プライベートロケーション を参照してください。

単一のプライベートロケーションのために複数のプライベートランナーをデプロイすると、それらのプライベートランナーはそのロケーションのテストキューをより迅速に処理できます。Splunk Synthetic Monitoringは、特定のプライベートロケーション用にデプロイされているプライベートランナーの数を追跡しません。独自のプライベートランナーフリートの管理方法は、お客様が決定します。

プライベートランナーの要件

要件	説明
Docker	Dockerコンテナは、ホストにifbカーネルモジュールがインストールされている必要があります。 Dockerコンテナには、アウトバウンドのインターネットアクセスが必要ですが、インバウンドのアクセスは必要ありません。
許可リスト	runner.<realm>.signalfx.com *.signalfx.com *.amazonaws.com quay.io/signalfx quay.io/v2
オペレーティングシステム	Linux、Windows、または macOS

ブラウザテストを実行する際に最適なパフォーマンスを得るには：

• Linux

• 2.3GHzデュアルコアIntel Xeon（または同等の）プロセッサー

• 8 GB RAM、2コア

対応プラットフォーム

• Docker

• Docker Compose

• AWS ECS

• MacまたはWindows用Docker

• Helm

• Kubernetes

• OpenShift

• Podman

• MacOSまたはWindows用のPodman

• AWSとGCP上のARM64マシン

ブラウザの互換性

プライベートランナーは、ブラウザテストを実行するためにヘッドレスブラウザを使用します。AMD64アーキテクチャー用のプライベートランナーDockerイメージにはChromeブラウザが含まれており、ARM64アーキテクチャー用のプライベートランナーDockerイメージにはChromiumブラウザが含まれています。ChromeはARM64では利用できないためです。ChromeとChromiumのバージョンは同じではない可能性があります。

ブラウザのタイプとバージョンを調べるには、Dockerイメージのラベル browser-type と browser-version を見てください。これらのラベルはhttp://quay.io/、または以下のコマンドの出力で見つけることができます：

docker pull quay.io/signalfx/splunk-synthetics-runner:latest
docker inspect -f '{{ index .Config.Labels "browser-type" }}' quay.io/signalfx/splunk-synthetics-runner:latest
docker inspect -f '{{ index .Config.Labels "browser-version" }}' quay.io/signalfx/splunk-synthetics-runner:latest

必須コンテナアクセス許可

このセクションでは、プライベートランナーのDockerイメージを実行するコンテナの最小要件の概要を説明します。

最小コンテナアクセス許可

コンテナには最低でも以下のアクセス許可が必要です。プライベートランナーのDockerイメージには、デフォルトでこれらのアクセス許可がすでに設定されているので、コンテナ実行ユーザーを変更しない場合は、何もする必要はありません：

• アプリケーションのホームディレクトリまたは作業ディレクトリへの読み書きアクセス権（通常、これは /home/pptruser/ です）。

• /tmp への読み取りおよび書き込みアクセス権（システムはデフォルトですべてのユーザーにこのアクセス許可を付与しています）

注釈

コンテナのルートファイルシステムを読み取り専用（ readOnlyRootFilesystem フラグ）に設定しないでください。コンテナが起動できなくなります。

カスタムCA証明書のオプションアクセス許可

プライベートランナーに送るテストがAPIと稼働時間テストにカスタムCA証明書を使用する必要がある場合、コンテナはinitコンテナで特権のエスカレーションをサポートする必要があり、これによりカスタム証明書がランナーのシステムCA証明書に追加されます。特権のエスカレーションを許可するには、containers.securityContext.allowPrivilegeEscalation を true に設定します：

containers:
  securityContext:
    allowPrivilegeEscalation: true

コンテナが特権昇格を許可していることを確認するには、sudo コマンドを実行するかどうかを確認します。

ネットワークシェーピングのオプションアクセス許可

プライベートランナーに送るテストが異なるネットワークスループットをシミュレートする必要がある場合、Dockerコンテナは NET_ADMIN （ネットワークシェーピング用）機能と共に特権のエスカレーションをサポートする必要があります。

containers:
  securityContext:
    capabilities:
      add:
      - NET_ADMIN
    allowPrivilegeEscalation: true

以下の警告メッセージが表示された場合、sudo: unable to send audit message：操作は許可されていません。AUDIT_WRITE 機能も追加してください：

containers:
  securityContext:
    capabilities:
      add:
      - NET_ADMIN
      - AUDIT_WRITE
    allowPrivilegeEscalation: true

必須コンテナリソース

プライベートランナーをデプロイするDockerコンテナには、以下のリソースが必要です。

プライベートランナーのポッドに割り当てられるリソースを増やしてください：

• ブラウザのクラッシュまたはエラー

• ブラウザの起動時にエラーが発生していることを示すログメッセージ

最小コンテナリソース

• CPU：1

• メモリ：2GB

推奨コンテナリソース

• CPU：2

• メモリ：8GB

リソース集約型テスト

各テストに必要なCPUとメモリは、実行されるテストに大きく依存します。プライベートランナーに送るテストが以下のようなリソースを大量に消費するブラウザテストの場合、Dockerコンテナには最小リソースではなく、少なくとも推奨リソースが必要です。

• 高解像度の画像や複雑なJavaScriptを含む複雑なウェブページの読み込み

• ビデオストリーミングなどのメディア再生

• 広範なDOM操作やメモリの大量消費など、重いJavaScriptの実行

• 大規模なデータセットの読み込みと操作（並べ替え、フィルタリング、検索操作など）

• 大容量ファイルのアップロードまたはダウンロード

これらは、リソースを大量に消費するブラウザテストの一例に過ぎません。

Docker上のプライベートランナー

プライベートランナーをインストールする

Docker runコマンドと以下のフラグを使用してコンテナを起動します：

docker run --cap-add NET_ADMIN \
-e "RUNNER_TOKEN=YOUR_TOKEN_HERE" \
quay.io/signalfx/splunk-synthetics-runner:latest

プライベートランナーをアップグレードする

手動アップグレード

Dockerイメージを手動でアップグレードするには、以下の手順に従ってください：

1. 最新の画像をプル：

   docker pull http://quay.io/signalfx/splunk-synthetics-runner:latest
   

2. 実行中のコンテナを停止する：

   docker stop <container_id_or_name>
   

3. 古いコンテナを削除する：

   docker rm <container_id_or_name>
   

4. 更新されたイメージで新しいコンテナを開始します：

   docker run --cap-add NET_ADMIN -e "RUNNER_TOKEN=YOUR_TOKEN_HERE" http://quay.io/signalfx/splunk-synthetics-runner:latest
   

自動アップグレード

Watchtower のような自動アップグレードソリューションを使用することで、プライベートロケーションのDockerイメージのアップグレードを自動化することができます。これはサードパーティのオープンソースDockerコンテナで、スケジュールに従ってリモートのDockerリポジトリに接続し、アップデートをチェックします。このセクションではWatchtowerの使い方を説明しますが、運用チームがすでにDockerイメージにアップデートをデプロイする仕組みを確立している場合は、プライベートランナーの設定を変更することなく、既存の仕組みを利用することができます。ベストプラクティスは、少なくとも24時間に1回はアップグレードの自動化を実行することです。プライベートランナーを最新の利用可能なイメージに更新しないと、データの不整合や機能の喪失につながる可能性があります。

Watchtowerは更新されたイメージを見つけると、Dockerホストにリポジトリから最新のイメージを取得し、コンテナを停止して、再度起動するように指示します。また、環境変数、ネットワーク設定、コンテナ間のリンクがそのままであることを保証します。

Dockerホスト上で、コマンドラインからWatchtowerコンテナを起動します：

docker run -d \
--name watchtower \
-v /var/run/docker.sock:/var/run/docker.sock \
v2tec/watchtower --label-enable --cleanup

label-enable フラグを使用すると、Splunkプライベートランナーのような正しいラベルを持つコンテナのみが自動更新されるようになります。

Docker ホストが古いイメージを保持しないようにするための古いイメージの自動クリーンアップなど、Watchtower ドキュメント では、探索できる追加オプションが利用可能です。

注釈

WatchtowerがDockerホストに対してコマンドを発行するには、docker.sock ボリュームまたはTCP接続が必要です。これにより、WatchtowerはDockerホストへの完全な管理者アクセス権を得ることができます。このレベルのアクセスをWatchtowerに提供できない場合は、アップデートを自動化するための他のオプションを検討することができます。

プライベートランナーをアンインストールする

1. すべてのコンテナのリスト：

   docker ps -a
   

2. 停止したコンテナをIDまたは名前で削除します：

   docker rm <container_id_or_name>
   

3. 実行中のコンテナを強制的に削除する：

   docker rm -f my_running_container
   

Docker Composeのプライベートランナー

このプライベートランナーは、Docker Composeのすべての最新バージョンで動作するはずです。

プライベートランナーをインストールする

1. 以下の定義で docker-compose.yml ファイルを作成します：

   version: '3'
   services:
     runner:
       image: quay.io/signalfx/splunk-synthetics-runner:latest
       environment:
         RUNNER_TOKEN: YOUR_TOKEN_HERE
       cap_add:
         - NET_ADMIN
       restart: always
   

2. 以下のコマンドを実行してコンテナを起動します：

   docker-compose up
   

プライベートランナーをアップグレードする

手動アップグレード

Dockerイメージを手動でアップグレードするには、以下の手順に従ってください：

1. docker-compose.yml を含むディレクトリに移動します。

   cd /path/to/your/docker-compose-file
   

2. 最新の画像をプル：

   docker-compose pull
   

3. 更新されたイメージでコンテナを再作成する：

   docker-compose up -d
   

自動アップグレード

アップグレードプロセスを自動化するには、CI/CDパイプラインを使用するか、Watchtower を使用します。

プライベートランナーをアンインストールする

1. プロジェクトディレクトリに移動する：

   cd /path/to/your/docker-compose-directory
   

2. docker-compose downコマンドを実行します：

   docker-compose down
   

MacまたはWindows用のDocker上のプライベートランナー

プライベートランナーをインストールする

1. Dockerをインストールします。手順については、Docker Community Edition for Mac または Windows をインストールするためのドキュメントを参照してください。

2. 以下のフラグでDockerコンテナを起動します：

   docker run -e "DISABLE_NETWORK_SHAPING=true" \
   -e "RUNNER_TOKEN=YOUR_TOKEN_HERE" \
   quay.io/signalfx/splunk-synthetics-runner:latest
   

プライベートランナーをアップグレードする

手動アップグレード

Dockerイメージを手動でアップグレードするには、以下の手順に従ってください：

1. 最新の画像をプル：

   docker pull http://quay.io/signalfx/splunk-synthetics-runner:latest
   

2. 実行中のコンテナを停止する：

   docker stop <container_id_or_name>
   

3. 古いコンテナを削除する：

   docker rm <container_id_or_name>
   

4. 更新されたイメージで新しいコンテナを開始します：

   docker run --cap-add NET_ADMIN -e "RUNNER_TOKEN=YOUR_TOKEN_HERE" \
   http://quay.io/signalfx/splunk-synthetics-runner:latest
   

自動アップグレード

Watchtower のような自動アップグレードソリューションを使用することで、プライベートロケーションのDockerイメージのアップグレードを自動化することができます。これはサードパーティのオープンソースDockerコンテナで、スケジュールに従ってリモートのDockerリポジトリに接続し、アップデートをチェックします。このセクションではWatchtowerの使い方を説明しますが、運用チームがすでにDockerイメージにアップデートをデプロイする仕組みを確立している場合は、プライベートランナーの設定を変更することなく、既存の仕組みを利用することができます。ベストプラクティスは、少なくとも24時間に1回はアップグレードの自動化を実行することです。プライベートランナーを最新の利用可能なイメージに更新しないと、データの不整合や機能の喪失につながる可能性があります。

Watchtowerは更新されたイメージを見つけると、Dockerホストにリポジトリから最新のイメージを取得し、コンテナを停止して、再度起動するように指示します。また、環境変数、ネットワーク設定、コンテナ間のリンクがそのままであることを保証します。

Dockerホスト上で、コマンドラインからWatchtowerコンテナを起動します：

docker run -d \
--name watchtower \
-v /var/run/docker.sock:/var/run/docker.sock \
v2tec/watchtower --label-enable --cleanup

label-enable フラグを使用すると、Splunkプライベートランナーのような正しいラベルを持つコンテナのみが自動更新されるようになります。

Docker ホストが古いイメージを保持しないようにするための古いイメージの自動クリーンアップなど、Watchtower ドキュメント では、探索できる追加オプションが利用可能です。

注釈

WatchtowerがDockerホストに対してコマンドを発行するためには、docker.sock ボリュームまたはTCP接続が必要です。これにより、WatchtowerはDockerホストへの完全な管理者アクセス権を得ることができます。このレベルのアクセスをWatchtowerに提供できない場合は、アップデートを自動化するための他のオプションを検討することができます。

プライベートランナーをアンインストールする

Dockerイメージを手動でアップグレードするには、以下の手順に従ってください：

1. すべてのコンテナのリスト：

   docker ps -a
   

2. 停止したコンテナをIDまたは名前で削除します：

   docker rm <container_id_or_name>
   

3. 実行中のコンテナを強制的に削除する：

   docker rm -f my_running_container
   

AWS ECS上のプライベートランナー

プライベートランナーをインストールする

1. AWS ECSコンソールで、Task definitions にアクセスします。

2. 黄色のドロップダウンメニューから Create new task definition with JSON を選択します

3. 以下のJSONをコピーし、コンソールにペーストします：

    {
     "requiresCompatibilities": [
     "EC2"
     ],
     "containerDefinitions": [
         {
             "name": "splunk-synthetics-runner",
             "image": "quay.io/signalfx/splunk-synthetics-runner:latest",
             "memory": 7680,
             "cpu": 2048,
             "essential": true,
             "environment": [
               {
                   "name": "RUNNER_TOKEN",
                   "value": "YOUR_TOKEN_HERE"
               }
             ],
             "linuxParameters": {
                   "capabilities": {
                     "add": ["NET_ADMIN"]
                   }
             }
         }
     ],
     "volumes": [],
     "networkMode": "none",
     "memory": "7680",
     "cpu": "2048",
     "placementConstraints": [],
     "family": "splunk-synthetics"
   }
   

4. Save を選択し、JSON入力パネルを閉じます。

5. Create を選択してタスクを作成します。

6. splunk-synthetics-runner を使用してクラスター内にサービスを作成します。手順については、AWS ドキュメントを参照してください。

プライベートランナーをアップグレードする

手動アップグレード

forceNewDeploymentオプションを使用すると、ランナーをアップグレードできます。これは既存のコンテナをシャットダウンし、リポジトリから最新のイメージを取得して新しいコンテナを起動します。

自動アップグレード

Watchtower のような自動アップグレードソリューションを使用することで、プライベートロケーションのDockerイメージのアップグレードを自動化することができます。これはサードパーティのオープンソースDockerコンテナで、スケジュールに従ってリモートのDockerリポジトリに接続し、アップデートをチェックします。このセクションではWatchtowerの使い方を説明しますが、運用チームがすでにDockerイメージにアップデートをデプロイする仕組みを確立している場合は、プライベートランナーの設定を変更することなく、既存の仕組みを利用することができます。ベストプラクティスは、少なくとも24時間に1回はアップグレードの自動化を実行することです。プライベートランナーを最新の利用可能なイメージに更新しないと、データの不整合や機能の喪失につながる可能性があります。

Watchtowerは更新されたイメージを見つけると、Dockerホストにリポジトリから最新のイメージを取得し、コンテナを停止して、再度起動するように指示します。また、環境変数、ネットワーク設定、コンテナ間のリンクがそのままであることを保証します。

AmazonのElastic Container ServiceでWatchtowerを使うには、Watchtower用のタスク定義を作成する必要があります。例えば、以下はクラスター内でDAEMONとして実行できるタスク定義のサンプルです。

{
  "requiresCompatibilities": [
    "EC2"
  ],
  "containerDefinitions": [
    {
      "command": [
        "--label-enable",
        "--cleanup"
      ],
      "name": "watchtower",
      "image": "v2tec/watchtower:latest",
      "memory": "512",
      "essential": true,
      "environment": [],
      "linuxParameters": null,
      "cpu": "256",
      "mountPoints": [
        {
          "readOnly": null,
          "containerPath": "/var/run/docker.sock",
          "sourceVolume": "dockerHost"
        }
      ]
    }
  ],
  "volumes": [
    {
      "name": "dockerHost",
      "host": {
        "sourcePath": "/var/run/docker.sock"
      },
      "dockerVolumeConfiguration": null
    }
  ],
  "networkMode": null,
  "memory": "512",
  "cpu": "256",
  "placementConstraints": [],
  "family": "watchtower"
}

プライベートランナーをアンインストールする

1. https://console.aws.amazon.com/ecs/v2でコンソールを開きます。

2. ナビゲーションバーから、タスク定義を含むリージョンを選択します。

3. ナビゲーションペインで、Task definitions を選択します。

4. Task definitions ページで、登録解除する1つ以上のリビジョンを含むタスク定義ファミリーを選択します。

5. Task definition name ページで、削除するリビジョンを選択し、Actions と Deregister を選択します。

6. Deregister ウィンドウの情報を確認し、 Deregister を選択して終了します。

Helmでデプロイされるプライベートランナー

プライベートランナーをインストールする

Helmのデプロイでは、最新のイメージとpullPolicyを使用するか、タグ付きイメージを使用することができます。

my-splunk-synthetics-runnerというリリース名のチャートをインストールするには、以下のコマンドを実行してください。詳細は、https://github.com/splunk/synthetics-helm-charts/tree/main/charts/splunk-synthetics-runner#installing-the-chart: を参照してください

helm repo add synthetics-helm-charts https://splunk.github.io/synthetics-helm-charts/
helm repo update
helm install my-splunk-synthetics-runner synthetics-helm-charts/splunk-synthetics-runner \
--set=synthetics.secret.runnerToken=YOUR_TOKEN_HERE \
--set synthetics.secret.create=true

プライベートランナーをアップグレードする

helm upgradeコマンドを実行します：

helm upgrade my-splunk-synthetics-runner synthetics-helm-charts/splunk-synthetics-runner --reuse-values

メジャーバージョンにアップグレードする場合は、Helmチャートもアップグレードする必要があります。

プライベートランナーをアンインストールする

helmアンインストールコマンドを実行します：

helm uninstall my-splunk-synthetics-runner

Kubernetes上のプライベートランナー

プライベートランナーをインストールする

1. ランナートークンでKubernetes Secretを作成します：

   kubectl create secret generic runner-token-secret \
   --from-literal=RUNNER_TOKEN=YOUR_TOKEN_HERE
   

2. デプロイYAMLを作成する：

   apiVersion: apps/v1
   kind: Deployment
   metadata:
    name: splunk-o11y-synthetics-runner
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: splunk-o11y-synthetics-runner
     template:
       metadata:
         labels:
           app: splunk-o11y-synthetics-runner
       spec:
         containers:
           - name: splunk-o11y-synthetics-runner
             image: quay.io/signalfx/splunk-synthetics-runner:latest
             imagePullPolicy: Always
             env:
               - name: RUNNER_TOKEN
                 valueFrom:
                   secretKeyRef:
                     name: runner-token-secret
                     key: RUNNER_TOKEN
             securityContext:
               capabilities:
                 add:
                   - NET_ADMIN
               allowPrivilegeEscalation: true
             resources:
               limits:
                 cpu: "2"
                 memory: 8Gi
               requests:
                 cpu: "2"
                 memory: 8Gi
   

3. デプロイYAMLを適用する：

   kubectl apply -f deployment.yaml
   

プライベートランナーをアップグレードする

kubectl applyコマンドを実行します：

kubectl apply -f deployment.yaml

imagePullPolicy: Always でlatestタグを使用しているため、deployment.yamlファイルに変更を加える必要はありません。デプロイを再適用すると、最新のイメージがプルされます。

プライベートランナーをアンインストールする

kubectl deleteコマンドを実行します：

kubectl delete -f deployment.yaml

OpenShift上のプライベートランナー

プライベートランナーをインストールする

1. ランナートークンでOpenShiftシークレットを作成します：

   oc create secret generic runner-token-secret --from-literal=RUNNER_TOKEN=YOUR_TOKEN_HERE
   

2. デプロイYAMLを作成する：

   apiVersion: apps/v1
   kind: Deployment
   metadata:
    name: splunk-o11y-synthetics-runner
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: splunk-o11y-synthetics-runner
     template:
       metadata:
         labels:
           app: splunk-o11y-synthetics-runner
       spec:
         containers:
           - name: splunk-o11y-synthetics-runner
             image: quay.io/signalfx/splunk-synthetics-runner:latest
             imagePullPolicy: Always
             env:
               - name: RUNNER_TOKEN
                 valueFrom:
                   secretKeyRef:
                     name: runner-token-secret
                     key: RUNNER_TOKEN
             securityContext:
               capabilities:
                 add:
                   - NET_ADMIN
               allowPrivilegeEscalation: true
             resources:
               limits:
                 cpu: "2"
                 memory: 8Gi
               requests:
                 cpu: "2"
                 memory: 8Gi
   

3. デプロイYAMLを適用する：

   oc apply -f deployment.yaml
   

プライベートランナーをアップグレードする

oc applyコマンドを実行します：

oc apply -f deployment.yaml

imagePullPolicy: Always で最新のタグを使用しているため、deployment.yaml ファイルに変更を加える必要はありません。デプロイを再適用すると、最新のイメージがプルされます。

プライベートランナーをアンインストールする

oc deleteコマンドを実行します：

oc delete -f deployment.yaml

Podman上のプライベートランナー

プライベートランナーをインストールする

Podman runコマンドと以下のフラグを使ってコンテナを起動します。

podman run --cap-add NET_ADMIN -e "RUNNER_TOKEN=YOUR_TOKEN_HERE" \
quay.io/signalfx/splunk-synthetics-runner:latest

プライベートランナーをアップグレードする

1. 最新の画像をプル：

   podman pull http://quay.io/signalfx/splunk-synthetics-runner:latest
   

2. 実行中のコンテナを停止する：

   podman stop <container_id_or_name>
   

3. 古いコンテナを削除する：

   podman rm <container_id_or_name>
   

4. 更新されたイメージで新しいコンテナを開始します：

   podman run --cap-add NET_ADMIN -e "RUNNER_TOKEN=YOUR_TOKEN_HERE" \
   http://quay.io/signalfx/splunk-synthetics-runner:latest
   

プライベートランナーをアンインストールする

1. すべてのコンテナのリスト：

   podman ps -a
   

2. 停止したコンテナをIDまたは名前で削除します：

   podman rm <container_id_or_name>
   

3. 実行中のコンテナを強制的に削除する：

   podman rm -f my_running_container
   

MacOSまたはWindows用のPodman上のプライベートランナー

プライベートランナーをインストールする

podman run -e "DISABLE_NETWORK_SHAPING=true" -e "RUNNER_TOKEN=YOUR_TOKEN_HERE" \
quay.io/signalfx/splunk-synthetics-runner:latest

プライベートランナーをアップグレードする

1. 最新の画像をプル：

   podman pull http://quay.io/signalfx/splunk-synthetics-runner:latest
   

2. 実行中のコンテナを停止する：

   podman stop <container_id_or_name>
   

3. 古いコンテナを削除する：

   podman rm <container_id_or_name>
   

4. 更新されたイメージで新しいコンテナを開始します：

   podman run --cap-add NET_ADMIN -e "RUNNER_TOKEN=YOUR_TOKEN_HERE" http://quay.io/signalfx/splunk-synthetics-runner:latest
   

プライベートランナーをアンインストールする

1. すべてのコンテナのリスト：

   podman ps -a
   

2. 停止したコンテナをIDまたは名前で削除します：

   podman rm <container_id_or_name>
   

3. 実行中のコンテナを強制的に削除する：

   podman rm -f my_running_container
   

AWSとGCP上のARM64マシン上のプライベートランナー

ARM64ベースのマシンで動作するDockerイメージをインストールまたはアップグレードするための特別な手順はありません。このイメージは、DockerまたはDocker Composeを使用して手動でデプロイするか、AWS EKS、GCP GKE、セルフホスト、またはAWS ECSでホストされているKubernetesにデプロイできます。

Dockerマニフェストには、利用可能なプラットフォームに関する情報と、正しいイメージへのリンクが含まれています。そのため、例えばdocker run http://quay.io/signalfx/splunk-synthetics-runner:latestというコマンドを実行すると、Dockerはマシンのアーキテクチャーに基づいて正しいイメージをダウンロードします。

プライベートランナーのトラブルシューティング

Dockerヘルスチェック

プライベートロケーションのDockerイメージは、Dockerヘルスチェックを利用して、コンテナが不健全な状態になったときに通信を行います。プライベートランナーがAPIで認証でき、過去30分以内に合成テストの取得に成功していれば、コンテナの状態は健全です。コンテナの状態が不健全な場合は、以下のトラブルシューティングのヒントをこの順に試してください：

1. コンテナのログをチェックして、認証エラーがあるかどうかを確認します。エラーがある場合は、ポッド起動時に RUNNER_TOKEN 環境変数に正しい値を指定したことを確認します。

2. コンテナを再起動します。

健全でないDockerコンテナを自動的に再起動する

プライベートロケーションを長期間運用する予定がある場合は、コンテナが不健全になった場合に自動的に再起動できるようにしておくと便利です。

コンテナを自動的に再起動するには、--restart unless-stopped と -e ALWAYS_HEALTHY=true をポッド起動コマンド（ docker run または podman run など）に追加する必要があります。ALWAYS_HEALTHY=true 環境変数は、ヘルスチェックに失敗するとすぐにDockerコンテナを終了します。このオプションは、どのDocker再起動ポリシーでも機能します。

docker run --restart unless-stopped -e ALWAYS_HEALTHY=true --cap-add NET_ADMIN \
-e "RUNNER_TOKEN=YOUR_TOKEN_HERE" \
quay.io/signalfx/splunk-synthetics-runner:latest

Dockerでの作業

Dockerでのロギングを制限するには、以下の手順に従ってください：

1. 以下のようなディレクトリにファイルを作成します： /etc/docker/daemon.json.

2. ファイルに追加します：

   {
     "log-driver": "local",
     "log-opts": {
       "max-size": "10m",
       "max-file": "3"
     }
   }
   

3. docker サービスを再起動します： sudo systemctl docker.service restart.

証明書を追加する

Splunk Synthetic Monitoringは、プライベートロケーションから実行されるアップタイムテストにカスタムルートCA証明書を注入することをサポートします。クライアントキーと証明書は現時点ではサポートされていません。

1. ホストマシン上に certs というフォルダを作成し、その中に CA 証明書（CRT 形式）を配置します。

2. コンテナ (-v ./certs:/usr/local/share/ca-certificates/my_certs/) にボリュームとしてcertsフォルダを追加します。

3. コンテナ起動時に使用するコマンドを変更し、エージェントバイナリ (bash -c "sudo update-ca-certificates && bundle exec bin/start_runner) を起動する前に CA 証明書キャッシュを更新します。

例えば、あるコマンドを自分の環境に合わせて修正した後のイメージは以下のとおりです：

docker run -e "RUNNER_TOKEN=<insert-token>" --volume=`pwd`/certs:/usr/local/share/ca-certificates/my_certs/ quay.io/signalfx/splunk-synthetics-runner:latest bash -c "sudo update-ca-certificates && bundle exec bin/start_runner"

注釈

カスタムルート CA 証明書は、ブラウザテストではサポートされていません。ブラウザテストでは、正確なテストのために SSL/TLS 検証が必要です。必要に応じて、ブラウザテストのSSL/TLS検証を無効にできます。

プライベートランナーのプロキシ設定を構成する

インターネットへの直接アクセスが制限されている環境では、以下の環境変数を設定することで、合成テストのトラフィックをプロキシサーバー経由でルーティングすることができます：

• http_proxy: HTTPトラフィックのプロキシサーバーを指定します。

  • 例： export http_proxy="http://proxy.example.com:8443"

• https_proxy：HTTPSトラフィックのプロキシサーバーを指定します。

  • 例： export https_proxy="http://proxy.example.com:8443"

• no_proxy: プロキシをバイパスするドメインまたはIPアドレスをカンマ区切りで指定します。

  • 例： export no_proxy="localhost,127.0.0.1,.internal-domain.com"

例えば、あるコマンドを自分の環境に合わせて修正した後のイメージは以下のとおりです：

docker run --cap-add NET_ADMIN -e "RUNNER_TOKEN=*****" -e "no_proxy=.signalfx.com,.amazonaws.com,127.0.0.1,localhost" -e "https_proxy=http://172.17.0.1:1234" -e "http_proxy=http://172.17.0.1:1234" quay.io/signalfx/splunk-synthetics-runner:latest

この例では：

http_proxy と https_proxy は、http://172.17.0.1:1234 のプロキシを経由してトラフィックをルーティングするように設定されています。

no_proxy は、ローカルアドレスと、.signalfx.comや.amazonaws.comのような特定のドメインのプロキシをバイパスするように設定されています。

これらの変数がネットワークポリシーに従って正しく設定されていることを確認してください。この設定により、制御されたネットワーク環境で、合成テストが安全かつ効率的に通信できるようになります。

プライベートランナーを使用する場合、ブラウザベースのテストで問題が発生しないように、プロキシ設定を正しく行うことが重要です。プライベートランナーの環境を設定する際には、以下の手順に従ってください：

1. 適切なno_proxyセットアップを確認する：

   no_proxy を設定する際には、必ず以下のアドレスを含めてください：

   • 127.0.0.1 (localhost通信用)

   • localhost (ローカルテストの解決用)

   これらのアドレスは、プロキシを経由せずに内部サービスやテストが正しく実行されることを保証し、潜在的な障害を防ぎます。

2. Dockerfileデフォルトを理解する：

   デフォルトでは、プライベートランナーはDockerfileの no_proxy 変数に 127.0.0.1 を含めるように設定されます。 no_proxy をオーバーライドする場合、 127.0.0.1 および localhost が存在することを確認する必要があります。存在しない場合、ブラウザテストが失敗する可能性があります。

注釈

小文字の変数名が優先し、かつベストプラクティスです。

このページは 2025年04月21日 に最終更新されました。

---

❮

Previous

グローバル変数

Next

パブリックロケーション

❯

---

• API docs
• Blog
• Training
• Free Trial