I'm building a custom Dynatrace plugin and would like to run 'sudo docker inspect' and 'sudo docker ps' when the plugin is executed (to get an IP address, it's complicated), although in my testing I've seen these commands to return nothing/blank/null to Dynatrace (it works fine when running locally on the host). Is the plugin being run in an isolated environment?
edit: the error I see in Dynatrace is "Error ('NoneType' object has no attribute 'group') for: <hostname>", meaning the Docker commands return null/nothing.
It's using it's own python interpreter in oneagent installation (not the systemwide python) and running as the dtuser who has /bin/false as the shell. I think this may be effectively block running shell commands from plugins unless you setup a valid shell for dtuser.
Personally I would try to access docker engine using API and not running commands. Are there any reasons not do it using Docker python API?
BTW. the error you have posted in comments refers to postgresql plugin (the dynatrace official plugin coming with oneagent). It's normal, since you either have postgresql plugin not correctly configured in Dynatrace or postgresql is not running on the host you are posting logs from.
@Julius L. Thank you for the help - how can I install the Docker Python API that you mentioned in Dynatrace's own Python interpreter, is that something that needs to be done? I installed it locally on the host and in using it have again built something that runs fine locally, but not when included in my Dynatrace plugin.
Dynatrace is showing this error:
module 'docker' has no attribute '<any method I try to call from the Docker API>'
I'm guessing there is a version mismatch somewhere - I previously encountered this error locally when running with Python 3, although it worked fine when running with Python 2. Using a previous version of the Docker API (2.1.0 vs. 2.7.0) seems to have resolved the issue locally for Python 3 (not on Dynatrace)
This is a potential cause - https://github.com/metacloud/molecule/issues/771#...
Update: we've implemented a work-around on our end but I'd still be curious to here any resolution on this.