Apache setup changes for multisite

[philipnorton42]

I've decided to create this meta issue that should cover several feature requests we have had that involve the Apache Role. The feature requests essentially boil down to the following:

Configurable document root: https://github.com/hashbangcode/vlad/issues/270 https://github.com/hashbangcode/vlad/issues/208 https://github.com/hashbangcode/vlad/issues/186

Multiple hosts: https://github.com/hashbangcode/vlad/issues/210

So rather than look at the Apache role I thought it best to look at how the end product should operate (from configs to setup). I wanted to collate my thoughts here to see if they were mad or coherent.

It should be possible to combine the above into a single feature. The config would be something like this:

vlad_apache_settings:
- address: 'drupal.local'
  directory: 'drupal.local'
  aliases:
    - 'www.drupal.local'
    - 'www.test.local'
- address: 'drupal8.local'
  directory: 'drupal8.local'
  aliases:
    - 'www.drupal8.local'

This would create the following directory structure.

/var/www/vhosts/drupal.local
/var/www/vhosts/drupal8.local
/var/www/vlad_aux/

For the above:

• drupal.local would be the location for the addresses drupal.local, www.drupal.local, and www.test.local.
• drupal8.local would be the location for the addresses drupal8.local, and www.drupal8.local.

Note: The slight change in the directory structure here. We are now separating out the vhosts and the Vlad utility directory. This makes it easy to add more sites without clashing with existing/future utility directories.

Also, one slight wrinkle here is that I haven't found a good way of setting up an SSL certificate for multiple vhosts. Is this even possible? I've found a few posts and issues online that suggest that it's impossible. If this is the case then we'll need to elect a single address as the SSL address and the rest will just default back to HTTP.

[dixhuit]

Seems coherent though this is certainly not an area of expertise for me.

One thing I'd add though, this looks as if Vlad will continue to rely on a very specific apache role i.e. ships with Vlad, for Vlad, not from Ansible Galaxy. If that's the case (I'm guessing likely) then we may want to take advantage of this opportunity in role refactoring to update any relevant vars used to make use of a vlad_ prefix in the interest of better name spacing (already rolling out in other parts of Vlad). I notice that the apache role itself doesn't provide any default vars (likely due to these vars being critical to other operations too, Vagrantfile?) Let's also take the opportunity to review this (entirely possible that we're already doing the right thing - best to check though) and make sure any breaking changes are as worth it as they can be.

[dixhuit]

Forgot to add: if any vars are moved to Vlad's apache role then I'd like to recommend using a vlad_apache_ prefix where appropriate.

[philipnorton42]

I'm torn between making the Apache component a galaxy role and keeping it in. It's a fundamental part of the system and lots of other roles (Adminer, PimpMyLog, etc) rely on Apache being there first and configured in a specific way.

If we did extract the role into a galaxy role we might still need some tasks present to configure some of the internal directories. Although a lot of the above work should cover this.

And yes. Prefixing the variables here is a good idea :)

[dixhuit]

I had similar concerns when refactoring the drush role. In the end I decided that in order to strike the best balance between a truly flexible, reusable Galaxy orientated role (not that the Drush role ended up on Galaxy - use you imagination for now!) and meeting any of Vlad's very specific needs that my preferred route was 2 roles:

• A "core" foundation role with lots of flex and minimal opinions
• An "extras" role that extends the core role to provide the opinionated stuff.

I like the idea that the Drush core role could effectively be swapped out later and all the bells & whistles in the extras role would stand half a chance of still working.

Could we adopt this approach with Vlad's use of Apache?

[philipnorton42]

Yup. I was actually thinking along the same lines. The galaxy role for a bunch of common/ un-opinionated setup and an additional role kept within the Vlad project for the local Vlad goodness.

[dixhuit]

Cool, well in that case, another tweak to suggested name space:

• apache galaxy role: apache_
• Vlad's apache_extras role: vlad_apache_extras_

I know I didn't follow suit when moving vars to the drush_extras role but at the time it was important to avoid breaking changes. I'd like to update this later as part of a big fat breaking update.

Btw, these breaking changes, should this all be going into a separate branch? Perhaps a v2 alpha/beta branch? Slight change of subject I know, new issue?

[philipnorton42]

I've created a 1.1.7 milestone for this. But maybe this would be better as a 1.2 milestone.

I think a review of milestones is in order :P

[dixhuit]

Can fit a Skype call today if that helps?

[zxaos]

Are the settings suggested in comment 1 in addition to the host_synced_folder settings or do they replace it? (In the case of the latter, I don't think it resolves the case described by #208 ).

[philipnorton42]

Good point. I think host_synced_folder would remain intact as this is a host setting. Not sure how this would effect the structure of the directories inside the server. We have two choices going forward here I think:

1) The host_synced_folder contains all of the site directories configured in the vlad_apache_settings setting. So rather than being served from /docroot/ everything would be served from /docroot/www.drupal.local. This will force people to use the system in a certain way, but it's not a bad way really... but it's a big change. 2) We alter the host_synced_folder to be an array and create an nfs instance for each site being created. I think this will create a lot of overhead in terms of nfs monitoring, but it creates the cleanest work environment.

Thoughts?

[zxaos]

