I came to the conclusion that in order to combine web and cli instrumentation, I had to disable automatic launching and instead start a proxy myself.
The simplest way to get in shape appear to be with the provided installation script and a few magic arguments. Specifying the proxy communication/proxy control directory (perhaps an idea to unify the terminology?) with --proxy-ctrl-dir takes care of the php configuration as well as the proxy auto start.
With --enable-cli and --enable-cli-long-running code is added to instrument php run from the command line
--- which also means that a misconfigured php-agent translates to broken php. Very incovenient if that same php also happens to drive your automation inside a container or jail. Not to worry, this time everything should work nicely.
# This first line swill sneak deploy files into standard places for CentOS/RHEL/OL without running any scriptlets
# Good for deploying inside a jailed environment or to sanitize the remains a failed configuratoin attempt
[root@appnode01 ~] # rpm -ihv --root /srv/app-root --noscripts --force appdynamics-php-agent-4.2.3.1-1.x86_64.rpm
[root@appnode01 ~] # chroot /srv/app-root bash-3.2# mkdir -p /var/run/appdynamics ; chown owner:group /var/run/appdynamics ; chmod 0770 /var/run/appdynamics bash-3.2# chown -R owner:group /usr/lib/appdynamics-php5 ; cd /usr/lib/appdynamics-php5 bash-3.2# ./install.sh -a account@access_key -p /usr/local/app/php/bin --ssl --enable-cli --enable-cli-long-running \
--proxy-ctrl-dir=/var/run/appdynamics account.saas.appdynamics.com 443 MyApplication AppNode appnode01.lab.company.com
With that in place, the proxy can be started with something like
[root@appnode01 ~] # screen -S proxy -m -d chroot /srv/app-root \
/usr/bin/sudo -u owner /usr/lib/appdynamics-php5/proxy/runProxy /var/run/appdynamics /usr/lib/appdynamics-php5/logs
At which point both web and cli code should be instrumented and happily reporting to the controller through agent and proxy, and in my case, with all components well seated inside the jail.