Buscar

Blog de Alfonso Tienda

Marketing, Startups, Proyectos y Tecnología.

Instalación y pruebas de Kubernetes en Ubuntu 18.04

En este paso guiaremos la instalación de kubernetes en Ubuntu 18.04 para pruebas, esto es, no una instalación en cluster, por lo que debemos instalar Minikube, el kubernetes para single node.

Seguir leyendo “Instalación y pruebas de Kubernetes en Ubuntu 18.04”

Anuncios

Software: Pruebas con usuarios.

Existen muchos sistemas para hacer pruebas con usuarios. En este post menciono unos cuantos para que no se te olviden al hacer pruebas:

Pruebas de usabilidad

La prueba de usabilidad es la observación de los usuarios que intentan realizar tareas con tu sistema. Las pruebas pueden centrarse en un solo proceso o ser mucho más amplias.

Prueba de concepto

Un investigador de UX comparte una aproximación de un producto que captura la esencia clave (la Propuesta de valor) de un nuevo concepto para determinar si satisface las necesidades de la audiencia objetivo. Las pruebas de concepto se pueden hacer individualmente o con un mayor número de participantes, ya sea en persona o en línea.

A/B Testing

A / B testing ofrece versiones alternativas de un producto a diferentes usuarios y compara los resultados para descubrir cuál funciona mejor. Esta es una gran técnica para optimizar embudos y landing pages.

Guerrilla Testing

Las pruebas de guerrilla son una de las formas más simples (y baratas) de pruebas de usuarios. El uso de pruebas de guerrilla generalmente significa ir a una cafetería u otro lugar público para preguntar a la gente sobre su producto o prototipo. Se puede llevar a cabo en cualquier lugar, excepto en una cafetería, biblioteca, estación de tren, etc., en cualquier lugar donde pueda encontrar una audiencia relevante.

Estudios de campo

El estudio de campo consiste en salir y observar a los usuarios “en la naturaleza” para que el comportamiento se pueda medir en el contexto en el que realmente se usará un producto. Esta técnica puede incluir investigación etnográfica, entrevistas y observaciones, además de investigación contextual.

Seguimiento del movimiento ocular

Una tecnología que analiza los movimientos oculares del usuario a través del diseño de la interfaz de usuario (es decir, la página web).  Este sistema proporciona datos sobre lo que mantiene a los usuarios interesados ​​en la pantalla y cómo su flujo de lectura podría optimizarse por diseño.

 

¿Qué es Design Thinking?

Design Thinking, si bien tiene su origen en el diseño, no es exclusivo de ellos. Innovadores en muchos campos  lo han practicado. Entonces, ¿por qué llamarlo Design Thinking? Lo que hace especial a Design Thinking es que los procesos de trabajo de los diseñadores pueden ayudarnos a extraer, enseñar, aprender y aplicar sistemáticamente estas técnicas centradas en el ser humano para resolver problemas de manera creativa e innovadora: en nuestros diseños, en nuestras empresas, en nuestros países, en nuestras vidas.

¿Qué es Design Thinking?

Design Thinking es un proceso iterativo en el que buscamos comprender al usuario, desafiar las suposiciones y redefinir los problemas en un intento por identificar estrategias y soluciones alternativas que pueden no ser evidentes de forma instantánea con nuestro nivel inicial de comprensión. Al mismo tiempo, Design Thinking proporciona un enfoque basado en soluciones para resolver problemas. Es una forma de pensar y trabajar, así como una colección de métodos prácticos.

Fases de Design Thinking

Nos centraremos en el modelo de cinco fases propuesto por el Instituto de Diseño Hasso-Plattner en Stanford. Según ellos, las cinco fases de Design Thinking son las siguientes:

  • Empatizar con tus usuarios
  • Definir sus necesidades, problemas e ideas
  • Idear desafiando las suposiciones y creando ideas para soluciones innovadoras
  • Prototipar para empezar a crear soluciones.
  • Probar la solucion

