github.com/anth0d/nomad@v0.0.0-20221214183521-ae3a0a2cad06/website/content/docs/job-specification/gateway.mdx (about) 1 --- 2 layout: docs 3 page_title: gateway Stanza - Job Specification 4 description: |- 5 The "gateway" stanza allows specifying options for configuring Consul Gateways 6 used in the Consul Connect integration 7 --- 8 9 # `gateway` Stanza 10 11 <Placement groups={['job', 'group', 'service', 'connect', 'gateway']} /> 12 13 The `gateway` stanza allows configuration of [Consul Connect Gateways](https://developer.hashicorp.com/consul/docs/connect/gateways). Nomad will 14 automatically create the necessary Gateway [Configuration Entry](https://developer.hashicorp.com/consul/docs/agent/config-entries) 15 as well as inject an Envoy proxy task into the Nomad job to serve as the Gateway. 16 17 The `gateway` configuration is valid within the context of a `connect` stanza. 18 Additional information about Gateway configurations can be found in Consul's 19 [Connect Gateways](https://developer.hashicorp.com/consul/docs/connect/gateways) documentation. 20 21 ~> **Note:** [Ingress Gateways](https://developer.hashicorp.com/consul/docs/connect/gateways/ingress-gateway) 22 are generally intended for enabling access into a Consul service mesh from within the 23 same network. For public ingress products like [NGINX](https://learn.hashicorp.com/tutorials/nomad/load-balancing-nginx?in=nomad/load-balancing) 24 provide more suitable features. 25 26 ```hcl 27 service { 28 connect { 29 gateway { 30 # ... 31 } 32 } 33 } 34 ``` 35 36 ## `gateway` Parameters 37 38 Exactly one of `ingress`, `terminating`, or `mesh` must be configured. 39 40 - `proxy` <code>([proxy]: nil)</code> - Configuration of the Envoy proxy that will 41 be injected into the task group. 42 - `ingress` <code>([ingress]: nil)</code> - Configuration Entry of type `ingress-gateway` 43 that will be associated with the service. 44 - `terminating` <code>([terminating]: nil)</code> - Configuration Entry of type `terminating-gateway` 45 that will be associated with the service. 46 - `mesh` <code>([mesh]: nil)</code> - Indicates a mesh gateway will be associated 47 with the service. 48 49 ### `proxy` Parameters 50 51 - `connect_timeout` `(string: "5s")` - The amount of time to allow when making upstream 52 connections before timing out. Defaults to 5 seconds. If the upstream service has 53 the configuration option <code>[connect_timeout_ms]</code> set for the `service-resolver`, that 54 timeout value will take precedence over this gateway proxy option. 55 - `envoy_gateway_bind_tagged_addresses` `(bool: false)` - Indicates that the gateway 56 services tagged addresses should be bound to listeners in addition to the default 57 listener address. 58 - `envoy_gateway_bind_addresses` <code>(map<string|[address]>: nil)</code> - A map of additional addresses to be bound. 59 The keys to this map are the same of the listeners to be created and the values are 60 a map with two keys - address and port, that combined make the address to bind the 61 listener to. These are bound in addition to the default address. 62 If `bridge` networking is in use, this map is automatically populated with additional 63 listeners enabling the Envoy proxy to work from inside the network namespace. 64 65 ``` 66 envoy_gateway_bind_addresses "<service>" { 67 address = "0.0.0.0" 68 port = <port> 69 } 70 ``` 71 72 - `envoy_gateway_no_default_bind` `(bool: false)` - Prevents binding to the default 73 address of the gateway service. This should be used with one of the other options 74 to configure the gateway's bind addresses. If `bridge` networking is in use, this 75 value will default to `true` since the Envoy proxy does not need to bind to the 76 service address from inside the network namespace. 77 - `envoy_dns_discovery_type` `(string: optional)` - Determintes how Envoy will 78 resolve hostnames. Defaults to `LOGICAL_DNS`. Must be one of `STRICT_DNS` or 79 `LOGICAL_DNS`. Details for each type are available in the [Envoy Documentation](https://www.envoyproxy.io/docs/envoy/v1.16.1/intro/arch_overview/upstream/service_discovery). 80 This option applies to terminating gateways that route to services addressed by a 81 hostname. 82 - `config` `(map: nil)` - Escape hatch for [Advanced Configuration] of Envoy. 83 Keys and values support [runtime variable interpolation][interpolation]. 84 85 #### `address` Parameters 86 87 - `address` `(string: required)` - The address to bind to when combined with `port`. 88 - `port` `(int: required)` - The port to listen to. 89 90 ### `ingress` Parameters 91 92 - `tls` <code>([tls]: nil)</code> - TLS configuration for this gateway. 93 - `listener` <code>(array<[listener]> : required)</code> - One or more listeners that the 94 ingress gateway should setup, uniquely identified by their port number. 95 96 #### `tls` Parameters 97 98 - `enabled` `(bool: false)` - Set this configuration to enable TLS for every listener 99 on the gateway. If TLS is enabled, then each host defined in the `host` field will 100 be added as a DNSSAN to the gateway's x509 certificate. 101 102 - `tls_min_version` `(string: optional)` - Set the default minimum TLS version 103 supported by the gateway. Refer to 104 [`TLSMinVersion`](https://developer.hashicorp.com/consul/docs/connect/config-entries/ingress-gateway#tlsminversion) 105 in the Consul documentation for supported versions. 106 107 - `tls_max_version` `(string: optional)` - Set the default maximum TLS version 108 supported by the gateway. Refer to 109 [`TLSMaxVersion`](https://developer.hashicorp.com/consul/docs/connect/config-entries/ingress-gateway#tlsmaxversion) 110 in the Consul documentation for supported versions. 111 112 - `cipher_suites` `(array<string>: optional)` - Set the default list of TLS 113 cipher suites for the gateway's listeners. Refer to 114 [`CipherSuites`](https://developer.hashicorp.com/consul/docs/connect/config-entries/ingress-gateway#ciphersuites) 115 in the Consul documentation for the supported cipher suites. 116 117 #### `listener` Parameters 118 119 - `port` `(int: required)` - The port that the listener should receive traffic on. 120 - `protocol` `(string: "tcp")` - The protocol associated with the listener. One 121 of `tcp`, `http`, `http2`, or `grpc`. 122 123 ~> **Note:** If using any protocol other than `tcp` (for example: `http` or `grpc`), preconfiguring a [service-default] in Consul to 124 set the [Protocol](https://developer.hashicorp.com/consul/docs/connect/config-entries/service-defaults#protocol) 125 of the service to the desired protocol is mandatory due to an [open issue](https://github.com/hashicorp/nomad/issues/8647). 126 127 - `service` <code>(array<[service]>: required)</code> - One or more services to be 128 exposed via this listener. For `tcp` listeners, only a single service is allowed. 129 130 #### `service` Parameters 131 132 - `name` `(string: required)` - The name of the service that should be exposed through 133 this listener. This can be either a service registered in the catalog, or a 134 service defined by other config entries, or a service that is going to be configured 135 by Nomad. If the wildcard specifier `*` is provided, then ALL services will be 136 exposed through this listener. This is not supported for a listener with protocol `tcp`. 137 - `hosts` `(array<string>: nil)` - A list of hosts that specify what requests will 138 match this service. This cannot be used with a `tcp` listener, and cannot be 139 specified alongside a wildcard (`*`) service name. If not specified, the default 140 domain `<service-name>.ingress.*` will be used to match services. Requests _must_ 141 send the correct host to be routed to the defined service. 142 143 The wildcard specifier `*` can be used by itself to match all traffic coming to 144 the ingress gateway, if TLS is not enabled. This allows a user to route all traffic 145 to a single service without specifying a host, allowing simpler tests and demos. 146 Otherwise, the wildcard specifier can be used as part of the host to match 147 multiple hosts, but only in the leftmost DNS label. This ensures that all defined 148 hosts are valid DNS records. For example, `*.example.com` is valid while `example.*` 149 and `*-suffix.example.com` are not. 150 151 ### `terminating` Parameters 152 153 - `service` <code>(array<[linked-service]>: required)</code> - One or more services to be 154 linked with the gateway. The gateway will proxy traffic to these services. These 155 linked services must be registered with Consul for the gateway to discover their 156 addresses. They must also be registered in the same Consul datacenter as the 157 terminating gateway. 158 159 #### `service` Parameters 160 161 - `name` `(string: required)` - The name of the service to link with the gateway. 162 If the wildcard specifier `*` is provided, then ALL services within the Consul 163 namespace wil lbe linked with the gateway. 164 165 - `ca_file` `(string: <optional>)` - A file path to a PEM-encoded certificate 166 authority. The file must be accessible by the gateway task. The certificate authority 167 is used to verify the authenticity of the service linked with the gateway. It 168 can be provided along with a `cert_file` and `key_file` for mutual TLS 169 authentication, or on its own for one-way TLS authentication. If none is provided 170 the gateway **will not** encrypt traffic to the destination. 171 - `cert_file` `(string: <optional>)` - A file path to a PEM-encoded certificate. 172 The file must be accessible by the gateway task. The certificate is provided to servers 173 to verify the gateway's authenticity. It must be provided if a `key_file` is provided. 174 - `key_file` `(string: <optional>)` - A file path to a PEM-encoded private key. 175 The file must be accessible by the gateway task. The key is used with the certificate 176 to verify the gateway's authenticity. It must be provided if a `cert_file` is provided. 177 - `sni` `(string: <optional>)` - An optional hostname or domain name to specify during 178 the TLS handshake. 179 180 ### `mesh` Parameters 181 182 The `mesh` block currently does not have any configurable parameters. 183 184 ~> **Note:** If using the Mesh Gateway for [WAN Federation][connect_mesh_gw], 185 the additional piece of service metadata `{"consul-wan-federation":"1"}` must 186 be applied. This can be done with the service [`meta`][meta] parameter. 187 188 ### Gateway with host networking 189 190 Nomad supports running gateways using host networking. A static port must be allocated 191 for use by the [Envoy admin interface](https://www.envoyproxy.io/docs/envoy/latest/operations/admin) 192 and assigned to the proxy service definition. 193 194 !> **Warning:** There is no way to disable the Envoy admin interface, which will be 195 accessible to any workload running on the same Nomad client. The admin interface exposes 196 information about the proxy, including a Consul Service Identity token if Consul ACLs 197 are enabled. 198 199 ### Specify Envoy image 200 201 The Docker image used for Connect gateway tasks defaults to the official [Envoy 202 Docker] image, `envoyproxy/envoy:v${NOMAD_envoy_version}`, where `${NOMAD_envoy_version}` 203 is resolved automatically by a query to Consul. The image to use can be configured 204 by setting `meta.connect.gateway_image` in the Nomad job. Custom images can still 205 make use of the envoy version interpolation, e.g. 206 207 ```hcl 208 meta.connect.gateway_image = custom/envoy-${NOMAD_envoy_version}:latest 209 ``` 210 211 ### Custom gateway task 212 213 The task created for the gateway can be configured manually using the 214 [`sidecar_task`][sidecar_task] stanza. 215 216 ``` 217 connect { 218 gateway { 219 # ... 220 } 221 222 sidecar_task { 223 # see /docs/job-specification/sidecar_task for more details 224 } 225 } 226 ``` 227 228 ### Examples 229 230 #### ingress gateway 231 232 ```hcl 233 job "ingress-demo" { 234 235 datacenters = ["dc1"] 236 237 # This group will have a task providing the ingress gateway automatically 238 # created by Nomad. The ingress gateway is based on the Envoy proxy being 239 # managed by the docker driver. 240 group "ingress-group" { 241 242 network { 243 mode = "bridge" 244 245 # This example will enable plain HTTP traffic to access the uuid-api connect 246 # native example service on port 8080. 247 port "inbound" { 248 static = 8080 249 to = 8080 250 } 251 } 252 253 service { 254 name = "my-ingress-service" 255 port = "8080" 256 257 connect { 258 gateway { 259 260 # Consul gateway [envoy] proxy options. 261 proxy { 262 # The following options are automatically set by Nomad if not 263 # explicitly configured when using bridge networking. 264 # 265 # envoy_gateway_no_default_bind = true 266 # envoy_gateway_bind_addresses "uuid-api" { 267 # address = "0.0.0.0" 268 # port = <associated listener.port> 269 # } 270 # 271 # Additional options are documented at 272 # https://www.nomadproject.io/docs/job-specification/gateway#proxy-parameters 273 } 274 275 # Consul Ingress Gateway Configuration Entry. 276 ingress { 277 # Nomad will automatically manage the Configuration Entry in Consul 278 # given the parameters in the ingress block. 279 # 280 # Additional options are documented at 281 # https://www.nomadproject.io/docs/job-specification/gateway#ingress-parameters 282 listener { 283 port = 8080 284 protocol = "tcp" 285 service { 286 name = "uuid-api" 287 } 288 } 289 } 290 } 291 } 292 } 293 } 294 295 # The UUID generator from the connect-native demo is used as an example service. 296 # The ingress gateway above makes access to the service possible over normal HTTP. 297 # For example, 298 # 299 # $ curl $(dig +short @127.0.0.1 -p 8600 uuid-api.ingress.dc1.consul. ANY):8080 300 group "generator" { 301 network { 302 mode = "host" 303 port "api" {} 304 } 305 306 service { 307 name = "uuid-api" 308 port = "api" 309 310 connect { 311 native = true 312 } 313 } 314 315 task "generate" { 316 driver = "docker" 317 318 config { 319 image = "hashicorpdev/uuid-api:v5" 320 network_mode = "host" 321 } 322 323 env { 324 BIND = "0.0.0.0" 325 PORT = "${NOMAD_PORT_api}" 326 } 327 } 328 } 329 } 330 ``` 331 332 #### terminating gateway 333 334 ```hcl 335 job "countdash-terminating" { 336 337 datacenters = ["dc1"] 338 339 # This group provides the service that exists outside of the Consul Connect 340 # service mesh. It is using host networking and listening to a statically 341 # allocated port. 342 group "api" { 343 network { 344 mode = "host" 345 port "port" { 346 static = "9001" 347 } 348 } 349 350 # This example will enable services in the service mesh to make requests 351 # to this service which is not in the service mesh by making requests 352 # through the terminating gateway. 353 service { 354 name = "count-api" 355 port = "port" 356 } 357 358 task "api" { 359 driver = "docker" 360 361 config { 362 image = "hashicorpdev/counter-api:v3" 363 network_mode = "host" 364 } 365 } 366 } 367 368 group "gateway" { 369 network { 370 mode = "bridge" 371 } 372 373 service { 374 name = "api-gateway" 375 376 connect { 377 gateway { 378 # Consul gateway [envoy] proxy options. 379 proxy { 380 # The following options are automatically set by Nomad if not explicitly 381 # configured with using bridge networking. 382 # 383 # envoy_gateway_no_default_bind = true 384 # envoy_gateway_bind_addresses "default" { 385 # address = "0.0.0.0" 386 # port = <generated listener port> 387 # } 388 # Additional options are documented at 389 # https://www.nomadproject.io/docs/job-specification/gateway#proxy-parameters 390 } 391 392 # Consul Terminating Gateway Configuration Entry. 393 terminating { 394 # Nomad will automatically manage the Configuration Entry in Consul 395 # given the parameters in the terminating block. 396 # 397 # Additional options are documented at 398 # https://www.nomadproject.io/docs/job-specification/gateway#terminating-parameters 399 service { 400 name = "count-api" 401 } 402 } 403 } 404 } 405 } 406 } 407 408 # The dashboard service is in the service mesh, making use of bridge network 409 # mode and connect.sidecar_service. When running, the dashboard should be 410 # available from a web browser at localhost:9002. 411 group "dashboard" { 412 network { 413 mode = "bridge" 414 415 port "http" { 416 static = 9002 417 to = 9002 418 } 419 } 420 421 service { 422 name = "count-dashboard" 423 port = "9002" 424 425 connect { 426 sidecar_service { 427 proxy { 428 upstreams { 429 # By configuring an upstream destination to the linked service of 430 # the terminating gateway, the dashboard is able to make requests 431 # through the gateway to the count-api service. 432 destination_name = "count-api" 433 local_bind_port = 8080 434 } 435 } 436 } 437 } 438 } 439 440 task "dashboard" { 441 driver = "docker" 442 443 env { 444 COUNTING_SERVICE_URL = "http://${NOMAD_UPSTREAM_ADDR_count_api}" 445 } 446 447 config { 448 image = "hashicorpdev/counter-dashboard:v3" 449 } 450 } 451 } 452 } 453 ``` 454 455 #### mesh gateway 456 457 Mesh gateways are useful when Connect services need to make cross-datacenter 458 requests where not all nodes in each datacenter have full connectivity. This example 459 demonstrates using mesh gateways to enable making requests between datacenters 460 `one` and `two`, where each mesh gateway will bind to the `public` host network 461 configured on at least one Nomad client in each datacenter. 462 463 Job running where Nomad and Consul are in datacenter `one`. 464 465 ```hcl 466 job "countdash-mesh-one" { 467 datacenters = ["one"] 468 469 group "mesh-gateway-one" { 470 network { 471 mode = "bridge" 472 473 # A mesh gateway will require a host_network configured on at least one 474 # Nomad client that can establish cross-datacenter connections. Nomad will 475 # automatically schedule the mesh gateway task on compatible Nomad clients. 476 port "mesh_wan" { 477 host_network = "public" 478 } 479 } 480 481 service { 482 name = "mesh-gateway" 483 484 # The mesh gateway connect service should be configured to use a port from 485 # the host_network capable of cross-datacenter connections. 486 port = "mesh_wan" 487 488 connect { 489 gateway { 490 mesh { 491 # No configuration options in the mesh block. 492 } 493 494 # Consul gateway [envoy] proxy options. 495 proxy { 496 # The following options are automatically set by Nomad if not explicitly 497 # configured with using bridge networking. 498 # 499 # envoy_gateway_no_default_bind = true 500 # envoy_gateway_bind_addresses "lan" { 501 # address = "0.0.0.0" 502 # port = <generated dynamic port> 503 # } 504 # envoy_gateway_bind_addresses "wan" { 505 # address = "0.0.0.0" 506 # port = <configured service port> 507 # } 508 # Additional options are documented at 509 # https://www.nomadproject.io/docs/job-specification/gateway#proxy-parameters 510 } 511 } 512 } 513 } 514 } 515 516 group "dashboard" { 517 network { 518 mode = "bridge" 519 520 port "http" { 521 static = 9002 522 to = 9002 523 } 524 } 525 526 service { 527 name = "count-dashboard" 528 port = "9002" 529 530 connect { 531 sidecar_service { 532 proxy { 533 upstreams { 534 destination_name = "count-api" 535 local_bind_port = 8080 536 537 # This dashboard service is running in datacenter "one", and will 538 # make requests to the "count-api" service running in datacenter 539 # "two", by going through the mesh gateway in each datacenter. 540 datacenter = "two" 541 542 mesh_gateway { 543 # Using "local" mode indicates requests should exit this datacenter 544 # through the mesh gateway, and enter the destination datacenter 545 # through a mesh gateway in that datacenter. 546 # Using "remote" mode indicates requests should bypass the local 547 # mesh gateway, instead directly connecting to the mesh gateway 548 # in the destination datacenter. 549 mode = "local" 550 } 551 } 552 } 553 } 554 } 555 } 556 557 task "dashboard" { 558 driver = "docker" 559 560 env { 561 COUNTING_SERVICE_URL = "http://${NOMAD_UPSTREAM_ADDR_count_api}" 562 } 563 564 config { 565 image = "hashicorpdev/counter-dashboard:v3" 566 } 567 } 568 } 569 } 570 ``` 571 572 Job running where Nomad and Consul are in datacenter `two`. 573 574 ```hcl 575 job "countdash-mesh-two" { 576 datacenters = ["two"] 577 578 group "mesh-gateway-two" { 579 network { 580 mode = "bridge" 581 582 # A mesh gateway will require a host_network configured for at least one 583 # Nomad client that can establish cross-datacenter connections. Nomad will 584 # automatically schedule the mesh gateway task on compatible Nomad clients. 585 port "mesh_wan" { 586 host_network = "public" 587 } 588 } 589 590 service { 591 name = "mesh-gateway" 592 593 # The mesh gateway connect service should be configured to use a port from 594 # the host_network capable of cross-datacenter connections. 595 port = "mesh_wan" 596 597 connect { 598 gateway { 599 mesh { 600 # No configuration options in the mesh block. 601 } 602 603 # Consul gateway [envoy] proxy options. 604 proxy { 605 # The following options are automatically set by Nomad if not explicitly 606 # configured with using bridge networking. 607 # 608 # envoy_gateway_no_default_bind = true 609 # envoy_gateway_bind_addresses "lan" { 610 # address = "0.0.0.0" 611 # port = <generated dynamic port> 612 # } 613 # envoy_gateway_bind_addresses "wan" { 614 # address = "0.0.0.0" 615 # port = <configured service port> 616 # } 617 # Additional options are documented at 618 # https://www.nomadproject.io/docs/job-specification/gateway#proxy-parameters 619 } 620 } 621 } 622 } 623 } 624 625 group "api" { 626 network { 627 mode = "bridge" 628 } 629 630 service { 631 name = "count-api" 632 port = "9001" 633 connect { 634 sidecar_service {} 635 } 636 } 637 638 task "api" { 639 driver = "docker" 640 641 config { 642 image = "hashicorpdev/counter-api:v3" 643 } 644 } 645 } 646 } 647 ``` 648 649 650 [address]: /docs/job-specification/gateway#address-parameters 651 [advanced configuration]: https://developer.hashicorp.com/consul/docs/connect/proxies/envoy#advanced-configuration 652 [connect_timeout_ms]: https://developer.hashicorp.com/consul/docs/connect/config-entries/service-resolver#connecttimeout 653 [connect_mesh_gw]: https://developer.hashicorp.com/consul/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways#mesh-gateways 654 [envoy docker]: https://hub.docker.com/r/envoyproxy/envoy/tags 655 [ingress]: /docs/job-specification/gateway#ingress-parameters 656 [proxy]: /docs/job-specification/gateway#proxy-parameters 657 [linked-service]: /docs/job-specification/gateway#service-parameters-1 658 [listener]: /docs/job-specification/gateway#listener-parameters 659 [interpolation]: /docs/runtime/interpolation 660 [service]: /docs/job-specification/gateway#service-parameters 661 [service-default]: https://developer.hashicorp.com/consul/docs/connect/config-entries/service-defaults 662 [sidecar_task]: /docs/job-specification/sidecar_task 663 [terminating]: /docs/job-specification/gateway#terminating-parameters 664 [tls]: /docs/job-specification/gateway#tls-parameters 665 [mesh]: /docs/job-specification/gateway#mesh-parameters 666 [meta]: /docs/job-specification/service#meta