drush aliases, ssh configs and ds binary update commands

[desmondmorris]

tldr; ds update-db will pull down the staging db and ds update-files will pull down the staging files

This merge introduces the managed drush alias file in the vagrant VM. It gives us access to the app at the new staging environment (staging.beta). To make this work, file ownership of the known_hosts fie needed to be granted to the vagrant user. I also added a ssh to avoid strict host checking when ssh-ing into the staging instance. This allows us to run drush commands against the staging instance directly from or VM.

drush @ds.staging cc all
drush @ds.staging fra

This also allows us to run rsync and sql-sync commands to quickly grab files and db from the staging instance.

This rsync's the files from the staging instance down to the current environment.

drush rsync @ds.staging @self -y 

This pulls the db from the staging instance down to the current environment.

drush sql-sync @ds.staging @self -y

Both of these must be run from within a working drupal webroot, so /vagrant/html.

WARNING - These commands can be dangerous if you are not careful. The first alias always represents the env you would like to pull from. If you switch these up, you will bork the staging site. So I created two convienience functions in the ds binary: update-db and update-files

UPDATE* - I was able to add a drush policy file (go figure), to restrict the sync commands from overwriting the staging db and files

Do not disappoint dries

Related to: #675

[aaronschachter]

The dangerous part is scary! What would be borked?

[desmondmorris]

@aaronschachter you could write over the staging db or files directories

[mshmsh5000]

@desmondmorris The drush alias should be using read-only credentials for DB. That would make overwriting the staging DB impossible.

[desmondmorris]

@mshmsh5000 +1 to that. I realized I did not have to set the db credents at all in the alias file, so I did not. But then I lose that granularity. This def makes sense for now as staging is the canonical source of data at this point.

The only challenge here is securing the mysql connection. Unlike blackangus, this instance is available to the public. So a passwordless login would not be ideal. The alternative is to set the db username and password in code, also not ideal. Is there anyway to restrict access to that mysql instance considering we are hitting it from a VM and at times distributed? Maybe restrict to internal ip addresses, which require connecting to the VPN?

[mshmsh5000]

Restrict to internal IP addresses: +1. VPN should be the answer in general to things like this. I assume this will work from within Vagrant, but haven't tested.

[desmondmorris]

Policy file added. You will now be incapable of running sql-sync or rsync to the staging environment

[aaronschachter]

what is this?

[desmondmorris]

that tells salt to load the dosomething.sls file

[aaronschachter]

👍