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

内部サイト、プライベートなWebアプリケーション、プライベートネットワークといったプライベートロケーションから合成テストを実行します。

プライベートロケーションとは、合成テストを実行できるカスタムロケーションを表すために Splunk Synthetic Monitoring で作成する名前です。プライベートロケーションに指定した名前は、合成テストの [Locations] フィールドで指定できます。また、プライベートロケーションから合成テストを実行するには、プライベートロケーション内に 1 つ以上のプライベートランナーをセットアップして、テストターゲットおよび Splunk Synthetic Monitoring との通信を実際に行えるようにする必要があります。

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

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

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

一般に公開されていないプライベートアプリケーションをテストする。
公開ステージングサイトを持たない本番前のアプリケーションをテストする。
Splunk Synthetic Monitoringにアプリケーションへのアクセス権を与えることで、より高いレベルの柔軟性を獲得する。
Splunk Synthetic Monitoring のパブリックロケーションで現在サポートされていないロケーションからテストする。

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

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

Splunk Synthetic Monitoring で、設定の歯車アイコン、Private locations の順に選択します。
Create private location を選択し、名前を追加します。
ガイド付きセットアップの手順に従って、そのプライベートロケーション用のプライベートランナーを1つ以上セットアップします。
プライベートロケーションを保存します。

プライベートロケーション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 コマンドと以下のフラグを使用してコンテナを起動します。 ENABLE_CLIENT_CERTS 環境変数は、このプライベートランナーで mTLS 認証を有効にする必要がある場合にのみ必要です。
```
docker run --cap-add NET_ADMIN \
-e "RUNNER_TOKEN=YOUR_TOKEN_HERE" \
-e "ENABLE_CLIENT_CERTS=true" \
quay.io/signalfx/splunk-synthetics-runner:latest
                    
```
プライベートランナーを手動でアップグレードする
1. 最新の Docker イメージをプルする：
```
docker pull 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
```
プライベートランナーを自動でアップグレードする

スケジュールに従ってリモート Docker リポジトリに接続して更新をチェックするサードパーティ製のオープンソース Docker コンテナである Watchtower などの自動アップグレードソリューションを使用して、プライベートロケーションの Docker イメージのアップグレードを自動化できます。このセクションでは Watchtower の使用方法について説明しますが、運用チームが Docker イメージの更新をデプロイするためのメカニズムをすでに確立している場合は、プライベートランナーに設定を変更せずに、既存のメカニズムを使用できます。ベストプラクティスは、少なくとも 24 時間ごとにアップグレードの自動化を実行することです。プライベートランナーを使用可能な最新のイメージに更新しないと、データに矛盾が生じ、機能が失われる可能性があります。

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 ファイルを作成します。 ENABLE_CLIENT_CERTS 環境変数は、このプライベートランナーで mTLS 認証を有効にする必要がある場合にのみ必要です。
```
version: '3'
services:
  runner:
    image: quay.io/signalfx/splunk-synthetics-runner:latest
    environment:
      RUNNER_TOKEN: YOUR_TOKEN_HERE
      ENABLE_CLIENT_CERTS: true
    cap_add:
      - NET_ADMIN
    restart: always
```
2. 以下のコマンドを実行してコンテナを起動します：
```
docker-compose up
```
プライベートランナーを手動でアップグレードする
1. docker-compose.ymlを含むディレクトリに移動します。
```
cd /path/to/your/docker-compose-file
```
2. 最新の Docker イメージをプルする：
```
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 forMacまたはWindows をインストールするためのドキュメントを参照してください。
2. 以下のフラグでDockerコンテナを起動します：
```
docker run -e "DISABLE_NETWORK_SHAPING=true" \
-e "RUNNER_TOKEN=YOUR_TOKEN_HERE" \
quay.io/signalfx/splunk-synthetics-runner:latest
```
プライベートランナーを手動でアップグレードする
1. 最新の Docker イメージをプルする：
```
docker pull 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 コンテナです。このセクションでは Watchtower の使用方法について説明しますが、運用チームが Docker イメージの更新をデプロイするためのメカニズムをすでに確立している場合は、プライベートランナーに設定を変更せずに、既存のメカニズムを使用できます。ベストプラクティスは、少なくとも 24 時間ごとにアップグレードの自動化を実行することです。プライベートランナーを使用可能な最新のイメージに更新しないと、データに矛盾が生じ、機能が失われる可能性があります。

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 が 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
```

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

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

AWS ECSコンソールで、Task definitionsにアクセスします。
黄色のドロップダウンメニューからCreate new task definition with JSONを選択します

以下の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"
}

Saveを選択し、JSON入力パネルを閉じます。
Createを選択してタスクを作成します。
[splunk-synthetics-runner] を使用して、クラスターにサービスを作成します。詳細は AWS のドキュメントを参照してください。

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

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

プライベートロケーションの Docker イメージのアップグレードは、スケジュールに従ってリモート Docker リポジトリに接続して更新をチェックするサードパーティのオープンソース Docker コンテナである Watchtower などの自動アップグレードソリューションを使用して自動化できます。このセクションでは Watchtower の使用方法について説明しますが、運用チームが Docker イメージの更新をデプロイするためのメカニズムをすでに確立している場合は、プライベートランナーに設定を変更せずに、既存のメカニズムを使用できます。ベストプラクティスは、少なくとも 24 時間ごとにアップグレードの自動化を実行することです。プライベートランナーを使用可能な最新のイメージに更新しないと、データに矛盾が生じ、機能が失われる可能性があります。

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

Amazon の Elastic Container Service で 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 uninstall コマンドを実行します。
```
helm uninstall my-splunk-synthetics-runner
```

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

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

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

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

デプロイ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

デプロイYAMLを適用する：
```
kubectl apply -f deployment.yaml
```

プライベートランナーをアップグレードするには、kubectl apply コマンドを実行します。
```
kubectl apply -f deployment.yaml
```
最新のタグと imagePullPolicy: Always を使用しているため、deployment.yaml ファイルに変更を加える必要はありません。デプロイを再適用すると、最新のイメージがプルされます。
プライベートランナーをアンインストールするには、kubectl delete コマンドを実行します。
```
kubectl delete -f deployment.yaml
```

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

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

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

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

デプロイ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

デプロイ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
```

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

