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. Select Create private location and add a name.

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コア

Supported platforms

• Docker

• Docker Compose

• AWS ECS

• Docker for Mac or Windows

• Helm

• Kubernetes

• OpenShift

• Podman

• Podman for MacOS or Windows

• ARM64 machines on AWS and GCP

Browser compatibility

The private runner uses a headless browser to run the browser tests. The private runner Docker image for AMD64 architecture contains the Chrome browser, and the private runner Docker image for ARM64 architecture contains the Chromium browser, because Chrome is unavailable for ARM64. Chrome and Chromium versions might not be the same.

To find the browser type and version, look at the labels browser-type and browser-version in the Docker image. You can find these labels either at http://quay.io/ or in the output of the following commands:

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

Required container permissions

This section outlines the minimum requirements for the container on which the private runner Docker image is running.

Minimum container permissions

The container must have the following permissions at a minimum. The private runner Docker image already has these permissions set up by default, so if you don’t change the container runtime user, you don’t need to take any action:

• Read and write access to the application’s home or working directory (usually this is /home/pptruser/)

• Read and write access to /tmp (the system grants this permission to all users by default)

注釈

Don’t set the container’s root filesystem to read-only (the readOnlyRootFilesystem flag), because this prevents the container from starting up.

Optional permissions for custom CA certificates

If the tests you send to the private runner need to use a custom CA certificate for API and uptime tests, the container must support privilege escalation in an init container, which adds the custom certificate to the runner’s system CA certificates. To allow privilege escalation, set containers.securityContext.allowPrivilegeEscalation to true:

containers:
  securityContext:
    allowPrivilegeEscalation: true

To verify that the container allows privilege escalation, see if it runs the sudo command.

Optional permissions for network shaping

If the tests you send to the private runner need to simulate different network throughputs, the Docker container must support privilege escalation along with the NET_ADMIN capability (for network shaping).

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

If you see the following warning message sudo: unable to send audit message: Operation not permitted, also add the AUDIT_WRITE capability:

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

Required container resources

The Docker container on which you deploy the private runner must have the following resources.

Increase the resources allocated to the private runner’s pod when you see:

• Browser crashes or errors

• Log messages indicating that there are errors spawning the browser

Minimum container resources

• CPUs: 1

• Memory: 2GB

Recommended container resources

• CPUs: 2

• Memory: 8GB

Resource intensive tests

The CPU and memory required for each test are heavily dependent on the test being executed. If the tests you send to the private runner are resource-intensive browser tests such as those listed below, the Docker container must have at least the recommended resources instead of the minimum resources.

• Loading complex webpages with high resolution images or complex JavaScript

• Media playback such as video streaming

• Heavy JavaScript execution such as extensive DOM manipulations or memory hogging

• Loading and interacting with large data sets (for example, sorting, filtering, or searching operations)

• Uploading or downloading large files

These are only some examples of resource-intensive browser tests; your test cases may vary.

Private runners on Docker

Install a private runner

Start your container using the Docker run command and the following flags:

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

Upgrade a private runner

Manual upgrades

To upgrade the Docker image manually, follow these steps:

1. Pull the latest image:

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

2. Stop the running container:

   docker stop <container_id_or_name>
   

3. Remove the old container:

   docker rm <container_id_or_name>
   

4. Start a new container with the updated image:

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

Automatic upgrades

You can automate the upgrade of the private location Docker images by using an automated upgrade solution such as Watchtower , a third party open-source Docker container that connects to remote Docker repositories on a schedule and checks for updates. This section explains how to use Watchtower, but if your operations team already has a mechanism established for deploying updates to Docker images you can use your existing mechanism without making any configuration changes to the private runner. The best practice is to run your upgrade automation at least once every 24 hours. Failing to update the private runner to the latest available image may result in inconsistent data and loss of functionality.

When Watchtower finds an updated image, it instructs your Docker host to pull the newest image from the repository, stop the container, and start it again. It also ensures that environment variables, network settings, and links between containers are intact.

On your Docker host, launch the Watchtower container from command line:

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

Using the label-enable flag ensures that only containers with the correct label, like the Splunk private runner, are auto-updated.

There are additional options available in the Watchtower documentation that you can explore, including auto-cleanup of old images to ensure that your Docker host does not hold onto outdated images.

注釈

For Watchtower to issue commands to the Docker host, it requires the docker.sock volume or TCP connection, which provides Watchtower with full administrative access to your Docker host. If you are unable to provide Watchtower with this level of access, you can explore other options for automating updates.

Uninstall a private runner

1. List all containers:

   docker ps -a
   