I'm for option 2. I suspect that for many people the overhead won't be noticeable, and if it is you could just perform a option-1-style configuration within the flexibility afforded by option 2.

Part my preference for option 2 is that I don't think option 1 is that I don't think it resolves my personal use case for this change. So, I'm probably biased here.

[philipnorton42]

So I've been working away at this (very slowly). I have created a new branch (but not pushed it yet).

I've changed the above settings to be as follows:

vlad_webserver_settings:
- address: 'drupal.local'
  directory: 'drupal.local'
  synced: './docroot'
  aliases:
    - 'www.drupal.local'
    - 'www.test.local'
- address: 'drupal8.local'
  directory: 'drupal8.local'
  synced: './drupal8'
  aliases:
    - 'www.drupal8.local'

This fits in with option 2 above by adding the synced directory into the webserver settings. I'm currently altering the Vagrantfile so that it can grab the needed settings from this structure and do things with it. This has meant learning some Ruby, but I'm cool with that :)

[zxaos]

@philipnorton42 Is directory meant to be a subdir inside the synced folder (and the docroot)? or is directory the location in the VM that the synced directory is being placed?

[philipnorton42]

directory is the directory location on the guest machine (the VM). The synced setting allows you to set the corresponding directory on the host machine. I suppose these could be the same setting, but I wanted to allow for both backwards compatibility and user choice.

[philipnorton42]

I've spent some time this weekend getting the multi-site builds working with Vlad. Which has culminated in the creation of the multisite branch: https://github.com/hashbangcode/vlad/tree/multisite

The settings changes lead to a few directory structure changes so instead of /var/www/site/docroot we now have /var/www/vhosts/www.drupal.local/docroot, with each site getting it's own docroot. I'm still running a few test builds with a few different settings, but everything seems to be working well so far :)

I've also merged in the latest changes from the dev branch so it's all up to date with the latest changes in dev.

Obviously, there are lots of changes being proposed here, and many of them are hugely back-breaking changes so we need to tread carefully when releasing this. We could always create some form of update script that would allow migration of one settings and directory structure to the other. As well as updating the documentation describing the ins and outs of the new way of doing things.

[philipnorton42]

Just popping this in here so I don't lose it. It's one of the test configurations I've been using to test this setup with.

vlad_webserver_settings:
- address: 'drupal.local'
  directory: 'drupal.local'
  synced_folder: './drupal.local'
  aliases:
    - 'www.drupal.local'
    - 'www.test.local'
- address: 'drupal8.local'
  directory: 'drupal8.local'
  synced_folder: './drupal8.local'
  aliases:
    - 'www.drupal8.local'
- address: 'monkey.local'
  directory: 'yeknom.local'
  synced_folder: './dhsflkjhsld.local'
  aliases:
    - 'www.monkey.local'
    - 'www.yeknom.local'

[eelkeblok]

I am testing this branch with my current projects setup, but I'm having a little trouble how (if at all) I can. My current setup looks like this:

Projects
|-vlad
|-project1
  |-code
  |...
|-project2
  |-code
  |...
|...

I would like the projects to be available as hostnames project1.dev and project2.dev. The code subdirectories contain the actual docroot for each project.

I've tried to get this to work, but:

• I can't figure out where vlad is actually creating the shared folders (it shouldn't, actually, because I have working Drupal installations; I would just like to link it up to the existing installations)
• I can't figure out how to get vlad to use a different docroot directory name (i.e. "code", in my example).

Is there a way to get this to work with the current code? What would need to change to allow for this?

[philipnorton42]

Great that you're giving this a test! :+1: What you are proposing sounds like it should work. What does your vlad_webserver_settings section look like? That might be a good place to start in answering your questions.

[eelkeblok]

I had to wipe the laptop I tried this on, but it must've been something like this (the alternative docroot "code" isn't mentioned anywhere, so at least that makes sense it's not working, but the shared locations didn't seem to hold my existing projects either).

vlad_webserver_settings:
- address: 'vlad.dev'
  directory: '.'
  synced_folder: '.'
  aliases:
    - 'www.vlad.dev'
- address: 'project1.dev'
  directory: '../project1'
  synced_folder: '../project1'
  aliases:
    - 'www.project1.dev'
- address: 'project2.dev'
  directory: '../project2'
  synced_folder: '../project2'
  aliases:
    - 'project2a.dev'
    - 'project2b.dev'

Other observations:

• Aliases are manditory, or the Cagrantfile will error out.
• The first project is required, because there is a task that wants to write a default vlad index file.

Could you give some pointers on how I should modify my vlad_webserver_settings to support the scenario I outlined above?

[philipnorton42]

Thanks for this @eelkeblok. All good points. I think adding a little bit of validation to the Vagrantfile might be in order for this to work correctly. This branch is a bit experimental, so your testing is really important to making it better :)

[eelkeblok]

Do you have some pointers what might be going wrong with the above configuration?

[philipnorton42]

Sorry, I've been busy this week so I haven't had time to devote to this. I will have a look at what is going on here and comment on a solution soon.

[zxaos]

@philipnorton42 A suggested enhancement here:

With the currently suggested configuration, there isn't an explicit "default" site set. How would this affect the behaviour of vagrant share, which presumably can't use name-base virtual hosts?