Es importante tener en cuenta que las fases, no siempre son secuenciales. No tienen que seguir ningún orden específico y, a menudo, pueden ocurrir en paralelo y repetirse de forma iterativa.

Los seres humanos, naturalmente, desarrollan patrones de pensamiento basados ​​en actividades repetitivas y en conocimientos de acceso común. Éstos nos ayudan a aplicar rápidamente las mismas acciones y conocimientos en situaciones similares, pero también tienen el potencial de evitar que desarrollemos nuevas formas de afrontar problemas. Estos patrones de pensamiento a menudo se denominan esquemas, que son conjuntos organizados de información y relaciones entre cosas, acciones y pensamientos que se estimulan e inician en la mente humana cuando encontramos algunos estímulos ambientales. La solución innovadora de problemas también se conoce como pensar “out of the box”.

Design Thinking, para terminar, nos proporciona un conjunto de herramientas para hacer estos posible.

Typescript

TypeScript es un lenguaje de programación de código abierto desarrollado y mantenido por Microsoft. TypeScript se puso a disposición por primera vez en octubre de 2012. Fue creado por Anders Hejlsberg y su equipo en Microsoft. Es un superconjunto de JavaScript tipado que se compila en JavaScript plano. TypeScript se puede usar para desarrollar aplicaciones JavaScript para la ejecución tanto del lado del cliente como del lado del servidor (con Node.js). Debido a que los navegadores solo comprenden JavaScript, cuando escribe su aplicación en lenguaje TypeScript, se necesita un compilador que compile el código y lo convierta a JavaScript para que su aplicación funcione. TypeScript es de código abierto, y se está desarrollando en GitHub.

Compatibilidad con JavaScript

TypeScript es un superconjunto estricto de ECMAScript 2015 (ECMAScript 6 o ES6), que es un superconjunto de ECMAScript 5, que es JavaScript que conocemos hoy. Por lo tanto, un programa de JavaScript también es un programa válido de TypeScript, y un programa de TypeScript puede consumir JavaScript sin inconvenientes. Con TypeScript, es posible usar código JavaScript existente, incorporar bibliotecas de JavaScript y llamar al código generado por TypeScript desde otro JavaScript.

 

 

Los principales componentes de Angular

Módulos

Todas las aplicaciones de angular se crean de forma modular. Esto significa que se trabaja con NgModules como parte de una aplicación.  Cada aplicación angular debe tener al menos un NgModule. Este es el módulo raíz y comúnmente se llama AppModule.

Bibliotecas

Angular incluye una colección de módulos escritos en JavaScript y estos módulos forman bibliotecas dentro de Angular, proporcionan funcionalidad para usar en sus aplicaciones. Las bibliotecas de angular se anotan con el prefijo @angular.

Componentes

Angular usa el concepto de un componente para controlar aspectos de su aplicación. Como ejemplo, un componente es una clase que contiene la lógica necesaria para manejar un aspecto de una página, llamado vistas.

Los controladores de angular crean y destruyen estos componentes durante las interacciones del usuario con la aplicación web.

Plantillas

La vista de un componente se define en una plantilla. Las plantillas son simplemente HTML que trabaja con Angular en la representación adecuada del componente dentro de la aplicación. Las plantillas utilizan etiquetas HTML estándar, pero Angular pondrá etiquetas y atributos disponibles para las implementaciones funcionales en la plantilla.

Data Binding

Las aplicaciones web interactivas y dinámicas se basan en datos. La actualización de la interfaz de usuario cuando los datos cambian es una tarea que consume tiempo con posibilidad de errores en los datos o en la sincronización de los datos y elementos de la interfaz de usuario.

Angular sobresale en el enlace de datos. Simplemente agrega un enlace a su marcado en las plantillas que crea y luego le dice a Angular cómo están conectados los datos y la UI. El enlace de datos puede ser unidireccional o bidireccional.

Directivas

Las directivas, en esencia, son comandos que le das al motor angular. Angular aplica las instrucciones especificadas por la directiva, cuando procesa la plantilla, para transformar el DOM en su página.

