Allow users to run BLT commands from their host environment

[ba66e77]

User Story

As a user of BLT, I want to run BLT commands from my host environment so that I don't have to keep ssh'ing into the VM.

Discussion

In BLT 8x, we allowed users to run blt commands from their host environment. That feature was dropped in BLT 9x and users are now required to ssh into their VM to run most commands. That is an impediment to the development process and we've gotten pretty dissed for going that way. Let's reverse course and go back to allowing blt commands from the host machine.

[wu-edward]

I'm in favor of this, but as I recall the reasoning for the change was:

1. Quite a few support issues were involved VM proxy command failures
2. The VM command proxy functionality is not testable via CI.

One alternate suggested to reinstating the VM proxy functionality in BLT proper was to use the vagrant-exec plugin https://github.com/p0deje/vagrant-exec.

I've only tried this on a test project, and I found that it required creating a Vagrantfile.local that included something like this:

if Vagrant.has_plugin?('vagrant-exec')
  config.exec.commands '*', directory: '/var/www/{ENTER_VM_PROJECT_DIR_HERE}'
end

If this works well, perhaps we can provide documentation for this in BLT as an easy way to bring back this functionality?

[grasmash]

Maintenance for this feature was an absolute nightmare, particularly when combined with the use of to drush aliases.

There were a seemingly infinite number of edge cases related to it. Proceed at your own peril.

[danepowell]

By the way, if individuals want to run commands outside the VM like "the old way" just to test this, it's pretty easy to do: just change your local alias in blt.yml to match the vm, then run commands like blt setup outside the vm, and optionally use -y to bypass the warnings. The functionality isn't gone, it's just well hidden :)

I know that running commands outside the VM creates a maintenance burden for BLT, but I think it's undeniably a better user experience in a lot of areas, and we should try to optimize that experience.

Specifically:

• Any file operations in the VM are agonizingly slow, and sometimes impossible, due to the latency of NFS. For instance, a simple npm install or composer install typically throws a lot of warnings due to file locks / race conditions, and if it finishes at all it can easily take 30-60 minutes. And just forget running a composer update.
• Remembering to SSH into the VM to run commands is one extra (albeit minor) friction point to getting work done.
• The mental overhead of knowing what you should and shouldn't do inside the VM is taxing and unnecessary.
• Doing anything related to Git inside the VM is likely to create problems due to SSH key forwarding and Git not being configured correctly. For instance, we often see commits come through on our projects that are owned by "vagrant" rather than by the actual developer because they committed inside the VM.

Some of these issues create their own maintenance burden for BLT. For instance, we get countless issues related to problems of SSH key forwarding and people trying to run composer/npm operations or git pushes inside the VM. I can't tell you if this burden is more or less than before, but it certainly feels bad now.

[bobbygryzynger]

While I saw first-hand how difficult the VM proxy behavior was to maintain, I think there are enough DX pain-points here to warrant reintroducing the behavior.

I personally have run into a couple of the issues outlined above by @danepowell (especially commits authored by vagrant).

It might be helpful to aggregate a list of the bug tickets related to this behavior here to get a better understanding of where all of the edge-cases lie. I ran into the following at various points:

• Command arguments lost when invokeCommand is called with @executeInDrupalVm within a Robo watch task #1872
• Parameters not passed when invokeCommand is used with @executeInDrupalVM #1866
• Connects to #1582: @executeInDrupalVm not respected during invokeCommand #1589
• @executeInDrupalVm annotation not respected #1582

[bobbygryzynger]

@danepowell while, like you, I would still like to see this functionality return to BLT, I am using one workaround that alleviates the git pain points. The following can be added to a project's Vagrantfile to sync the user's git configuration to the virtual machine so commits are properly signed.

Vagrant.configure('2') do |config|
    config.vm.provision :file, source: '~/.gitconfig', destination: '/home/vagrant/.gitconfig'
end

[wu-edward]

Update on using the vagrant-exec plugin: https://github.com/p0deje/vagrant-exec

I've found that this works pretty well on a couple projects. Steps I took:

1. Installed the vagrant exec plugin vagrant plugin install vagrant-exec
2. Created a Vagrantfile.local file in the repo root with this:

if Vagrant.has_plugin?('vagrant-exec')
  config.exec.commands '*', directory: '/var/www/{ENTER_VM_PROJECT_DIR_HERE}'
end

(Could possibly just add it to the Vagrantfile and commit it.)
3. Now you can run blt commands via host machine CLI that will run inside the VM like so: vagrant exec blt {BLT_COMMAND}.
4. (Optional) I added an alias to my ~/.bash_profile: alias vlt="vagrant exec blt", so now I can just type vlt setup for example, to run blt setup within the VM.

Notes:

1. I had to run blt sync for the first time within the VM in order to add to known hosts. Also, SSH key forwarding into the VM still needs to be in place.
2. To run frontend commands such as gulp, I still have to log into the VM and run gulp in the theme directory there.
3. I haven't really tested with multitsite, and I imagine some tweaking drush aliases might be necessary.
4. All the colors in the console are stripped.

[grasmash]

The BLT feature that allowed commands to be run from outside the VM simply added vagrant exec in front of BLT commands.

I think it would be far better to take @wu-edward's suggestion and let users directly use the plugin rather than having BLT do it on their behalf.

[danepowell]

As much as I would love this feature, I don't think we have the resources to worry about it right now.

[danepowell]

Actually... I do think this is a good idea and we need to find resources to support it. It just doesn't make sense to do things like composer updates or git commits inside a VM, and forcing people to drop in and out of the VM based on what command they are running isn't any better. Redispatching BLT commands definitely has its pitfalls but it seems like the best user experience.

[alexxed]

composer on a shared folder in the vm has considerable worse performance.

You don't need a plugin, you just need to execute vagrant ssh -c "command".

For drush, I added support for vagrant transport, which would remove the need to handle the ssh key through the now present ssh transport. But still, you won't be able to run drush from the host and sync between 2 remotes, because drush will see the vm alias as a remote.

For vagrant, you can have an option to run commands prefixed with vagrant ssh -c. Unless the vm is not started, there's no problem with that, otherwise the vm won't be working at all if that connection is broken.

[danepowell]

There are very few BLT commands that are tightly coupled to anything inside the VM -- namely Drupal installs and updates. Pretty much every other BLT command can be run the same (if not better) on the host, right?

If that's true, then redispatching the entire BLT CLI via vagrant ssh or vagrant exec like we used to seems like massive overkill, when we can simply use Drush's built-in redispatching to handle those special cases.

When BLT sets up a VM, it already generates a VM-aware Drush alias. You'd just need to set this as your default local alias. And BLT would need to remove all of its nasty warnings about running on the host.

Does anyone see a problem with that? I know it's not ideal to run things like npm or composer on the host since you might run into issues with version mismatches, but it's so much faster that way, and I think it would be better to encourage people to use nvm, Composer version constraints and things like that to ensure consistency rather than running all of those things inside the VM.

And if anyone really loves waiting on Composer to update dependencies on NFS (barf), well they can still do things the old way by simply keeping the local drush alias as 'self'. We'll document the pros and cons of both options.

[wu-edward]

I think you still want to run npm and the frontend commands inside the VM, because node-sass, for example, has OS specific dependencies and blows up until you go into the VM and rebuild.

ETA: Unless all that can be done exclusively on the host: basically all of it needs to happen either on the host or the VM.

[danepowell]

Yeah, I would advocate for doing it all on the host. It's marginally less safe, maybe, if you aren't good about enforcing NPM versions. But so much faster and cleaner (NPM complaints violently about running on NFS). I'm open to other opinions though.

[alexxed]

The only problem I see is that I often see the prompt where I am told a blt command should be run inside the vm, but I still get the option to run it outside, which is confusing and slowing you down. If we can get rid of that prompt and just do the right thing, run it in the vm or outside, I think that fixes this ticket.

[danepowell]

I created #3613 to start testing this. I'm sure there are edge cases we haven't considered which is why I want to keep this a hidden-ish feature to start. Once it's shaken out a bit, we can fully document it (i.e. how and why to choose to run blt inside or outside the vm, maybe even make outside the default, etc...)