BlueSpice 5 is delivered as a container-based application stack. The architecture is modular and can be operated as an all-in-one setup or adapted to use external services such as a custom database, search service or load balancer / reverse proxy. BlueSpice 5 is not installed as a classic manual file-based application; it is primarily provided through container images.
Architecture diagram
* MongoDB is used for collaborative editing. The main application database is MySQL or MariaDB; BlueSpice 5 also supports external database services if required.
Load balancer
The load balancer is the central entry point for users. It accepts HTTPS requests and routes them to one or more frontend containers. In a single-node setup, this can be the proxy container shipped with the BlueSpice stack. In enterprise or high-availability environments, the proxy layer can be replaced by an existing customer load balancer or reverse proxy infrastructure.
The load balancer is responsible for TLS termination, routing, health checks and distribution of traffic. Only the frontend containers should receive external web traffic; databases, storage, search and task services remain internal backend services.
Depending on the setup, the load balancer can route traffic to one wiki instance, to multiple frontend containers of the same wiki instance, or to multiple wiki instances in a wiki farm.
Frontend container: API, BlueSpice app and resources
The frontend container is the user-facing application container. It serves the BlueSpice web interface, MediaWiki and BlueSpice APIs, static resources, skins, JavaScript, CSS and user interactions. In the Docker stack this corresponds to the main wiki web service, commonly referred to as wiki-web. The BlueSpice Docker stack defines the main wiki containers as wiki-web and wiki-task.
The frontend container does not contain the authoritative persistent wiki data. Persistent data such as page content, uploaded files, database records and search indexes belong to the backend services of the corresponding wiki instance.
In a horizontally scaled setup, multiple frontend containers can serve the same wiki instance behind a load balancer. In that case, they must use the same backend context for that wiki instance.
In a wiki farm setup, however, each wiki instance has its own application and backend context unless the environment is explicitly configured otherwise.
Taskrunner container: Regular tasks, notifications and maintenance
The taskrunner container handles background work that should not be executed directly in the user request path. This includes regular scheduled jobs, notification processing, maintenance scripts, update tasks, queue processing and other recurring application tasks. In the Docker stack this corresponds to the wiki-task container. During the first startup, the wiki-task container also performs the initial installation and database setup.
Typical responsibilities of the taskrunner include:
- scheduled jobs;
- notification processing;
- maintenance scripts;
- update and housekeeping tasks;
- background processing;
- search indexing jobs where applicable.
The taskrunner belongs to the same wiki instance as the frontend container. It must use the same configuration and backend services as that wiki instance.
Database
The database stores the structured application data of the wiki, including pages, revisions, users, permissions, configuration data and extension data. BlueSpice 5 uses MySQL or MariaDB for the main application database. The standard container stack includes database services, but external database services can also be configured.
The database is part of the persistent data context of a specific wiki instance.
In a wiki farm setup, each wiki instance typically has its own database context. A shared database across multiple independent wiki instances should not be assumed unless the customer environment has been explicitly designed that way.
Storage
Storage contains persistent file-based data such as uploaded files, generated files, configuration-related data and other wiki data that must survive container restarts or replacement.
The Docker deployment uses a configurable data directory, for example DATADIR=/data/bluespice, to store persistent data outside the containers.
For a horizontally scaled setup of the same wiki instance, the storage design must ensure that all relevant frontend and taskrunner containers of that wiki instance can access the required persistent files.
At the moment, BlueSpice 5 does not provide a general shared resources module or shared file system for uploaded files across independent wiki instances.
Search
Search is provided by OpenSearch. BlueSpice 5 supports OpenSearch 2.x with the ingest-attachments plugin, which enables indexing of wiki content and attached files.
Search is generally handled on a wiki-instance basis. In wiki farm environments, instances can be configured to participate in global search, so that a search in one wiki can also return results from other configured wiki instances.
Common services
Common services are auxiliary services required by the BlueSpice application. Depending on the edition and enabled features, these can include services for caching, rendering, PDF export, formulas, diagrams, Java/Tomcat-based services, NodeJS-based services and other supporting functionality.
Node 2 ... n: Horizontal scaling
Additional nodes can be added by running further frontend containers behind the load balancer. This is the primary horizontal scaling model for BlueSpice web traffic. The operating manual explicitly notes that BlueSpice can run in a distributed environment and that one possible scenario is horizontal scaling of the web frontend service.
In a horizontally scaled setup of one wiki instance, additional frontend containers can be added behind the load balancer. These frontend containers serve the same wiki instance and use the backend services of that wiki instance. This can be used to scale user-facing web traffic.
In a wiki farm setup, Node 1, Node 2 and further nodes may instead represent separate wiki instances. In that case, each wiki instance has its own application context and its own persistent data context, including database, storage and search configuration.
Request and processing flow
A typical user request flows through the load balancer to the appropriate frontend container. The frontend container serves the BlueSpice interface, processes API calls and retrieves or writes data through the database, storage and search services of the corresponding wiki instance.
Static resources are delivered by the frontend container, while backend functions such as search indexing, notifications, maintenance and scheduled jobs are handled by the taskrunner.
In a simple setup, all components belong to one wiki instance. In a horizontally scaled setup, several frontend containers may serve the same wiki instance. In a wiki farm setup, several wiki instances may exist side by side, and selected features such as global search can connect them where configured.
