Con motivo de mi participación en la BlockchainCon 2018 como ponente en uno de los workshops del evento, he preparado este artículo que resume la primera parte de mi sesión acerca de cómo desplegar cargas de blockchain – en concreto, en el workshop usamos Ethereum Proof of Work (PoW) – en Azure.

Introducción a los entornos de nube

Muchas organizaciones empiezan a considerar a los entornos de nube (el famoso «cloud computing«) adecuados para albergar sus sistemas de negocio e información, también incluso aquellos que denominamos de «misión crítica«. En la práctica totalidad de los «proveedores de nube» (aka «cloud vendors«) se puede encontrar una oferta muy completa de servicios de infraestructura (IaaS o «Infrastructure as a Service«), software como servicio (SaaS o «Software as a Service») y también servicios denominados de «plataforma» (PaaS o «Platform as a Service») que comentaremos brevemente a continuación.

Habitualmente la mayoría de los profesionales IT suelen conocer bastante bien los servicios IaaS ya que no es más que una vuelta de tuerca más a lo que los «hosters» y los «datacenters» de sus empresas han estado ofreciendo desde la época de esplendor del «mainframe«. Los servicios SaaS también son ampliamente conocidos por todos los usuarios de Internet (recordemos que servicios como las cuentas de correo de Outlook o GMail son servicios SaaS). Donde hay un poco más de desconocimiento en los profesionales de la tecnología es acerca de qué son los servicios PaaS. Para que nos entendamos, son servicios sobre los que nos apoyaremos a la hora de construir un nuevo servicio o solución y de los que no necesitaremos saber cual es la infraestructura que soporta dichos servicios de plataforma. Por poner un ejemplo: una máquina virtual sobre la que ejecutamos un motor de base de datos es una solución de BD pero utilizando servicios IaaS. Ese mismo motor de base de datos utilizando servicios como Azure Database for SQL o Amazon RDS son el mismo tipo de solución pero en este caso no sabremos si nuestro motor de BD está sobre una máquina virtual, o varias, o si por ejemplo esta soportado por un «cluster» de contenedores. Ni lo sabremos, ni querremos saberlo porque así no será responsabilidad nuestra mantener funcionando dicho soporte, sino que lo hará el proveedor del servicio. Tenemos cientos de servicios PaaS sobre los que apoyarnos a la hora de construir nuestras aplicaciones: BBDD relacionales, almacenamiento de Blobs, motores de contenedores, proveedores de identidad, etc.

En este post vamos a hablar de como podemos utilizar estos servicios «cloud» para desplegar y poner a funcionar un consorcio privado de blockchain en Azure.

Primer paso: Acceder a Azure

Si disponemos de un usuario que tenga acceso a una suscripción de Azure, simplemente tendremos que acceder a la dirección https://portal.azure.com e introduciendo nuestras credenciales accederemos al portal de gestión de nuestra suscripción asociada.

Ahora simplemente tendremos que indicar qué tipo de servicio o recurso es el que queremos utilizar.

Segundo paso: seleccionar servicio

Dentro del portal, en el menu de la izquierda, hacemos clic [1] en la opción «Crear un recurso» («Create a Resource«)  que nos abrirá un «blade» (sí, así se llaman los formularios del portal de Azure) de selección de servicios. En el menu izquierdo del «blade» seleccionaremos la categoría «Blockchain» lo cual nos ofrecerá una primera selección de los servicios más comunes en dicha categoría [2]

Una vez que tengamos a la derecha del «blade» los servicios de Blockchain destacados, pulsaremos [3] en el enlace  «Ver todos» («See all«) para acceder a un listado con todos los tipos de redes de blokchain que podemos desplegar en Azure.

Tercer Paso: Seleccionar Ethereum PoW

En la nueva pantalla buscaremos el «ledger» de Ethereum con el mecanismo PoW («Proof of Work«) y haremos clic sobre él [4]

Ahora el portal nos mostrará un blade informativo acerca de nuestra selección con una descripción detallada de cual es el servicio en cuestión, y algunos enlaces interesantes a la documentación oficial, información sobre precios, acceso al foro de soporte, y algunos materiales de formación sobre el particular. En la parte inferior derecha del nuevo «blade» encontramos un botón para iniciar la creación del recurso seleccionado.

