Implementación de NGINX como puerta de enlace de API, parte 3: publicación de servicios gRPC

Liam CrillyDirector sénior de Gestión de Producto

Esta es la tercera entrada de nuestra serie de artículos sobre la implementación de NGINX Open Source y NGINX Plus como puerta de enlace de API.

• Parte 1 proporciona instrucciones detalladas para varios casos de uso de NGINX Open Source y NGINX Plus como puerta de enlace de API para API RESTful basadas en HTTP.
• Parte 2 amplía esos casos de uso y analiza diversas medidas de protección que pueden aplicarse para proteger y asegurar los servicios de API de backend en producción.
• Este artículo explica cómo implementar NGINX Open Source y NGINX Plus como puerta de enlace de API para servicios gRPC. Publicado originalmente en 2018, el artículo se ha actualizado para aprovechar la compatibilidad incorporada en NGINX Plus versión 23 con el protocolo nativo de comprobación del estado de gRPC. Consulte Implementación de comprobaciones de estado.

Nota: Salvo que se indique lo contrario, toda la información de esta publicación se aplica tanto a NGINX Plus como a NGINX Open Source. Para facilitar la lectura, en el resto del blog se utiliza simplemente «NGINX» cuando lo expuesto se aplica a ambas versiones.

Los conceptos y las ventajas de las arquitecturas de aplicaciones basadas en microservicios se han documentado ampliamente en los últimos años, especialmente en el blog de NGINX. La API HTTP constituye el núcleo de las aplicaciones de microservicios, y las dos primeras entradas de esta serie utilizan una API REST hipotética para mostrar cómo NGINX aborda este tipo de aplicaciones.

A pesar de la popularidad de las API REST con formatos de mensaje JSON para las aplicaciones modernas, este enfoque no resulta idóneo para todos los casos ni para todas las organizaciones. Los retos más habituales son:

• Estándares de documentación – Sin una buena disciplina por parte de los desarrolladores ni requisitos obligatorios de documentación, es muy fácil acabar con varias API REST que carezcan de una definición precisa. La Especificación OpenAPI se ha consolidado como un lenguaje genérico de descripción de interfaces para las API REST, pero su uso es opcional y requiere una gobernanza sólida dentro de la organización de desarrollo.
• Eventos y conexiones de larga duración – Las API REST y el uso que hacen de HTTP como transporte imponen en gran medida un patrón de solicitud-respuesta para todas las llamadas a la API. Cuando la aplicación requiere eventos generados por el servidor, puede resultar útil recurrir a soluciones como sondeo largo HTTP y WebSocket, pero el uso de estas soluciones requiere, en última instancia, crear una API independiente y complementaria.
• Transacciones complejas – Las API REST se basan en el concepto de recursos únicos, cada uno representado por un URI. Cuando un evento de la aplicación requiere actualizar varios recursos, es necesario realizar varias llamadas a la API, lo cual resulta ineficiente, o implementar una transacción compleja en el backend, lo que contradice el principio fundamental de REST.

En los últimos años, gRPC se ha consolidado como un enfoque alternativo para crear aplicaciones distribuidas y, en particular, aplicaciones de microservicios. Desarrollado originalmente en Google, gRPC se publicó como software de código abierto en 2015 y actualmente es un proyecto de la Cloud Native Computing Foundation. Cabe destacar que gRPC utiliza HTTP/2 como mecanismo de transporte, aprovechando su formato de datos binario y sus capacidades de transmisión multiplexada.

Las principales ventajas de gRPC son:

• Lenguaje de definición de interfaces estrechamente integrado (búferes de protocolo)
• Compatibilidad nativa con la transmisión de datos (en ambas direcciones)
• Formato de datos binarios eficiente
• Generación automatizada de código para numerosos lenguajes de programación, lo que permite un verdadero entorno de desarrollo políglota sin introducir problemas de interoperabilidad

Definición de la puerta de enlace gRPC

Las dos primeras publicaciones de esta serie explicaron cómo se pueden ofrecer varias API a través de un único punto de entrada (por ejemplo, https://api.example.com). El comportamiento y las características predeterminados del tráfico gRPC nos llevan a adoptar el mismo enfoque cuando NGINX se implementa como puerta de enlace gRPC. Aunque es posible compartir el tráfico HTTP y gRPC en el mismo nombre de host y puerto, hay varias razones por las que es preferible separarlos:

• Los clientes de API de aplicaciones REST y gRPC esperan respuestas de error en formatos diferentes
• Los campos relevantes de los registros de acceso varían entre REST y gRPC
• Como gRPC nunca tiene que interactuar con navegadores web antiguos, puede aplicar una política TLS más estricta

Para lograr esta separación, incluimos la configuración de nuestra puerta de enlace gRPC en un bloque server{} independiente dentro del archivo de configuración principal de gRPC, grpc_gateway.conf, ubicado en el directorio /etc/nginx/conf.d.

Cargando ejemplo de código…

Empezamos definiendo el formato de las entradas del registro de acceso para el tráfico gRPC (líneas 1–4). En este ejemplo, utilizamos un formato JSON para recopilar los datos más relevantes de cada solicitud. Por ejemplo, el método HTTP no se incluye, ya que todas las solicitudes gRPC utilizan POST. También registramos el código de estado de gRPC junto con el código de estado HTTP. Sin embargo, el código de estado de gRPC puede generarse de distintas formas. En condiciones normales, grpc-status se devuelve como un tráiler HTTP/2 desde el backend, pero, en determinadas condiciones de error, puede devolverse como una cabecera HTTP/2, ya sea desde el backend o desde el propio NGINX. Para simplificar el registro de acceso, utilizamos un bloque map (líneas 6–9) para evaluar una nueva variable, $grpc_status, y obtener el estado de gRPC independientemente de dónde se origine.

Esta configuración contiene dos directivas listen (líneas 12 y 13), lo que nos permite probar tanto el tráfico sin cifrar (puerto 50051) como el protegido mediante TLS (puerto 443). El parámetro http2 configura NGINX para aceptar conexiones HTTP/2; tenga en cuenta que es independiente del parámetro ssl. Asimismo, tenga en cuenta que el puerto 50051 es el puerto convencional para gRPC sin cifrar, pero no es adecuado para entornos de producción.

La configuración de TLS es convencional, a excepción de la directiva ssl_protocols (línea 23), que establece TLS 1.2 como el protocolo mínimo aceptable. La especificación HTTP/2 exige el uso de TLS 1.2 (o una versión posterior), lo que garantiza que todos los clientes sean compatibles con la extensión Server Name Indication (SNI) de TLS. Esto significa que la puerta de enlace gRPC puede compartir el puerto 443 con servidores virtuales definidos en otros bloques server{}.

Ejecución de servicios gRPC de ejemplo

Para explorar las capacidades de gRPC de NGINX, utilizamos un entorno de prueba sencillo que representa los componentes clave de una puerta de enlace gRPC, con varios servicios gRPC implementados. Utilizamos dos aplicaciones de ejemplo de las guías oficiales de gRPC: helloworld (escrita en Go) y RouteGuide (escrita en Python). La aplicación RouteGuide resulta especialmente útil porque incluye los cuatro métodos de servicio de gRPC:

• RPC simple (una única solicitud y respuesta)
• RPC con transmisión de respuestas
• RPC con transmisión de solicitudes
• RPC de streaming bidireccional

Ambos servicios gRPC están instalados como contenedores Docker en nuestro host NGINX. Para obtener instrucciones completas sobre cómo crear el entorno de pruebas, consulte el Apéndice.

Configuramos NGINX para que reconozca los servicios RouteGuide y helloworld, junto con las direcciones de los contenedores disponibles.

Cargando ejemplo de código…

Añadimos un bloque upstream para cada uno de los servicios gRPC (líneas 40–45 y 47–51) y los rellenamos con las direcciones de los contenedores individuales que ejecutan el código del servidor gRPC.

Enrutamiento de solicitudes gRPC

Con NGINX escuchando en el puerto convencional de texto sin cifrar para gRPC (50051), añadimos información de enrutamiento a la configuración para que las solicitudes de los clientes lleguen al servicio de backend correcto. Pero antes debemos comprender cómo se representan las llamadas a métodos gRPC como solicitudes HTTP/2. El siguiente diagrama muestra una versión abreviada del archivo route_guide.proto del servicio RouteGuide e ilustra cómo el paquete, el servicio y el método RPC conforman el URI tal como lo ve NGINX.

Por lo tanto, la información incluida en la solicitud HTTP/2 puede utilizarse para el enrutamiento simplemente buscando una coincidencia con el nombre del paquete (en este caso, routeguide o helloworld).

Cargando ejemplo de código…

El primer bloque location (línea 26), sin ningún modificador, define una coincidencia de prefijo, de modo que /routeguide. coincide con todos los servicios y métodos RPC definidos en el archivo .proto correspondiente a ese paquete. Por tanto, la directiva grpc_pass (línea 27) reenvía todas las solicitudes del cliente RouteGuide al grupo de servidores ascendentes routeguide_service. Esta configuración (y la equivalente para el servicio helloworld en las líneas 29 y 30) proporciona una correspondencia sencilla entre un paquete gRPC y sus servicios de backend.

Tenga en cuenta que el argumento de las directivas grpc_pass comienza con el esquema grpc://, que reenvía las solicitudes mediante una conexión gRPC sin cifrar. Si el backend está configurado para usar TLS, podemos utilizar el esquema grpcs:// para proteger la conexión gRPC con cifrado de extremo a extremo.

Después de ejecutar el cliente RouteGuide, podemos confirmar el comportamiento del enrutamiento revisando las entradas del archivo de registro. Aquí vemos que el método RPC RouteChat se enrutó al contenedor que se ejecuta en el puerto 10002.

$ python route_guide_client.py...
$ tail -1 /var/log/nginx/grpc_log.json | jq
{
  "timestamp": "2021-01-20T12:17:56+01:00",
  "client": "127.0.0.1",
  "uri": "/routeguide.RouteGuide/RouteChat",
  "http-status": 200,
  "grpc-status": 0,
  "upstream": "127.0.0.1:10002",
  "rx-bytes": 161,
  "tx-bytes": 212
}

Enrutamiento preciso

Como se muestra arriba, el enrutamiento de varios servicios gRPC a distintos backends es sencillo, eficiente y requiere muy pocas líneas de configuración. Sin embargo, los requisitos de enrutamiento en un entorno de producción pueden ser más complejos y exigir un enrutamiento basado en otros elementos del URI (el servicio gRPC o incluso métodos RPC concretos).

El siguiente fragmento de configuración amplía el ejemplo anterior para que el método RPC de streaming bidireccional RouteChat se enrute a un backend y todos los demás métodos de RouteGuide a otro backend distinto.

Cargando ejemplo de código…

La segunda directiva location (línea 7) utiliza el modificador = (signo igual) para indicar que se trata de una coincidencia exacta con el URI del método RPC RouteChat. Las coincidencias exactas se procesan antes que las coincidencias de prefijo, lo que significa que no se tiene en cuenta ningún otro bloque location para el URI de RouteChat.

Respuesta a errores

Los errores de gRPC son algo diferentes de los del tráfico HTTP convencional. Los clientes esperan que las condiciones de error se expresen como respuestas gRPC, por lo que el conjunto predeterminado de páginas de error de NGINX (en formato HTML) no resulta adecuado cuando NGINX está configurado como puerta de enlace gRPC. Para solucionarlo, especificamos un conjunto de respuestas de error personalizadas para los clientes gRPC.

Cargando ejemplo de código…

El conjunto completo de respuestas de error de gRPC constituye una configuración relativamente extensa y en gran medida estática, por lo que las guardamos en un archivo independiente, errors.grpc_conf, y usamos la directiva include (línea 34) para hacer referencia a ellas. A diferencia de los clientes HTTP/REST, no se espera que las aplicaciones cliente de gRPC gestionen una amplia variedad de códigos de estado HTTP. La documentación de gRPC especifica cómo un proxy intermedio como NGINX debe convertir los códigos de error HTTP en códigos de estado de gRPC para que los clientes siempre reciban una respuesta adecuada. Usamos la directiva error_page para realizar esta correspondencia.

Cargando ejemplo de código…

Cada uno de los códigos de estado HTTP estándar se envía a una ubicación con nombre mediante el prefijo @, de modo que se pueda generar una respuesta compatible con gRPC. Por ejemplo, la respuesta HTTP 404 se redirige internamente a la ubicación @grpc_unimplemented, que se define más adelante en el archivo:

Cargando ejemplo de código…

La ubicación con nombre @grpc_unimplemented solo está disponible para el procesamiento interno de NGINX; los clientes no pueden solicitarla directamente, ya que no existe ningún URI enrutable. Dentro de esta ubicación, creamos una respuesta gRPC rellenando las cabeceras gRPC obligatorias y enviándolas, sin cuerpo de respuesta, mediante el código de estado HTTP 204 (Sin contenido).

Podemos utilizar el comando curl(1) para simular un cliente gRPC con un comportamiento incorrecto que solicita un método gRPC inexistente. Sin embargo, tenga en cuenta que curl no suele ser adecuado como cliente de prueba de gRPC, ya que los búferes de protocolo utilizan un formato de datos binario. Para probar gRPC desde la línea de comandos, considere utilizar grpc_cli.

$ curl -i --http2 -H "Content-Type: application/grpc" -H "TE: trailers" -X POST https://grpc.example.com/does.Not/ExistHTTP/2 204 
server: nginx/1.19.5
date: Wed, 20 Jan 2021 15:03:41 GMT
grpc-status: 12
grpc-message: unimplemented

El archivo grpc_errors.conf mencionado anteriormente también contiene asignaciones de códigos de estado de HTTP a gRPC para otras respuestas de error que NGINX podría generar, como errores de tiempo de espera y de certificados de cliente.

Autenticación de clientes con metadatos de gRPC

gRPC metadatos permite a los clientes enviar información adicional junto con las llamadas a métodos RPC, sin que sea necesario incluir esos datos en la especificación de Protocol Buffers (archivo .proto). Los metadatos son una lista sencilla de pares clave-valor, cada uno de los cuales se transmite como una cabecera HTTP/2 independiente. Por tanto, NGINX puede acceder fácilmente a los metadatos.

De los numerosos casos de uso de los metadatos, la autenticación de clientes es el más habitual en una puerta de enlace de API gRPC. El siguiente fragmento de configuración muestra cómo NGINX Plus puede utilizar los metadatos de gRPC para realizar la autenticación mediante JWT (la autenticación mediante JWT es exclusiva de NGINX Plus). En este ejemplo, el JWT se envía en los metadatos auth-token.

Cargando ejemplo de código…

Cada encabezado de solicitud HTTP está disponible para NGINX Plus como una variable denominada $http_header. Los guiones (-) del nombre del encabezado se convierten en guiones bajos ( _ ) en el nombre de la variable, por lo que el JWT está disponible como $http_auth_token (línea 2).

Si se utilizan claves de API para la autenticación, por ejemplo, con API HTTP/REST existentes, también se pueden incluir en los metadatos de gRPC y NGINX puede validarlas. En la parte 1 de esta serie de artículos se proporciona una configuración para la autenticación mediante claves de API<.htmla>.

Implementación de comprobaciones de estado

Al equilibrar la carga de tráfico entre varios backends, es importante evitar enviar solicitudes a aquellos que estén caídos o no disponibles por cualquier otro motivo. Con NGINX Plus, podemos utilizar comprobaciones de estado activas para enviar de forma proactiva solicitudes fuera de banda a los backends y retirarlos de la rotación del equilibrador de carga cuando no respondan a las comprobaciones de estado según lo esperado. De este modo, garantizamos que las solicitudes de los clientes nunca lleguen a backends que estén fuera de servicio.

El siguiente fragmento de configuración habilita las comprobaciones de estado activas para los servicios gRPC RouteGuide y helloworld; para destacar la configuración relevante, se omiten algunas directivas incluidas en el archivo grpc_gateway.conf utilizado en las secciones anteriores.

Cargando ejemplo de código…

Para cada ruta, ahora también especificamos la directiva health_check (líneas 17 y 21). Tal como indica el argumento type=grpc, NGINX Plus utiliza el protocolo de comprobación de estado de gRPC para enviar una comprobación de estado a cada servidor del grupo de servidores ascendentes. Sin embargo, nuestros sencillos servicios gRPC no implementan el protocolo de comprobación de estado de gRPC, por lo que esperamos que respondan con el código de estado que significa «no implementado» (grpc_status=12). Cuando lo hacen, basta para indicar que nos estamos comunicando con un servicio gRPC activo.

Con esta configuración, podemos detener cualquiera de los contenedores de backend sin que los clientes gRPC sufran retrasos ni tiempos de espera agotados. Las comprobaciones de estado activas son exclusivas de NGINX Plus; obtenga más información sobre las comprobaciones de estado de gRPC en nuestro blog.

Aplicación de la limitación de solicitudes y otros controles de la puerta de enlace de API

La configuración de ejemplo de grpc_gateway.conf es apta para su uso en producción, con algunas modificaciones menores para TLS. La capacidad de enrutar solicitudes gRPC en función del paquete, el servicio o el método RPC permite aplicar las funcionalidades existentes de NGINX al tráfico gRPC exactamente del mismo modo que a las API HTTP/REST o, de hecho, al tráfico web convencional. En cada caso, el bloque location correspondiente puede ampliarse con opciones de configuración adicionales, como la limitación de la tasa de solicitudes o el control del ancho de banda.

Resumen

En esta tercera y última entrada de nuestra serie sobre la implementación de NGINX Open Source y NGINX Plus como puerta de enlace de API, nos centramos en gRPC como tecnología nativa de la nube para crear aplicaciones de microservicios. Demostramos que NGINX puede servir aplicaciones gRPC con la misma eficacia que las API HTTP/REST y que ambos tipos de API pueden publicarse a través de NGINX como una puerta de enlace de API multipropósito.

Las instrucciones para configurar el entorno de pruebas utilizado en esta entrada del blog se encuentran en el apéndice que aparece más abajo, y puede descargar todos los archivos de nuestro repositorio de GitHub Gist.

Consulta las demás entradas de esta serie:

• Parte 1 explica cómo configurar NGINX para algunos casos de uso esenciales de puertas de enlace de API basadas en HTTP.
• Parte 2 analiza casos de uso más avanzados para proteger los servicios de backend frente a clientes maliciosos o con un comportamiento inadecuado.

Para probar NGINX Plus como puerta de enlace de API, inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso. Durante el periodo de prueba, utilice el conjunto completo de archivos de configuración de nuestro repositorio de GitHub Gist.

Apéndice: Configuración del entorno de pruebas

Las siguientes instrucciones permiten instalar el entorno de pruebas en una máquina virtual para que esté aislado y sea reproducible. Sin embargo, no hay ningún motivo por el que no pueda instalarse en un servidor físico, es decir, directamente sobre el hardware.

Para simplificar el entorno de pruebas, utilizamos contenedores Docker para ejecutar los servicios gRPC. Esto significa que no necesitamos varios hosts para el entorno de pruebas, pero NGINX puede seguir realizando conexiones mediante proxy a través de una llamada de red, como en un entorno de producción.

El uso de Docker también nos permite ejecutar varias instancias de cada servicio gRPC en puertos diferentes sin necesidad de modificar el código. Cada servicio gRPC escucha en el puerto 50051 dentro del contenedor, que está asignado a un puerto localhost único en la máquina virtual. Esto, a su vez, deja libre el puerto 50051 para que NGINX pueda utilizarlo como puerto de escucha. Por tanto, cuando los clientes de prueba se conectan mediante el puerto 50051 que tienen preconfigurado, llegan a NGINX.

Instalación de NGINX Open Source o NGINX Plus

1. Instale NGINX Open Source o NGINX Plus siguiendo las instrucciones de la Guía de administración de NGINX Plus.
2. Copie los siguientes archivos del repositorio de GitHub Gist en /etc/nginx/conf.d: Nota: Si no utiliza TLS, convierta en comentarios las directivas ssl_* de grpc_gateway.conf.
   • grpc_gateway.conf
   • errors.grpc_conf
3. Inicie NGINX Open Source o NGINX Plus.

$ sudo nginx

Instalación de Docker

Para Debian y Ubuntu, ejecuta:

$ sudo apt-get install docker.io

Para CentOS, RHEL y Oracle Linux, ejecute:

$ sudo yum install docker

Instalación de los contenedores del servicio RouteGuide

1. Cree la imagen de Docker para los contenedores de RouteGuide a partir del siguiente Dockerfile.

   Cargando ejemplo de código…

   Puede copiar el Dockerfile en un subdirectorio local antes de crear la imagen o especificar la URL del Gist del Dockerfile como argumento del comando docker build:

$ sudo docker build -t routeguide https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/routeguide.Dockerfile

1. La descarga y la compilación de la imagen pueden tardar unos minutos. La aparición del mensaje «Successfully built» y de una cadena hexadecimal (el ID de la imagen) indica que la compilación ha finalizado.
2. Confirme que la imagen se ha creado ejecutando «docker images».

$ sudo docker imagesREPOSITORY     TAG          IMAGE ID          CREATED         SIZE
routeguide     latest       63058a1cf8ca      1 minute ago    1.31 GB
python         latest       825141134528      9 days ago      923 MB

1. Inicia los contenedores de RouteGuide.

$ sudo docker run --name rg1 -p 10001:50051 -d routeguide$ sudo docker run --name rg2 -p 10002:50051 -d routeguide
$ sudo docker run --name rg3 -p 10003:50051 -d routeguide

1. Al ejecutarse correctamente cada comando, aparece una larga cadena hexadecimal que representa el contenedor en ejecución.
2. Comprueba que los tres contenedores estén en ejecución ejecutando docker ps. (El resultado de ejemplo se ha dividido en varias líneas para facilitar su lectura).

$ sudo docker psCONTAINER ID  IMAGE       COMMAND              STATUS        ...
d0cdaaeddf0f  routeguide  "python route_g..."  Up 2 seconds  ...
c04996ca3469  routeguide  "python route_g..."  Up 9 seconds  ...
2170ddb62898  routeguide  "python route_g..."  Up 1 minute   ...

      ... PORTS                     NAMES
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

1. La columna PORTS de la salida muestra cómo cada contenedor ha asignado un puerto local distinto al puerto 50051 dentro del contenedor.

Instalación de los contenedores del servicio helloworld

1. Cree la imagen de Docker para los contenedores helloworld a partir del siguiente Dockerfile.

   Cargando ejemplo de código…

   Puede copiar el Dockerfile en un subdirectorio local antes de crear la imagen o especificar la URL del Gist del Dockerfile como argumento del comando docker build:

$ sudo docker build -t helloworld https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/helloworld.Dockerfile

1. La descarga y la creación de la imagen pueden tardar unos minutos. La aparición del mensaje «Successfully built» y de una cadena hexadecimal (el ID de la imagen) indica que la compilación ha finalizado.
2. Confirme que la imagen se ha creado ejecutando docker images.

$ sudo docker images
REPOSITORY     TAG          IMAGE ID          CREATED           SIZE
helloworld     latest       e5832dc0884a      10 seconds ago    926MB
routeguide     latest       170761fa3f03      4 minutes ago     1.31GB
python         latest       825141134528      9 days ago        923MB
golang         latest       d0e7a411e3da      3 weeks ago       794MB

1. Inicia los contenedores helloworld.

$ sudo docker run --name hw1 -p 20001:50051 -d helloworld$ sudo docker run --name hw2 -p 20002:50051 -d helloworld

1. A medida que cada comando se ejecuta correctamente, aparece una larga cadena hexadecimal que representa el contenedor en ejecución.
2. Comprueba que los dos contenedores helloworld estén en ejecución ejecutando docker ps.

$ sudo docker psCONTAINER ID  IMAGE       COMMAND              STATUS        ... 
e0d204ae860a  helloworld  "go run greeter..."  Up 5 seconds  ... 
66f21d89be78  helloworld  "go run greeter..."  Up 9 seconds  ... 
d0cdaaeddf0f  routeguide  "python route_g..."  Up 4 minutes  ... 
c04996ca3469  routeguide  "python route_g..."  Up 4 minutes  ... 
2170ddb62898  routeguide  "python route_g..."  Up 5 minutes  ... 

      ... PORTS                     NAMES
      ... 0.0.0.0:20002->50051/tcp  hw2
      ... 0.0.0.0:20001->50051/tcp  hw1
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

Instalación de las aplicaciones cliente de gRPC

1. Instale los requisitos previos del lenguaje de programación, algunos de los cuales puede que ya estén instalados en el entorno de prueba. Tenga en cuenta que python-pip requiere que el repositorio EPEL esté habilitado (ejecute primero sudo yum install epel-release si es necesario).
   • Para Ubuntu y Debian, ejecute:

$ sudo apt-get install golang-go python3 python-pip git

• Para CentOS, RHEL y Oracle Linux, ejecute:

$ sudo yum install golang python python-pip git

1. Descarga la aplicación helloworld:

$ go get google.golang.org/grpc

1. Descarga la aplicación RouteGuide:

$ git clone -b v1.14.1 https://github.com/grpc/grpc
$ pip install grpcio-tools

Probar la configuración

1. Ejecuta el cliente helloworld:

$ go run go/src/google.golang.org/grpc/examples/helloworld/greeter_client/main.go

1. Ejecuta el cliente RouteGuide:

$ cd grpc/examples/python/route_guide
$ python route_guide_client.py

1. Comprueba los registros de NGINX para confirmar que el entorno de pruebas está operativo:

$ tail /var/log/nginx/grpc_log.json

Sobre el autor

Liam CrillyDirector sénior de Gestión de Producto

Más artículos de Liam Crilly