También puede tener directivas estructurales y de atributos. Se encuentran dentro de etiquetas de elementos similares a los atributos con la directiva estructural que se encarga de alterar los diseños a través de elementos DOM.

Inyección de dependencia

La documentación en Angular define la inyección de dependencia (DI) como, “una forma de suministrar una nueva instancia de una clase con las dependencias completamente formadas que requiere”. La mayoría de las dependencias son servicios. Angular usa la inyección de dependencias para proporcionar nuevos componentes con los servicios que necesitan.

Esencialmente es un mecanismo en el que los componentes de una aplicación angular resuelven cualquier dependencia relacionada con los servicios o componentes requeridos por su componente.

Instalación de Hyperledger Fabric

En esta entrada vamos a instalar Hyperledger Fabric. Para ello es fundamental tener instalado docker en el sistema y en correcto funcionamiento, así como git. Uso Ubuntu 18.04 para la ejecución.

Primero de todo visitaremos esta página:

http://hyperledger-fabric.readthedocs.io/en/release-1.1/samples.html#binaries

Hyperledger Fabric en el momento de esta entrada está en versión 1.1, sin embargo cambia continuamente. En el momento de la entrada, la instalación se realiza mediante el comando:

curl -sSL https://goo.gl/6wtTN5 | bash -s 1.1.0
Aunque esto va cambiando continuamente.
Tras la instalación veremos que se han generado una serie de imágenes de docker:
===> List out hyperledger docker images
hyperledger/fabric-tools latest b7bfddf508bc 4 months ago 1.46GB
hyperledger/fabric-tools x86_64-1.1.0 b7bfddf508bc 4 months ago 1.46GB
hyperledger/fabric-orderer latest ce0c810df36a 4 months ago 180MB
hyperledger/fabric-orderer x86_64-1.1.0 ce0c810df36a 4 months ago 180MB
hyperledger/fabric-peer latest b023f9be0771 4 months ago 187MB
hyperledger/fabric-peer x86_64-1.1.0 b023f9be0771 4 months ago 187MB
hyperledger/fabric-ccenv latest c8b4909d8d46 4 months ago 1.39GB
hyperledger/fabric-ccenv x86_64-1.1.0 c8b4909d8d46 4 months ago 1.39GB
Nos habrá creado un subdirectorio donde lo hayamos ejecutado, y entraremos en el:
$ ls
fabric-samples
$ cd fabric-samples/
$ ls
balance-transfer basic-network bin chaincode chaincode-docker-devmode config fabcar fabric-ca first-network high-throughput LICENSE MAINTAINERS.md README.md scripts

Aquí, por comodidad, podemos incluir el directorio de binarios en el path:

export PATH=$PWD/bin:$PATH

Ahora nos clonamos los ejemplos:

git clone https://github.com/hyperledger/fabric-samples.git

cd fabric-samples/first-network

Primero de todo vamos a generar los certificados necesarios ejecutando el script:

./byfn.sh -m generate

Y podemos ya levantar los nodos

./byfn.sh -m up

 

 

Hyperledger Fabric

Elementos de Hyperledger Fabric

Vamos a repasar lo que son los elementos de Hyperledger Fabric.

Canales

Los canales son mecanismos de partición de datos que permiten la visibilidad de las transacciones solo para las partes interesadas. Cada canal es una cadena independiente de bloques de transacciones que contiene solo transacciones para ese canal en particular. Por ejemplo, los miembros de un canal pueden ver sus precios pero no los precios a los que se vende un producto a los miembros de otro canal.

Los canales permiten que las organizaciones utilicen la misma red, a la vez que mantienen la separación entre varias cadenas de bloques. Solo los miembros del canal en el que se realizó la transacción pueden ver los detalles de la transacción. En otras palabras, los canales dividen la red para permitir la visibilidad de las transacciones solo para las partes interesadas. Este mecanismo funciona mediante la delegación de transacciones a diferentes ledgers. Solo los miembros del canal participan en el consenso, mientras que otros miembros de la red no ven las transacciones en el canal.