Cuarto Paso: Iniciar procedimiento de despliege

Al pulsar sobre el botón «Crear» («Create«) se nos abrirá un nuevo «blade» con el primer paso (de 7) para crear nuestro consorcio de Ethereum. Procederemos a rellenar las opciones que se nos solicitan:

• Crearemos un nuevo grupo de recursos en el que se albergará todos los componentes de que consta nuestro despliegue.
• En este ejemplo vamos a desplegar una red blokchain que no será parte de un consorcio donde posteriormente hayamos de añadir más recursos por lo que seleccionamos la opción «Standalone«
• Añadimos un prefijo que servirá para prefijar los recursos generados en este despliegue
• Seleccionaremos un usuario y una contraseña para el usuario que podrá acceder a las VMs que formen parte de este despliegue (ojo, este usuario podrá hacer «sudo» de ahí que la contraseña tenga que tener cierta complejidad, no vale el típico admin/admin). Si queremos identificar a nuestro usuario con alguna clave SSH podremos hacerlo cambiando a la opción correspondiente
• Seleccionaremos sobre qué suscripción vamos a realizar el despliegue (aunque debería estar prefijada la nuestra por defecto)
• Y en nuestro caso vamos a pedir a Azure que cree un grupo de recursos nuevo que agrupara todos los recursos de este despliegue
• Por último deberemos seleccionar sobre que región queremos desplegar nuestro «ledger»; en nuestro ejemplo seleccionamos «Oeste de Europa» («West Europe») por corresponder a Holanda y así tendremos más «cerca» nuestros recursos

Si todo va bien deberíamos tener un «blade» parecido al de la siguiente imagen. Si es así, pulsaremos «Ok» para pasar al siguiente paso.

Quinto Paso: Seleccionar regiones de despliegue

En el siguiente «blade» deberemos indicar sobre qué regiones queremos desplegar los nodos de nuestro «ledger«. En nuestro caso, por simplicidad desplegaremos todo en una única región. En despliegues con mayores requisitos de fiabilidad o cobertura geográfica es cuando esta opción nos otorga la flexibilidad de seleccionar varias regiones de despliegue. Una vez completado este paso, hacemos clic en el botón de «Ok«. Si todo está correcto, saltaremos al siguiente «blade» de opciones de despliegue.

Sexto Paso: Definición de la red de nodos

En el siguiente blade vamos a decirle a Azure cuántos nodos de «minado» («mining nodes») tendrá nuestro consorcio (o nuestra red blockchain que para el caso es lo mismo) y cuando nodos de transacciones («transaction nodes»). Igualmente seleccionaremos de un catalogo de tamaños de VMs qué tamaños de máquinas soportarán cada uno de los tipos de nodos. En nuestro caso vamos a dejar los valores por defecto en todas las opciones.

Un par de observaciones en este apartado:

• Los «mining nodes» son los encargados de proporcionar el mecanismo de generación y firmado de bloques de la cadena utilizando un algoritmo de «PoW» (del inglés «Proof of Work» o «Prueba de Trabajo«. Este mecanismo fue de los primeros utilizados por las cadenas de blockchain (p.e. BitCoin usaba y usa este algoritmo) y se basa en que los nodos de minado realicen operaciones intensivas en cálculo (basadas en algoritmos de generación de hash o encriptación unidireccional) para generar y firmar los bloques que componen la cadena. Por ello, es habitual que este tipo de nodos utilicen tipos de VMs con gran potencia de cálculo. También, en este caso, Azure va a desplegar los nodos de minado como parte de un «Conjunto de Escalado de VMs» («Scale Set») que permitirá que el día de mañana podamos definir cómo queremos que escalen horizontalmente nuestros nodos de minado. Si tenéis interés en conocer qué aporta un «Scale Set» os sugiero que echéis un vistazo a su documentación oficial sobre conjuntos de escalado.
• Los «transaction nodes» son los encargados de recibir y procesar las transacciones solicitadas a la cadena de blockchain. Serían los equivalentes a los puntos de entrada a las operaciones con la cadena. Siempre que queramos realizar una operación sobre uno de nuestros «smart contracts» deberemos solicitar la transacción a un «transaction node«. De ahí, que Azure despliegue estos nodos de transacción en un modo de balanceo de carga. Tengamos en cuenta que los nodos de transacción deben estar siempre disponibles para que podamos interactuar con nuestro «ledger». En nuestro ejemplo no tiene mucho sentido puesto que hemos indicado que solo queremos un «transaction node» en nuestro «ledger». Lo positivo es que siempre podemos añadir más «transaction nodes» colgando del balanceador que Azure nos va a desplegar.

Séptimo Paso: Sumario y Validación de la configuración

En este penúltimo paso, se nos presentará un «blade» de sumario con todas las opciones que hemos ido decidiendo en los pasos anteriores. Al mismo tiempo, la configuración se somete a un proceso de validación para garantizar que el posible despliegue llegará a buen puerto si nos decidimos a hacerlo. Si la verificación es exitosa, un boton de «Ok» se nos activará para que procedamos a realizar el último paso del despliegue.

Como curiosidad, en este paso tenemos la posibilidad de descargarnos un conjunto de ficheros (plantillas de despliegue) que representan nuestro despliegue, de manera que podríamos utilizar dichos ficheros para tener una «copia de seguridad» de lo que vamos a desplegar más adelante.

Octavo y último paso: Despliegue de la configuración

Si en el paso anterior nos decidimos y pulsamos el botón de «Ok«, aparecerá un último «blade» para arrancar el proceso de despliegue. En este «blade» se nos indica que el procedimiento de despliegue creará múltiples recursos en nuestra suscripción por lo que podría resultar costoso para nosotros. De ahí que en el blade se nos advierta de que este despliegue es sólo para usuarios avanzados.

Si pulsamos el botón de «Crear» («Create«) procederemos a realizar el despliegue y el planificador de recursos de Azure empezará a crear los recursos implicados en nuestro despliegue (que como veremos son mucho y variados).

Comprobación del despliegue

Pasados unos minutos (en mi última prueba, esto tomó unos 20 minutos desplegando en la región de Europa Occidental) tendremos a nuestra disposición un grupo de recursos con varios recursos que estarán soportando nuestro Consorcio de Ethereum con las características que hayamos solicitado al definir dicho despliegue según los parámetros definidos en los pasos anteriores.

  

 

La forma de verificar que nuestro despliegue está funcionando correctamente, es tomar la IP pública («Public IP«) del «Load Balancer» que está gestionando nuestro(s) nodo(s) de transacción y con dicha dirección IP acceder con un navegador de internet a ella.

La plantilla instala una pequeña aplicación web en cada nodo de transacción que nos sirve para inspeccionar nuestro «ledger» y ver los bloques minados, las transacciones y alguna otra pequeña información adicional. Esto es más que suficiente para poder comprobar que nuestro «ledger» está funcionando. Incluso, si disponemos de algún «wallet» que soporte Ethereum (como por ejemplo, MetaMask que es una extensión para nuestro browser Chrome) podemos utilizar la misma dirección IP (aunque para este caso utilizando el puerto 8545) como punto de acceso RPC a nuestro «ledger» y nuestra aplicación «wallet» nos permitirá interactuar de manera básica con dicho «ledger» de manera básica.

Conclusión

Como hemos visto, los entornos «cloud» son idóneos para desplegar este tipo de cargas de trabajo, tanto para entornos temporales o  de desarrollo, como para entornos menos volátiles o más de «misión crítica«. En este «post» hemos aprendido a desplegar de manera tremendamente sencilla y rápida un «ledger» de Ethereum que posteriormente podremos utilizar para desplegar nuestros «Smart Contracts«. Algo que ya comentamos en una serie de artículos anteriores acerca de Desarrollo en Blockchain: Creando nuestro primer smart contract

En siguientes «posts» profundizaremos en como desplegar plataformas blockchain más orientadas al ámbito empresarial en Azure.