{"id":10209,"date":"2019-05-18T17:00:44","date_gmt":"2019-05-18T15:00:44","guid":{"rendered":"https:\/\/pi3g.com\/?p=10209"},"modified":"2019-05-18T17:00:44","modified_gmt":"2019-05-18T15:00:44","slug":"envoy-docker-and-websockets-debugging-and-configuration","status":"publish","type":"post","link":"https:\/\/pi3g.com\/de\/envoy-docker-and-websockets-debugging-and-configuration\/","title":{"rendered":"envoy, Docker und Websockets - Fehlersuche und Konfiguration"},"content":{"rendered":"

Websockets are an exciting technology, allowing you to upgrade a HTTP connection to a long-running persistent binary connection, which you can use to send bi-directional messages.<\/p>\n

As an aside, the MQTT protocol can be transported using websockets \u2013 which is the only (?) way for a JavaScript client delivered by the website, for instance.<\/p>\n

In any case, as websockets run on the same ports as the normal HTTP & HTTPS traffic (80 \/ 443), corporate networks are more likely to let them pass.<\/p>\n

Envoy and websockets<\/h1>\n

Envoy supports websockets. There are some gotchas:<\/p>\n

\n

Unable to parse JSON as proto (INVALID_ARGUMENT:(route_config.virtual_hosts[3].routes[0].route) use_websocket: Cannot find field<\/strong>.): <\/p>\n<\/blockquote>\n

Envoy used to support websockets with an old directive, \u201cuse_websocket\u201d. On a current envoy installation (e.g. I currently use envoy 1.10.0-dev for testing purposes) this directive is gone and it has been replaced.<\/p>\n

The idea is to have more generic upgrade requests \/ possibilities. <\/p>\n

The correct syntax is now using upgrade_configs<\/strong>. Have a look at my envoy.yaml:<\/p>\n

\n

static_resources:
   listeners:
   – address:
       socket_address:
         address: 0.0.0.0
         port_value: 80
     filter_chains:
     – filters:
       – name: envoy.http_connection_manager
         config:
           upgrade_configs:
             – upgrade_type: websocket<\/strong>
           codec_type: auto
           stat_prefix: ingress_http
           use_remote_address: true
           xff_num_trusted_hops: 0
           route_config:
             virtual_hosts:
             – name: debug
               domains: [“debug.local:80”]
               routes:
                 – match: { prefix: “\/” }
                   route:
                     cluster: target_dwebsocket
             – name: backend
               domains: [“morpheus.local”]
               routes:
               – match: { prefix: “\/” }
                 redirect:
                   path_redirect: “\/”
                   https_redirect: true<\/p>\n

(snip)<\/em><\/p>\n

– address:
     socket_address:
       address: 0.0.0.0
       port_value: 443
   filter_chains:
   – tls_context:
       common_tls_context:
         tls_certificates:
         – certificate_chain: { filename: “\/etc\/envoy\/example.crt” }
           private_key: { filename: “\/etc\/envoy\/example.key” }
         alpn_protocols: [ “h2,http\/1.1” ]
     filters:
     – name: envoy.http_connection_manager
       config:
         upgrade_configs:
           – upgrade_type: websocket
         stat_prefix: ingress_https
         use_remote_address: true
         xff_num_trusted_hops: 0
         route_config:
           virtual_hosts:
           – name: debug
             domains: [“debug.local:443”]
             routes:
               – match: { prefix: “\/” }
                 route:
                   cluster: target_dwebsocket<\/p>\n


\n(snip)<\/em><\/p>\n

clusters:
\n– name: target_dwebsocket
   connect_timeout: 0.25s
   type: strict_dns
   lb_policy: round_robin
   hosts:
   – socket_address:
       address: dwse
       port_value: 8080<\/p>\n<\/blockquote>\n

You can use this upgrade_configs directive in two places, according to the documentation. on http_connection_manager (as in my example above), and on individual routes.<\/p>\n

          upgrade_configs:
            – upgrade_type: websocket<\/p>\n

\nRoutes not matching<\/h2>\n

The other important thing to note, if you get \u201c404s\u201d ( error: Unexpected server response: 404 ): the :authority header will be, for some strange reason, set including the port \u2013 and will therefore not match if you supply just the domain.<\/p>\n

Look at this route:<\/p>\n

\n

[“debug.local:80”]<\/p>\n<\/blockquote>\n

The port is specified after the domain in this instance. In my tests \u2013 only if the port was specified, was I able to connect through envoy to the websocket server I have set up. This is a major stumbling block. <\/p>\n

Next up, I will discuss, how to debug envoy in cases like this.<\/p>\n

Debugging envoy, websockets, Docker:<\/h1>\n

Making envoy output verbose<\/h2>\n

Here\u2019s my docker-compose.yaml:<\/p>\n

\n

version: ‘3.7’<\/p>\n

services:
   envoy:
     build:
       context: .\/
       dockerfile: Dockerfile
     container_name: penvoyage-morpheus-envoy
     ports:
       – “80:80”
       – “443:443”
     volumes:
       – type: volume
         source: penvoyage_volume
         target: \/etc\/envoy
     networks:
       – envoy_net
     #user: “2000:2000”
     user: “root:root”
     restart: unless-stopped
     environment:
       loglevel: debug<\/strong><\/p>\n

volumes:
   penvoyage_volume:
     external:
       name: penvoyage_volume<\/p>\n

networks:
   envoy_net:
     external:
       name: my-bridge-network<\/p>\n<\/blockquote>\n

Note that an environment variable \u201cloglevel: debug\u201d is set. <\/p>\n

loglevel can be one of:<\/p>\n