mirror of
https://github.com/bigchaindb/bigchaindb.git
synced 2024-10-13 13:34:05 +00:00
Remove cluster-dns
This commit is contained in:
Ahmed Muawia Khan
@@ -16,9 +16,9 @@ First create a directory for the CA and cd into it:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
mkdir bdb-cluster-ca
|
||||
mkdir bdb-node-ca
|
||||
|
||||
cd bdb-cluster-ca
|
||||
cd bdb-node-ca
|
||||
|
||||
Then :ref:`install and configure Easy-RSA in that directory <how-to-install-and-configure-easyrsa>`.
|
||||
|
||||
@@ -27,7 +27,7 @@ Step 2: Create a Self-Signed CA
|
||||
-------------------------------
|
||||
|
||||
You can create a self-signed CA
|
||||
by going to the ``bdb-cluster-ca/easy-rsa-3.0.1/easyrsa3`` directory and using:
|
||||
by going to the ``bdb-node-ca/easy-rsa-3.0.1/easyrsa3`` directory and using:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ to sign the request.
|
||||
|
||||
If you are the admin of the managing organization's self-signed CA,
|
||||
then you can import the CSR and use Easy-RSA to sign it.
|
||||
Go to your ``bdb-cluster-ca/easy-rsa-3.0.1/easyrsa3/``
|
||||
Go to your ``bdb-node-ca/easy-rsa-3.0.1/easyrsa3/``
|
||||
directory and do something like:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
@@ -69,6 +69,18 @@ These parameters are shared across the cluster. More information about the gener
|
||||
of these parameters can be found at :ref:`generate-the-blockchain-id-and-genesis-time`.
|
||||
|
||||
|
||||
vars.NODE_DNS_SERVER
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
`CLUSTER-IP` of Kubernetes service(kube-dns), can be retrieved using
|
||||
using CLI(kubectl) or k8s dashboard. This parameter is used by the Nginx gateway instance
|
||||
to resolve the hostnames of all the services running in the k8s cluster.
|
||||
The value defaults to `10.0.0.1`.
|
||||
|
||||
.. code::
|
||||
# retrieval via commandline.
|
||||
$ kubectl get services
|
||||
|
||||
|
||||
.. _generate-config:
|
||||
|
||||
Generate configuration
|
||||
|
||||
@@ -73,7 +73,7 @@ to the above command (i.e. the path to the private key).
|
||||
$ kubectl get pods
|
||||
|
||||
will get a list of the pods in the Kubernetes cluster associated
|
||||
with the context named ``k8s-bdb-test-cluster-0``.
|
||||
with the context named ``k8s-bdb-test-node-0``.
|
||||
|
||||
Step 2: Connect to Your Cluster's Web UI (Optional)
|
||||
---------------------------------------------------
|
||||
@@ -157,9 +157,9 @@ Step 5: Assign DNS Name to the NGINX Public IP
|
||||
|
||||
* Once a public IP is assigned, you can map it to
|
||||
a DNS name.
|
||||
We usually assign ``bdb-test-cluster-0``, ``bdb-test-cluster-1`` and
|
||||
We usually assign ``bdb-test-node-0``, ``bdb-test-node-1`` and
|
||||
so on in our documentation.
|
||||
Let's assume that we assign the unique name of ``bdb-test-cluster-0`` here.
|
||||
Let's assume that we assign the unique name of ``bdb-test-node-0`` here.
|
||||
|
||||
|
||||
**Set up DNS mapping in Azure.**
|
||||
@@ -171,7 +171,7 @@ changes to be reflected.
|
||||
Select the ``Public IP`` resource that is attached to your service (it should
|
||||
have the Azure DNS prefix name along with a long random string, without the
|
||||
``master-ip`` string), select ``Configuration``, add the DNS assigned above
|
||||
(for example, ``bdb-test-cluster-0``), click ``Save``, and wait for the
|
||||
(for example, ``bdb-test-node-0``), click ``Save``, and wait for the
|
||||
changes to be applied.
|
||||
|
||||
To verify the DNS setting is operational, you can run ``nslookup <DNS
|
||||
@@ -244,7 +244,7 @@ Step 10: Start the NGINX Kubernetes Deployment
|
||||
----------------------------------------------
|
||||
|
||||
* NGINX is used as a proxy to the BigchainDB, Tendermint and MongoDB instances in
|
||||
the node. It proxies HTTP/HTTPS requests on the ``cluster-frontend-port``
|
||||
the node. It proxies HTTP/HTTPS requests on the ``node-frontend-port``
|
||||
to the corresponding OpenResty(if 3scale enabled) or BigchainDB backend, TCP connections
|
||||
on ``mongodb-frontend-port``, ``tm-p2p-port`` and ``tm-pub-key-access``
|
||||
to MongoDB and Tendermint respectively.
|
||||
@@ -580,7 +580,7 @@ Step 20(Optional): Start a Kubernetes Deployment for OpenResty
|
||||
|
||||
* The configuration uses the following values set in the ConfigMap:
|
||||
|
||||
- ``cluster-dns-server-ip``
|
||||
- ``node-dns-server-ip``
|
||||
- ``openresty-backend-port``
|
||||
- ``ngx-bdb-instance-name``
|
||||
- ``bigchaindb-api-port``
|
||||
@@ -736,7 +736,7 @@ To test the vanilla NGINX instance:
|
||||
|
||||
$ nslookup ngx-http-instance-0
|
||||
|
||||
$ dig +noall +answer _public-cluster-port._tcp.ngx-http-instance-0.default.svc.cluster.local SRV
|
||||
$ dig +noall +answer _public-node-port._tcp.ngx-http-instance-0.default.svc.cluster.local SRV
|
||||
|
||||
$ dig +noall +answer _public-health-check-port._tcp.ngx-http-instance-0.default.svc.cluster.local SRV
|
||||
|
||||
@@ -755,15 +755,15 @@ To test the NGINX instance with HTTPS and 3scale integration:
|
||||
|
||||
$ nslookup ngx-instance-0
|
||||
|
||||
$ dig +noall +answer _public-secure-cluster-port._tcp.ngx-instance-0.default.svc.cluster.local SRV
|
||||
$ dig +noall +answer _public-secure-node-port._tcp.ngx-instance-0.default.svc.cluster.local SRV
|
||||
|
||||
$ dig +noall +answer _public-mdb-port._tcp.ngx-instance-0.default.svc.cluster.local SRV
|
||||
|
||||
$ dig +noall +answer _public-insecure-cluster-port._tcp.ngx-instance-0.default.svc.cluster.local SRV
|
||||
$ dig +noall +answer _public-insecure-node-port._tcp.ngx-instance-0.default.svc.cluster.local SRV
|
||||
|
||||
$ wsc -er wss://<cluster-fqdn>/api/v1/streams/valid_transactions
|
||||
$ wsc -er wss://<node-fqdn>/api/v1/streams/valid_transactions
|
||||
|
||||
$ curl -X GET http://<cluster-fqdn>:27017
|
||||
$ curl -X GET http://<node-fqdn>:27017
|
||||
|
||||
The above curl command should result in the response
|
||||
``It looks like you are trying to access MongoDB over HTTP on the native driver port.``
|
||||
@@ -776,7 +776,7 @@ Check the MongoDB monitoring agent on the MongoDB Cloud Manager
|
||||
portal to verify they are working fine.
|
||||
|
||||
If you are using the NGINX with HTTP support, accessing the URL
|
||||
``http://<DNS/IP of your exposed BigchainDB service endpoint>:cluster-frontend-port``
|
||||
``http://<DNS/IP of your exposed BigchainDB service endpoint>:node-frontend-port``
|
||||
on your browser should result in a JSON response that shows the BigchainDB
|
||||
server version, among other things.
|
||||
If you are using the NGINX with HTTPS support, use ``https`` instead of
|
||||
|
||||
@@ -14,7 +14,7 @@ Since we used Easy-RSA version 3 to
|
||||
we use it to revoke certificates too.
|
||||
|
||||
Go to the following directory (associated with the self-signed CA):
|
||||
``.../bdb-cluster-ca/easy-rsa-3.0.1/easyrsa3``.
|
||||
``.../bdb-node-ca/easy-rsa-3.0.1/easyrsa3``.
|
||||
You need to be aware of the file name used to import the certificate using the
|
||||
``./easyrsa import-req`` before. Run the following command to revoke a
|
||||
certificate:
|
||||
|
||||
@@ -70,7 +70,7 @@ to sign the request.
|
||||
|
||||
If you are the admin of the managing organization's self-signed CA,
|
||||
then you can import the CSR and use Easy-RSA to sign it.
|
||||
Go to your ``bdb-cluster-ca/easy-rsa-3.0.1/easyrsa3/``
|
||||
Go to your ``bdb-node-ca/easy-rsa-3.0.1/easyrsa3/``
|
||||
directory and do something like:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
Reference in New Issue
Block a user