mirror of
https://github.com/bigchaindb/bigchaindb.git
synced 2024-10-13 13:34:05 +00:00
108 lines
3.9 KiB
ReStructuredText
108 lines
3.9 KiB
ReStructuredText
.. _kubernetes-template-overview:
|
|
|
|
Overview
|
|
========
|
|
|
|
This page summarizes the steps *we* go through
|
|
to set up a production BigchainDB cluster.
|
|
We are constantly improving them.
|
|
You can modify them to suit your needs.
|
|
|
|
.. _generate-the-blockchain-id-and-genesis-time:
|
|
|
|
Generate All Shared Tendermint Setup Parameters
|
|
-----------------------------------------------
|
|
|
|
There are some shared Tendermint setup paramters that every node operator
|
|
in the consortium shares
|
|
because they are properties of the Tendermint cluster.
|
|
They look like this:
|
|
|
|
.. code::
|
|
|
|
# Tendermint data
|
|
TM_SEEDS='tm-instance-1,tm-instance-2,tm-instance-3,tm-instance-4'
|
|
TM_VALIDATORS='tm-instance-1,tm-instance-2,tm-instance-3,tm-instance-4'
|
|
TM_VALIDATOR_POWERS='10,10,10,10'
|
|
TM_GENESIS_TIME='0001-01-01T00:00:00Z'
|
|
TM_CHAIN_ID='test-chain-rwcPML'
|
|
|
|
Those paramters only have to be generated once, by one member of the consortium.
|
|
That person will then share the results (Tendermint setup parameters)
|
|
with all the node operators.
|
|
|
|
The above example parameters are for a cluster of 4 initial (seed) nodes.
|
|
Note how ``TM_SEEDS``, ``TM_VALIDATORS`` and ``TM_VALIDATOR_POWERS`` are lists
|
|
with 4 items each.
|
|
**If your consortium has a different number of initial nodes,
|
|
then those lists should have that number or items.**
|
|
Use ``10`` for all the power values.
|
|
|
|
To generate a ``TM_GENESIS_TIME`` and a ``TM_CHAIN_ID``,
|
|
you can do this:
|
|
|
|
.. code::
|
|
|
|
$ mkdir $(pwd)/tmdata
|
|
$ docker run --rm -v $(pwd)/tmdata:/tendermint tendermint/tendermint:0.13 init
|
|
$ cat $(pwd)/tmdata/genesis.json
|
|
|
|
You should see something that looks like:
|
|
|
|
.. code:: json
|
|
|
|
{"genesis_time": "0001-01-01T00:00:00Z",
|
|
"chain_id": "test-chain-bGX7PM",
|
|
"validators": [
|
|
{"pub_key":
|
|
{"type": "ed25519",
|
|
"data": "4669C4B966EB8B99E45E40982B2716A9D3FA53B54C68088DAB2689935D7AF1A9"},
|
|
"power": 10,
|
|
"name": ""}
|
|
],
|
|
"app_hash": ""
|
|
}
|
|
|
|
The value with ``"genesis_time"`` is ``TM_GENESIS_TIME`` and
|
|
the value with ``"chain_id"`` is ``TM_CHAIN_ID``.
|
|
|
|
Now you have all the Tendermint setup parameters and can share them
|
|
with all of the node operators. (They will put them in their ``vars`` file.
|
|
We'll say more about that file below.)
|
|
|
|
|
|
.. _things-each-node-operator-must-do:
|
|
|
|
Things Each Node Operator Must Do
|
|
---------------------------------
|
|
|
|
1. :doc:`Deploy a Kubernetes cluster on Azure <../production-deployment-template/template-kubernetes-azure>`.
|
|
|
|
2. Make up an FQDN for your BigchainDB node (e.g. ``mynode.mycorp.com``).
|
|
Make sure you've registered the associated domain name (e.g. ``mycorp.com``),
|
|
and have an SSL certificate for the FQDN.
|
|
(You can get an SSL certificate from any SSL certificate provider.)
|
|
|
|
3. Download the HTTPS certificate chain and HTTPS certificate key of your registered domain.
|
|
Certificate chain includes your primary SSL cert (e.g. your_domain.crt) followed by all intermediate and root
|
|
CA cert(s). e.g. If cert if from DigiCert, download "Best format for nginx".
|
|
|
|
4a. If the BigchainDB node uses 3scale for API authentication, monitoring and billing,
|
|
you must ask the BigchainDB node operator/owner for all relevant 3scale credentials and deployment
|
|
workflow.
|
|
|
|
4b. If the BigchainDB does not use 3scale for API authentication, then the organization managing the BigchainDB
|
|
node **must** generate a unique *SECRET_TOKEN* for authentication and authorization of requests to the BigchainDB node.
|
|
|
|
.. Note::
|
|
All the operations required to set up a Self-Signed CA can be automatically generated from
|
|
our :ref:`"How to configure a BigchainDB node" <how-to-configure-a-bigchaindb-node>` guide.
|
|
|
|
5. Set Up a Self-Signed Certificate Authority
|
|
|
|
We use SSL/TLS and self-signed certificates
|
|
for MongoDB authentication (and message encryption).
|
|
The certificates are signed by the organization managing the :ref:`bigchaindb-node`.
|
|
|
|
You can now proceed to set up your :ref:`BigchainDB node <kubernetes-template-deploy-a-single-bigchaindb-node>`.
|