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 API or scripted browser monitors.
- 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.
Guidelines for mounting volumes
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.
Docker
- Directories are mounted onto a container as volumes by specifying a
-v
argument withindocker run
- For example,
docker run ... -v /path/to/src:/path/to/dest:rw
Kubernetes
- 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/dest
will 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 node modules
Custom node modules are exclusive to the CPM. They allow you to provide an arbitrary set of node 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 thedependencies
field 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.json
with a Node.js version-specific directory. This allows a script to be updated per monitor runtime if a Node.js 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.json
you 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.
Change package.json
for custom modules
Along with local and hosted 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.
Caution
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.
Permanent data storage
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
/var/lib/newrelic/synthetics
.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.permanentData
configuration 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> ...
User-defined environment variables for scripted monitors
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.
Accessing user-defined environment variables from scripts
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.
For example, $env.USER_DEFINED_VARIABLES.MY_VARIABLE
Caution
User-defined environment variables are not sanitized from logs. For sensitive information, consider using the secure credentials feature.
Environment variables
Environmental variables allow you to fine-tune the CPM configuration to meet your specific environmental and functional needs.