Support connect sidecar without a network port

[Gufran]

Feature Description

Please support Connect sidecar proxy that does not require the service to expose a network port. Right now Connect registers a healthcheck in consul that will fail if the service is not reachable by the sidecar, this causes problems for a service that only exists for background tasks and does not offer functionality over the network.

Use Case(s)

Background workers, cron and services with similar nature where it is still necessary for the service to communicate with other connect enabled services but it does not expect inbound network connection.

[david-yu]

Hi @Gufran thanks for the feedback. We have seen issues in the past where folks have requested to service to service Ingress communication paths. This functionality is something we are targeting for our Consul 1.8 beta coming later this month. Would you be willing try out our beta and let us know what you think?

[Gufran]

@david-yu I can try the beta but we're deploying with Nomad, and unless Nomad also support this functionality I don't think it will be possible for me to properly test it.

[ghost]

@david-yu I'm happy to try this beta feature. This would be useful on my Traefik reverse-proxy so it can route internet traffic to my Connect-enabled services.

[Gufran]

I see v1.8.0 has been tagged but I can't find any mention of this feature in changelog or documentation. Is it available in this release? If yes then can you please point me to the documentation or pull-request that can give me an idea how to proceed with testing here?

[tjhiggins]

@david-yu I have the same use-case as ghost and would be interested in a beta. Any updates on when this might get released?

[blake]

Hi @Gufran, by default Consul registers two checks for the sidecar proxy. One is a TCP check for the proxy itself, and the other is an alias check on the parent service (https://www.consul.io/docs/connect/registration/sidecar-service#check).

I registered a sample service using the following definition, and both checks were immediately set to passing. I did not see any failures for this service, even though it does not have a downstream port. I assume this service would be able to reach upstream services, should any be configured.

service {
  name = "web"
  connect {
      sidecar_service {}
  }
}

Perhaps I'm not understanding something from your original description. Would you mind providing a little more detail on the issue you're seeing? Thanks.

[EtienneBruines]

Can this be done though, without listening on a public address for this service?

root@s3-backup:/etc/consul.d# netstat -tupln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1497287/envoy       
tcp        0      0 172.16.17.51:8301       0.0.0.0:*               LISTEN      1496435/consul      
tcp        0      0 127.0.0.1:8500          0.0.0.0:*               LISTEN      1496435/consul      
tcp        0      0 127.0.0.1:8502          0.0.0.0:*               LISTEN      1496435/consul      
tcp        0      0 127.0.0.1:19000         0.0.0.0:*               LISTEN      1497287/envoy       
tcp        0      0 127.0.0.1:8600          0.0.0.0:*               LISTEN      1496435/consul      
tcp        0      0 0.0.0.0:21000           0.0.0.0:*               LISTEN      1497287/envoy       

Since Envoy does not have a local port / socket, why would it need to listen on 0.0.0.0:21000? Without knowing what exactly it does (or potentially opens up), I'd much rather have it listen on 127.0.0.1:21000 instead? This would still make health-checks possible (and thus knowing if the sidecar is active).

Envoy seems to get its settings from public_listener:0.0.0.0:21000 from the service sidecar definition.

@blake Would it make sense / be possible to limit the listener to a loopback address, when no downstream port / socket is defined? It wouldn't be getting any other service that connects to it, since it has nothing to offer. It would only be there to provide access to upstream services.

[shanliu]

d much rather have it listen on 127.0.0.1:21000 instead? This would still make health-checks possible (and thus knowing if the sidecar is active).

how did you solve this problem? @Gufran