--- title: Install synthetics job manager source: https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/install-job-manager --- Our synthetic monitoring job managers are [container](https://www.docker.com/resources/what-container)-based resources that accept and execute [synthetic monitors](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/intro-synthetic-monitoring/#types-of-synthetic-monitors) assigned to [private locations](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/private-locations-overview-monitor-internal-sites-add-new-locations). The job manager can operate in a Docker container system environment, a Podman container system environment, Kubernetes container orchestration system environment, or an OpenShift container system environment. > #### ⚠️ IMPORTANT > > If you're migrating from Node.js 16 / Chrome 134 runtimes to Node.js 22 / Chrome 146, see the [private location runtime transition guide](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/runtime-transition-guide) for migration strategies, deployment examples, and troubleshooting steps. ## Synthetics job manager features [#enhancements] Because the synthetics job manager operates as a container instead of a virtual machine, we've simplified [installation](#install), [getting started ](#start), and [updating](#install) your job management and orchestration. It also comes with some additional functionality: - Compatible with Linux, [macOS](https://docs.docker.com/docker-for-mac/), and [Windows](https://docs.docker.com/docker-for-windows/). - Enhanced [security](#security) and support for [non-root](#run-as-non-root) user execution. - Ability to leverage a Docker container as a [sandbox](#docker-dependencies) environment. ## Kubernetes-specific features [#kubernetes-enhancements] The job manager introduces some additional Kubernetes-specific functionality: - Uses Kubernetes CronJob resources to run non-ping monitors - Doesn't require privileged access to the Docker socket - Supports hosted and on-premise Kubernetes clusters - Supports various container engines such as Docker and Containerd - Deployable via Helm charts as well as configuration YAMLs - Allows configurable job runtime (ping, API, and browser) based resource allocation for optimum resource management - Observability offered via the New Relic Kubernetes cluster explorer ## Version requirements [#version-requirements] Some capabilities require a minimum version of job manager and runtime container images. | Capability | Job manager version | Runtime version(s) | | ------------------------- | ------------------- | ----------------------------------------------------- | | Step monitor | release-332 | Node browser runtime v2.2.22 | | Broken links monitor | release-341 | Node API runtime v1.2.54 | | Certificate check monitor | release-341 | Node API runtime v1.2.54 | | VSE support | release-345 | N/A | | User-Defined Variables | release-347 | N/A | | Custom node modules | release-363 | Node browser runtime v2.2.49 Node API runtime v1.2.63 | ## System requirements and compatibility [#system-requirements] To host synthetics job managers, your system must meet the minimum requirements for the chosen system environment. > #### ⚠️ CAUTION > > Do not modify any synthetics job manager files. New Relic is not liable for any modifications you > make. For more information, contact your account representative or a New Relic > [technical sales rep](https://newrelic.com/contact-sales). **Docker container system environment requirements** | Compatibility for | Requirements | | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Operating system | **Linux kernel:** 4.18 or higher (Recommended for v447+) **macOS:** 10.11 or higher **Windows:** Windows 10 64-bit or higher You must also configure Docker to run Linux containers in order for synthetics job managers to work on Windows systems. | | Processor | A modern, multi-core AMD64 or x86_64 CPU | | Memory | 3.256 GiB of RAM per CPU core (dedicated) | | Disk size | A minimum of 50 GiB per host | | Disk file system | NFSv4.1 or higher (if using NFS) | | [Docker version](https://docs.docker.com/engine/release-notes/) | Docker [17.12.1-ce](https://docs.docker.com/engine/release-notes/17.12/) or higher | | Private location key | You must have a [private location key](#private-location-key) | > #### ⚠️ CAUTION > > The Docker synthetics job manager is not designed for use with container orchestrators such as, AWS ECS, Docker Swarm, Apache Mesos, Azure Container Instances, etc. Running the Docker synthetics job manager in a container orchestrator results in unexpected issues as it functions as an orchestrator itself. If you're using container orchestration, see our [Kubernetes synthetics job manager requirements](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/install-job-manager/#kubernetes-requirements). > #### ⚠️ CAUTION > > Starting with Synthetics Job Manager v447 (which uses Ubuntu 24.04 as its base image), RHEL 7 and other distributions using Linux kernel versions older than 4.18 are no longer supported due to modern glibc and seccomp requirements. For a stable experience, use RHEL 8/9 or an equivalent modern Linux distribution. **Podman container system environment requirements** | Compatibility for | Requirements | | --------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | Operating system | **Linux kernel:** 4.18 or higher (Recommended for v447+) | | Processor | A modern, multi-core AMD64 or x86_64 CPU | | Memory | 3.256 GiB of RAM per CPU core (dedicated) | | Disk size | A minimum of 50 GiB per host | | Disk file system | NFSv4.1 or higher (if using NFS) | | [Podman version](https://github.com/containers/podman/releases) | Podman [5.0.0-ce](https://github.com/containers/podman/releases/tag/v5.0.0) or higher | | Private location key | You must have a [private location key](#private-location-key) | > #### ⚠️ CAUTION > > The Podman synthetics job manager is not designed for use with container orchestrators such as, AWS ECS, Docker Swarm, Apache Mesos, Azure Container Instances, etc. Running the Docker synthetics job manager in a container orchestrator results in unexpected issues as it functions as an orchestrator itself. If you're using container orchestration, see our [Kubernetes synthetics job manager requirements](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/install-job-manager/#kubernetes-requirements). **Kubernetes container orchestration system environment requirements** | Compatibility for | Requirements | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Operating system | **Linux kernel:** 4.18 or higher (Recommended for v447+) **macOS:** 10.11 or higher Linux containers, including job manager, only run on Linux K8s nodes. | | Processor | A modern, multi-core CPU | | Synthetics job manager pod | **CPU (vCPU/Core):** 0.5 up to 0.75 **Memory:** 800Mi up to 1600Mi Resources allocated to a synthetics job manager pod are user configurable. | | Ping runtime pod | **CPU (vCPU/Core):** 0.5 up to 0.75 **Memory:** 500Mi up to 1Gi Additional considerations: - Resources allocated to a ping runtime pod are user configurable. - The maximum limit-request resource ratio for both CPU and memory is 2. | | Node.js API runtime pod | **CPU (vCPU/Core):** 0.5 up to 0.75 **Memory:** 1250Mi up to 2500Mi Additional considerations: - Resources allocated to a Node.js API runtime pod are user configurable. - The maximum limit-request resource ratio for both CPU and memory is 2. | | Node.js browser runtime pod | **CPU (vCPU/Core):** 1.0 up to 1.5 **Memory:** 2000Mi up to 3000Mi Additional considerations: - Resources allocated to a Node.js browser runtime pod are user configurable. - The maximum limit-request resource ratio for both CPU and memory is 2. | | Disk size | **Root volume:** A minimum of 50 GiB | | Disk file system | NFSv4.1 or higher (if using NFS) | | Kubernetes version | [Kubernetes v1.21](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/) or newer is required. | | Private location key | You must have a [private location key](#private-location-key) | | Helm | Follow [installation instructions for Helm v3](https://helm.sh/docs/intro/install/) for your OS. | | Kubectl | Follow [installation instructions for Kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) for your OS. | To view versions, dependencies, default values for how many runtime pods start with each synthetics job manager and more, please see [Show help and examples](#help) below. **OpenShift container system environment requirements** | Compatibility for | Requirements | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Operating system | **Linux kernel:** [4.18 or higher (Recommended for v447+)](https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html/deploying_installer-provisioned_clusters_on_bare_metal/ipi-install-prerequisites#minimum-resource-requirements) **macOS:** 10.11 or higher Linux containers, including job manager, only run on Linux K8s nodes. | | Processor | A modern, multi-core `AMD64` or `x86_64 CPU` | | Ping runtime pod | **CPU (vCPU/Core):** 0.5 up to 0.75 **Memory:** 500Mi up to 1Gi Additional considerations: - Resources allocated to a ping runtime pod are user configurable. - The maximum limit-request resource ratio for both CPU and memory is 2. | | Node.js API runtime pod | **CPU (vCPU/Core):** 0.5 up to 0.75 **Memory:** 500Mi up to 1Gi Additional considerations: - Resources allocated to a ping runtime pod are user configurable. - The maximum limit-request resource ratio for both CPU and memory is 2. | | Node.js API runtime pod | **CPU (vCPU/Core):** 0.5 up to 0.75 **Memory:** 1250Mi up to 2500Mi Additional considerations: - Resources allocated to a Node.js API runtime pod are user configurable. - The maximum limit-request resource ratio for both CPU and memory is 2. | | Node.js browser runtime pod | **CPU (vCPU/Core):** 1.0 up to 1.5 **Memory:** 2000Mi up to 3000Mi Additional considerations: - Resources allocated to a Node.js browser runtime pod are user configurable. - The maximum limit-request resource ratio for both CPU and memory is 2. | | Disk size | **Root volume:** A minimum of 50 GiB | | Disk file system | NFSv4.1 or higher (if using NFS) | | Version | Version 4.11 and later. | | Private location key | You must have a [private location key](#private-location-key) | | Helm | Follow [installation instructions for Helm v3](https://helm.sh/docs/intro/install/) for your OS. | To view versions, dependencies, default values for how many runtime pods start with each synthetics job manager and more, please see [Show help and examples](#help) below. ## Private location key Before launching synthetics job managers, you must have a [private location key](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/private-locations-overview-monitor-internal-sites-add-new-locations#create-location). Your synthetics job manager uses the key to authenticate against New Relic and run monitors associated with that private location. To find the key for existing private location: 1. Go to **[one.newrelic.com > Synthetic monitoring > Private locations](https://one.newrelic.com/synthetics-nerdlets/private-location-list)**. 2. In the **Private locations** index, locate the private location you want your synthetics job manager to be assigned to. 3. Note the key associated with the private location with the key icon. ## Install, update, and configure synthetics job manager [#install] If you're running more than one Docker or Podman private location container on the same host, you'll have port conflicts. To avoid this port contention, make sure to run each job manager on a separate host. Synthetics job manager images are hosted on [Docker Hub](https://hub.docker.com/). Go to [hub.docker.com/r/newrelic/synthetics-job-manager/tags](https://hub.docker.com/r/newrelic/synthetics-job-manager/tags) for a list of all the releases. Unless you are hosting the images in a local image repository, you need to allow connections to `docker.io` through your firewall so that Docker or Podman can pull the synthetics job manager and synthetics runtime images. When the synthetics job manager starts up, the runtime images are pulled automatically. See [Docker environment configuration](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration/#docker-env-config), [Podman environment configuration](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration/#podman-env-config), and [Kubernetes environment configuration](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration/#kubernetes-env-config) for details on how to set a local repository and the runner registry endpoint. For more details on advanced configuration settings, see [synthetics job manager configuration](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration). ## Start synthetics job manager [#start] Following are the applicable Docker, Podman, or Kubernetes instructions to start the job manager. **Docker start procedure** 1. Locate your [private location key](#private-location-key). 2. Ensure you've enabled [Docker dependencies](#docker-dependencies) for sandboxing and [installed](#install-update) synthetics job manager on your system. 3. Run the appropriate script for your system. Tailor the common default `/var/run/docker.sock` in the following examples to match your system. - Linux/macOS: ```shell docker run \ --name YOUR_CONTAINER_NAME \ -e "PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY" \ -v /var/run/docker.sock:/var/run/docker.sock:rw \ -d \ --restart unless-stopped \ newrelic/synthetics-job-manager:latest ``` - Windows: ```shell docker run ^ --name YOUR_CONTAINER_NAME ^ -e "PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY" ^ -v /var/run/docker.sock:/var/run/docker.sock:rw ^ -d ^ --restart unless-stopped ^ newrelic/synthetics-job-manager:latest ``` View the logs for your job manager container: ```shell docker logs --follow YOUR_CONTAINER_NAME ``` **Podman start procedure** 1. Locate your [private location key](#private-location-key). 2. Ensure you've enabled [Podman dependencies](#podman-dependencies) for sandboxing and [installed](#install-update) synthetics job manager on your system. 3. Run the below script for your system. To create a pod in Linux and add the host machine's IP address: ``` podman pod create --network slirp4netns --name YOUR_POD_NAME --add-host=podman.service:HOST_IP_ADDRESS ``` To start tart the Job Manager: ``` podman run \ --name YOUR_CONTAINER_NAME \ --pod YOUR_POD_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" \ -d \ --restart unless-stopped \ newrelic/synthetics-job-manager:latest ``` To view the logs for your job manager container: ``` podman logs --follow YOUR_CONTAINER_NAME ``` **Kubernetes start procedure** 1. Locate your [private location key](#private-location-key). 2. Set up the a namespace for the synthetics job manager in your Kubernetes cluster: ```shell kubectl create namespace YOUR_NAMESPACE ``` 3. Copy the Helm charts from the New Relic Helm repo. - If you are copying the charts for the first time: ```shell helm repo add YOUR_REPO_NAME https://helm-charts.newrelic.com ``` - If you previously copied the Helm charts from the New Relic Helm repo, then get the latest: ```shell helm repo update ``` 4. Install synthetics job manager with the following Helm command: - For a fresh installation of the synthetics job manager: ``` helm install YOUR_JOB_MANAGER_NAME YOUR_REPO_NAME/synthetics-job-manager -n YOUR_NAMESPACE --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY ``` - To update an existing synthetics job manager installation: ```shell helm upgrade YOUR_JOB_MANAGER_NAME YOUR_REPO_NAME/synthetics-job-manager -n YOUR_NAMESPACE --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY ``` 5. Check if the synthetics job manager pod is up and running: ```shell kubectl get -n YOUR_NAMESPACE pods ``` Once the `status` attribute of each pod is shown as `running`, your synthetics job manager is up and ready to run monitors assigned to your private location. **OpenShift start procedure** Ensure you have the [OpenShift CLI (oc)](https://docs.redhat.com/en/documentation/openshift_container_platform/4.8/html/cli_tools/openshift-cli-oc) installed to run commands via OpenShift cli. 1. Locate your [private location key](#private-location-key). 2. Login to your OpenShift project: ```shell oc project your_namespace ``` 3. Create image tag using command: ```shell oc create imagestream image_streame_name -n your_namespace ``` 4. Create `buildConfig.yaml` ```dockerfile apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: synthetics-node-api-runtime-build namespace: spec: output: to: kind: ImageStreamTag name: : source: type: Dockerfile dockerfile: |- FROM newrelic/synthetics-node-api-runtime:latest USER root RUN setcap -r /usr/bin/node USER 2000 strategy: type: Docker dockerStrategy: platform: architecture: amd64 postCommit: {} triggers: - type: ConfigChange - type: ImageChange imageChange: from: kind: ImageStreamTag name: :latest ``` 5. Apply the `BuildConfig`: ```shell oc create -f buildConfig.yaml ``` 6. (Optional) Start the build (If build doesn’t auto starts, run this command): ```shell oc start-build synthetics-node-api-runtime-build -n your-namespace ``` > #### ⚠️ IMPORTANT > > Monitor the build progress using: > > ```shell > oc logs -f bc/synthetics-node-api-runtime-build -n synthetics > ``` 7. Deploy with Helm: - Run this command to add the New Relic Helm chart repository to your local Helm configuration, allowing you to easily install the Kubernetess integrations. ```shell helm repo add newrelic https://helm-charts.newrelic.com ``` - Run below command to run SJM in your private location on OpenShift: ```shell helm install release_name newrelic/synthetics-job-manager -n your_namespace --set synthetics.privateLocationKey=private_location_key --set image_stream_name.image.repository=image_repo --set image_stream_name.appVersionOverride=tag ``` - **release_name**: any name you want to give to your image. - **your_namespace**: as mentionml file. - **private_location_key**: unique key corresponding to your private location. - **image_stream_name**: as mentioned in builded in buildConfig yaConfig yaml file. - **tag**: as mentioned in buildConfig yaml file. - **image_repo**: - run oc registry info in terminal to fetch registry url. - image_repo is a combination of registry url, `your_namespace`, `your_output_image_name` as mentioned in buildConfig yaml file separated by forward slash. registery_url/your_namespace/your_output_image_name Let us consider the following example: ```shell helm install synthetics-kevin newrelic/synthetics-job-manager -n synthetics --set synthetics.privateLocationKey= --set node-api-runtime.image.repository=default-route-openshift-image-registry.apps-crc.testing/synthetics/synthetics-node-api-runtime --set node-api-runtime.appVersionOverride=custom ``` 8. Check the synthetics job manager pod is up and running: ```shell oc get pods -n your-namespace ``` ## Stop or delete the synthetics job manager [#stop] On a Docker or Podman container system environment, use the respective `stop` procedure to stop the synthetics job manager. On a Kubernetes container orchestration system environment, use the Kubernetes `delete` procedure to stop the synthetics job manager from running. **Docker stop procedure** You can [stop a Docker container](https://docs.docker.com/engine/reference/commandline/stop/) either by the container name, or the container ID. - Container name stop for Linux, macOS, and Windows: ```shell docker stop YOUR_CONTAINER_NAME docker rm YOUR_CONTAINER_NAME ``` - Container ID stop for Linux/macOS: In the examples the container is stopped and removed. To only stop the container, omit `docker rm $CONTAINER_ID`. ```shell CONTAINER_ID=$(docker ps -aqf name=YOUR_CONTAINER_NAME) docker stop $CONTAINER_ID docker rm $CONTAINER_ID ``` - Container ID stop for Windows: In the examples the container is stopped and removed. To only stop the container, omit `docker rm $CONTAINER_ID`. ```shell 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% ``` **Podman stop procedure** You can [stop a Podman container](https://docs.podman.io/en/stable/markdown/podman-stop.1.html) either by the container name, or the container ID. - Container name stop for Linux: ``` podman stop YOUR_CONTAINER_NAME podman rm YOUR_CONTAINER_NAME ``` - Container ID stop for Linux: In the examples the container is stopped and removed. To only stop the container, omit `podman rm $CONTAINER_ID`. ``` CONTAINER_ID=$(podman ps -aqf name=YOUR_CONTAINER_NAME) podman stop $CONTAINER_ID podman rm $CONTAINER_ID ``` **Kubernetes delete procedure** 1. Get the `JOB_MANAGER_POD_INSTALLATION_NAME` of the synthetics job manager pod you want to delete: ```shell helm list -n YOUR_NAMESPACE ``` 2. Delete the job manager pod: ```shell helm uninstall -n YOUR_NAMESPACE JOB_MANAGER_POD_INSTALLATION_NAME ``` 3. Delete the namespace set up for the synthetics job manager in your Kubernetes cluster: ```shell kubectl delete namespace YOUR_NAMESPACE ``` **OpenShift delete procedure** ````shell helm uninstall release_name -n your_namespace ``` ```` ## Sandboxing and Dependencies [#sandboxing-and-deps] Sandboxing and dependencies are applicable to the synthetics job manager in a Docker or Podman container system environment. **Docker dependencies** The synthetics job manager runs in Docker and is able to leverage Docker as a sandboxing technology. This ensures complete isolation of the monitor execution, which improves security, reliability, and repeatability. Every time a scripted or browser monitor is executed, the synthetics job manager creates a brand new Docker container to run it in using the matching runtime. The synthetics job manager container needs to be configured to communicate with the Docker engine in order to spawn additional runtime containers. Each spawned container is then dedicated to run a check associated with the [synthetic monitor](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/using-monitors/add-edit-monitors) running on the private location the synthetics job manager container is associated with. There is a crucial dependency at launch. To enable sandboxing, ensure that: - Your writable Docker UNIX socket is mounted at `/var/run/docker.sock` or `DOCKER_HOST` [environment variable](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration/#environment-variables). For more information, see Docker's [Daemon socket option](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-socket-option). > #### ⚠️ CAUTION > > Core count on the host determines how many runtime containers the synthetics job manager can run concurrently on the host. Since memory requirements are scaled to the expected count of runtime containers, we recommend **not running multiple synthetics job managers on the same host** to avoid resource contention. For additional information on sandboxing and running as a root or non-root user, see [Security, sandboxing, and running as non-root](#run-non-root). **Podman dependencies** The synthetics job manager runs in Podman and is able to leverage Podman as a sandboxing technology. This ensures complete isolation of the monitor execution, which improves security, reliability, and repeatability. Every time a scripted or browser monitor is executed, the synthetics job manager creates a brand new Podman container to run it in using the matching runtime. The synthetics job manager container needs to be configured to communicate with the Podman engine in order to spawn additional runtime containers. Each spawned container is then dedicated to run a check associated with the [synthetic monitor](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/using-monitors/add-edit-monitors) running on the private location the synthetics job manager container is associated with. There is a crucial dependency at launch. To enable sandboxing, ensure that you have: 1. Installed the Podman [5.0.0-ce](https://github.com/containers/podman/releases/tag/v5.0.0) or higher. 2. Enabled the Rootless execution: - Set up Podman to run containers without requiring root privileges. ``` mkdir -p ~/.config/containers touch ~/.config/containers/containers.conf vi ~/.config/containers/containers.conf ``` - Edit the `containers.conf` file to configure Podman to use `crun` and `systemd`: ``` [engine] runtime = "crun" cgroup_manager = "systemd" ``` 3. Enabled the cgroups v2 (RHEL Only): - Edit the GRUB to enable cgroups v2, this ensures compatibility with modern container runtimes in RHEL. ``` sudo sed -i 's/GRUB_CMDLINE_LINUX="/&systemd.unified_cgroup_hierarchy=1 /' /etc/default/grub sudo grub2-mkconfig -o /boot/grub2/grub.cfg sudo reboot ``` 4. Enabled the system-wide delegation to allow `cgroups` delegation for the Podman services. ``` 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 ``` 5. Set up the user-level `systemd` service: - Create directories for the user-level `systemd` services. ``` mkdir -p ~/.config/systemd/user/podman.service.d ``` - Add delegate configuration to the user-level `systemd` service. ``` echo -e "[Service]\nDelegate=yes" > ~/.config/systemd/user/podman.service.d/override.conf ``` 6. Enabled and started the Podman socket. ``` systemctl --user enable podman.socket systemctl --user start podman.socket systemctl --user status podman.socket ``` 7. Created and configured the Podman API service: - Create a Podman API service, sets up Podman to provide HTTP API access. ``` mkdir -p ~/.config/systemd/user touch ~/.config/systemd/user/podman-api.service vi ~/.config/systemd/user/podman-api.service ``` - Define the service to expose the Podman's API at port 8000. ``` [Unit] Description=Podman API Service After=default.target [Service] Type=simple ExecStart=/usr/bin/podman system service -t 0 tcp:0.0.0.0:8000 Restart=on-failure [Install] WantedBy=default.target ``` 8. Enabled and started the Podman API service. ``` systemctl --user daemon-reload systemctl --user enable podman-api.service systemctl --user start podman-api.service systemctl --user status podman-api.service ``` > #### ⚠️ CAUTION > > Core count on the host determines how many runtime containers the synthetics job manager can run concurrently on the host. Since memory requirements are scaled to the expected count of runtime containers, we recommend **not running multiple synthetics job managers on the same host** to avoid resource contention. ## Security, sandboxing, and running as non-root [#security] By default, the software running inside a synthetics job manager is executed with `root` user privileges. This is suitable for most scenarios, as the execution is sandboxed. To run the synthetics job manager as a non-root user, additional steps are required: **Run as non-root user for Docker** For more information, see Docker's official documentation about [security](https://docs.docker.com/engine/security/security/) and [AppArmor security profiles](https://docs.docker.com/engine/security/apparmor/). If your environment requires you to run the synthetics job manager as a non-root user, follow this procedure. In the following example, the non-root user is `my_user`. 1. Ensure that `my_user` can use the Docker engine on the host: Verify that `my_user` [belongs to the `"docker"` system group](https://docs.docker.com/engine/install/linux-postinstall/). Scoped root access to the `docker.sock` is still needed to create bridge networks. OR Enable the [Docker TCP socket option](https://docs.docker.com/engine/reference/commandline/dockerd/#examples), and pass the `DOCKER_HOST` [environment variable](#environemnt-variables) to synthetics job manager. 2. Verify that `my_user` has read/write permissions to all the directories and volumes passed to synthetics job manager. To set these permission, use the `chmod` command. 3. Get the `uid` of `my_user` for use in the run command: `id -u my_user`. Once these conditions are met, use the option `"-u :"` when launching synthetics job manager: ```shell docker run ... -u 1002 ... ``` OR ```shell docker run ... -u 1002 -e DOCKER_HOST=http://localhost:2375 ... ``` ## Understand your Docker, Podman, Kubernetes or OpenShift environments [#understand] Below is additional information about maintaining and understanding the job manager's container environment. View license information, understand the job manager's network settings, and check out the Docker image repo. **Maintain the job manager** Use these options as applicable: - To keep track of Docker or Podman logs and verify the health of your monitors, see [synthetics job manager maintenance and monitoring](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/job-manager-maintenance-monitoring). - For a synthetics job manager in the **OpenShift** and **Kubernetes** container orchestration system environment, the following Helm `show` commands can be used to view the `chart.yaml` and the `values.yaml`, respectively: ```shell helm show chart YOUR_REPO_NAME/synthetics-job-manager ``` ```shell helm show values YOUR_REPO_NAME/synthetics-job-manager ``` **Show license information** Some of our open-source software is listed under multiple software licenses, and in that case we have listed the license we've chosen to use. Our license information is also available in the [our licenses documentation](https://docs.newrelic.com/docs/licenses/new-relic-products/new-relic-synthetics/new-relic-synthetics-licenses). **Network settings** For both Docker and Kubernetes, the synthetics job manager and its runtime containers will inherit network settings from the host. For an example of this on a Docker container system environment, see the [Docker site](https://docs.docker.com/config/containers/container-networking/). A bridge network is created for communication between the synthetics job manager and runtime containers. This means networking command options like `--network` and `--dns` passed to the synthetics job manager container at launch (such as through Docker run commands on a Docker container system environment) are not inherited or used by the runtime containers. When these networks are created, they pull from the default IP address pool configured for daemon. For an example of this on a Docker container system environment, see the [Docker site](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file). In case of Podman, we don't use bridge network for communication between the synthetics job manager and runtime containers instead we use a Podman Pod. All containers in a Podman pod share the same network namespace. This means they share the same IP address within that pod. In this case the although the containers share the same IP, their services are exposed on different ports. **Docker image repository** A single synthetics job manager Docker image serves the **Docker**, **Podman**, **OpenShift**, and **Kubernetes** container orchestration system environment. The Docker image is hosted on the Docker Hub. To make sure your Docker image is up-to-date, see the [Docker Hub newrelic/synthetics-job-manager repository](https://hub.docker.com/r/newrelic/synthetics-job-manager/tags). ## Additional considerations for synthetics job manager connection [#FAQ] | Connection | Description | | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Synthetics job managers without Internet access | A synthetics job manager can operate without access to the internet, but with some exceptions. The synthetics job manager needs to be able to contact the `"synthetics-horde.nr-data.net"` domain. This is necessary for it to report data to New Relic and to receive monitors to execute. Ask your network administration if this is a problem and how to set up exceptions. | | Communicate with synthetics via a proxy | To set up communication with New Relic by proxy, use the [environment variables](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration#environment-variables) named `HORDE_API_PROXY*.` | | Arguments passed at launch | This applies to Docker and Podman container environment only. Arguments passed to the synthetics job manager container at launch do not get passed on to the runtime containers spawned by the synthetics job manager. Docker and Podman has no concept of "inheritance" or a "hierarchy" of containers, and we don't copy the configuration that is passed from synthetics job manager to the runtime containers. However, in case of Podman arguments passed at the pod level are shared between the synthetics job manager and runtime containers with in the pod. The only shared configuration between them is the one set at the [Docker daemon](https://docs.docker.com/config/daemon/) level. |