Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do I set my Drupal site URI in Lando for easy Drushing? #8

Open
dustinleblanc opened this issue Mar 23, 2020 · 17 comments
Open

How do I set my Drupal site URI in Lando for easy Drushing? #8

dustinleblanc opened this issue Mar 23, 2020 · 17 comments

Comments

@dustinleblanc
Copy link

As a follow up to lando/lando#447, we should write up a guide on how to modify Drush options within Lando to make uli use the correct domain so that users can make their Lando setup just that much nicer.

@dustinleblanc dustinleblanc self-assigned this Mar 23, 2020
@gitressa
Copy link
Contributor

There is already this page, or do you think it should be expanded?
https://docs.lando.dev/config/drupal8.html#configuration

@serundeputy
Copy link

@gitressa yep that doc has it and also a significant amount of other info.

The goal here is to pull that out (leave it where it is too) as a very specific guide to answer the one question How do I set my Drupal site URI in Lando for easy Drushing?, but maybe we could work on the wording of that question, but that is the question.

@gitressa
Copy link
Contributor

Thanks for clarifying @serundeputy. I just discovered another and slightly shorter way of setting the Drupal site URI:

tooling:
  drush:
    service: appserver
    cmd: drush --root=/app/web --uri=http://mysite.lndo.site

Compared to this:

services:
  appserver:
    overrides:
      environment:
        DRUSH_OPTIONS_URI: "http://mysite.lndo.site"

I wonder if there are reasons to use one over the other?

@gitressa
Copy link
Contributor

To answer my own question, it appears that defining Drush URI via tooling will not work in another instance of tooling:

tooling:
  drush:
    service: appserver
    cmd: drush --root=/app/web --uri=http://mysite.lndo.site
  post-import:
    service: appserver
    cmd: drush uli

The result is http://default/user/reset/1/1586688025/TOp-0F....XxQ/login

@dustinleblanc
Copy link
Author

I'd prefer the env variable approach, it seems cleaner and more intentional

@gitressa
Copy link
Contributor

Yes, and it's the one that will actually work inside another tooling instance, whereas defining Drush URI in tooling doesn't. So unless that gets fixed, it's not very useful.

@AB-exe
Copy link

AB-exe commented Apr 24, 2020

it can be useful if modified in creative way .

@mdrmike
Copy link

mdrmike commented May 25, 2020

https://github.com/lando/lando/issues/2080#issuecomment-603511033

There is already this page, or do you think it should be expanded?
https://docs.lando.dev/config/drupal8.html#configuration

Yes! From the Lando homepage, the point is to "Save time, headaches, frustration and do more real work."

In that spirit I feel there should be complete real-world working examples for both Drush 8 and Drush 9+. It's worth noting the current docs are written for Drush 8 and below (yet link to Drush 10 alias examples). Also Drush 9/10 use yaml alias files not the older drush php alias files. Finally, each should demonstrate a global-site and local-site setup. including how to setup @self and @Remote aliases; e.g. @staging or @production.

My Use Case

I'm working to deploy my first Drupal 8.8 site using composer, with Drush 9. My experience setting up Drush aliases has been, erm, $#%@ difficult. 😬

I have previous Drupal/Drush experience, but Lando Drush aliases setup has been particularly confusing to me. I'm also new to Drupal 8 and trying to figure out what Lando (docker) is doing behind the scenes.

My Experience with Lando Docs

It took me many multiple reads of the Lando Drush config docs before I understood what is meant by a global install -vs- local install. It also didn't help that there were/are still multiple links broken. The first time I read global install, I thought it meant an OS environment install (existing Drupal / Drush setup) that is outside/agnostic of Lando. I assumed this because both a "lando recipe" and "composer install" of Drush are in fact "local" to the Lando/docker container app. (This is not what was meant). It also didn't help that links from the doc external examples to install a site-local Drush defaults to Drush 10 examples (master branch), which are totally different than anything else on the Lando documents page.

How To Debug

The difficult thing for me has been trying to discover/debug the $PATH that Drush uses in order to figure out where to put the (alias settings) file, especially in the case of installing a local version of drush with composer, yet lando also installs a global version as part of the recipe. Its a tangled web.


Anyway, that's my two cents. Hope I didn't come across as rude. Don't hate me... just trying to share what I feel could be improved (in the upcoming guide). 🥰
*-edited for clarity, I hope.

@pirog
Copy link
Sponsor Member