2. Remove a stopped container by ID or name:

   docker rm <container_id_or_name>
   

3. Force-remove a running container:

   docker rm -f my_running_container
   

Private runners on Docker Compose

The private runner should work on all the latest versions of Docker Compose.

Install a private runner

1. Create a docker-compose.yml file with the following definition:

   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. Run the following command to start the container:

   docker-compose up
   

Upgrade a private runner

Manual upgrades

To upgrade the Docker image manually, follow these steps:

1. Navigate to the directory containing your docker-compose.yml

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

2. Pull the latest images:

   docker-compose pull
   

3. Recreate containers with the updated images:

   docker-compose up -d
   

Automatic upgrades

You can automate the upgrade process by using your CI/CD pipelines or by using Watchtower.

Uninstall a private runner

1. Navigate to your project directory:

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

2. Run the docker-compose down command:

   docker-compose down
   

Private runners on Docker for Mac or Windows

Install a private runner

1. Install Docker. For steps, see the docs to install Docker Community Edition for Mac or for Windows .

2. Start your Docker container with the following flags:

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

Upgrade a private runner

Manual upgrades

To upgrade the Docker image manually, follow these steps:

1. Pull the latest image:

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

2. Stop the running container:

   docker stop <container_id_or_name>
   

3. Remove the old container:

   docker rm <container_id_or_name>
   

4. Start a new container with the updated image:

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

Automatic upgrades

You can automate the upgrade of the private location Docker images by using an automated upgrade solution such as Watchtower , a third-party open source Docker container that connects to remote Docker repositories on a schedule and checks for updates. This section explains how to use Watchtower, but if your operations team already has a mechanism established for deploying updates to Docker images, you can use your existing mechanism without making any configuration changes to the private runner. The best practice is to run your upgrade automation at least once every 24 hours. Failing to update the private runner to the latest available image may result in inconsistent data and loss of functionality.

When Watchtower finds an updated image, it instructs your Docker host to pull the newest image from the repository, stop the container, and start it again. It also ensures that environment variables, network settings, and links between containers are intact.

On your Docker host, launch the Watchtower container from the command line:

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

Using the label-enable flag ensures that only containers with the correct label, like the Splunk private runner, are be auto-updated.

There are additional options available in the Watchtower documentation that you can explore, including auto-cleanup of old images to ensure that your Docker host does not hold onto outdated images.

注釈

In order for Watchtower to issue commands to the Docker host, it requires the docker.sock volume or TCP connection, which provides Watchtower with full administrative access to your Docker host. If you are unable to provide Watchtower with this level of access you can explore other options for automating updates.

Uninstall a private runner

To upgrade the Docker image manually, follow these steps:

1. List all containers:

   docker ps -a
   

2. Remove a stopped container by ID or name:

   docker rm <container_id_or_name>
   

3. Force-remove a running container:

   docker rm -f my_running_container
   

Private runners on AWS ECS

Install a private runner

1. In your AWS ECS console, go to Task definitions.

2. Select Create new task definition with JSON from the yellow dropdown menu.

