Improvements for self-hosting

[lukavdplas]

In the long term, I'd love to see other teams adopt I-analyzer and host their own version. That's technically possible right now, but it's not really an attractive option unless you're capable of forking the repository and doing some development of your own.

How can we improve this? Suggestions welcome; right now, I can think of the following things:

• Clear documentation for setting up a server
• Something something docker. We have a docker configuration for development; I'm not really sure what (if anything) is needed to make that a solution for deployment
• Some parts of the frontend should be configurable without forking, such as the about page, logos, privacy statement. Some of these already are, some are not.
• Make it straightforward to add corpora without forking. We're already working on this.

[BeritJanssen]

Some thoughts about deployment setup for Docker:

No adjustment necessary:

• as far as I'm aware, the redis and celery services could be adapted directly from the Docker dev setup

Adjustments that are relatively easy:

• use gunicorn instead of Django server for backend service
• build frontend instead of using Angular server for frontend service
• adjust ENV variables

Adjustments that need decisions:

Apache / Nginx config

This could be achieved through either an additional Nginx container with the application-specific nginx config, or would have to be handled directly on the server.

Database

The current Docker setup implies that the database is also containerized. That works fine, but there is no periodical backup system for the database is in place (yet). Using a native database would be tricky with Docker - the container can network among themselves, but cannot usually access the host network, unless you let the Docker containers run on the network of the host machine, which may have security drawbacks.

Elasticsearch

Also, the current dev setup containerizes Elasticsearch - this could be a feature (each server can have their own containerized cluster), but also a drawback, as sharing a cluster with multiple servers will be more involved (you'd need to define shared networks for that, and if we have a "backend" service running on it multiple times, this will lead to conflicts). For the containerized version, we would also need to decide whether or not to support Kibana. Adding a container for Kibana is easy, but access to it would still need to be achieved through routes in an nginx/apache config.

As we'll likely get into "networking between containers on multiple VMs" territory here, it's worthwhile to first look into Kubernetes before taking further steps.