Chaincode

El chaincode (Smart Contracts) encapsula las definiciones de los activos y la lógica de negocios (o transacciones) para modificar esos activos. Las invocaciones de transacción producen cambios en el libro mayor. El chaincode en Fabric (los Smart Contracts) se desarrollan en el lenguaje de programación GO.

Ledger

El ledger contiene el estado actual de la red y una cadena de invocaciones de transacciones. Un libro de contabilidad compartido y autorizado es un sistema de registros de solo anexión y sirve como una fuente única de verdad.

Red

La red es la colección de pares de procesamiento de datos que forman una red blockchain. La red es responsable de mantener un libro mayor constantemente replicado.

Servicio de ordering

El servicio de ordering u ordenación es una colección de nodos que ordena transacciones en un bloque.

Estado global

El estado global refleja los datos actuales sobre todos los activos en la red. Esta información se almacena en una base de datos para un acceso eficiente. Las invocaciones de Chaincode ejecutan transacciones contra los datos de estado actuales. Para que estas interacciones de chaincodes sean extremadamente eficientes, los últimos pares clave / valor para cada activo se almacenan en una base de datos de estado. La base de datos del estado es simplemente una vista indexada de las transacciones que han hecho commit en el blockchain. Por lo tanto, puede regenerarse en cualquier momento. La base de datos del estado se recuperará automáticamente (o se generará, si es necesario) tras el arranque de los nodos, antes de que se acepten nuevas transacciones. La base de datos de estado predeterminada, LevelDB, se puede reemplazar con CouchDB.

  • LevelDB es la base de datos de estado / clave predeterminada para Hyperledger Fabric, y simplemente almacena pares clave / valor.
  • CouchDB es una alternativa a LevelDB. A diferencia de LevelDB, CouchDB almacena objetos JSON. CouchDB es único ya que admite consultas con clave, compuesto, rango clave y completo de datos.

Ambas son muy similares en su estructura y función.

Membership service provider

El proveedor de servicios de membresía (MSP) administra la identidad y el acceso permitido para clientes y pares. Hyperledger Fabric es una red autorizada, lo que significa que solo los participantes que han sido aprobados pueden obtener acceso a la red. Para gestionar la membresía y la identidad de la red, los proveedores de servicios de membresía (MSP) administran los ID de usuario y autentican a todos los participantes en la red. Una red de cadena de bloques Hyperledger Fabric puede ser gobernada por uno o más MSP. Esto proporciona la modularidad de las operaciones de membresía y la interoperabilidad a través de diferentes estándares y arquitecturas de membresía. El objetivo es disponer de membresías o MSPs diferentes para los actores de una aplicación determinada del blockchain, por ejemplo una cadena de suministros. Las políticas se definen para dictar las políticas de lectura / escritura de un canal o las políticas de aprobación de un chacode.

En Hyperledger Fabric, los MSP también permiten la membresía dinámica para agregar o eliminar miembros para mantener la integridad y el funcionamiento de la cadena de suministro. Por ejemplo, para revocar una membresía, sin comprometer el resto de la red. Esta característica es crítica, especialmente para aplicaciones empresariales, donde las relaciones comerciales cambian con el tiempo.

Para empezar, los usuarios se autentican usando una autoridad de certificación. La autoridad de certificación identifica las identidades de la aplicación, el nodo, el endosante y el orderer, y verifica estas credenciales. Una firma se genera a través del uso de un Algoritmo de Firma y un Algoritmo de Verificación de Firma.

Específicamente, la generación de una firma comienza con un Algoritmo de firma, que utiliza las credenciales de las entidades asociadas con sus respectivas identidades y genera un endoso. Se genera una firma, que es una matriz de bytes que está vinculada a una identidad específica. A continuación, el algoritmo de verificación de firma toma la identidad, el endoso y la firma como entradas, y las salidas ‘aceptan’ si la matriz de bytes de la firma corresponde con una firma válida para el endoso ingresado, o las salidas ‘rechazan’ si no. Si la salida es ‘aceptar’, el usuario puede ver las transacciones en la red y realizar transacciones con otros actores en la red. Si el resultado es ‘rechazo’, el usuario no se ha autenticado correctamente y no puede enviar transacciones a la red ni ver ninguna transacción anterior.