最新の画像をプル：

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

実行中のコンテナを停止する：
```
podman stop container_id_or_name
```
古いコンテナを削除する：
```
podman rm container_id_or_name
```

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

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

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

最新の画像をプル：

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

実行中のコンテナを停止する：
```
podman stop container_id_or_name
```
古いコンテナを削除する：
```
podman rm container_id_or_name
```

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

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 分以内に合成テストを正常に取得できている場合、コンテナの状態は正常です。コンテナの状態が異常な場合は、次の順序でトラブルシューティングのヒントを試してください。

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

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

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

コンテナを自動的に再起動するには、ポッドの起動コマンド（docker runまたはpodman runなど）に--restart unless-stoppedと-e ALWAYS_HEALTHY=trueを追加する必要があります。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でのロギングを制限するには、以下の手順に従ってください：

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

ファイルに追加します：

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

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

証明書を追加する

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

ホストマシン上に certs というフォルダを作成し、その中に CA 証明書（CRT 形式）を配置します。
コンテナ (-v ./certs:/usr/local/share/ca-certificates/my_certs/) にボリュームとしてcertsフォルダを追加します。
コンテナ起動時に使用するコマンドを変更し、エージェントバイナリ (bash -c "sudo update-ca-certificates && bundle exec bin/start_runner) を起動する前に CA 証明書キャッシュを更新します。

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

docker run -e "RUNNER_TOKEN=YOUR_TOKEN_HERE" --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 検証を非アクティブにすることができます。クライアント証明書を使用するには、「mTLS 認証」を参照してください。

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

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

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=YOUR_TOKEN_HERE" -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のような特定のドメインのプロキシをバイパスするように設定されています。

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

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

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

no_proxy を設定する際には、必ず以下のアドレスを含めてください：
- 127.0.0.1 (localhost通信用)
- localhost (ローカルテストの解決用)
これらのアドレスは、プロキシを経由せずに内部サービスやテストが正しく実行されることを保証し、潜在的な障害を防ぎます。
Dockerfileデフォルトを理解する：

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

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