Set a production and development server in the build-oracc server

[raquelalegre]

Production and development servers should run the contents of the master and development branch, respectively.

[ageorgou]

@raquel-ucl has set this up:

• Port 5000 has a Flask server running the master branch with export FLASK_ENV=production
• Port 5100 is running development with export FLASK_ENV=development
• Both servers running with nohup

This is currently realised by having two copies of the repository under workspace/oracc-rest. We might be able to achieve the same thing but a bit cleaner with git worktree if I understand it right - perhaps worth looking into (more info)?

This can probably be closed now though!

[ageorgou]

Actually, before this is closed, we should consider setting up the code to choose between port 9200 or 9300, depending on the FLASK_ENV (so make a configuration file for the app), so that we don't accidentally mess up the main ElasticSearch instance from the development app.

[ageorgou]

This is a bit more complicated: by default, ElasticSearch uses port 9200 for external access and port 9300 for communication between nodes. Since we have ports 9200 and 9300 open on the build server, we can restart ElasticSearch to use 9200 for external and (eg) 9201 for internal communication:
elasticsearch -E http.port=9200 -E transport.tcp.port=9201
We can then have an development version running on ports 9300 and 9301.

Another issue to consider is how to pass the choice of ES port to the Flask app. I think the easiest option would be an ES_PORTS environment variable (defaulting to 9200 if that is not set).

The cleanest way would be to say that the develoment configuration always uses ES on 9300 and listens to requests on 5100, and the production configuration uses ES on 9200 and listens to requests on 5000 (default values for ES and Flask). However, our main instructions here are for a development setup but they use 9200 and 5000, so they (and our local workflow) would need to be changed. Having an extra variable to control the ES port would give more flexibility, which is why I would favour it.

This is all assuming that we actually want to have two instances of ES running...

Does this make sense, @raquel-ucl?