* Updated CHANGELOG.md for version 2.0 Alpha 5
* Updated image tags in k8s files for 2.0 Alpha 5
* Updated version.py for 2.0 Alpha 5
* Problem: Missing alpha5 image update for test network containers
* Problem: CHANGELOG not updated with 2284
* Problem: Liveness probe frequency change not the important
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?
- Separate deployments, services, statefulsets etc
`yaml` files for tendermint based deployment.
- Separate Dockerfiles for mongodb, nginx for
tendermint integrated BigchainDB.
- turned off server tokens so the server does not leak nginx information
on errors and header
- Added header to turn off cross site scripting
- use stable release of nginx instead of mainline
- limit available methods
- update response code
- If a mandatory variable is not specified, it will exit with the relevant
code and error message.
- For more verbosity, we will also echo the values for all the mandatory
variables.
- Documentation support to add a new BDB node to an existing
replica set, using x.509 certificates and SSL/TSL connections, across
geographically dispersed clusters.
- Fix some documentation issues and add more references i.e.
specifically about signing of MongoDB member certificates.
- Minor fixes for nginx-https-dep.yaml(invalid configMap var)
- Reconfigure nginx keep_alive between MongoDB front and backend ports.
- Editor removed whitespaces
* Remove support for whitelist
* Rename nginx to nginx-api
* Remove websocket support from nginx-api
* Change nginx to nginx-api service
The nginx-api service will proxy requests to the BigchainDB HTTP API.
* Rename ngx-instance-0 to ngx-api-instance-0 in nginx_3scale
* Update nginx-api service base docker image and README
* Add nginx-ws service to support Websocket
* Add config files for simple dev setup
* WS support with split NGINX
* NGINX module as single entrypoint into the cluster.
* Tested HTTP and WS with latest configs
* Openresty as separate service
* Remove upstream api port as configuration parameter
* Changes while testing
* Adding READMEs for nginx-http and nginx-https modules
* Documentation update
* Change 'Openresty' to 'OpenResty'.