The job manager can operate in a Docker container system environment or a Kubernetes container orchestration system environment. The job manager will auto-detect its environment to select the appropriate operating mode.
Because the synthetics job manager operates as a container instead of a virtual machine, we've simplified installation, getting started , and updating your job management and orchestration. It also comes with some additional functionality:
- Compatible with Linux, macOS, and Windows.
- Enhanced security and support for non-root user execution.
- Ability to leverage a Docker container as a sandbox environment.
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
To host synthetics job managers, your system must meet the minimum requirements for the chosen system environment.
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.
Before launching synthetics job managers, you must have a private location key. 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:
- Go to one.newrelic.com > Synthetic monitoring >Private locations.
- In the Private locations index, locate the private location you want your synthetics job manager to be assigned to.
- Note the key associated with the private location with the key icon.
Synthetics job manager images are hosted on Docker Hub. Go to hub.docker.com/r/newrelic/synthetics-job-manager/tags for a list of all the releases.
Unless hosting the images in a local image repository, you need to allow connections to
docker.io through your firewall so Docker 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 and Kubernetes environment configuration 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.
Below are the applicable Docker or Kubernetes instructions to start the job manager.
On a Docker container system environment, use the Docker
stop procedure to stop the synthetics job manager from running. On a Kubernetes container orchestration system environment, use the Kubernetes
delete procedure to stop the synthetics job manager from running.
Sandboxing and Docker dependencies are applicable to the synthetics job manager in a Docker container system environment.
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:
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.
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
Communicate with synthetics via a proxy
To set up communication with New Relic by proxy, use the environment variables named
Arguments passed at launch
This applies to a Docker 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 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. The only shared configuration between them is the one set at the Docker daemon level.