En general, las Autoridades de Certificación administran certificados para un blockchain autorizado. Fabric-CA es la autoridad de certificación predeterminada para Hyperledger Fabric, y maneja el registro de identidades de usuario. La autoridad de certificación Fabric-CA está a cargo de emitir y revocar certificados de inscripción (E-Certs).

Roles

Hay tres tipos diferentes de roles dentro de una red Hyperledger Fabric:

Cliente

Los clientes son aplicaciones que actúan en nombre de una persona para proponer transacciones en la red.

Pares

Los pares mantienen el estado de la red y una copia del libro mayor (ledger). Hay dos tipos diferentes de pares: los que endosan (endorsing) y los que hacen el commit. Sin embargo, existe una superposición entre los pares de endoso y de commit, en el sentido de que los pares de endoso son un tipo especial de pares de commit. Todos los pares hacen commit sobre el ledger.
– Los endosantes simulan y respaldan transacciones
– Los pares de commit verifican las aprobaciones y validan los resultados de las transacciones, antes de hacer commits de la transaccion sobre el blockchain.

Servicio de orden

El servicio de orden acepta transacciones endosadas, las ordena en un bloque y entrega los bloques a los pares que harán el commit.

Flujo de consenso

Para llegar al consenso habrá que seguir tres pasos:

  1. Propuesta de transacción, donde las aplicaciones clientes mandarán sus transacciones hacia el blockchain, a los pares de “endoso”
  2. Cada nodo de endoso simula la transacción propuesta, sin actualizar el ledger. Los nodos de endoso capturarán el conjunto de datos leídos y escritos, llamados conjuntos RW. Estos conjuntos de RW capturan lo que se leyó del estado global mientras se simulaba la transacción, así como lo que se habría escrito si se hubiera ejecutado la transacción. Estos conjuntos RW son luego firmados por el nodo de endoso y devueltos a la aplicación cliente para ser utilizados en futuros pasos del flujo de transacción. Estos nodos de endoso tendrán, por lo tanto, los smart contracts que han de simular.
  3. La aplicación envía la transacción endosada y los conjuntos RW al servicio de ordenación.
  4. El servicio de ordenación toma las transacciones aprobadas y los conjuntos RW, ordena esta información en un bloque y entrega el bloque a todos los nodos de commit. El servicio de ordenación acepta las transacciones endosadas y especifica el orden en que esas transacciones harán commit en el ledger. La implementación específica de ‘ordenar’ (Solo, Kafka, BFT) es configurable en Fabric, siendo Kafka el predeterminado.
  5. Los nodos de commit validan la transacción comprobando que los conjuntos de RW aún coinciden con el estado global actual. Específicamente, que los datos de lectura que existieron cuando los endosantes simularon la transacción son idénticos al estado global actual. Una vez validada la transacción se ejecuta y el estado global cambia. Si la transacción falla, esto es que el estado global no corresponde con el endosado, la transacción ordenada en un bloque seguirá incluyéndose en ese bloque, pero se marcará como no válida, y el estado global no se actualiza. Los nodos de commit son responsables de agregar bloques de transacciones al ledger y actualizar el estado. Pueden tener smart contracts, pero no es un requisito.
  6. Por último, los nodos de commit son los encargados de notificar de forma asíncrona a la aplicación cliente el éxito o el fracaso de la transacción.

Verificación de identidad

Además de la gran cantidad de comprobaciones de endoso, validez y control de versiones que se llevan a cabo, también hay verificaciones de identidad en cada paso del flujo de la transacción. Las ACLs se implementan en las capas jerárquicas de la red (desde el servicio de pedido hasta los canales), y los payloads se firman, verifican y autentican repetidamente a medida que una propuesta de transacción pasa por los diferentes componentes.

 

 

 

