We manually add all the required configurations and secretes in config-map.yaml and secret.yaml. There is a need for a wrapper script which takes these generated mongodb certs and also process https certificates and populates config-map.yaml and secret.yaml
- Update docs for azure cluster deployment template
- Update entrypoint for MongoDB to handle user configuration
more efficiently
- remove `use admin` in js file, that is an invalid format
- Currently, we had to manually log into the MongoDB container
and create users, this change will configure the relevant users
from a single script `configure_mdb.sh`
- Improvements can be done but keeping it minimal for the workshop
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?
- Remove commands that were not required.
- export-my-pubkey
- set-shards
- set-replicas
- add-replicas
- remove-replicas
- Update bigchaindb --help, usage description
- Re-enable tests
- Update docker-compose.travis.yml and Dockerfile for travis
because some env variables are not needed
- No need to deprecate commands that are not needed because
tendermint integrated BigchainDB does not overlap with
BigchainDB(v1.x)
- Update some sets
- Add more commands and usage.
- Update imagePullPolicy from IfNotPresent to Always
for all unstable images we are using in k8s template,
because those images are updated regularly, we will
keep it unstable until the official release.
- Use Tendermint v0.13 as base docker image, since our current
integration is based out of v0.13
Description
Currently we manually configure ports in deployment and service files for k8s deployment e.g here. Instead these ports should be constant since these are always the same for each deployment
Issues This PR Fixes
Fixes#2077