Buscar

Blog de Alfonso Tienda

Marketing, Startups, Proyectos y Tecnología.

Kafka Listeners

Necesitamos en KAFKA establecer advertised.listeners (o KAFKA_ADVERTISED_LISTENERS  utilizando imágenes Docker) en la dirección externa (host / IP) para que los clientes puedan conectarse correctamente. De lo contrario, intentarán conectarse a la dirección del host interno, y si no se puede acceder, entonces surgen problemas. Hay que diferenciar primero entre LISTENERS y ADVERTISED_LISTENERS: 

  • LISTENERS son a qué interfaces se une Kafka
  • ADVERTISED_LISTENERS es cómo los clientes pueden conectarse.

images / docker01.png

En esta publicación, hablaré sobre por qué esto es necesario y luego mostraré cómo hacerlo, en base a un par de escenarios: Docker y AWS.

¿Alguien está escuchando?

Kafka es un sistema distribuido. Los datos se leen y se escriben en el líder para una partición determinada, que podría estar en cualquiera de los brokers de un cluster. Cuando se inicia un cliente (productor / consumidor), solicitará metadatos sobre qué broker es el líder de una partición, y puede hacerlo desde cualquier broker. Los metadatos devueltos incluirán los endpoints disponibles para el broker líder de esa partición, y el cliente luego usará esos endpoints para conectarse al broker para leer / escribir datos según sea necesario.

Son estos endpoints los que causan problemas. En una sola máquina, ejecutando ‘bare metal’ (sin VM, sin Docker), todo podría ser el nombre de host (o solo localhost ) y es fácil. Pero una vez que pasa a configuraciones de red más complejas y múltiples nodos, es algo más complejo.

Supongamos que tienes más de una red. Esto podría ser cosas como:

  • Redes internas de Docker más máquina host
  • Brokers en la nube (p. Ej., AWS EC2) y máquinas “on premise” (o incluso en otra nube)

Debes decirle a Kafka cómo los brokers pueden comunicarse entre sí, pero también asegurarse de que los clientes externos (productores / consumidores) puedan comunicarse con el broker que necesitan.

La clave es que cuando ejecutas un cliente, el broker que le pasas como parámetro es justo a dónde irá y obtendrá los metadatos sobre los brokers en el clúster . El host y la IP reales a los que se conectará para leer / escribir datos se basan en los datos que el broker devuelve en esa conexión inicial, incluso si es solo un nodo y el broker devuelto es el mismo al que está conectado.

Para configurar esto correctamente, debe comprender que los brokes de Kafka pueden tener múltiples listners . Un listener es una combinación de

  1. Host / IP
  2. Puerto
  3. Protocolo

Veamos algunas configuraciones. A menudo, el protocolo también se usa para el nombre del listener, pero aquí hagámoslo bien y claro usando nombres abstractos para los oyentes:

KAFKA_LISTENERS: LISTENER_BOB://kafka0:29092,LISTENER_FRED://localhost:9092 
KAFKA_ADVERTISED_LISTENERS: LISTENER_BOB://kafka0:29092,LISTENER_FRED://localhost:9092 
KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_BOB:PLAINTEXT,LISTENER_FRED:PLAINTEXT 
KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_BOB

Estoy usando los nombres de configuración de Docker; sería una configuración análoga usando server.properties directamente. Estos elementos son:

  • KAFKA_LISTENERS (listeners) es una lista de listeners separados por comas, y el host / ip y el puerto al que se une Kafka para escuchar. Para redes más complejas, esta podría ser una dirección IP asociada con una interfaz de red dada en una máquina. El valor predeterminado es 0.0.0.0, lo que significa escuchar en todas las interfaces.
  • KAFKA_ADVERTISED_LISTENERS (advertised.listeners) es una lista de listeners separados por comas con su host / ip y puerto. Estos son los metadatos que se devuelven a los clientes.
  • KAFKA_LISTENER_SECURITY_PROTOCOL_MAP (listener.security.protocol.map) define pares clave / valor para el protocolo de seguridad a utilizar, por nombre de listener.
  • KAFKA_INTER_BROKER_LISTENER_NAME ( inter.broker.listener.name ) Los brokers de Kafka se comunican entre sí , generalmente en la red interna (por ejemplo, la red Docker, AWS VPC, etc.). Para definir qué listener utilizar para esta comunicación, especifiamos esta variable. El host / IP utilizado debe ser accesible desde la máquina del broker a otros.

Es posible que los clientes de Kafka no sean locales en la red del broker, y aquí es donde entran los listeners adicionales.

Cada listener, cuando esté conectado, informará la dirección a la que se puede acceder. La dirección en la que llega a un broker depende de la red utilizada . Si se está conectando al broker desde una red interna, será un host / IP diferente al que se conecta externamente.

Al conectarse a un broker, el listener que se devolverá al cliente será el listener al que se conectó (según el puerto).

kafkacat es una herramienta útil para explorar esto. Usando -L puede ver los metadatos para el oyente al que se conectó. Basado en la misma configuración de escucha que la anterior ( LISTENER_BOB / LISTENER_FRED ), consulte las entradas respectivas para el broker 0 at : –

Al conectarse en el puerto 9092 (que asignamos como LISTENER_FRED ), la dirección del broker se devuelve como localhost

$ kafkacat -b kafka0:9092 \ -L 

Metadata for all topics (from broker -1: kafka0:9092/bootstrap): 1 brokers: broker 0 at localhost:9092

Conectándose en el puerto 29092 (que asignamos como LISTENER_BOB ), la dirección del broker se devuelve como kafka0 :

$ kafkacat -b kafka0:29092 \ -L 

Metadata for all topics (from broker 0: kafka0:29092/0): 1 brokers: broker 0 at kafka0:29092

También puede usar tcpdump para examinar el tráfico de un cliente que se conecta al broker y detectar el nombre de host que devuelve el broker.

¿Por qué me puedo conectar al broker, pero el cliente aún falla?

Incluso si puede realizar la conexión inicial con el broker, la dirección que se devuelve en los metadatos puede seguir siendo un hostname al que no puede acceder nuestro cliente.

Pensemos esto paso a paso.

  1. Tenemos un broker en AWS. Queremos enviarle un mensaje desde nuestra computadora portátil. Conocemos el nombre de host externo para la instancia EC2 ( ec2-54-191-84-122.us-west-2.compute.amazonaws.com ). Hemos creado la entrada necesaria en el grupo de seguridad para abrir el puerto del agente a nuestro tráfico entrante. Hacemos cosas inteligentes como verificar que nuestra máquina local pueda conectarse al puerto en la máquina:
    $ nc -vz ec2-54-191-84-122.us-west-2.compute.amazonaws.com 9092 
    found 0 associations found 1 connections: 1: flags=82<CONNECTED,PREFERRED> outif utun5 src 172.27.230.23 port 53352 dst 54.191.84.122 port 9092 rank info not available TCP aux info available Connection to ec2-54-191-84-122.us-west-2.compute.amazonaws.com port 9092 [tcp/XmlIpcRegSvc] succeeded!

    ¡Las cosas se ven bien! Ejecutamos:

    echo "test"|kafka-console-producer --broker-list ec2-54-191-84-122.us-west-2.compute.amazonaws.com:9092 --topic test

    Ahora … ¿qué pasa después?

  2. Nuestro PC resuelve ec2-54-191-84-122.us-west-2.compute.amazonaws.com éxito (a la dirección IP 54.191.84.122) y se conecta a la máquin en el puerto 9092
  3. El broker recibe la conexión entrante en el puerto 9092. Devuelve los metadatos al cliente, con el nombre de host ip-172-31-18-160.us-west-2.compute.internal porque este es el nombre de host del broker y el valor predeterminado para los listeners .
  4. El cliente intenta enviar datos al broker utilizando los metadatos que se le dieron. Dado que ip-172-31-18-160.us-west-2.compute.internal no se puede resolver desde Internet, falla.
    $ echo "test"|kafka-console-producer --broker-list ec2-54-191-84-122.us-west-2.compute.amazonaws.com:9092 --topic test >>[2018-07-30 15:08:41,932] ERROR Error when sending message to topic test with key: null, value: 4 bytes with error: (org.apache.kafka.clients.producer.internals.ErrorLoggingCallback) org.apache.kafka.common.errors.TimeoutException: Expiring 1 record(s) for test-0: 1547 ms has passed since batch creation plus linger time
  5. Desconcertado, intentamos lo mismo desde la propia máquina de brokers:
    $ echo "foo"|kafka-console-producer --broker-list ec2-54-191-84-122.us-west-2.compute.amazonaws.com:9092 --topic test >> $ kafka-console-consumer --bootstrap-server ec2-54-191-84-122.us-west-2.compute.amazonaws.com:9092 --topic test --from-beginning foo

    ¡Funciona bien! Esto se debe a que nos estamos conectando al puerto 9092, que está configurado como escucha interna y, por lo tanto, informa su nombre de host como ip-172-31-18-160.us-west-2.compute.internal que se puede resolver desde la máquina del agente (¡ya que es su propio nombre de host!)

  6. Podemos hacer la vida aún más fácil usando kafkacat . Usando el indicador -L podemos ver los metadatos devueltos por el broker:
    $ kafkacat -b ec2-54-191-84-122.us-west-2.compute.amazonaws.com:9092 -L 
    
    Metadata for all topics (from broker -1: ec2-54-191-84-122.us-west-2.compute.amazonaws.com:9092/bootstrap): 1 brokers: broker 0 at ip-172-31-18-160.us-west-2.compute.internal:9092

    Claro como día, se devuelve el nombre de host interno . Esto también hace que este error aparentemente confuso tenga mucho más sentido: conectarse a un nombre de host y obtener un error de búsqueda en otro:

    $ kafkacat -b ec2-54-191-84-122.us-west-2.compute.amazonaws.com:9092 -C -t test % 
    
    ERROR: Local: Host resolution failure: ip-172-31-18-160.us-west-2.compute.internal:9092/0: Failed to resolve 'ip-172-31-18-160.us-west-2.compute.internal:9092': nodename nor servname provided, or not known

    Aquí estamos usando kafkacat en modo consumidor ( -C ) de nuestra máquina local para intentar leer el tema. Como antes, debido a que estamos recuperando el nombre de host del listener interno del intermediario en los metadatos, el cliente no puede resolver ese nombre de host para leer / escribir.

Cómo: Conectarse a Kafka en Docker

images / docker01.png

Ejecute dentro de Docker, deberá configurar dos listeners para Kafka:

  1. Comunicación dentro de la red Docker . Esto podría ser la comunicación entre intermediarios (es decir, entre intermediarios) y entre otros componentes que se ejecutan en Docker, como Kafka Connect, o clientes o productores de terceros.

    Para estas comunicaciones, necesitamos usar el nombre de host de los contenedores Docker . Cada contenedor de Docker en la misma red de Docker utilizará el nombre de host del contenedor del agente Kafka para alcanzarlo.

  2. Tráfico de red no Docker. Esto podría ser clientes que se ejecutan localmente en la máquina host Docker, por ejemplo. Se supone que se conectarán en localhost , a un puerto expuesto desde el contenedor Docker.

    Aquí está el fragmento de docker-compose:

 

kafka0:
image: "confluentinc/cp-enterprise-kafka:5.2.1"
ports:
- '9092:9092'
- '29094:29094'
depends_on:
- zookeeper
environment:
- KAFKA_LISTENERS: LISTENER_BOB://kafka0:29092,LISTENER_FRED://kafka0:9092,LISTENER_ALICE://kafka0:29094
- KAFKA_ADVERTISED_LISTENERS: LISTENER_BOB://kafka0:29092,LISTENER_FRED://localhost:9092,LISTENER_ALICE://never-gonna-give-you-up:29094
- KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_BOB:PLAINTEXT,LISTENER_FRED:PLAINTEXT,LISTENER_ALICE:PLAINTEXT
- KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_BOB

 

  • Los clientes dentro de la red Docker se conectan utilizando el oyente “BOB”, con el puerto 29092 y el nombre de host kafka0 . Al hacerlo, recuperan el nombre de host kafka0 al cual conectarse. Cada contenedor de docker resolverá kafka0 utilizando la red interna de Docker y podrá comunicarse con el broker.
  • Los clientes externos a la red Docker se conectan utilizando el oyente “FRED”, con el puerto 9092 y el nombre de host localhost . El puerto 9092 está expuesto por el contenedor Docker y está disponible para conectarse. Cuando los clientes se conectan, se les da el nombre de host localhost para los metadatos del intermediario, y se conectan a esto cuando leen / escriben datos.
  • La configuración anterior no manejaría el escenario en el que un cliente externo a Docker y externo a la máquina host desea conectarse. Esto se debe a que ni kafka0 (el nombre de host interno de Docker) ni localhost (la dirección de bucle de retorno para la máquina host de Docker) serían resolubles.

Cómo: Conexión a Kafka en Cloud

Aquí se aplican exactamente los mismos conceptos que con Docker. La principal diferencia es que, mientras que con Docker las conexiones externas pueden estar solo en el host local (como arriba), con Kafka alojado en la nube (como en AWS) la conexión externa será de una máquina no local al broker y que necesita poder conectarse al broker.

Otra complicación es que, si bien las redes de Docker están muy segregadas de las del host, en IaaS a menudo el nombre de host externo se puede resolver internamente , lo que lo hace impredecible cuando realmente puede encontrar estos problemas.

Existen dos enfoques, dependiendo de si la dirección externa a través de la cual se va a conectar al intermediario también se puede resolver localmente para todos los intermediarios en la red (por ejemplo, VPC).

Opción 1: la dirección externa se puede resolver localmente

images / aws01.png

El listner existente, llamado PLAINTEXT , solo necesita sobrescribir para establecer el nombre de host anunciado (es decir, el que se pasa a los clientes entrantes)

advertised.listeners=PLAINTEXT://ec2-54-191-84-122.us-west-2.compute.amazonaws.com:9092

Ahora las conexiones tanto internas como externas utilizarán ec2-54-191-84-122.us-west-2.compute.amazonaws.com para conectarse. Debido a que ec2-54-191-84-122.us-west-2.compute.amazonaws.com puede resolverse tanto local como externamente, las cosas funcionan bien.

Opción 2: la dirección externa NO se puede resolver localmente

Deberá configurar dos oyentes para Kafka:

  1. Comunicación dentro de la red AWS (VPC) . Esto podría ser la comunicación entre intermediarios (es decir, entre intermediarios) y entre otros componentes que se ejecutan en la VPC, como Kafka Connect o clientes o productores de terceros. Para estas comunicaciones, necesitamos usar la IP interna de la máquina EC2 (o el nombre de host, si DNS está configurado).
  2. Tráfico externo de AWS. Esto podría estar probando la conectividad desde una computadora portátil, o simplemente desde máquinas no alojadas en Amazon. En ambos casos, se debe usar la IP externa de la instancia (o el nombre de host, si DNS está configurado).

images / aws02.png

Aquí hay un ejemplo de configuración:

listeners=INTERNAL://0.0.0.0:19092,EXTERNAL://0.0.0.0:9092 

listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT 

advertised.listeners=INTERNAL://ip-172-31-18-160.us-west-2.compute.internal:19092,EXTERNAL://ec2-54-191-84-122.us-west-2.compute.amazonaws.com:9092 

inter.broker.listener.name=INTERNAL

 

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”

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.

 

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

Subir ↑