3. Copy the following JSON and paste it into the console:

    {
     "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. Select Save to close the JSON input panel.

5. Select Create to create the task.

6. Create a service in your cluster using the splunk-synthetics-runner. For steps, see the AWS documentation.

Upgrade a private runner

Manual upgrades

You can upgrade the runner by using the forceNewDeployment option. This shuts down the existing container and brings up a new container by pulling the latest image from the repository.

Automatic upgrades

You can automate the upgrade of the private location Docker images by using an automated upgrade solution such as Watchtower , a third party open source Docker container that connects to remote Docker repositories on a schedule and checks for updates. This section explains how to use Watchtower, but if your operations team already has a mechanism established for deploying updates to Docker images you can use your existing mechanism without making any configuration changes to the private runner. The best practice is to run your upgrade automation at least once every 24 hours. Failing to update the private runner to the latest available image may result in inconsistent data and loss of functionality.

When Watchtower finds an updated image, it instructs your Docker host to pull the newest image from the repository, stop the container, and start it again. It also ensures that environment variables, network settings, and links between containers are intact.

To use Watchtower with Amazon’s Elastic Container Service, you need to create a task definition for it. For example, here is a sample task definition that you can run as a DAEMON within your cluster.

{
  "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"
}

Uninstall a private runner

1. Open the console at https://console.aws.amazon.com/ecs/v2.

2. From the navigation bar, select the region that contains your task definition.

3. In the navigation pane, select Task definitions.

4. On the Task definitions page, select the task definition family that contains one or more revisions that you want to deregister.

5. On the Task definition name page, select the revisions to delete, and then select Actions and Deregister.

6. Verify the information in the Deregister window, and then select Deregister to finish.

Private runners deployed with Helm

Install a private runner

For Helm deployments, you can either use the latest image and pullPolicy or a tagged image.

To install the chart with the release name my-splunk-synthetics-runner, run the following commands. For more information, see 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

Upgrade a private runner

Run the helm upgrade command:

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

If you’re upgrading to an image that has major version change, you must also upgrade your Helm chart.

Uninstall a private runner

Run the helm uninstall command:

helm uninstall my-splunk-synthetics-runner

Private runners on Kubernetes

Install a private runner

1. Create a Kubernetes Secret with the runner token:

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

2. Create the deployment 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. Apply the Deployment YAML:

   kubectl apply -f deployment.yaml
   

Upgrade a private runner

Run the kubectl apply command:

kubectl apply -f deployment.yaml

Since you’re using the latest tag with imagePullPolicy: Always, you don’t need to make changes to the deployment.yaml file. Reapplying the deployment pulls the latest image.

Uninstall a private runner

Run the kubectl delete command:

kubectl delete -f deployment.yaml

Private runners on OpenShift

Install a private runner

1. Create a OpenShift Secret with the runner token:

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

2. Create the deployment 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. Apply the deployment YAML:

   oc apply -f deployment.yaml
   

Upgrade a private runner

Run the oc apply command:

oc apply -f deployment.yaml

Since you’re using the latest tag with imagePullPolicy: Always, you don’t need to make changes to the deployment.yaml file. Reapplying the deployment pulls the latest image.

Uninstall a private runner

Run the oc delete command:

oc delete -f deployment.yaml

Private runners on Podman

Install a private runner

Start your container using the Podman run command and the following flags.

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

Upgrade a private runner

1. Pull the latest image:

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

2. Stop the running container:

   podman stop <container_id_or_name>
   

3. Remove the old container:

   podman rm <container_id_or_name>
   

4. Start a new container with the updated image:

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

Uninstall a private runner

1. List all containers:

   podman ps -a
   

2. Remove a stopped container by ID or name:

   podman rm <container_id_or_name>
   

3. Force remove a running container:

   podman rm -f my_running_container
   

Private runners on Podman for MacOS or Windows

Install a private runner

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

Upgrade a private runner

1. Pull the latest image:

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

2. Stop the running container:

   podman stop <container_id_or_name>
   

3. Remove the old container:

   podman rm <container_id_or_name>
   

4. Start a new container with the updated image:

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

Uninstall a private runner

1. List all containers:

   podman ps -a
   

2. Remove a stopped container by ID or name:

   podman rm <container_id_or_name>
   

3. Force remove a running container:

   podman rm -f my_running_container
   

Private runners on ARM64 machines on AWS and GCP

There are no special instructions to install or upgrade a Docker image running on an ARM64-based machine. You can deploy this image manually with Docker or Docker Compose, deploy it to Kubernetes hosted on AWS EKS, GCP GKE, self-hosted, or deploy it on AWS ECS.

The Docker manifest contains information about available platforms and links to the correct images. So, for example, when you run the command docker run http://quay.io/signalfx/splunk-synthetics-runner:latest Docker downloads the correct image based on the architecture of your machine.

Troubleshoot a private runner

Docker health check

The private location Docker image utilizes the Docker health check to communicate when its container has entered an unhealthy state. The container state is healthy if the private runner is able to authenticate with the API and has successfully fetched a synthetics test in the last 30 minutes. If the container state is unhealthy, try the following troubleshooting tips in this order:

1. Check the logs of the container to see if there is an authentication error. If there is, confirm that you specified the correct value for the RUNNER_TOKEN environment variable at pod startup.

2. Restart the container.

Automatically restart unhealthy Docker containers

If you plan on running a private location for an extended period of time, it can be helpful to allow the container to automatically restart in the event that it becomes unhealthy.

To automatically restart the container you must add --restart unless-stopped and -e ALWAYS_HEALTHY=true to the pod startup command (docker run or podman run and so on). The ALWAYS_HEALTHY=true environment variable terminates the Docker container as soon as it fails a health check. This option works on any Docker restart policy.

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

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

When using a private runner, it’s important to correctly configure the proxy settings to avoid issues with browser-based tests. Follow these steps when setting up the environment of the private runners:

1. Ensure proper no_proxy setup:

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

   • 127.0.0.1 (localhost通信用)

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

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

2. Understand Dockerfile defaults:

   デフォルトでは、プライベートランナーは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