pirog commented Jul 31, 2020

@mdrmike ill be honest i dont really understand what you are saying in most of the above comment.

@dustinleblanc @serundeputy there are two new things to consider here

  1. You can now specify envvars for tooling commands eg
tooling:
  drush:
    service: appserver
    cmd: drush
    env:
      DRUSH_OPTIONS_URI: mysite.lndo.site
  1. There is now an expanded PROXY format for advanced usage
proxy:
  appserver:
    - hostname: object-format.lndo.site
      port: 80
      pathname: /
      middlewares:
        - name: test
          key: headers.customrequestheaders.X-Lando-Test
          value: on
        - name: test-secured
          key: headers.customrequestheaders.X-Lando-Test-SSL
          value: on

I think this gives some more flex on what we can do including perhaps finally setting DRUSH_OPTIONS_URI automatically. The big "hiccup" there has always been never knowing what the "primary" url is but i feel like it wouldnt be hard to support something like:

proxy:
  appserver:
    - hostname: site.lndo.site
      port: 80
      pathname: /
      primary: true

and have that imply appserver.environment.DRUSH_OPTIONS_URI = https://site.lndo.site or somesuch

@mdrmike
Copy link

mdrmike commented Aug 3, 2020

@pirog Ha! Sorry. I was confused with the issue and some terms when I commented.

I was piling on with detailed explanation. My comment was an attempt to show where I had problems with the config docs and make the case for why its important to have beginning-to-end examples, both a basic and complex example. But I think that's the intention of guides. Right?

Also, the words guide, docs (in url: https://docs.lando.dev/config/drupal8.html), and config didn't have enough distinction for me to realize I was seeing/reading multiple things. It took multiple re-reads. Sorry, its just the lando lingo that I'm sure is second nature to most of you... but I finally figured out they had specific meanings.

@markdorison
Copy link

Is there a solution for this that would work in a multi-site setup? Maybe that is the proxy option? It's not 100% clear to me how that connects.

@dustinleblanc
Copy link
Author

@markdorison when dealing with Drupal multisite, I don't see a way around passing -l with every drush command unless you add multiple tooling commands that string it on to drush itself. Its been ages since I had to work on a multi-site, but I remember having to do that to run things

@stale
Copy link

stale bot commented Apr 27, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

@gitressa
Copy link
Contributor

Thanks Stalebot, but this issue is still relevant.

@froboy
Copy link

froboy commented Oct 5, 2021

One other consideration here is ports. Drush needs the correct port to be passed to DRUSH_OPTIONS_URI and unless it’s hard-coded in .lando.yml the port could be different depending on what lando grabs when it starts up the site.

I’m currently struggling with this trying to run lando and docksal in parallel (not forever, hopefully…).

@dslatkin
Copy link

dslatkin commented Nov 9, 2022

If this helps anybody else, I've had success modifying my Landofile to explicitly set --url (quivalent to -l) similar to gitressa but (maybe crucially?) using localhost for the domain and using the port matching lando info output.

This has let me run multiple sites simultaneously with Lando and Drush support with a recipe that looks like:

recipe: pantheon
config:
  framework: drupal8
name: my-site
tooling:
  drush:
    service: appserver
    cmd: 'drush --root=/app/web --uri=http://localhost:49426'

You can generate this URI programmatically after the container is built with a script similar to:

lando_uri=$(lando info --filter service=appserver_nginx --path 0.urls.1 | tr -d "'")
{
    printf "tooling:\n"
    printf "  drush:\n"
    printf "    service: appserver\n"
    printf "    cmd: 'drush --root=/app/web --uri=%s'\n" "$lando_uri"
} >> "$site_landofile"

A few notes:

  • This was all done in a dev container, so I'm not sure how your lando info command might differ, and I haven't tried anything with lndo.site hostnames yet
  • I couldn't find documentation on the syntax that --path takes, but that pattern above let me index array elements and grab properties by name so it works well enough
  • You may also want to omit or change --root depending on the needs of your project
  • I've assumed it's important and thought it was nice in general to have a separate name for each site to differentiate the containers so I've been generating that programmatically as well

@almunnings
Copy link
Sponsor

This appears to be working for me.

tooling:
  drush:
    service: appserver
    cmd: /bin/sh -c "drush --root=$LANDO_WEBROOT --uri=https://$LANDO_APP_NAME.lndo.site $@" "$0"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests