0

It's possible I'm going about this all wrong, and I should be setting up my aliases file differently.

We have a set up with 4 load-balanced production servers running the same code and accessing the same database. I want to set up a drush aliases file to access them by a short name and also allow commands to be run on all of them simultaneously. Here's what I have so far, in ~/.drush/cust.aliases.drushrc.php:

<?php
$aliases['production'] = array (
  'root' => '/var/www/cust',
  'uri' => 'www.example.com',
  'databases' => array(
    'default' => array(
      'default' => array(
        'database' => '...',
        'username' => '...',
        'password' => '...',
        'host' => '...',
        'port' => '3306',
        'driver' => 'mysql',
      ),
    ),
  ),
  'site-list' => array(
    'production.1',
    'production.2',
    'production.3',
    'production.4',
  ),
);
$aliases['production.1'] = array (
  'parent' => '@production',
  'remote-host' => '...',
  'site-list' => array(),
);
$aliases['production.2'] = array (
  'parent' => '@production',
  'remote-host' => '...',
);
$aliases['production.3'] = array (
  'parent' => '@production',
  'remote-host' => '...',
);
$aliases['production.4'] = array (
  'parent' => '@production',
  'remote-host' => '...',
);
?>

Now the problem I have is that the site-list variable is being added to the individual definitions, so the site-ssh command thinks that they are a list. I've tried a few things to sort this out, including adding 'site-list' => NULL, 'site-list' => array() and 'site-list' => '' to the the production.x definitions, but this doesn't work since site-ssh just uses isset. Neither do my attempts to use the unset function because the inheritance happens after I've tried to unset it.

2

The problem here is that Drush will always prefer the non-empty 'site-list' in @production over any empty value you provide in the specific site aliases. This is regrettable, as it makes it Hard to delete values.

There are a couple of alternatives, though. The most straightforward solution is to just take advantage of the fact that Drush alias files are executable php. You can refactor your alias definitions like this:

<?php
$common = array (
  'root' => '/var/www/cust',
  'uri' => 'www.example.com',
  'databases' => array(
    'default' => array(
      'default' => array(
        'database' => '...',
        'username' => '...',
        'password' => '...',
        'host' => '...',
        'port' => '3306',
        'driver' => 'mysql',
      ),
    ),
  ),
);
$aliases['production'] = array (
  'site-list' => array(
    'production.1',
    'production.2',
    'production.3',
    'production.4',
  ),
);
$aliases['production.1'] = array (
  'remote-host' => '...',
) + $common;
$aliases['production.2'] = array (
  'remote-host' => '...',
) + $common;
$aliases['production.3'] = array (
  'remote-host' => '...',
) + $common;
$aliases['production.4'] = array (
  'remote-host' => '...',
) + $common;

Your second option is to take advantage of a Drush feature that automatically creates group aliases for all aliases that are defined in a single alias file. Start with your alias file definition as you show it in the question above; then:

1) Delete 'site-list' from the 'production' alias.

2) Move the 'production' alias to a different file (I use servers.aliases.drushrc.php to store aliases to all of the servers that I have sites on).

3) Keep the individual site aliases as they are, with 'parent' => '@server.production'.

Once you have done that, you may use @cust as an alias list for all of the aliases defined in cust.aliases.drushrc.php.

  • I tried the first solution to this (using a separate $common array), which mostly works, except for that drush @cust.production status fails with Invalid argument supplied for foreach() backend.inc:707 [warning]. I don't really want to go down the route of more files, as I'd like to be able to distribute a single file around the team. Is this a bug in my distro's drush 5.10.0 version? – dutchie Oct 24 '14 at 13:10
  • Drush 5 isn't supported any longer. If you find you're having the same problem with Drush 7, post a bug to the Drush project on GitHub. We can fix it, and backport it to Drush 6. – greg_1_anderson Oct 24 '14 at 13:51
  • OK, so after a composer global require drush/drush:dev-master, I tried drush @cust.production status again, and it still failed. This time I got a more helpful error message though: Not found: production.1, production.2, production.3, production.4 [warning]. If I change the content of the site-list to be @cust.production.x then it works. Is this a bug that I should report or expected behaviour? – dutchie Oct 24 '14 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.