• Sign In
  1. Messages

Running two distinct sites off one LabKey Server instance?

LabKey Support Forum

View Message

view list print
Running two distinct sites off one LabKey Server instance? Ben Bimber  2018-03-21 09:14
Status: Closed
 

I have talked with some of you about this, but I wanted to revisit something we're considering. We have a couple smaller grants that would like a public facing LabKey site. These will be low use, and there is a lot of extra cost and time from paying for distinct VMs, configuring LK instances, etc. specific to each project. It would be really nice if we could host all of these off one LK instance, possibly adding/removing projects over time. Obviously I can make separate projects for each one; however, it would be highly preferable to make each one look and behave to users as though it was the only thing being hosted off that LK instance. A single site with different project doesnt behave like that at all. My base assumption is that each 'site' is actually a project within LabKey.

Requirements would be:

  • dedicated URL for each project (i.e. https://myproject.ohsu.edu, not https://labkey.ohsu.edu/myproject/). I think I can do some configuration in httpd to shuttle traffic from that project-specific URL to the LK project URL, but have not tried that. i dont know if there will be gotchas from the different host names. it would be nice to keep the URL in the browser with that project-specific URL, as opposed to doing a one-time redirect and then using generic URLs.

  • whenever people access their project, all site UI should look as though it is specific to their "site". for example, each project should have their own logo, and maybe color scheme. i believe that's possible to configure project-level already

  • this does mean regular users should never get UI that directs them to anything outside their project. this is the trickiest one. a lot of UI in LabKey directs you to /home, and because there is one /home shared across all these 'sites', it would need to be non-branded. it's ideally a never accessed folder.

Has anyone attempted to thought about this, and are there any pitfalls or problems I'm not thinking about?
 
 
adam responded:  2018-03-27 11:11

Security groups and role assignments are project-scoped and would work reasonably well in this scenario. And yes, the "look and feel settings" set on a per project basis would help, as far as they go. Beyond that, treating projects as separate "sites" could be an uphill battle. In addition to the home project, there are quite a few site-wide resources, settings, and pages that might need to become project-scoped. Some that come to mind: the Shared project, base server URL, authentication settings, headers/footers/site welcome page, scripting engines, email templates, user management workflows, et al. You'd still be stuck with a single group of site administrators, site settings, and users (maybe that's what you want), and you'd have to be very prescriptive with role assignments to ensure that projects don't bleed into other "sites."

One easier alternative: Take advantage of LabKey's new cloud services, low-cost (or free, depending on your Premium Edition) hosting options that offload all the configuration and maintenance of your deployments. Your multiple sites could be administered and scaled independently. LabKey Cloud Services

Another alternative: Deploy your sites on-premise on a shared machine or VM. Use a single machine, database server, Tomcat instance, and LabKey distribution, but separate databases for each site. Configure Tomcat to respond to multiple domains. This would give you independent sites with distinct URLs but easier maintenance compared to distinct machines for each site.

Adam
 
Ben Bimber responded:  2018-03-27 12:11

Thanks. Your idea about tomcat with multiple domains might be a better idea than my idea of multiple projects. The fact that some site settings are shared was actually generally a positive for our purposes; however, I bet we could synchronize some of that.

We actually more or less have a cloned VM per site/project now (though the dev-ops stuff isnt as efficient as it should be). Unfortunately we are also charged per VM, which is really kinda silly for the actual use these 'sites' get and the cost hoping to avoid. Even with the clones VM, there's still a non-zero time cost with each new VM instance as well.

Does LabKey have any newer features designed to help bootstrap a fresh instance with some config automatically applies? If you're spinning up cloud instances perhaps this has been considered?
 
jeckels responded:  2018-03-27 12:43

Yes, please see ModuleLoader.getConfigProperties(), which we use when bootstrapping newly provisioned instances.

Thanks,
Josh