-
Notifications
You must be signed in to change notification settings - Fork 22
drush aliases, ssh configs and ds binary update commands #872
Conversation
…ypass strict host checking on ds.org domains
The dangerous part is scary! What would be borked? |
@aaronschachter you could write over the staging db or files directories |
@desmondmorris The drush alias should be using read-only credentials for DB. That would make overwriting the staging DB impossible. |
@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? |
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. |
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is this?
There was a problem hiding this comment.
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
👍 |
drush aliases, ssh configs and ds binary update commands
tldr;
ds update-db
will pull down the staging db andds update-files
will pull down the staging filesThis 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.
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.
This pulls the db from the staging instance down to the current environment.
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
andupdate-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