Hi J-P,

Consider the following mysite.aliases.drushrc.php

<?php

$aliases['staging'] = array(
    'uri' => 'staging.mysite.com',
    'root' => '/var/www/drupal7-mysite',
    'remote-host' => 'server.mysite.com',
    'path-aliases' => array(
      '%files' => 'sites/files/mysite',
    ),
);

Trying to build the instance results in:

$ drush instance-build @mysite.staging
Sorry, drush instance does not currently support remote hosts like @my.staging.

Is there a reason not to allow remote hosts? Would certainly make deployments easier.

Thank you,
Dan

Comments

jp.stacey’s picture

jp.stacey commented

@zerolab,

Having had a quick poke around, I'd say there's three problems that need to be tackled to a greater or lesser extent, to build support for remote hosts:

1. Drush instance (unlike other simple site-alias commands) stores a lot of extra data along with the (locally stored) site alias. There would therefore need to be (established and developed) a standard way for piping that data over. Drush instance also currently works only off a site alias: if you only have that site alias registered locally, then the remote command won't have any record of e.g. where the site root is, as it currently ignores flags like "-r" for simplicity.
2. As it stands, Drush instance runs a lot of simple local-filesystem operations. Even if the support in 1. were built in, the actual PHP commands only run locally. So there needs to be some kind of fork-and-dispatch built in, based on the localness or remoteness.
3. It's very difficult to unit-test in a way that others can also unit-test, and almost all the existing code has test coverage. That's not a reason not to do it, of course, but it's the reason why effort's been concentrated elsewhere, where a test harness exists.

1. and 2. are probably a consequence of architectural shortcomings that could be resolved by someone with considerable Drush experience, and I really welcome suggestions for how to do that. I'm currently coming down slightly with Drupalflu, though, so right now I can't see a simple way to put it in place.

However! I can see a simple functional equivalent of what you want to do. This is just:

1. Store the instance array for the production site alias on the remote, production server (with no remote-host etc. values.) So treat it as a local alias, stored on that server. This also has the advantage you only need to store one copy across all developers.
2. Instead of running:

drush instance-build @mysite.prod

run this:

ssh deployment_user@prod.server "drush instance-build @mysite.prod"

If you also have .ssh/config set up correctly, this could be shortened to:

ssh prod "drush instance-build @mysite.prod"

which is only eleven more characters than what you've asked for. Using ssh directly is a bit of a cop-out, I appreciate: but really that's only doing what site aliases do under the hood anyway (I believe.)

Let me know if this helps and bridges the gap. As I say, I'm open to other suggestions, but it would probably need some rearchitecting: it's not just a simple "remove that `else` statement and it all works."

J-P

zerolab’s picture

zerolab commented
Status: Active » Closed (works as designed)

Good points above. I think rather than overcomplicating things, the ssh method is the way to go.

Closing this, then.

Thank you J-P.