8b05efcf88
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
2.1 KiB
2.1 KiB
New jobspec
Entry Checklist
Code
- Consider similar features in Consul, Kubernetes, and other tools. Is there prior art we should match? Terminology, structure, etc?
- Add structs/fields to
api/
packageapi/
structs usually have Canonicalize and Copy methods- New fields should be added to existing Canonicalize, Copy methods
- Test the structs/fields via methods mentioned above
- Add structs/fields to
nomad/structs
packagestructs/
structs usually have Copy, Equals, and Validate methods- Validation happens in this package and must be implemented
- Note that analogous struct field names should match with
api/
package - Test the structs/fields via methods mentioned above
- Implement and test other logical methods
- Add conversion between
api/
andnomad/structs
incommand/agent/job_endpoint.go
- Add test for conversion
- Implement diff logic for new structs/fields in
nomad/structs/diff.go
- Note that fields must be listed in alphabetical order in
FieldDiff
slices innomad/structs/diff_test.go
- Add test for diff of new structs/fields
- Note that fields must be listed in alphabetical order in
- Add change detection for new structs/feilds in
scheduler/util.go/tasksUpdated
- Might be covered by
.Equals
but might not be, check. - Should return true if the task must be replaced as a result of the change.
- Might be covered by
HCL1 (deprecated)
New jobspec entries should only be added to jobspec2
. It makes use of HCL2
and the api
package for automatic parsing. Before, additional parsing was
required in the original jobspec
package.
Parse in(HCL1 only)jobspec/parse.go
Test in(HCL1 only)jobspec/parse_test.go
(preferably with ajobspec/text-fixtures/<feature>.hcl
test file)
Docs
- Changelog
- Jobspec entry https://www.nomadproject.io/docs/job-specification/index.html
- Jobspec sidebar entry https://github.com/hashicorp/nomad/blob/master/website/source/layouts/docs.erb
- Job JSON API entry https://www.nomadproject.io/api/json-jobs.html
- Sample Response output in API https://www.nomadproject.io/api/jobs.html
- Consider if it needs a guide https://www.nomadproject.io/guides/index.html