mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
Fresh look at Multiple BookStack Instances #1247
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @DeftNerd on GitHub (Jul 3, 2019).
As described in issue #215 there are times where a single code base serving multiple BookStack instances could be valuable.
I'm creating this feature request to get input from the developers and community. If there is interest in this feature, I can try to implement it and submit the changes as a PR.
The current instructions for Multiple BookStack Instances basically just teach people how to set up vhosts and install BookStack into multiple directories. This makes sense because of two assumptions:
I believe both of these problems can be overcome
Overcoming .env Issues
Laravel's .env handler is actually the vlucas/phpdotenv package. One of the nice features that the package has is that it'll only apply .env values that do not conflict with environmental variables set by PHP or by Apache/Nginx itself. This creates an opportunity where the PHP-FPM process or the web server can be configured to set values such as APP_KEY, APP_URL, DB_DATABASE, etc.
The server administrator could set values in the .env file that are shared among all of the BookStack instances (DB_HOST, MAIL_HOST, etc) and then only configure the PHP/HTTPServer environmental variables for the values that are unique for every instance.
Another possibility would be just looking a .env file setting of
MULTITENANT=TRUEwhich could configure the app to look for .env files in somewhere like"/storage/tenants/intranet.example.com/.envand then use the contents to override the default values or just pass it onto the LaraveluseEnvironmentPath()andloadEnvironmentFrom()functions. This would avoid having to set too many variables within the php-fpm worker pool configuration or the HTTP server vhost config.Overcoming File Storage issues
It wouldn't be too difficult to add a new
config/app.phporconfig/filesystem.phpmodification that allows for an environmental variable to be used to specify a subdirectory withinstorage/uploadsor perhaps even a new directory likestorage/tenants, resulting in something likestorage/tenants/intranet.example.com/uploadsorstorage/tenants/docs.example.com/uploadsThis will require some modification of some hard-coded values like $basePath in \BookStack\Uploads\AttachmentService::putFileInStorage() so it uses the config() helper to build the proper $basePath.
It might also be possible to just specify a different filesystem location within an environmental variable that doesn't have to reside within
storage, like/mnt/files/intranetPossible Pitfalls
Specifying environmental variables within PHP or the web server might not expose them to CLI-based PHP execution.
It will probaby break
artisan migrateand require aartisan bookstack:migrateor to extend theartisan migratecommand to be multi-tenant aware and handle it cleanly.Potential future cron calls to
artisan queue:workwould also have to take it into account.Alternatives
Would it be better to just explore using the tenancy/multi-tenant package and refactoring BookStack to use that? It's potentially a difficult thing to accomplish without breaking existing installations, but it might be possible. At the very least, it would be worth examining what they've built to learn from their hard work.
@ssddanbrown commented on GitHub (Jul 3, 2019):
Thanks @DeftNerd for the detailed proposal.
To be totally honest, Right now I really don't see the implementation effort and, more importantly, the maintenance effort being worth the benefit this feature would bring. This would be a pain to test for in addition to bringing a new potential variable into the mix when helping with support.
This would likely be something used by a very small segment of the BookStack audience and, once implemented, would probably widen the appeal only to those that may not be using the platform for the primary purpose it provides (Thinking along the lines of someone providing wiki hosting rather than using BookStack for an internal wiki themselves).
If someone was serious enough about needing a multi-instance setup, I think they'd be better suited to doing this at an infrastructure level than us supporting at app-level especially since systems, configuration & integrations could vary wildly. In this day and age of containers you could achieve this quite nicely with a container for each instance routed to from central proxy.
Apologies if it seems I'm being rather dismissal, Maybe I just don't see a vital use case, but I'm happy to leave this open for a while to gather insight and thoughts as I could likely be wrong and be missing a much needed requirement.
@DeftNerd commented on GitHub (Jul 4, 2019):
That makes perfect sense and I concur with your opinion. It's a feature that, while useful to a few people, would likely add points of failure and have possible unexpected results that could impact a much larger userbase.
Your suggestion of using Docker is a very sane, and modern, approach.
I think I just ran across the old issue and went down a rabbit hole of musing about "how could it be accomplished?" without much consideration about if it should be accomplished.
Your response was not dismissive at all. You showed great thoughtfulness to the idea and gave it full consideration. Thank you!
@ssddanbrown commented on GitHub (Jul 4, 2019):
Thank you for your understanding @DeftNerd. In that case, I'll close this if you agree with my thinking. Can always be found via search for people looking for multi-instances in the future.