Implantando o NGINX como um gateway de API, parte 3: publicação de serviços gRPC

Liam CrillyDiretor Sênior de Gestão de Produtos

Este é o terceiro post da nossa série sobre a implantação do NGINX Open Source e do NGINX Plus como gateway de API.

• Parte 1 fornece instruções detalhadas para diversos casos de uso do NGINX Open Source e do NGINX Plus como gateway de API para APIs RESTful baseadas em HTTP.
• Parte 2 amplia esses casos de uso e analisa uma série de medidas de proteção que podem ser aplicadas para proteger e manter seguros os serviços de API de backend em produção.
• Este post explica como implantar o NGINX Open Source e o NGINX Plus como um gateway de API para serviços gRPC. Publicado originalmente em 2018, o post foi atualizado para aproveitar o suporte introduzido no NGINX Plus Release 23 ao protocolo nativo de verificação de integridade do gRPC. Consulte Implementação de verificações de integridade.

Observação: Exceto quando indicado, todas as informações desta publicação se aplicam tanto ao NGINX Plus quanto ao NGINX Open Source. Para facilitar a leitura, no restante do blog usamos apenas “NGINX” quando a discussão se aplica às duas versões.

Os conceitos e benefícios das arquiteturas de aplicações de microsserviços têm sido amplamente documentados nos últimos anos, sobretudo no blog da NGINX. No centro das aplicações de microsserviços está a API HTTP, e os dois primeiros posts desta série usam uma API REST hipotética para ilustrar como o NGINX lida com esse estilo de aplicação.

Apesar da popularidade das APIs REST com formatos de mensagem JSON para aplicações modernas, essa não é a abordagem ideal para todos os cenários nem para todas as organizações. Os desafios mais comuns são:

• Padrões de documentação – Sem uma boa disciplina por parte dos desenvolvedores ou requisitos obrigatórios de documentação, é muito fácil acabar com várias APIs REST sem uma definição precisa. A Open API Specification surgiu como uma linguagem genérica de descrição de interfaces para APIs REST, mas seu uso é opcional e exige uma governança rigorosa na organização de desenvolvimento.
• Eventos e conexões de longa duração – As APIs REST e o uso de HTTP como transporte determinam, em grande parte, um padrão de solicitação e resposta para todas as chamadas de API. Quando a aplicação exige eventos gerados pelo servidor, o uso de soluções como long polling HTTP e WebSocket pode ajudar, mas essas soluções acabam exigindo a criação de uma API separada e complementar.
• Transações complexas – As APIs REST são desenvolvidas com base no conceito de recursos únicos, cada um representado por um URI. Quando um evento da aplicação exige a atualização de vários recursos, são necessárias várias chamadas de API, o que é ineficiente, ou é preciso implementar uma transação complexa no backend, o que contradiz o princípio fundamental do REST.

Nos últimos anos, o gRPC surgiu como uma abordagem alternativa para a criação de aplicações distribuídas, especialmente aplicações de microsserviços. Desenvolvido originalmente pelo Google, o gRPC teve seu código aberto em 2015 e agora é um projeto da Cloud Native Computing Foundation. Vale destacar que o gRPC usa HTTP/2 como mecanismo de transporte, aproveitando seu formato de dados binário e seus recursos de streaming multiplexado.

Os principais benefícios do gRPC são:

• Linguagem de definição de interface fortemente acoplada (Protocol Buffers)
• Suporte nativo para streaming de dados (em ambas as direções)
• Formato eficiente de dados binários
• Geração automatizada de código para diversas linguagens de programação, possibilitando um verdadeiro ambiente de desenvolvimento poliglota sem introduzir problemas de interoperabilidade

Definindo o gateway gRPC

