Конечная точка службы gRP C недоступна через Kong Gateway - PullRequest
0 голосов
/ 02 мая 2020
Сервисы

gRP C (разработанные в springboot) развернуты как контейнер docker в AWS linux (ec2). Запустил образ docker с переадресацией портов -p6565: 6565. Теперь при прямом попадании через BloomRP C на ноутбук это сработало: ec2.IP: 6565 Package.Service.Method

Настроенный сервис и маршрут в Конге:

{
            "host": "ec2.IP",
            "created_at": 1588403433,
            "connect_timeout": 60000,
            "id": "e657d8df-6247-458a-a8e8-bec00c41e03c",
            "protocol": "grpc",
            "name": "aws-grpc1",
            "read_timeout": 60000,
            "port": 6565,
            "path": null,
            "updated_at": 1588403433,
            "retries": 5,
            "write_timeout": 60000,
            "tags": null,
            "client_certificate": null
}

Route:
{
            "strip_path": false,
            "path_handling": "v0",
            "updated_at": 1588403452,
            "destinations": null,
            "headers": null,
            "protocols": [
                "grpc",
                "grpcs"
            ],
            "created_at": 1588403452,
            "snis": null,
            "service": {
                "id": "e657d8df-6247-458a-a8e8-bec00c41e03c"
            },
            "name": "aws-grpc1-route1",
            "methods": null,
            "preserve_host": false,
            "regex_priority": 0,
            "paths": [
                "/grpc2"
            ],
            "sources": null,
            "id": "5739297e-3be7-4a0d-8afb-cfa8ed01cec2",
            "https_redirect_status_code": 426,
            "hosts": null,
            "tags": null
        }

Теперь ударил его через grpcurl -> он не работает:

grpcurl -v -d "{}" -insecure ec2.ip:8443 package.service.pingMethod

Error invoking method "package.service.ping": target server does not expose service "package.service"

Вот конг конфигурации, которая выглядит связанной:

"proxy_listen": [
            "0.0.0.0:8000 reuseport backlog=16384",
            "0.0.0.0:8443 **http2** ssl reuseport backlog=16384"
        ],

Итак, вот запросы: (1) 8000 также может быть настроен для https как небезопасно -> через передачу переменной env KONG_PROXY_LISTEN во время запуска контейнера kong на

    -e "KONG_PROXY_LISTEN=0.0.0.0:8000 http2, 0.0.0.0:8443 http2 ssl" 

Это хорошо делать?

(2) Как включить отражение на стороне сервера? ИЛИ что использовать /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo?

1 Ответ

0 голосов
/ 02 мая 2020

Дополнительные обновления:

gRP C развернуто за kong.ingress работает нормально:

grpcurl -v -d "{\"greeting\":\"111\"}" -insecure acfb0xxxxx.elb.us-east-2.amazonaws.com:443 hello.HelloService.SayHello

Ответ:

Resolved method descriptor:
rpc SayHello ( .hello.HelloRequest ) returns ( .hello.HelloResponse );

Request metadata to send:
(empty)

Response headers received:
content-type: application/grpc
date: Sat, 02 May 2020 07:00:17 GMT
server: openresty
trailer: Grpc-Status
trailer: Grpc-Message
trailer: Grpc-Status-Details-Bin
via: kong/2.0.3
x-kong-proxy-latency: 1
x-kong-upstream-latency: 9

Response contents:
{
  "reply": "hello 111"
}

Response trailers received:
(empty)
Sent 1 request and received 1 response

при настройке на kong- API-шлюз, он не работает:

grpcurl -v -d "{\"greeting\":\"111\"}" -insecure kong.ce-gateway.ip:8443 hello.HelloService.SayHello
Error invoking method "hello.HelloService.SayHello": failed to query for service descriptor "hello.HelloService": rpc error: code = Internal desc = An invalid response was received from the upstream server
...