External Routing (HTTP/TCP with TLS)

[charles-d-burton]

I can't find it in the documentation, but is it possible to have routing to an external service? Meaning I have appmesh in place and the container/microservice needs to connect to an externally managed service like gitlab? I added the URL as a backend to the virtual node but whenever it attempts to connect I get this error:

ENVOY LOG:
original_dst: New connection accepted
[2018-12-27 22:55:11.526][18][debug][filter] source/extensions/filters/listener/tls_inspector/tls_inspector.cc:73] tls inspector: new connection accepted
[2018-12-27 22:55:11.526][18][debug][filter] source/extensions/filters/listener/tls_inspector/tls_inspector.cc:126] tls:onServerName(), requestedServerName:
[2018-12-27 22:55:11.526][18][debug][main] source/server/connection_handler_impl.cc:193] closing connection: no matching filter chain found

POD LOG:
Error: initializing server: Get https://api/v4//version: read tcp 10.100.2.185:37252->:443: read: connection reset by peer

Connecting to this service works if I'm not using appmesh.

[bcelenza]

Hey @charles-d-burton, if you connect to your upstream gitlab with TLS, then at the moment we do not have the API support in place to enable this. If you're using plain HTTP, you can model this today by setting up a VirtualNode, VirtualRouter, and Route for the external service. We're looking for ways to simplify configuration for this, in addition to adding TLS support.

For example, if you had a gateway service similar to the one provided in the colorteller example, you could setup the appropriate resources by specifying the external service DNS name in backends as you have done, and then adding a VirtualNode, VirtualRouter, and Route that represents the desired DNS name. I have not tested this, but the following configuration should work:

VirtualNode for gateway service (amazon.com used an example external service):

{
    "meshName": "test-mesh",
    "spec": {
        "backends": [
            "amazon.com"
        ],
        "listeners": [
            {
                "portMapping": {
                    "port": 9080,
                    "protocol": "http"
                }
            }
        ],
        "serviceDiscovery": {
            "dns": {
                "serviceName": "gateway.local"
            }
        }
    },
    "virtualNodeName": "gateway"
}

VirtualNode for external service:

{
    "meshName": "test-mesh",
    "spec": {
        "listeners": [
            {
                "portMapping": {
                    "port": 80,
                    "protocol": "http"
                }
            }
        ],
        "serviceDiscovery": {
            "dns": {
                "serviceName": "amazon.com"
            }
        }
    },
    "virtualNodeName": "amazon"
}

VirtualRouter for amazon.com:

{
    "meshName": "test-mesh",
    "spec": {
        "serviceNames": [
            "amazon.com"
        ]
    },
    "virtualRouterName": "amazon"
}

Route for amazon.com:

{
    "meshName": "test-mesh",
    "routeName": "amazon",
    "spec": {
        "httpRoute": {
            "action": {
                "weightedTargets": [
                    {
                        "virtualNode": "amazon",
                        "weight": 100
                    }
                ]
            },
            "match": {
                "prefix": "/"
            }
        }
    },
    "virtualRouterName": "amazon"
}

Hopefully this works for you for now. Once TLS support is available, this will be simplified to just specifying the VirtualNode that represents the upstream service (with TCP and TLS options specified).

[charles-d-burton]

Gotcha, it's a TLS problem then because our service is TLS only.

[bcelenza]

Closing this in favor of #76 (egress traffic for external service) and #32, #33, #34 for TLS support. Please re-open this issue (or a new one) if you have any more questions.