-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consul/connect: Add support for Connect terminating gateways #9829
Conversation
c22ab5a
to
36b0969
Compare
36b0969
to
04bf502
Compare
return c.setCE(ctx, convertTerminatingCE(service, entry)) | ||
} | ||
|
||
// also mesh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// also mesh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great @shoenig! A heck of a lot of work to plumb this all in!
I've left a few comments and questions, but nothing that should be blocking.
@@ -2,21 +2,25 @@ | |||
|
|||
## Code |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for bringing this up-to-date!
nomad/job_endpoint.go
Outdated
return err | ||
} | ||
} | ||
for service, entry := range entries.Terminating { | ||
fmt.Println("SH JE set terminating CE", service) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we missed a leftover debug message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
// networking is being used the network_mode driver configuration is set here. | ||
func connectGatewayDriverConfig(hostNetwork bool) map[string]interface{} { | ||
m := map[string]interface{}{ | ||
"image": envoy.GatewayConfigVar, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like the only value besides the network mode that's different between the gateway task config and the sidecar task config... but the docs suggest that the same sidecar_task {}
block is used for either. So I can't figure out where this value is coming from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The config var variables represent meta.sidecar_image
and meta.gateway_image
for when configuring a sidecar or gateway image through client configuration (leaving room for them to be different). When setting the task in jobspec, sidecar_task
serves double duty since only 1 of sidecar_service
or gateway
can be configured per connect block. In retrospect, sidecar_task
would have been better named connect_task
or similar . (The other alternative would be duplicating the sidecar_task
plumbing just to have another field named gateway_task
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aye, that all makes sense. It's probably worth spelling some of these details out in the documentation before we ship, just so that the relationship between those configuration values is super-clear.
63eb6e7
to
6730de3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good and I especially like the code cleanup/tidiness done throughout.
One general question I had that shouldn't hold up this PR is if we could show an example of integrating with vault's pki backend to pull the ca and maybe the cert and key too for mutual tls. Maybe thats better saved for a learn guide though. Thoughts?
This PR implements Nomad built-in support for running Consul Connect terminating gateways. Such a gateway can be used by services running inside the service mesh to access "legacy" services running outside the service mesh while still making use of Consul's service identity based networking and ACL policies. https://www.consul.io/docs/connect/gateways/terminating-gateway These gateways are declared as part of a task group level service definition within the connect stanza. service { connect { gateway { proxy { // envoy proxy configuration } terminating { // terminating-gateway configuration entry } } } } Currently Envoy is the only supported gateway implementation in Consul. The gateay task can be customized by configuring the connect.sidecar_task block. When the gateway.terminating field is set, Nomad will write/update the Configuration Entry into Consul on job submission. Because CEs are global in scope and there may be more than one Nomad cluster communicating with Consul, there is an assumption that any terminating gateway defined in Nomad for a particular service will be the same among Nomad clusters. Gateways require Consul 1.8.0+, checked by a node constraint. Closes #9445
This parameter is now supposed to be non-nil even if empty, and the Copy method should also maintain that invariant.
10a1eb2
to
74780f0
Compare
Yeah @nickethier we definitely need learn guides around this and also ingress gateways. It's on my list to get some first drafts written around 1.1 |
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
This PR implements Nomad built-in support for running Consul Connect
terminating gateways. Such a gateway can be used by services running
inside the service mesh to access "legacy" services outside the mesh
while still making use of Consul's service identity based networking and
ACL policies.
https://www.consul.io/docs/connect/gateways/terminating-gateway
These gateways are declared as part of a task group level service
definition within the connect stanza.
Currently Envoy is the only supported gateway implementation in
Consul. The gateway task can be customized by configuring the
connect.sidecar_task
block ormeta.connect.gateway_image
client attribute.
When the gateway.terminating field is set, Nomad will write/update
the Configuration Entry into Consul on job submission. Because CEs
are global in scope and there may be more than one Nomad cluster
communicating with Consul, there is an assumption that any terminating
gateway defined in Nomad for a particular service will be the same
among Nomad clusters.
Gateways require Consul 1.8.0+, checked by a node constraint.
Closes #9445