Os dois primeiros posts desta série descreveram como várias APIs podem ser disponibilizadas por meio de um único ponto de entrada (por exemplo, https://api.example.com). O comportamento padrão e as características do tráfego gRPC nos levam a adotar a mesma abordagem quando o NGINX é implantado como um gateway gRPC. Embora seja possível compartilhar o tráfego HTTP e gRPC no mesmo nome de host e na mesma porta, há vários motivos pelos quais é preferível separá-los:

• Os clientes de API para aplicações REST e gRPC esperam respostas de erro em formatos diferentes
• Os campos relevantes para os logs de acesso variam entre REST e gRPC
• Como o gRPC nunca precisa lidar com navegadores antigos, ele pode adotar uma política de TLS mais rigorosa

Para obter essa separação, colocamos a configuração do nosso gateway gRPC em seu próprio bloco server{} no arquivo de configuração principal do gRPC, grpc_gateway.conf, localizado no diretório /etc/nginx/conf.d.

Carregando exemplo de código…

Começamos definindo o formato das entradas no log de acesso para o tráfego gRPC (linhas 1–4). Neste exemplo, usamos o formato JSON para registrar os dados mais relevantes de cada solicitação. Observe, por exemplo, que o método HTTP não está incluído, pois todas as solicitações gRPC usam POST. Também registramos o código de status gRPC junto com o código de status HTTP. No entanto, o código de status gRPC pode ser gerado de diferentes maneiras. Em condições normais, grpc-status é retornado pelo backend como um trailer HTTP/2, mas, em algumas condições de erro, pode ser retornado como um cabeçalho HTTP/2, seja pelo backend ou pelo próprio NGINX. Para simplificar o log de acesso, usamos um bloco map (linhas 6–9) para avaliar uma nova variável, $grpc_status, e obter o status gRPC independentemente de sua origem.

Essa configuração contém duas diretivas listen (linhas 12 e 13), para que possamos testar tanto o tráfego sem criptografia (porta 50051) quanto o tráfego protegido por TLS (porta 443). O parâmetro http2 configura o NGINX para aceitar conexões HTTP/2 — observe que isso independe do parâmetro ssl. Observe também que a porta 50051 é a porta convencional para gRPC sem criptografia, mas não é adequada para uso em produção.

A configuração de TLS é convencional, com exceção da diretiva ssl_protocols (linha 23), que especifica o TLS 1.2 como o protocolo mínimo aceitável. A especificação HTTP/2 exige o uso do TLS 1.2 (ou superior), o que garante que todos os clientes sejam compatíveis com a extensão Server Name Indication (SNI) do TLS. Isso significa que o gateway gRPC pode compartilhar a porta 443 com servidores virtuais definidos em outros blocos server{}.

Executando serviços gRPC de exemplo

Para explorar os recursos de gRPC do NGINX, usamos um ambiente de teste simples que representa os principais componentes de um gateway gRPC, com vários serviços gRPC implantados. Usamos dois aplicativos de exemplo dos guias oficiais do gRPC: helloworld (escrito em Go) e RouteGuide (escrito em Python). O aplicativo RouteGuide é especialmente útil porque inclui cada um dos quatro métodos de serviço gRPC:

• RPC simples (uma única solicitação e resposta)
• RPC com streaming de resposta
• RPC com streaming de requisições
• RPC com streaming bidirecional

Os dois serviços gRPC são instalados como contêineres Docker em nosso host NGINX. Para obter instruções completas sobre como criar o ambiente de teste, consulte o Apêndice.

Configuramos o NGINX para reconhecer os serviços RouteGuide e helloworld, juntamente com os endereços dos contêineres disponíveis.

Carregando exemplo de código…

Adicionamos um bloco upstream para cada um dos serviços gRPC (linhas 40–45 e 47–51) e os preenchemos com os endereços dos contêineres individuais que estão executando o código do servidor gRPC.

Roteamento de solicitações gRPC

Com o NGINX escutando na porta convencional de texto simples do gRPC (50051), adicionamos informações de roteamento à configuração para que as solicitações dos clientes cheguem ao serviço de backend correto. Mas primeiro precisamos entender como as chamadas de método gRPC são representadas como solicitações HTTP/2. O diagrama a seguir mostra uma versão resumida do arquivo route_guide.proto do serviço RouteGuide, ilustrando como o pacote, o serviço e o método RPC formam o URI, conforme visto pelo NGINX.

Portanto, as informações contidas na solicitação HTTP/2 podem ser usadas para fins de roteamento simplesmente verificando a correspondência com o nome do pacote (neste caso, routeguide ou helloworld).

Carregando exemplo de código…

O primeiro bloco location (linha 26), sem nenhum modificador, define uma correspondência por prefixo, de modo que /routeguide. corresponda a todos os serviços e métodos RPC definidos no arquivo .proto correspondente desse pacote. Portanto, a diretiva grpc_pass (linha 27) encaminha todas as solicitações do cliente RouteGuide para o grupo upstream routeguide_service. Essa configuração (e a configuração equivalente para o serviço helloworld nas linhas 29 e 30) fornece um mapeamento simples entre um pacote gRPC e seus serviços de backend.

Observe que o argumento das diretivas grpc_pass começa com o esquema grpc://, que encaminha as solicitações por meio de uma conexão gRPC sem criptografia. Se o backend estiver configurado para TLS, podemos usar o esquema grpcs:// para proteger a conexão gRPC com criptografia de ponta a ponta.

Depois de executar o cliente RouteGuide, podemos confirmar o comportamento do roteamento analisando as entradas do arquivo de log. Aqui, vemos que o método RPC RouteChat foi encaminhado para o contêiner em execução na porta 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
}

