Category: General

whatever whatever :D

launch a jenkins slave via drush

If you already have Drush aliases set up for your live machines, deploy those aliases to your CI server, and use them to launch your nodes (instead of copying the SSH info).

Create a new “Dumb slave” but instead of “SSH slave”, select “Launch slave via execution”

This is the command to use:

/usr/local/bin/drush @abclive ssh 'wget https://your-jenkins-server.example.com/jnlpJars/slave.jar -O /tmp/slave.jar && exec java -jar /tmp/slave.jar'

Jenkins will run the command which sets up the remoting capabiliity.

drush uli gets “access denied” using vagrant

I noticed randomly “drush uli” would just result in “access denied” when Drupal was inside of a Vagrant machine.

The funny this was, if I waited a little bit, and tried the user login link again, it worked fine.

The problem is the Vagrant machine’s clock may be only a few seconds ahead of your local machine.

So the token that uli generates isn’t valid until then.

Solution: install “ntp” on both your host and inside the Vagrant machine.

dynamic drush alias files

Alias files are useful. If you have many sites on a remote server, instead of manually adding them to your alias file every time, write some code to automatically generate them.

[php title=”~/.drush/dynamic.aliases.drushrc.php”]
$domains = explode(“\n”, trim(shell_exec(“ssh user@myserver.example.com ‘ls /some/path'”)));
// now $domains is a list of directories on your remote server

// set up an alias for each one
foreach ($domains as $domain) {
$aliases[$domain] = array(
‘root’ => “/path/to/$domain/public_html”,
‘remote-host’ => ‘some-server.com’,
// if necessary, URI other than default
‘uri’ => $domain,
‘remote-user’ => ‘user_if_necessary’,
);
}
[/php]

Now whenever a site is configured on your target server, you will automatically have the alias!

consider versioning your .drush directory

Our team uses Drush frequently during the entire development workflow for doing things like grabbing database dumps of sites and running commands – drush make, registry rebuild, custom company-specific ones, etc. – and in the past everyone would have to manually download or copy them to their .drush.

Now, we version the .drush directory, so when a new developer onboards, they can just checkout the .drush directory from version control.

This is incredibly useful for

You can build a very powerful devops toolkit across all team members since everyone will have the same Drush setup!

a faster alternative to sql-sync

Where I work I probably load environments about 50 times a day. Testing bug fixes, data migrations, reproducing errors, failure analysis, and so on.

Even if I can save 30 seconds with an automated database reload process, it will add up.

There’s been work on improving drush sql-sync, including https://drupal.org/project/drush_sql_sync_pipe

The bottleneck is that drush sql-sync works with temporary files – meaning it has to:

  1. Connect to the remote machine
  2. Perform a sql-dump to a file on the remote machine and compress it
  3. Transfer that file to your machine
  4. Restores the dump to database

The problem with this is that each step is executed consecutively. It would be better if all these steps were performed concurrently. Drush defaults to this method because it is compatible with most systems. If you’re a power user though, you may want a find a faster solution.

What we’d like to do is

  1. Connect to the remote machine
  2. Perform these steps at the same time
    1. Read the file remotely
    2. Compress on the fly
    3. Stream it to your local machine
    4. Uncompress on the fly
    5. Pipe sql to database

I wrote this little script that accomplishes just that and a little extra for dumping locally. The key is piping data instead of saving it temporarily. Note that this only works on Linux/Mac.

#!/bin/bash -x
drush -y sql-drop # this doesnt have an alias for a reason. only work locally
drush $1 sql-dump --gzip | gzip -cd | drush sqlc
drush -y updb
# Set last update date to now to prevent checking for updates for a bit
drush -y vset update_last_check `date +%s`
# Setting file paths (use default)
drush -y vdel file_directory_path
drush -y vdel file_public_path
# Clear cache
drush cc drush

Put this script somewhere (maybe ~/bin) and chmod a+x it.

From within your site directory, run `fastdump @someAlias`

This will

  1. Delete all the local tables (to ensure tables that don’t exist in your source are gone)
  2. Restore the database from an alias
  3. Run updates

But quickly! The next step for this would be making it into a Drush command instead of a shell script.

don’t kill your live site with a sql-sync

We have a shared alias file that represents every site that we work with. For example


@abcstage
@abctest
@abclive

are all valid aliases. Developers would have access to stage and test, while live only works for privileged users.

But, we still want to make sure that no funny business goes on.

Create a file, ~/.drush/policy.drush.inc

function drush_policy_sql_sync_validate($source = NULL, $destination = NULL) {
  if (strpos($destination, 'live') !== FALSE) {
    return drush_set_error(dt('Per ~/.drush/policy.drush.inc, you may never overwrite the production database.'));
  }
  if (strpos($source, 'stage') !== FALSE && strpos($destination, 'test') !== FALSE) {
    return drush_set_error(dt('Dumping from stage to test is a terrible idea.'));
  }
  if (strpos($source, 'stage') !== FALSE && strpos($destination, 'live') !== FALSE) {
    return drush_set_error(dt('Dumping from stage to live is even worse.'));
  }
}

This will ensure that nobody can accidentally sql-sync to a live site. You can adjust the criteria as need be.