Creando una aplicación en Hyperledger Sawtooth

Una aplicación en sawtooth está compuesta fundamentalmente de dos partes. Una aplicación cliente, que envía transacciones al blockchain, generalmente a través de la API REST Sawtooth y proporciona una interfaz de usuario para la aplicación (linea de comandos, página web, o cualquier interfaz capaz de usar http). La otra parte es un procesador de transacciones, que contiene la lógica de negocio de la aplicación y se comunica con el validador, que envía las transacciones recibidas del cliente para su validación.

Crear una aplicación requiere algunos pasos importantes:

  1. Definir los activos que residirán en el ledger distribuido,
    así como las transacciones que actuarán sobre estos activos para cambiar su estado. Básicamente qué es lo que vamos a guardar y cómo se modifica. Desde un punto de vista de objetos, el activo son las propiedades del objeto y las transacciones sus métodos.
  2. Diseñar la lógica de transacción que opera en estos activos. Esto es, la lógica de los métodos del objeto, siguiendo nuestro ejemplo.

Cuando se recibe una transacción por un nodo de Sawtooth, esta transacción se redirige a los demás nodos. Uno de los nodos es elegido por el algoritmo de consenso para publicar un bloque. Este bloque contendrá las transacciones que se hayan recibido y ejecutado de forma satisfactoria, y se hará un broadcast al resto de nodos. Cada nodo recibe este bloque y verifica su validez. En ese momento notificará a la aplicación el cambio de estado.

Vamos a desarrollar un caso práctico de una moneda. Muy básico. Se crea y se transfiere, aceptando o no la transferencia.

Vamos a utilizar un fork de uno de los materiales de hyperledger. Este fork está aquí:

git clone https://github.com/afoone/education.git

Una vez clonado podéis ir education/LFS171x/sawtooth-material/sawtooth-tuna y ejecutar:

docker-compose up

A continuación, en un navegador podemos poner la URL:

http://localhost:8000/

Publico esta entrada que iré mejorando durante los próximos días explicando cada una de las partes de una aplicación Sawtooth.

 

Instalando Hyperledger Sawtooth

En este blog vamos a ver cómo instalar Hyperledger Sawtooth para hacer nuestras primeras pruebas con redes blockchain. Las pruebas las hago con MacOS, si bien pueden funcionar en Linux o Windows, siempre que cumplan los siguientes requisitos de programas instalados:

  •  cURL
  • Git
  • Docker
  • Docker Compose

Las pruebas las estoy haciendo con la versión 18 de docker community. Este post asume que las herramientas citadas las domina el lector.

Instalar Hyperledger Sawtooth implicará agregar claves de firma para el creador del software a nuestro entorno, incluido el repositorio que contiene el código en nuestro sistema, y realizar una actualización / instalación típica. Un nodo de validación de Sawtooth se puede ejecutar a partir de imágenes Docker preconstruidas o de forma nativa utilizando Ubuntu 16.04 o posterior. Nuestro ejemplo es un nodo validador único que utiliza el consenso de modo de desarrollo, una API de REST, tres procesadores de transacción y un contenedor de cliente.

Vamos a utilizar el siguiente docker-compose.yml estándar de Intel:

# Copyright 2017 Intel Corporation
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# ------------------------------------------------------------------------------

version: "2.1"

services:

settings-tp:
 image: hyperledger/sawtooth-settings-tp:1.0
 container_name: sawtooth-settings-tp-default
 depends_on:
 - validator
 entrypoint: settings-tp -vv -C tcp://validator:4004

intkey-tp-python:
 image: hyperledger/sawtooth-intkey-tp-python:1.0
 container_name: sawtooth-intkey-tp-python-default
 depends_on:
 - validator
 entrypoint: intkey-tp-python -vv -C tcp://validator:4004

xo-tp-python:
 image: hyperledger/sawtooth-xo-tp-python:1.0
 container_name: sawtooth-xo-tp-python-default
 depends_on:
 - validator
 entrypoint: xo-tp-python -vv -C tcp://validator:4004

validator:
 image: hyperledger/sawtooth-validator:1.0
 container_name: sawtooth-validator-default
 expose:
 - 4004
 ports:
 - "4004:4004"
 # start the validator with an empty genesis batch
 entrypoint: "bash -c \"\
 sawadm keygen && \
 sawtooth keygen my_key && \
 sawset genesis -k /root/.sawtooth/keys/my_key.priv && \
 sawadm genesis config-genesis.batch && \
 sawtooth-validator -vv \
 --endpoint tcp://validator:8800 \
 --bind component:tcp://eth0:4004 \
 --bind network:tcp://eth0:8800 \
 \""

rest-api:
 image: hyperledger/sawtooth-rest-api:1.0
 container_name: sawtooth-rest-api-default
 ports:
 - "8008:8008"
 depends_on:
 - validator
 entrypoint: sawtooth-rest-api -C tcp://validator:4004 --bind rest-api:8008

shell:
 image: hyperledger/sawtooth-all:1.0
 container_name: sawtooth-shell-default
 depends_on:
 - rest-api
 entrypoint: "bash -c \"\
 sawtooth keygen && \
 tail -f /dev/null \
 \""

Ahora debería ser suficiente con ejecutar el compose:

docker-compose up

El último de los servicios es un shell de utilidades, que podemos asimismo abrir:

docker-compose exec shell bash

No me voy a entretener con docker, pero comentar que lo que hacemos es abrir el shell de un contenedor de docker (bash), y estamos dentro de la red de docker. Como vemos en el contenedor (instrucción depends on), éste se comunica con el contenedor de rest-api. Probémoslo:

curl http://rest-api:8008/blocks

La rest-api debería devolver un json con datos, batches, etc. Como podemos ver en el composer, hemos sacado el puerto 8008 de la rest api al host, por lo que desde nuestro host (mi maravilloso mac) deberíamos también acceder a esta información (http://localhost:8008/blocks) en el navegador, por ejemplo.

Vamos a repasar un poco lo que tenemos instalado. Para información de cada componente se puede consultar la entrada Hyperledger Sawtooth: Introducción

  • hyperledger/sawtooth-xo-tp-python. Este es un procesador de transacciones, que en este caso está escrito en python. XO es una familia de transacciónes de ejemplo incluida en el SDK de Sawtooth. Es una implementación del popular juego tres en raya. Podéis consultar más información en https://sawtooth.hyperledger.org/docs/core/releases/latest/app_developers_guide/intro_xo_transaction_family.html
  • hyperledger/sawtooth-settings-tp. Es un contenedor que tiene un procesador de transacciones que gestiona las transacciones de configuración.
  • hyperledger/sawtooth-intkey-tp-python. Es un contenedor que contiene un procesador de transacciones que gestiona las transacciones de la familia IntegerKey. La familia de transacciones IntegerKey permite a los usuarios establecer, incrementar y disminuir el valor de las entradas almacenadas en un diccionario de estado.
  • hyperledger/sawtooth-validator. El validador sawtooth
  • hyperledger/sawtooth-rest-api. El api rest que usaremos
  • hyperledger/sawtooth-all. Un shell con todas las operaciones que necesitaremos.

Ya lo tenemos instalado. Lo siguiente es crear una aplicación. Una aplicación en sawtooth está compuesta fundamentalmente de dos partes. Una aplicación cliente, que envía transacciones al blockchain, generalmente a través de la API REST Sawtooth y proporciona una interfaz de usuario para la aplicación (linea de comandos, página web, o cualquier interfaz capaz de usar http). La otra parte es un procesador de transacciones, que contiene la lógica de negocio de la aplicación y se comunica con el validador, que envía las transacciones recibidas del cliente para su validación.

Veremos todo esto en el post siguiente: Creando una aplicación en Hyperledger Sawtooth

 

 

 

Crea un blog o un sitio web gratuitos con WordPress.com.

Subir ↑