Separate Xdebug install/config into separate role, manage SSH Tunnels to remote hosts for debugging

[nathanielks]

This adds the ability for Trellis to manage creating SSH tunnels for use with Xdebug. While it's not recommended to use in production, it can be useful in production-like environments. For example, if there's an issue in production that you can't duplicate locally in development, or also exists in staging, you can create an SSH Tunnel to bridge the production-like environment to your local machine, allowing communication between Xdebug and whatever local debugger you're using (PHPStorm, Vim, Sublime Text, etc).

Another use case is cloning your production server and working on that instead of production itself so as to not ruin things more 😐

Usage:

Provided this hosts file:

# let's pretend hosts/prodlike

some_inventory_hostname ansible_ssh_host=12.34.56.78

[prodlike]
some_inventory_hostname

[web]
some_inventory_hostname

./xdebug-tunnel.sh some_inventory_hostname

This script runs the xdebug-tunnel.yml playbook with the necessary variables to install Xdebug on the environment as well as establish the tunnel.

To close the tunnel, as well as disable Xdebug, run:

./xdebug-tunnel.sh some_inventory_hostname close

This will remove the /etc/php/7.0/fpm/conf.d/20-xdebug.ini symlink, effectively disabling it for that environment while leaving xdebug installed. It also closes the SSH connection.

If you don't use inventory aliases in your host files, you can also use an ip address directly instead of the alias. For example, if your host file looks like this:

[prodlike]
12.34.56.78

[web]
12.34.56.78

You can do this:

./xdebug-tunnel.sh 12.34.56.78

You do have to be consistent though. If you open it using an alias and close it using an ip address, it'll yell at you because the tunnel socket is created using that passed parameter. It creates files matching the following pattern:

/tmp/trellis-xdebug-{{ provided host }}

[swalkinshaw]

Is this needed? Thought we always required an explicit env

[nathanielks]

@swalkinshaw not necessarily. For the deploy command I believe we do, though now I'm wondering if we don't... At the very least, the xdebug-tunnel.sh script does not require it because you have to specify which host you want to establish the ssh tunnel with. Because the host is specified, we don't need to do the web:&{{env}} deal to select which hosts we want to run the playbook on.

[nathanielks]

ah, yeah, the deploy command does require it because otherwise it wouldn't be able to do a subsection of hosts

[swalkinshaw]

Think it's better to be explicit here with the open command?

./xdebug-tunnel.sh example_com_prod open
./xdebug-tunnel.sh example_com_prod close

Is this better?

./xdebug-tunnel.sh open example_com_prod
./xdebug-tunnel.sh close example_com_prod

Reads better at least

[nathanielks]

I like the second syntax, I'll make that update 👍

[nathanielks]

Corresponding docs: roots/docs#56

[swalkinshaw]

Does this work? Redundant? It's being set in both branches

[swalkinshaw]

🚀

[fullyint]

Thank you @nathanielks !