lando / drupal

The Official Drupal Lando plugin
https://docs.lando.dev/drupal
GNU General Public License v3.0
16 stars 17 forks source link

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

Open dustinleblanc opened 4 years ago

dustinleblanc commented 4 years ago

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.

gitressa commented 4 years ago

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

serundeputy commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

gitressa commented 4 years ago

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 commented 4 years ago

it can be useful if modified in creative way .

mdrmike commented 4 years ago

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. :grimacing:

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). :smiling_face_with_three_hearts: *-edited for clarity, I hope.

pirog commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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[bot] commented 3 years ago

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 commented 3 years ago

Thanks Stalebot, but this issue is still relevant.

froboy commented 3 years ago

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 commented 2 years ago

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:

almunnings commented 1 year ago

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"
soniktrooth commented 1 month ago

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…).

I'm struggling with the port as well when running pygmy in parallel with Lando. Pygmy just hijacks 80 and 443 but Lando is more graceful and works around this to run on a different port however it is not always the same port so hardcoding the DRUSH_OPTIONS_URI doesn't work.

Is there anyway to grab the port Lando is currently using? (hai @dustinleblanc 👋 😬)

reynoldsalec commented 1 month ago

@soniktrooth Lando has a set of configurable fallback ports: https://docs.lando.dev/core/v3/proxy.html#configuration

I'm not sure how the fallback works, but if it's not consistent on your machine, I'm guessing you could choose a single fallback and set that in your global Lando settings.

soniktrooth commented 1 month ago

Thanks @reynoldsalec that will help me I think. Would be nice if the port being used was exposed as a variable somehow so it could be referenced but I'm sure the feature request pile is high so I will take this as a win.