Roteamento preciso

Como mostrado acima, o roteamento de vários serviços gRPC para diferentes backends é simples, eficiente e requer pouquíssimas linhas de configuração. No entanto, os requisitos de roteamento em um ambiente de produção podem ser mais complexos e exigir o roteamento com base em outros elementos do URI (o serviço gRPC ou até mesmo métodos RPC individuais).

O trecho de configuração a seguir amplia o exemplo anterior para que o método RPC de streaming bidirecional RouteChat seja encaminhado para um backend e todos os outros métodos de RouteGuide sejam encaminhados para outro backend.

Carregando exemplo de código…

A segunda diretiva location (linha 7) usa o modificador = (sinal de igual) para indicar que esta é uma correspondência exata com o URI do método RPC RouteChat. As correspondências exatas são processadas antes das correspondências de prefixo, o que significa que nenhum outro bloco location é considerado para o URI de RouteChat.

Respondendo a erros

Os erros de gRPC são um pouco diferentes dos erros do tráfego HTTP convencional. Os clientes esperam que as condições de erro sejam expressas como respostas gRPC, o que torna inadequado o conjunto padrão de páginas de erro do NGINX (em formato HTML) quando o NGINX está configurado como um gateway gRPC. Para resolver isso, especificamos um conjunto de respostas de erro personalizadas para clientes gRPC.

Carregando exemplo de código…

O conjunto completo de respostas de erro do gRPC é uma configuração relativamente longa e, em grande parte, estática. Por isso, mantemos essas respostas em um arquivo separado, errors.grpc_conf, e usamos a diretiva include (linha 34) para referenciá-las. Ao contrário dos clientes HTTP/REST, não se espera que os aplicativos clientes gRPC processem uma grande variedade de códigos de status HTTP. A documentação do gRPC especifica como um proxy intermediário, como o NGINX, deve converter códigos de erro HTTP em códigos de status gRPC para que os clientes sempre recebam uma resposta adequada. Usamos a diretiva error_page para realizar esse mapeamento.

Carregando exemplo de código…

Cada um dos códigos de status HTTP padrão é encaminhado para um local nomeado usando o prefixo @ para que uma resposta compatível com gRPC possa ser gerada. Por exemplo, a resposta HTTP 404 é redirecionada internamente para o local @grpc_unimplemented, que é definido mais adiante no arquivo:

Carregando exemplo de código…

O local nomeado @grpc_unimplemented está disponível apenas para o processamento interno do NGINX – os clientes não podem solicitá-lo diretamente, pois não há um URI roteável. Nesse local, criamos uma resposta gRPC preenchendo os cabeçalhos gRPC obrigatórios e enviando-os, sem um corpo de resposta, usando o código de status HTTP 204 (Sem conteúdo).

Podemos usar o comando curl(1) para simular um cliente gRPC com comportamento inadequado solicitando um método gRPC inexistente. No entanto, vale observar que o curl geralmente não é adequado como cliente de teste gRPC, pois os buffers de protocolo usam um formato de dados binário. Para testar o gRPC na linha de comando, considere usar o 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

O arquivo grpc_errors.conf mencionado acima também contém mapeamentos de códigos de status HTTP para gRPC referentes a outras respostas de erro que o NGINX pode gerar, como tempos limite e erros de certificado do cliente.

Autenticando clientes com metadados do gRPC

Os metadados do gRPC permitem que os clientes enviem informações adicionais junto com as chamadas de métodos RPC, sem exigir que esses dados façam parte da especificação dos buffers de protocolo (arquivo .proto). Os metadados consistem em uma lista simples de pares de chave-valor, sendo cada par transmitido como um cabeçalho HTTP/2 separado. Portanto, os metadados são facilmente acessíveis ao NGINX.

Entre os muitos casos de uso de metadados, a autenticação de clientes é o mais comum em um gateway de API gRPC. O trecho de configuração a seguir mostra como o NGINX Plus pode usar metadados gRPC para realizar a autenticação JWT (a autenticação JWT é exclusiva do NGINX Plus). Neste exemplo, o JWT é enviado nos metadados auth-token.

Carregando exemplo de código…

Cada cabeçalho de solicitação HTTP fica disponível para o NGINX Plus como uma variável chamada $http_header. Os hifens (-) no nome do cabeçalho são convertidos em sublinhados ( _ ) no nome da variável, portanto, o JWT fica disponível como $http_auth_token (linha 2).

Se chaves de API forem usadas para autenticação, talvez com APIs HTTP/REST existentes, elas também poderão ser transportadas nos metadados do gRPC e validadas pelo NGINX. Uma configuração para autenticação por chave de API<.htmla> é fornecida na Parte 1 desta série de artigos.

Implementação de verificações de integridade

Ao balancear a carga do tráfego entre vários backends, é importante evitar o envio de solicitações a backends que estejam inativos ou indisponíveis por algum outro motivo. Com o NGINX Plus, podemos usar verificações ativas de integridade para enviar proativamente solicitações fora de banda aos backends e removê-los da rotação de balanceamento de carga quando eles não responderem às verificações de integridade conforme esperado. Dessa forma, garantimos que as solicitações dos clientes nunca cheguem a backends que estejam fora de serviço.

O trecho de configuração a seguir habilita verificações de integridade ativas para os serviços gRPC RouteGuide e helloworld. Para destacar a configuração relevante, ele omite algumas diretivas incluídas no arquivo grpc_gateway.conf usado nas seções anteriores.

Carregando exemplo de código…

Para cada rota, agora também especificamos a diretiva health_check (linhas 17 e 21). Conforme especificado pelo argumento type=grpc, o NGINX Plus usa o protocolo de verificação de integridade do gRPC para enviar uma verificação de integridade a cada servidor do grupo upstream. No entanto, nossos serviços gRPC simples não implementam o protocolo de verificação de integridade do gRPC, portanto, esperamos que eles respondam com o código de status que significa “não implementado” (grpc_status=12). Quando isso acontece, é suficiente para indicar que estamos nos comunicando com um serviço gRPC ativo.

Com essa configuração implementada, podemos desativar qualquer um dos contêineres de backend sem que os clientes gRPC enfrentem atrasos ou tempos limite. As verificações de integridade ativas são exclusivas do NGINX Plus; saiba mais sobre as verificações de integridade do gRPC em nosso blog.

Aplicação de limitação de taxa e outros controles de gateway de API

A configuração de exemplo em grpc_gateway.conf é adequada para uso em produção, com algumas pequenas modificações para TLS. A capacidade de rotear solicitações gRPC com base no pacote, serviço ou método RPC permite aplicar as funcionalidades existentes do NGINX ao tráfego gRPC exatamente da mesma forma que às APIs HTTP/REST ou ao tráfego web convencional. Em cada caso, o bloco location relevante pode ser ampliado com configurações adicionais, como limitação de taxa ou controle de largura de banda.

Resumo

Neste terceiro e último post da nossa série sobre a implantação do NGINX Open Source e do NGINX Plus como gateway de API, abordamos o gRPC como uma tecnologia nativa da nuvem para a criação de aplicações de microsserviços. Demonstramos como o NGINX é capaz de disponibilizar aplicações gRPC com a mesma eficiência que APIs HTTP/REST e como ambos os estilos de API podem ser publicados por meio do NGINX como um gateway de API multifuncional.

As instruções para configurar o ambiente de teste usado nesta publicação do blog estão no apêndice abaixo, e você pode baixar todos os arquivos do nosso repositório do GitHub Gist.

Confira os outros posts desta série:

• Parte 1 explica como configurar o NGINX em alguns casos de uso essenciais de gateway de API baseado em HTTP.
• Parte 2 explora casos de uso mais avançados para proteger os serviços de back-end contra clientes mal-intencionados ou com comportamento inadequado.

Para experimentar o NGINX Plus como gateway de API, inicie hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso. Durante o período de avaliação, use o conjunto completo de arquivos de configuração disponível em nosso repositório de Gists no GitHub.

Apêndice: Configuração do ambiente de teste

As instruções a seguir instalam o ambiente de teste em uma máquina virtual, para que ele fique isolado e possa ser reproduzido. No entanto, não há motivo para que ele não possa ser instalado em um servidor físico, do tipo “bare metal”.

Para simplificar o ambiente de teste, usamos contêineres Docker para executar os serviços gRPC. Isso significa que não precisamos de vários hosts para o ambiente de teste, mas ainda podemos fazer com que o NGINX estabeleça conexões por proxy por meio de uma chamada de rede, como em um ambiente de produção.

O uso do Docker também nos permite executar várias instâncias de cada serviço gRPC em portas diferentes sem exigir alterações no código. Cada serviço gRPC escuta na porta 50051 dentro do contêiner, que é mapeada para uma porta localhost exclusiva na máquina virtual. Isso, por sua vez, libera a porta 50051 para que o NGINX possa usá-la como porta de escuta. Portanto, quando os clientes de teste se conectam usando a porta 50051 pré-configurada, eles chegam ao NGINX.

Instalação do NGINX Open Source ou NGINX Plus

1. Instale o NGINX Open Source ou o NGINX Plus de acordo com as instruções do Guia de Administração do NGINX Plus.
2. Copie os seguintes arquivos do repositório GitHub Gist para /etc/nginx/conf.d: Observação: se não estiver usando TLS, comente as diretivas ssl_* em grpc_gateway.conf.
   • grpc_gateway.conf
   • errors.grpc_conf
3. Inicie o NGINX Open Source ou o NGINX Plus.

$ sudo nginx

Instalando o Docker

Para Debian e Ubuntu, execute:

$ sudo apt-get install docker.io

Para CentOS, RHEL e Oracle Linux, execute:

$ sudo yum install docker

Instalando os contêineres do serviço RouteGuide

1. Crie a imagem do Docker para os contêineres do RouteGuide usando o Dockerfile a seguir.

   Carregando exemplo de código…

   Você pode copiar o Dockerfile para um subdiretório local antes da criação ou especificar a URL do Gist do Dockerfile como argumento para o comando docker build:

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

1. Pode levar alguns minutos para baixar e criar a imagem. O aparecimento da mensagem Successfully built e de uma string hexadecimal (o ID da imagem) indica que a compilação foi concluída.
2. Confirme se a imagem foi criada executando 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. Inicie os contêineres do 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. À medida que cada comando é executado com sucesso, uma longa string hexadecimal é exibida, representando o contêiner em execução.
2. Verifique se os três contêineres estão em execução usando docker ps. (O exemplo de saída está dividido em várias linhas para facilitar a leitura.)

$ 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. A coluna PORTS na saída mostra como cada contêiner mapeou uma porta local diferente para a porta 50051 dentro do contêiner.

Instalando os contêineres do serviço helloworld

1. Crie a imagem do Docker para os contêineres helloworld usando o seguinte Dockerfile.

   Carregando exemplo de código…

   Você pode copiar o Dockerfile para um subdiretório local antes da criação ou especificar a URL do Gist do Dockerfile como argumento para o comando docker build:

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

1. Pode levar alguns minutos para baixar e criar a imagem. A exibição da mensagem Successfully built e de uma string hexadecimal (o ID da imagem) indica que a compilação foi concluída.
2. Confirme se a imagem foi criada executando 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. Inicie os contêineres helloworld.

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

1. À medida que cada comando é executado com sucesso, uma longa string hexadecimal é exibida, representando o contêiner em execução.
2. Verifique se os dois contêineres helloworld estão em execução executando 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

Instalando os aplicativos cliente gRPC

1. Instale os pré-requisitos da linguagem de programação, alguns dos quais talvez já estejam instalados no ambiente de teste. Observe que o python-pip requer que o repositório EPEL esteja habilitado (execute sudo yum install epel-release primeiro, se necessário).
   • Para Ubuntu e Debian, execute:

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

• Para CentOS, RHEL e Oracle Linux, execute:

$ sudo yum install golang python python-pip git

1. Baixe o aplicativo helloworld:

$ go get google.golang.org/grpc

1. Baixe o aplicativo RouteGuide:

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

Testando a configuração

1. Execute o cliente helloworld:

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

1. Execute o cliente RouteGuide:

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

1. Verifique os logs do NGINX para confirmar se o ambiente de teste está operacional:

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

Sobre o autor

Liam CrillyDiretor Sênior de Gestão de Produtos

Mais publicações de Liam Crilly