Read on to learn how to configure your containerized private minion (CPM).
You can do the following to customize your CPMs:
- Set up custom modules for scripted browsers in New Relic.
- Preserve launch data with permanent data storage.
- Use environment variables in your configuration.
You may not modify any CPM files and New Relic is not liable for any modifications you make.
All directories and files must be assigned group ownership as
3729 with read/write permissions. This ensures that the Runner, which uses
uid: 1000 and
gid: 3729, has access to all the mounted volumes. However, the Minion is able to run as root (
uid: 0) or with any
uid between the range of
[2000, 4000], inclusive. For more information, see running as non-root in Kubernetes or Docker.
- Directories are mounted onto a container as volumes by specifying a
- For example,
docker run ... -v /path/to/src:/path/to/dest:rw
- It is possible to add a directory onto a persistent volume (PV) by using
kubectl cp. However, alternative approaches are supported as long as the file permissions are set appropriately.
- For example,
kubectl cp /path/to/src <POD_NAME>:/path/to/destwill add a directory onto each PV in the specified pod
- Each PV must have a separate copy of the directories. For example, a cluster with n Minion replicas must have n PVs, each with their own copy of directories
- The directories and files must be added prior to the Minion boot up, otherwise the Minion must be restarted to detect the updates
Custom npm modules are exclusive to the CPM. They allow you to provide an arbitrary set of npm modules, and make them available for scripted monitors in synthetic monitoring.
To set up the modules:
Create a directory which contains a
package.json, following the npm official guidelines, in the root of the directory. Anything contained in the
dependenciesfield will be installed by the CPM at start, and made available when running monitors on that private minion.
Optionally, you can override the root level
package.jsonwith a Node version-specific directory. This allows a script to be updated per monitor runtime if a Node version of a runtime is no longer compatible with your dependencies. See an example of this below.
Once you create the custom modules directory and the
package.jsonyou can apply it to your CPM for Docker and Kubernetes.
Look at the CPM logs for
"... Initialization of Custom Modules ..."to see if the modules were installed properly, or if there were any errors. The npm installation logs will be shown.
Now you can add
"require('async');" into the script of monitors you send to this private location.
Along with npm modules, you can also use Node.js modules. To change the custom modules used by your CPM, modify
package.json and reboot the CPM. It will detect the change in configuration during the reboot, and then clean up and re-install.
Local modules: While your
package.json can include any local module, these modules must reside inside the tree under your custom module directory. If stored outside the tree, the initialization process will fail and you will see an error message in the docker logs after launching CPM.
CPM is a stateless application and does not preserve information from prior requests or sessions by default. However, you can preserve data between launches by enabling permanent data storage. For example, you can permanently set how the minion identifies itself (for example,
Minion_ID), and use it to associate that data with the exact minion that produced it.
To set permanent data storage on Docker:
Create a directory.
Launch the CPM, mounting the directory at
Example:docker run ... -v /example-permanent-dir:/var/lib/newrelic/synthetics:rw ...
To set permanent data storage on Kubernetes:
Launch the CPM, setting a value for the
persistence.permanentDataconfiguration value either in the command line or in a YAML file during installation. The value should specify the subpath on your Minion's Persistent Volume where you want the data to be saved.
Example:helm install ... --set persistence.permanentData=<permanent-data-subpath> ...
Containerized private minions let you configure environment variables for use in scripted monitors. These variables are hosted locally on the CPM and can be accessed via
$env.USER_DEFINED_VARIABLES. There are two ways to set user-defined variables: by mounting a JSON file or by supplying an environment variable to the CPM on launch. If both are provided, the CPM will use values provided from the environment only.
To reference a configured user-defined environment variable, use the reserved
$env.USER_DEFINED_VARIABLES followed by the name of a given variable with dot notation.
User-defined environment variables are not sanitized from logs. For sensitive information, consider using the secure credentials feature.
Environmental variables allow you to fine-tune the CPM configuration to meet your specific environmental and functional needs.