-
Notifications
You must be signed in to change notification settings - Fork 10
Advanced
By default, PrtgDocker will redirect the C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors folder to C:\ProgramData\Paessler\PRTG Network Monitor\Custom Sensors. When -Volume is specified to New-PrtgContainer, C:\ProgramData\Paessler\PRTG Network Monitor will be mapped to your volume, giving you direct access to the Custom Sensors folder within from your Docker host's filesystem.
While this works well for one container (such as the PRTG Core Server), if you're attempting to create half a dozen probes for load balancing purposes, copying and pasting sensors across all of your container's Custom Sensors folders whenever you make a change no longer becomes ideal.
PrtgDocker allows you to work around this issue by specifying a -CustomSensorsPath pointing to a UNC folder containing your Custom Sensors files.
New-PrtgContainer -Probe -CustomSensorsPath "\\fs-1.consoto.local\CustomSensors"When -CustomSensorsPath is specified, the original symlink on C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors is replaced with a new symlink to the external UNC path you specified.
It is important to note that your Custom Sensors UNC path must use the fully qualified domain name of the target server. i.e. make sure you specify \\fs-1.contso.local\CustomSensors and not \\fs-1\CustomSensors. Your container will not know how to resolve your server's short name by default. Unless you know how to make DNS search domain resolution work inside of Docker, I recommend just specifying the FQDN to avoid any issues.
Note that while specifying -CustomSensorsPath will allow your Custom Sensors folder to point to an outside domain resource, in practice you will likely find that your container is unable to authenticate to this network resource, as containers are not part of the domain. To work around this issue, please see the Credential Spec section.
Docker containers can authenticate to network resources in most contexts (with some caveats) using Active Directory credentials via the use of a Group Managed Service account (gMSA). Once a gMSA has been created for your domain and your Docker hosts have been configured to use it, individual containers can take advantage of gMSA accounts via the use of a credential spec configuration file. PrtgDocker can automatically create credential specs for you and pass them in the arguments to docker run via the -CredentialSpec and -CredentialSpecAccount parameters
New-PrtgContainer -Probe -Name "New York 1" -CredentialSpec -CredentialSpecAccount container_gmsaWhen -CredentialSpec is specified, PrtgDocker will attempt to locate a credential spec based on the -Name that was specified for the container (in this case, the credential spec would be called new_york_1). If a -Name was not specified in conjunction with -CredentialSpec, New-PrtgContainer will throw an exception. If a credential spec with the desired name could not be found, PrtgDocker will helpfully create one for you based on the specified -CredentialSpecAccount. If a credential spec could not be found and -CredentialSpecAccount was not specified, New-PrtgContainer will throw an exception.
If you don't like how PrtgDocker handles credential specs, you can take over this process yourself and specify the Docker credential spec arguments as -AdditionalArgs to New-PrtgContainer.
For more information on configuring your environment for use with Group Managed Service Accounts, please see gMSA Configuration.
If you wish to run your images on a system that does not match the system the image was built on, you may be able to do so using Hyper-V isolation.
Images can be built and deployed using Hyper-V isolation by specifying the -HyperV parameter to New-PrtgBuild or New-PrtgContainer respectively.
- Install Hyper-V on your Docker server
New-PrtgBuild -HyperVNew-PrtgContainer -HyperV
Note: If your Docker server is a virtual machine, you may need to enable nested virtualization in order to install Hyper-V