Bigchaindb instalar Blockchain en ec2
Documento basado en el link https://docs.bigchaindb.com
BigchainDB, MongoDB and Tendermint EC2
Instalar y configurar software para BigchainDB en cada node: BigchainDB Server, MongoDB and Tendermint.
¿Qué es la blockchain?
La blockchain o cadena de bloques, es un registro que guarda las transacciones de las criptomonedas, parecido a un libro contable. La información se almacena en cada bloque de la cadena y cada uno contiene lo siguiente:
La cantidad de transacciones o registros válidos.
La información vinculada a ese bloque.
La vinculación con el bloque anterior y el bloque siguiente por medio del hash de cada bloque, que es un código único que hace el papel de la huella digital del bloque.
Cada bloque tiene un sitio particular e inamovible dentro de la cadena, porque cada uno contiene datos del hash del bloque anterior. La cadena completa es guardada en cada nodo de la red donde está conformada la blockchain y una copia exacta de la misma, es almacenada en todos los participantes de la red.
A medida que nuevos registros son creados, estos son validados y verificados por los nodos de la red y luego se añaden a un nuevo bloque que es enlazado a la cadena.
BigchainDB Introducción
Los desarrolladores describen Ethereum como «una plataforma de código abierto para escribir y distribuir aplicaciones descentralizadas». Una plataforma descentralizada para aplicaciones que se ejecutan exactamente como están programadas, sin posibilidad de fraude, censura o interferencia de terceros. Por otro lado, BigchainDB se detalla como «Una base de datos con características de blockchain». Está diseñada para fusionar lo mejor de dos mundos: el mundo «tradicional» de las bases de datos distribuidas y el mundo «tradicional» del blockchain. Con un alto rendimiento, una baja latencia, una potente funcionalidad de consulta, un control descentralizado, un almacenamiento de datos inmutable y un soporte de activos incorporado.
BigchainDB permite a los desarrolladores y a la empresa implementar pruebas de concepto, plataformas y aplicaciones de blockchain con una base de datos blockchain escalable. En lugar de tratar de escalar la tecnología blockchain, BigchainDB comienza con una base de datos distribuida y luego agrega características de blockchain - control descentralizado, inmutabilidad y la capacidad de crear y transferir activos. BigchainDB es compatible con una amplia gama de industrias y casos de uso, desde la identidad y la propiedad intelectual hasta las cadenas de suministro, la energía, el IoT y los ecosistemas financieros. Con un alto rendimiento, latencia de menos de un segundo y una potente funcionalidad para automatizar los procesos de negocio, BigchainDB se ve, actúa y se siente como una base de datos, pero tiene las características principales de blockchain que las empresas desean.
Esta arquitectura permite a cualquier desarrollador construir aplicaciones blockchain rápidamente sin necesidad de un conocimiento profundo de las tecnologías blockchain subyacentes, una barrera importante para una adopción más amplia de blockchain
A BigchainDB node usa un sistema de clock (reloj) para generar los timestamp para block y votos, así que el reloj debe guardar total sincronía con algún reloj standar(s). Una forma estándar de hacerlo es mediante NTP daemon (Network Time Protocol daemon) o con CHRONY de amazon ec2 en cada nodo.
Verificar con el comandos
#sudo date
#mié nov 30 20:40:40 UTC 2022
En todos los nodos que la fecha y hora este sincronizada
Instalar reloj en cada nodo:
# sudo yum install ntp
o
#sudo yum install chrony
Dependiendo de su versión de ec2 que tenga el nodo
Instalar BigchainDB Server
BigchainDB Server requiere Python 3.6+,
Para ec2:
#sudo yum install python3-pip
ec2 16.04, y otras distribuciones linux, puede requerir otros paquetes según el caso
#sudo yum install libffi-devel
#sudo yum install openssl-devel
BigchainDB Server requiere gevent, para instalar gevent, debe usar pip3 o superior.
#sudo pip3 install -U pip
#sudo yum install python3-devel
#sudo pip3 install --upgrade setuptools
#sudo pip3 install Cmake
#sudo pip3 install python-rapidjson
#sudo yum install gcc
#sudo pip3 install wheel
Ahora instalar la ultima versión de BigchainDB Server. Se puede encontarar en el enlace BigchainDB project release history page on PyPI. Para instalar la ultima versión
# sudo pip3 install BigchainDB
Verifique la versión correcta de BigchainDB Server usando bigchaindb --version.
Configure BigchainDB Server
Para configurar BigchainDB Server, ejecute:
# sudo bigchaindb configure
La primera pregunta cual es su API Server bind? (default `localhost:9984`).
Si usa NGINX (e.g. si usa HTTPS), acepte el valor por defecto (
localhost:9984).Si usted no está usando NGINX, entonces entre el valor
0.0.0.0:9984
Usted puede aceptar los valores por defecto para todo las preguntas que solicita BigchainDB config settings y seleccionar 0.0.0.0:9984 indicando que no esta usando NGINX (si desea usarlo mas adelante se puede configurar)
Si usa NGINX, se debe editar BigchainDB config file (in $HOME/.bigchaindb por defecto) y colo
car los siguientes valores en "wsserver":
"advertised_scheme": "wss",
"advertised_host": "bnode.example.com",
"advertised_port": 443
donde bnode.example.com debe ser remplazado con el valor de su sub dominio.
NOTA: Para la instalación inicial recomiendo hacer la configuración básica dando enter en toda las preguntas que solicitan, posteriormente se puede configurar NGIX para implementar la seguridad, el instalar de forma inmediata NGIX crea una dificultad que de momento no considero aporte nada importante a la instalación base de bigchaindb, mas adelante volveremos sobre este punto para proteger los nodos.
Instalar la reciente versión de MongoDB. BigchainDB Server se requiere 3.4 o superior.
# sudo yum install mongodb
# sudo systemctl status mongodb
Si no existe debe crear /var/log
# sudo mkdir /var/log
Si usted instala MongoDB el anterior comando,i if configura MongoDB, inicie MongoDB (en background), e instale un MongoDB startup script (para que mondo se inicie automaticamente una vez la maquina se reinicie.
Revise la documentación de MongoDB para la forma correcta de iniciar MongoDB en su maquina.
Instalar Tendermint
La versión de BigchainDB Server indica que solo funciona correctamente con la versión 0.31.5 o superior:
Instalamos los siguientes paquetes que nos permiten descomprimir e instalar tendermint
# sudo yum install unzip
# sudo yum install wget
# sudo wget https://github.com/tendermint/tendermint/releases/download/v0.31.5/tendermint_v0.31.5_linux_amd64.zip
#sudo unzip tendermint_v0.31.5_linux_amd64.zip
#sudo rm tendermint_v0.31.5_linux_amd64.zip
#sudo mv tendermint /usr/local/bin
Iniciar Configuración Tendermint
Que es Tendermint?
Tendermint es un protocolo de blockchain creado en 2014, que se utiliza para replicar y lanzar aplicaciones de blockchain en máquinas de forma segura y consistente.
Tendermint es un algoritmo de consenso utilizado por muchos proyectos de blockchain. Tendermint Core está compuesto de:
Un motor de consenso basado en PoS (Proof of Stake)
La interfaz de aplicación de la cadena de bloques (ABCI) que actúa como una herramienta para que las cadenas de bloques se vinculen al protocolo Tendermint Core
El propósito de Tendermint es ser un motor de blockchain. Está pensado para ser una herramienta que los desarrolladores puedan utilizar para no tener que dedicar esfuerzos y recursos a la parte de la criptografía y saltar al desarrollo de aplicaciones y blockchains de más alto nivel.
En el algoritmo de consenso de Tendermint se basa en el concepto fundamental de Tolerancia a Fallos Bizantinos (BFT). El BFT Proof-of-Stake de Tendermint permite que cien validadores confirmen de forma rápida y segura sus libros de contabilidad entre sí. El algoritmo BFT Proof-of-Stake supera el problema de los generales bizantinos utilizando un modelo de red parcialmente síncrono. Básicamente, esto significa que los validadores que votan un bloque no necesitan actuar en un momento preestablecido. Los bloques no se votan según un horario o un tamaño predeterminado. Tendermint consigue esto asignando primero al azar a los validadores el derecho a proponer un bloque. Una vez propuestos los bloques, los validadores votan en un proceso determinista de varias rondas. Es decir, el primer paso es bastante indiscriminado y el segundo sigue un orden prescrito. Con Tendermint, los validadores se rotan en un formato determinista de ronda ponderada. Cuanto más participaciones tenga un validador, más veces podrá ser elegido como líder. Actualmente, el protocolo tiene un límite de cien validadores, pero es posible aumentar el número de validadores si es necesario.
Encima del núcleo de Tendermint está la interfaz de la cadena de bloques de aplicaciones (ABCI). La ABCI es un replicador bizantino tolerante a fallos de aplicaciones escritas en cualquier lenguaje. Puede replicar sus aplicaciones de blockchain escritas en C++, Python, Solidity o cualquier otro lenguaje en un motor de blockchain BFT prefabricado. El ABCI es el traductor, el envoltorio y el socket entre las aplicaciones de blockchain y el motor de blockchain Tendermint sobre el que se asientan.
En general hay que completar algunos pasos de configuración para que tdo quede funcionando correctamente de momento solo nos ocuoparemos de lo básico para no agregar complejidad innecesaria en este paso de puesta unto de blogchaindb.
En general la instalación en si misma de BigChainDB y Tendermint no reviste mayor complejidad en cuanto al concepto en si mismo, pero he encontrado que en la instalación que por demás suele ser sencilla el problema se genera es el uso de la librerías adecuadas, pues aunque en ocasiones y a pesar de que al instalar no se presentan errores, si se muestran cuando se pretende ponerlo a funcionar y en su mayoría de de a las diferentes paquetes y librerías involucrados sobre todo lo relacionado con phyton y su versión.
En este caso especifico con pip3.7 las librerías phyton que funcionaron correctamente de describen a continuación, existen otros set que también lo hacen correctamente es cuestión de verificar cuales son las que mejor funcionan en cada sistema, de resaltar que cuando se instala como ya se dijo no se muestran error y solo lo hacen cuando se ejecuta el proceso ya sea
# sudo tendermint init
o
# sudo bigchaindb start
Puede se presentar algunos errores como los siguientes:
ImportError: cannot import name 'escape' from 'jinja2' (/usr/local/lib/python3.7/site-packages/jinja2/__init__.py)
ImportError: cannot import name 'json' from 'itsdangerous' (/usr/local/lib/python3.7/site-packages/itsdangerous/__init__.py)
ImportError: cannot import name 'BaseResponse' from 'werkzeug.wrappers' (/usr/local/lib/python3.7/site-packages/werkzeug/wrappers/__init__.py)
ValueError: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 40 from PyObject
En este caso las siguientes instalaciones que son todas compatible entre si permitieron resolver todos esos errores.
pip3.7 install Jinja2==3.0.3
pip3.7 install itsdangerous==2.0.1
pip3.7 install werkzeug==2.0.3
pip3.7 install gevent==20.6.2
pip3.7 install gunicorn==20.0.4
pip3.7 install greenlet==0.4.16
Yo sugiero ir verificando paso a paso mediante el uso de :
# sudo bigchaindb start
El mensaje de error que va apareciendo le va indicando lo que debe actualizar o instalar si hace falta, es un poco engorroso , pero se ve como va quedando.
Si todo que funcionando correctamente deberíamos ver una pantalla similar a lo siguientes al ejecutar el comando. En este caso el bigchaindb mas actualizado es el 2.2.2.
# sudo bigchaindb start
****************************************************************************
*
* BigchainDB 2.2.2
* codename "jumping sloth"
* Initialization complete. BigchainDB Server is ready and waiting.
* You can send HTTP requests via the HTTP API documented in the
* BigchainDB Server docs at:
* https://bigchaindb.com/http-api
*
* Listening to client connections on: localhost:9984
*
****************************************************************************
Esto indica que mínimo bigchaindb esta ejecutando correctamente, digo mínimo porque hasta ahora no hemos configurado los nodos ni los otros parámetros que permiten que tengamos un modelo funcional. De blockchain mediante bigchaindb.
Recomiendo aunque no es imprescindible instalar un navegador de consola denominado lynx para verificar que esta aquí vamos bien, en general solamente vamos a establecer que el puerto de bigchaindb esta respondiendo.
# sudo yum install lynx
Si todo quedo correcto
Puede verificar su instalación mediante el siguiente comando:
# sudo lynx http://localhost:9984
El navegador enviara un mensaje indicando que que estableció conexión con el puerto 9984 que es el puerto por defecto de bigchaindb. O en en su defecto que no pudo hacerlo
Recuerde abrir el puerto 9984 para TCP para que pueda ser accesado.
Recuerde que en EC2 debe abrir los puertos mediante la consola de AWS – EC2 en la instancia que esta funcionado e ir a grupos de seguridad y allí habilitar los puertos de entrada y salida.
En este documento se supone que se tiene un manejo medio del uso de EC2 y vamos a utilizar 3 nodos ( sitios web si se quiere hacer una analogía) incluyendo el Coordinador, este documento solo describe una red abierta (se puede hacer con redes locales pero aquí no vamos abordar ese posibilidad)
Todos los nodos deben ser configurados con forme a los pasos que hemos efectuado hasta el momento de forma separa, deben tener una IP publica y y un nombre de dominio el se pueda tener acceso de un un navegador externo mediante la URL.
En generar en este caso vamos usar EC2 para los 3 nodos , pero no hay nada que impida que puedan estar en diferentes sistemas operativos, lo único es que deben tener un nombre de dominio y una IP publica. (en este caso como se dijo para red constituida con diferentes servidotes).
En este documento vamos a tener 3 servidores denominado : servidor1.com.co, servidor2.com.co, servidor3.com.co
Al haber llegado a este punto es probable que ya tengo sus sistema base bigchaindb y tendermint funcionando correctamente.
Vamos entonce a continuar conformando al red de servidores para que trabajen conjuntamente.
Para tal efecto vamos a necesitar tener a mano alguna información que el mismo sistema nos proporciona como es el nodo id establecido al haber efectuado el comandos
# sudo tendermint init
Que crea los diferentes node id en cada servidor
y genera una salida de información similar a siguiente: donde deberemos tener presentas las 2 rutas de archivos resaltadas que utilizaremos mas tarde en la configuración de la red bigchaindb
Found private validator module=main keyFile=/root/.tendermint/config/priv_validator_key.json stateFile=/root/.tendermint/data/priv_validator_state.json
Found node key module=main path=/root/.tendermint/config/node_key.json
Found genesis file module=main path=/root/.tendermint/config/genesis.json
Para obtener el node id de cada servidor usamos el comando
# sudo tendermint show_node_id
Parta este caso tendremos en este ejemplo ejecutando en los diferentes servidor los siguientes valores:
servidor1: 23fc7fb02c2e0ae9941ed5856e37e735ce9f5a18
servidor2: e04f0ca4015824df8b7ee1dca1b187f93e9fea14
servidor3: d30acb973aa8f48a4f03fe879b68b01a7aa803ca
En cada caso estos valores difieren de acuerdo a la instalación efectuada estos son solo de ejemplo.
Tengamos estos valores presente por los vamos a necesitar para implementar la red necesaria para que funcione de forma conjunto el modelo el descentralizado de bigchaindb/tendermint.
Ahora de cada nodo procederemos a extraer las dirección (address) y clave publica (pub_key) que esta en el archivo obtenido anteriormente obtenido con el comando tendermint init , en cada nodo. Usamos el comando less o cualquiera otro que nos permita ver el contenido de un archivo texto.
# less /root/.tendermint/config/priv_validator_key.json
Para el servidor1 obtenemos:
{
"address": "68927F2B68A719827677D641D1A9DA6ABCFD5DBA",
"pub_key": {
"type": "tendermint/PubKeyEd25519",
"value": "UW09e91NM9o1fnOg0CU/rFsRWDs3IkFCPGhqcyxpoXI="
},
"priv_key": {
"type": "tendermint/PrivKeyEd25519",
"value": "oNLikUNPdTVMW+/uMDlU7BQFhpyNV14B8Qt4BNCU365RbT173U0z2jV+c6DQJT+sWxFYOzciQUI8aGpzLGmhcg=="
}
}
Para el servidor2:
{
"address": "97EC148332EA0486507A4AD8013064C1EB71D29A",
"pub_key": {
"type": "tendermint/PubKeyEd25519",
"value": "HjFzatt1xcoZ+soI2qEXUvP+/deJgdfMOXQBw+olAI8="
},
"priv_key": {
"type": "tendermint/PrivKeyEd25519",
"value": "MyQFwms2F19UrqKNYkDl4HT2QAfy0kkiP6NImzwzTsAeMXNq23XFyhn6ygjaoRdS8/7914mB18w5dAHD6iUAjw=="
}
}
Para el servidor 3:
{
"address": "CE20C44677175F533C945620DBDFD90F47D2E3D3",
"pub_key": {
"type": "tendermint/PubKeyEd25519",
"value": "rMP1BSi+J79Tr6B246tBN5Z33wGw/N71wiY9jZrG1tM="
},
"priv_key": {
"type": "tendermint/PrivKeyEd25519",
"value": "mAcR5LpOIdb4uO6UtWeS2wdrDdE3vU0KVAor7vqm9mOsw/UFKL4nv1OvoHbjq0E3lnffAbD83vXCJj2NmsbW0w=="
}
}
Con la información proporcionada con el comando tendermint init obtenemos de cada servidor los siguientes items:
IP publicado
DNS de el servidor
Node id
Address
Pub_key
Que nos permite crear la conformación de la red Bigchaindb/Tendermint
El archivo /root/.tendermint/config/genesis.json también obtenido con el comando tendermint init en cada uno de los servidore nos muestra una información similar a la siguiente:
{
"genesis_time": "2022-11-02T19:04:25.76222194Z",
"chain_id": "test-chain-H4FdJ6",
"consensus_params": {
"block": {
"max_bytes": "22020096",
"max_gas": "-1",
"time_iota_ms": "1000"
},
"evidence": {
"max_age": "100000"
},
"validator": {
"pub_key_types": [
"ed25519"
]
}
},
"validators": [
{
"address": "68927F2B68A719827677D641D1A9DA6ABCFD5DBA",
"pub_key": {
"type": "tendermint/PubKeyEd25519",
"value": "UW09e91NM9o1fnOg0CU/rFsRWDs3IkFCPGhqcyxpoXI="
},
"power": "10",
"name": ""
},
],
"app_hash": ""
}
Este archivo denominado genesis.json debe ser completado con la información de los demás servidores con respectivas address y pub_key y DNS, el campo name es una cadena que permita identificar a cada uno de los servidores en el archivo genesis.json y su información asociada es puramente informativo, los demás campos obtenidos en los pasos anteriores en el servidor que va ser asignado como coordinador (incia la generación de bloques de blockchain) posteriormente vamos a remplazar el archivos genesis.json de los servidores2 y servidor3 con el contenido modificado del servidor1 que deberá lucir similar a esto: Los validadores son los servidores que van permitir generar los bloques de Blockchain necesarios para construir el modelo en base a la información de consenso del servidor1, los cuales usualmente son los valores por defecto al usar el comando tendermint init
{
"genesis_time": "2022-11-02T19:04:25.76222194Z",
"chain_id": "test-chain-H4FdJ6",
"consensus_params": {
"block": {
"max_bytes": "22020096",
"max_gas": "-1",
"time_iota_ms": "10abci.socketClient failed to connect to tcp://127.0.0.1:2665800"
},
"evidence": {
"max_age": "100000"
},
"validator": {
"pub_key_types": [
"ed25519"
]abci.socketClient failed to connect to tcp://127.0.0.1:26658
}
},
"validators": [
{
"address": "68927F2B68A719827677D641D1A9DA6ABCFD5DBA",
"pub_key": {
"type": "tendermint/PubKeyEd25519",
"value": "UW09e91NM9o1fnOg0CU/rFsRWDs3IkFCPGhqcyxpoXI="
},
"power": "10",
"name": "servidor1"
},
{
"address": "97EC148332EA0486507A4AD8013064C1EB71D29A",
"pub_key": {
"type": "tendermint/PubKeyEd25519",
"value": "HjFzatt1xcoZ+soI2qEXUvP+/deJgdfMOXQBw+olAI8="
},
"power": "10",
"name": "servidor2"
},
{
"address": "CE20C44677175F533C945620DBDFD90F47D2E3D3",
"pub_key": {
"type": "tendermint/PubKeyEd25519",
"value": "rMP1BSi+J79Tr6B246tBN5Z33wGw/N71wiY9jZrG1tM="
},
"power": "10",
"name": "servidor3"
}
],
"app_hash": ""
}
El servidor denominado Coordindor en es este caso el servidor1 recibe los datos desde todos los miembros servidor1,servidor2 y servidor3 y los combina según se ve en el archivo genesis.json.
En este punto el servidor Cordinador comparte la información con todos los miembros de la red (nodos).
En est punto todos los miembros de la red comparten el mismo chain_id y genesis_time generado y contendido en el archivo genesis.json del servidor1 que se seleccionó como el cordinador
Que en este caso está eon los siguientes valores en el archivo genesis.json final.
"genesis_time": "2022-11-02T19:04:25.76222194Z",
"chain_id": "test-chain-H4FdJ6",
Estos campos son los que al ser compartidos en el archivos genesis.json de todos los miembros configuran la red bigchaindb/tendermint.
Conjuntamente con todos los campos y archivos generador por tendermint init y que ya hemos visto se genera otro archivo en cada uno de los miembros o nodos de la red.
/root/.tendermint/config/config.toml que entre otros muchos prametros que lo cosntituyen tiene uno que nos es de importancia y se denomina persistencia (persisten) y es el que comunica todas las intancias de bigchaindb de todos los miembros (nodos) entre si
...
create_empty_blocks = false log_level = "main:info,state:info,*:error" persistent_peers = "” recheck = false …
En este archivo debemos cualificar la red con los parámetros generados en tendermint init y que identifica cada nodo (node id) d forma única en la red el siguiente comando nos permite buscar este valor.
# sudo tendermint show_node_id
Devuelve un valor por cada nodo
servidor1 :23fc7fb02c2e0ae9941ed5856e37e735ce9f5a18
servidor2 :e04f0ca4015824df8b7ee1dca1b187f93e9fea14
servidor3 :d30acb973aa8f48a4f03fe879b68b01a7aa803ca
Con estos identificador de nodo mas el dns de los servidores vamos a modificar el archivo
indicando parámetros que identifican a cada nodo según la siguiente conformación.
persistent_peers = "<Member 1 node id>@<Member 1 hostname>:26656,\
<Member 2 node id>@<Member 2 hostname>:26656,\
<Member N node id>@<Member N hostname>:26656,"Donde cada nodo se registra con el identificador del nodo seguido del carácter @ (arroba) el dns del nodo y el puerto por donde se escucha al nodo , que en este caso usamos 26656 como el nodo de escucha por defecto.
En nuestro caso debe quedar similar a lo siguiente:
# Comma separated list of nodes to keep persistent connections to
persistent_peers = "23fc7fb02c2e0ae9941ed5856e37e735ce9f5a18@servidor1.com.co:26656,e04f0ca4015824df8b7ee1dca1b187f93e9fea14@servidor2.com.c\
o:26656,d30acb973aa8f48a4f03fe879b68b01a7aa803ca@servidor3.com.co:26656"
De igual forma como se hizo con el puerto 9984 para el puerto de de escucha de tendermint debemos abrir el puerto 26656 como TCP por donde escucha bigchaindb.
La información del parámetro de persistencia peer debe ser copiado en cada de los nodos que integran la red. Y cambiar recheck = false.
Hasta aquí la configuración de una sencilla red externa con 3 nodos.
Si bien es cierto podemos lanzar dicha red de forma manual mediante los comandos:
# sudo tendermint init
# sudo bigchaindb start
o con
# sudo bigchaindb start | monit start tendermint
No suele ser buena idea, porque ambos procesos trabajan de forma conjunta y si alguno de los 2 tiene alguna falla y para, el otro no se entera y genera errores que pueden ser importantes.
Debido a esto es mejor recurrir a un sistema que verifique constantemente el estado del par de procesos y si encuentra que alguno de los 2 está detenido lo reanude.
Puertos abiertos necesarios
Los siguientes puertos debe estar abiertos en TCP para permitir el trafico desde las diferentes instancias de BigChainDB en los diferentes nodos.
Port 22 para conexión del administrador.
Port 9984 recibe trafico desde los clientes BigchainDB HTTP API.
Port 9985 recibe trafico desde clientes WebSocket de BigchainDB .
Port 26656 recibe trafico desde otras conexiones de nodos Tendermint P2P .
Port 9986 recibe traficoHTTP (TCP) desde clientes accesando desde Public Key o de Tendermint insttancias.
Que es Monit?
En las distribuciones del tipo linux y ec2 existe el comando monit.
Monit es un software de monitorización que se caracteriza por supervisar de manera proactiva cualquier sistema operativo basado en Linux y Unix. Este sistema de monitorización también es capaz de vigilar la red local e incluso los servicios en la nube, proporcionando una interfaz de gestión sencilla a través de web.
Para lanzar nuestro pareja bigchaindb/tendermint procederemos a intalar monit en nuestros servidores de la red.
Como mini hace parte del repositorio epel de linux es necesario entonces antes de proceder a instalr monit instalar epel en ec2
# sudo amazon-linux-extras install epel -y
# sudo yum install monit
Ahora procedemos a registrar bigchaindb/tendermint en monit para que pueda efectuar el monitoreo y corregir algún inconveniente que se presente por la detención de alguno de los procesos y pase a reiniciarlo con el siguiente comando
# sudo bigchaindb-monit-config
Con esto queda registrado, ahora debemos lanzar monit para que empiece el proceso de monitorio
# sudo monit -d 1
Con este comando permitimos que monit corra como un daemon en segundo plano (d) cada 1 segundo.
Iniciamos monitorio
# sudo monit start all
Si deseamos parar el sistema lo haremos con el comandos
# sudo monit stop all
# sudo killall -9 tendermint
Para detener bigchainddb
# sudo killall -9 bigchaind
o
# sudo pkill tendermint
# sudo pkill bigshaindb
Observar que se detienen todo los procesos de forma independiente y en el orden que se indica, si por ejemplo se detiene solamente tendermint y no monit, monit lanzará de nuevo tendermint de forma igual con bigchaindb , porque precisamente esa es la función de monit.
Al lanzar monit start all se levantan todos los procesos de bigchaindb/tendermin y podemos verificar si nuestros nodos están activos de forma individual con el comandos
# sudo monit summary
Se nos presenta un cuadro similar al siguiente:
Monit 5.30.0 uptime: 7h 3m
┌────────────────-─┬────────────────────────────┬───────────────┐
│ Service Name │ Status Type │
├──────────────---──┼────────────────────────────┼───────────────┤
│ ip-172-31-83-211.ec2.interna l OK │ System │
├───────────────---─┼────────────────────────────┼───────────────┤
│ bigchaindb │ OK │ Process │
├───────────────-----┼────────────────────────────┼───────────────┤
│ tendermint │ OK │ Process │
├───────────────--─┼─────────────────────────── ─┼───────────────┤
│ tendermint.out.log │ OK │ File │
├───────────────--─┼────────────────────────────--┼───────────────┤
│ tendermint.err.log │ OK │ File │
└────────────────--┴───────────────────────────--─┴───────────────┘
Figura 1
Si se presenta algun error por ejemplo el mas común es tenderming pending debermos entonces recurrir a los archivos de log de tendermint el cual nos indica donde está el problema.
#sudo tail -100 /root/.bigchaindb-monit/logs/tendermint.err.log
#sudo tail -100 /root/.bigchaindb-monit/logs/tendermint.out.log
Estos dos archivos muestran en general los problemas que se están generando en el lanzamiento de la red.
El comando tail de linux es muy útil parque nos permite revisar las -N lineas ultimas generadas , esto es importante porque monit genera una linea por segundo (monit -d 1) o el parametyro que coloquemos al registrarlo , por lo si no se hace de forma simular puede llegar a ser muy engorroso encontrar el problema por la cantidad de información que almacena, en general 200MB de información antes usar el modelo Log Rotation.
Se sugiere eliminar cada tiempo los archivos anteriores pueden llegar a tener un volumen significativo.
Yo uso el comando cron (es un comando linux para automatizar procesos en background) para efectuar la tarea de limpiar el contenido mediante
# cp /dev/null
que permite limpiar un archivo existente en este caso cada 30 minutos ( 0,30 ).
# sudo crontab -e
0,30 * * * * /usr/bin/cp /dev/null /root/.bigchaindb-monit/logs/tendermint.err.log
0,30 * * * * /usr/bin/cp /dev/null /root/.bigchaindb-monit/logs/tendermint.out.log
0,30 * * * * /usr/bin/cp /dev/null /usr/bin/bigchaindb.log
0,30 * * * * /usr/bin/cp /dev/null /usr/bin/bigchaindb-errors.log
Una muestra del archivo de errores /root/.bigchaindb-monit/logs/tendermint.err.log podría ser semejante a los siguiente:
E[2022-11-25|22:34:15.588] abci.socketClient failed to connect to tcp://127.0.0.1:26658. Retrying... module=abci-client connection=query err="dial tcp 127.0.0.1:26658: connect: connection refused"
E[2022-11-25|22:34:18.588] abci.socketClient failed to connect to tcp://127.0.0.1:26658. Retrying... module=abci-client connection=query err="dial tcp 127.0.0.1:26658: connect: connection refused"
E[2022-11-25|22:34:21.589] abci.socketClient failed to connect to tcp://127.0.0.1:26658. Retrying... module=abci-client connection=query err="dial tcp 127.0.0.1:26658: connect: connection refused"
Y una salida para /root/.bigchaindb-monit/logs/tendermint.out.log
podría ser.
I[2022-11-25|23:23:49.139] Committed state module=state height=261 txs=0 appHash=
I[2022-11-25|23:23:50.107] Executed block module=state height=262 validTxs=0 invalidTxs=0
I[2022-11-25|23:23:50.151] Committed state module=state height=262 txs=0 appHash=
I[2022-11-25|23:23:51.123] Executed block module=state height=263 validTxs=0 invalidTxs=0
I[2022-11-25|23:23:51.167] Committed state module=state height=263 txs=0 appHash=
Algunos errores se deben a la falta de apertura de los puertos, mala configuración de la red en genesis.json, mala definición de los nodos en persitence-pool del archivo /root/.tendermint/config/config.toml.
Falta de iniciar algún nodo o como se dijo arriba hay conflicto en algunas de las librerías usadas por la versión de pyton que se emplea.
Un error ue suele ocurrir es que por alguna razón algún nodo no puede ser iniciado y muestra un mensaje similar al siguientes[2022-11-29 17:55:04] [ERROR] (bigchaindb.core) Got invalid InitChain ABCI request (time {
seconds: 1669687745
nanos: 505465525
}
chain_id: "test-chain-Nfve9h"
consensus_params {
block {
max_bytes: 22020096
max_gas: -1
}
evidence {
max_age: 100000
}
validator {
pub_key_types: "ed25519"
}
}
) - the chain test-chain-H4FdJ6 is already synced. (MainProcess - pid: 20121)
Este error se debe a que alguna información de genesis.json , config.toml o cualquier otro archivo de configuración cambio, pero la base de datos en mongodb denomina bigchain no actualizo las collections correctas.
Aunque lo que recomiendan en diferentes blogs es volver a iniciar mediante : bigchiandb configure y/o tendermin init , a mi no me funciono, pues cambian todos los archivos pero la base de datos no se actualiza nuevamente a pesar de que el sistema indica que lo va a remplazar y solicita permiso para hacerlo.
Lo que mi me funciono fue que elimine la base de datos bigchain en mongodb mediante los comandos
# sudo mongo
> use bigchain
> db.dropDatabase();
> exit
Esto es equivalente al comando
# sudo bigchaindb drop
Nota:En ocasiones no me funciono el anterior comando por eso coloco aquí su equivalente funcional.
Verifique que su archivo genesis.jso tenga el valor del nodo correcto del nodo que esta tratando de re configurar, las claves publicas correctas, y los chain id también de todos los nodos del sistema.
Re inicie Tendermint uando
# tendermint unsafe_reset_all
Eliminamos el directorio de configuración tendermint
#sudo rm -rf /root/.tendermint
Si todo esta bien
ejecutar el comando para se cargue los valores correctos en la base datos bigchain en mongo
# monit start all
Detengo el servidor bigchaindb
# monit start stop
# pkill bigchaindb
# pkill tendermint
y verifico la base de datos esta actualizado con los valores del genesis.json
# sudo mongo
> use bigchain
> db.abci_chains.find().pretty(){
"_id" : ObjectId("638796cf2f48c79e5a5057e2"),
"height" : 0,
"chain_id" : "test-chain-Nfve9h",
"is_synced" : true
}
> db.validators.find().pretty()
{
"_id" : ObjectId("638796cf2f48c79e5a5057e0"),
"height" : 1,
"validators" : [
{
"public_key" : {
"type" : "ed25519-base64",
"value" : "HjFzatt1xcoZ+soI2qEXUvP+/deJgdfMOXQBw+olAI8="
},
"voting_power" : 10
}
>
> exit
ahora actualizar el archivo genesis.gen general con todos los validadores .
En /root/.tndermint/config/genesis.json
# monit start all
Este procedimiento me funciono correctamente.
Puede verificar que el sistema esta funcionandfo mediante el siguiente comandos
# sudo bigchaindb start | monit start tendermint
La siguiente salida indica que el sistema esta corriendo ok*
*******************************************************************************
* *
* BigchainDB 2.2.2 *
* codename "jumping sloth" *
* Initialization complete. BigchainDB Server is ready and waiting. *
* *
* You can send HTTP requests via the HTTP API documented in the *
* BigchainDB Server docs at: *
* https://bigchaindb.com/http-api *
* *
* Listening to client connections on: 0.0.0.0:9984 *
* *
*********************************************************************************
(MainProcess - pid: 4878)
[2022-11-30 21:17:42 +0000] [4920] [INFO] Starting gunicorn 20.0.4
[2022-11-30 21:17:42 +0000] [4920] [INFO] Listening at: http://0.0.0.0:9984 (4920)
[2022-11-30 21:17:42 +0000] [4920] [INFO] Using worker: sync
[2022-11-30 21:17:42 +0000] [4921] [INFO] Booting worker with pid: 4921
[2022-11-30 21:17:42 +0000] [4922] [INFO] Booting worker with pid: 4922
[2022-11-30 21:17:42 +0000] [4924] [INFO] Booting worker with pid: 4924
[2022-11-30 21:17:42 +0000] [4925] [INFO] Booting worker with pid: 4925
[2022-11-30 21:17:42 +0000] [4926] [INFO] Booting worker with pid: 4926
[2022-11-30 21:17:43] [INFO] (abci.app) ABCIServer started on port: 26658 (MainProcess - pid: 4878)
[2022-11-30 21:17:45] [INFO] (abci.app) ... connection from Tendermint: 127.0.0.1:41038 ... (MainProcess - pid: 4878)
[2022-11-30 21:17:45] [INFO] (abci.app) ... connection from Tendermint: 127.0.0.1:41040 ... (MainProcess - pid: 4878)
[2022-11-30 21:17:45] [INFO] (abci.app) ... connection from Tendermint: 127.0.0.1:41052 ... (MainProcess - pid: 4878)
[2022-11-30 21:17:45] [INFO] (bigchaindb.core) Tendermint version: 0.31.5-d2eab536 (MainProcess - pid: 4878)
Cuando se llega a obtener un cuadro similar al anterior a la salida anterior indica que la red bigchaindb/tendermint está operativa para empezar a crear nuestros primeros certificados inteligentes (Smart Contract), crypto activos (NFT) y crypto monedas.
Antes de terminar recomiendo la lectura del proyecto Cosmos (sdk) https://blog.cosmos.network/tendermint/home
https://cac9999.blogspot.com/2022/11/tendermintcosmos-blogchain-para-dummys.html
Comentarios
Publicar un comentario