Solution
Since BigchainDB and Tendermint are so tightly coupled we need to introduce a process supervisor to make them act like a single microservice, so that if BigchainDB crashes, Tendermint does as well and both are restarted and Tendermint requests a connection towards the proxy app.
In Kubernetes, they can be exposed as part of a one POD.
For BigchainDB as a system service/process, we need to introduce a process supervisor such as systemd.
This PR only solves the former.
Changes
Upgrade deployment from Tendermint v0.12.0 to v0.19.0
Update some documentation
Fix nginx-http entrypoint issues.
Update generate-configs.sh script to handle config generation without https-certificates.
Update Dockerfile to process dependency links introduced by abci
Integrate BigchainDB and Tendermint as a single microservice.
This required making BigchainDB to be exposed as a statefulset.
Introduce new liveness probe checks.
Issues Resolved
Partially fixes#2232
* Fix for access token authorization for GET calls
- Naming inconsistency for cluster-fqdn causing issues
- Change cluster-frontend-port to node-frontend-port
* Change hardcoded 9984 to configurable
Problem
The current production deployment template uses 3scale to ensure that POST requests to the network (from anyone) only get through if they come from a client with an account (app_id and app_key).
A private network wants to launch so that all HTTP requests (POST and GET) sent to the nodes in the network get be dropped unless they come from a small set of known (and unchanging) clients/sources. They don't need 3scale. They will want a modified version of the production deployment template.
Solution
Generate a special HTTP header and share it with all the known clients/sources.
Have a single NGINX in each node which checks for that HTTP header value. If it's present, let the request pass through to the network. (HTTP headers are encrypted if HTTPS is used.)
Are there other simpler or better options?
