Skip to content
This repository has been archived by the owner on Oct 29, 2020. It is now read-only.

drush aliases, ssh configs and ds binary update commands #872

Merged
merged 4 commits into from
Feb 26, 2014

Conversation

desmondmorris
Copy link
Contributor

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
dries-buytaert_pan_23415

Related to: #675

@aaronschachter
Copy link
Contributor

The dangerous part is scary! What would be borked?

@desmondmorris
Copy link
Contributor Author

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

@mshmsh5000
Copy link
Contributor

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

@desmondmorris
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link
Contributor Author

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

@@ -7,4 +7,5 @@ base:
- install
- composer
- node
- dosomething
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that tells salt to load the dosomething.sls file

@aaronschachter
Copy link
Contributor

👍

desmondmorris added a commit that referenced this pull request Feb 26, 2014
drush aliases, ssh configs and ds binary update commands
@desmondmorris desmondmorris merged commit 31ae823 into DoSomething:dev Feb 26, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants