-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
[feature] Add support (and documentation) for consul ingress gateways #8294
Comments
I made a proof of concept where I add the connect->sidecar_service to my nomad job's group->service definition.
Then following the tutorial here (https://learn.hashicorp.com/consul/developer-mesh/ingress-gateways) to create an ingress-gateway service and run A fair approach would be if there was a simple way to run the envoy ingress-gateway process as a job in Nomad (maybe there already is?). Then as long as nomad job group services have the sidecar_service enabled we could deploy the ingress-gateway using a nomad job separately, defining the port and listener etc. Another issue I encountered is that in our use case we want one ingress-gateway routing to multiple services which can only be achieved with HTTP, and the services created by Nomad jobs use TCP by default in Consul. I then used a service-defaults for each service to make it HTTP afterwards, which is a bit cumbersome but not a showstopper.
Definition of an ingress-gateway could then look like:
and run |
Here's a full group definition for something that works: group "web" {
network {
mode = "bridge"
port "http" { to = 80 }
}
service {
name = "web"
tags = ["http"]
port = "http"
connect {
sidecar_service {
proxy {
config {
protocol = "http"
}
local_service_port = 80
}
}
}
check {
type = "http"
path = "/"
interval = "10s"
timeout = "10s"
}
}
task "web" {
driver = "docker"
meta {
version = 49
}
config = {
image = "fill in the blanks"
}
}
} |
This PR adds initial support for running Consul Connect Ingress Gateways (CIGs) in Nomad. These gateways are declared as part of a task group level service definition within the connect stanza. ```hcl service { connect { gateway { proxy { // envoy proxy configuration } ingress { // ingress-gateway configuration entry } } } } ``` A gateway can be run in `bridge` or `host` networking mode, with the caveat that host networking necessitates manually specifying the Envoy admin listener (which cannot be disabled) via the service port value. Currently Envoy is the only supported gateway implementation in Consul, and Nomad only supports running Envoy as a gateway using the docker driver. Aims to address #8294 and tangentially #8647
This PR adds initial support for running Consul Connect Ingress Gateways (CIGs) in Nomad. These gateways are declared as part of a task group level service definition within the connect stanza. ```hcl service { connect { gateway { proxy { // envoy proxy configuration } ingress { // ingress-gateway configuration entry } } } } ``` A gateway can be run in `bridge` or `host` networking mode, with the caveat that host networking necessitates manually specifying the Envoy admin listener (which cannot be disabled) via the service port value. Currently Envoy is the only supported gateway implementation in Consul, and Nomad only supports running Envoy as a gateway using the docker driver. Aims to address #8294 and tangentially #8647
Support for ingress gateways was added in #8709 |
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues. |
It would be great (given the usage of consul & connect in nomad) to have first class support for ingress gateways (https://www.consul.io/docs/connect/ingress-gateway) in Nomad. For an outsider it kinda feels weird that all the examples (https://www.hashicorp.com/blog/ingress-gateways-in-hashicorp-consul-1-8/) are either bare-bones or kubernetes specific. You've got a great scheduler here, make use of it :)
The text was updated successfully, but these errors were encountered: