3804677570
Starting from and extending the mechanism introduced in #12110 we can specially handle the 3 main special Consul RPC endpoints that react to many config entries in a single blocking query in Connect: - `DiscoveryChain.Get` - `ConfigEntry.ResolveServiceConfig` - `Intentions.Match` All of these will internally watch for many config entries, and at least one of those will likely be not found in any given query. Because these are blends of multiple reads the exact solution from #12110 isn't perfectly aligned, but we can tweak the approach slightly and regain the utility of that mechanism. ### No Config Entries Found In this case, despite looking for many config entries none may be found at all. Unlike #12110 in this scenario we do not return an empty reply to the caller, but instead synthesize a struct from default values to return. This can be handled nearly identically to #12110 with the first 1-2 replies being non-empty payloads followed by the standard spurious wakeup suppression mechanism from #12110. ### No Change Since Last Wakeup Once a blocking query loop on the server has completed and slept at least once, there is a further optimization we can make here to detect if any of the config entries that were present at specific versions for the prior execution of the loop are identical for the loop we just woke up for. In that scenario we can return a slightly different internal sentinel error and basically externally handle it similar to #12110. This would mean that even if 20 discovery chain read RPC handling goroutines wakeup due to the creation of an unrelated config entry, the only ones that will terminate and reply with a blob of data are those that genuinely have new data to report. ### Extra Endpoints Since this pattern is pretty reusable, other key config-entry-adjacent endpoints used by `agent/proxycfg` also were updated: - `ConfigEntry.List` - `Internal.IntentionUpstreams` (tproxy) |
||
|---|---|---|
| .changelog | ||
| .circleci | ||
| .github | ||
| .release | ||
| acl | ||
| agent | ||
| api | ||
| bench | ||
| build-support | ||
| command | ||
| connect | ||
| contributing | ||
| docs | ||
| grafana | ||
| internal | ||
| ipaddr | ||
| lib | ||
| logging | ||
| proto | ||
| sdk | ||
| sentinel | ||
| service_os | ||
| snapshot | ||
| terraform | ||
| test | ||
| testrpc | ||
| tlsutil | ||
| types | ||
| ui | ||
| version | ||
| website | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yml | ||
| CHANGELOG.md | ||
| Dockerfile | ||
| GNUmakefile | ||
| INTERNALS.md | ||
| LICENSE | ||
| NOTICE.md | ||
| README.md | ||
| Vagrantfile | ||
| codecov.yml | ||
| go.mod | ||
| go.sum | ||
| main.go | ||
| main_test.go | ||
| package-lock.json | ||
README.md
Consul
Consul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.
- Website: https://www.consul.io
- Tutorials: HashiCorp Learn
- Forum: Discuss
Consul provides several key features:
-
Multi-Datacenter - Consul is built to be datacenter aware, and can support any number of regions without complex configuration.
-
Service Mesh/Service Segmentation - Consul Connect enables secure service-to-service communication with automatic TLS encryption and identity-based authorization. Applications can use sidecar proxies in a service mesh configuration to establish TLS connections for inbound and outbound connections without being aware of Connect at all.
-
Service Discovery - Consul makes it simple for services to register themselves and to discover other services via a DNS or HTTP interface. External services such as SaaS providers can be registered as well.
-
Health Checking - Health Checking enables Consul to quickly alert operators about any issues in a cluster. The integration with service discovery prevents routing traffic to unhealthy hosts and enables service level circuit breakers.
-
Key/Value Storage - A flexible key/value store enables storing dynamic configuration, feature flagging, coordination, leader election and more. The simple HTTP API makes it easy to use anywhere.
Consul runs on Linux, macOS, FreeBSD, Solaris, and Windows and includes an optional browser based UI. A commercial version called Consul Enterprise is also available.
Please note: We take Consul's security and our users' trust very seriously. If you believe you have found a security issue in Consul, please responsibly disclose by contacting us at security@hashicorp.com.
Quick Start
A few quick start guides are available on the Consul website:
- Standalone binary install: https://learn.hashicorp.com/tutorials/consul/get-started-install
- Minikube install: https://learn.hashicorp.com/tutorials/consul/kubernetes-minikube
- Kind install: https://learn.hashicorp.com/tutorials/consul/kubernetes-kind
- Kubernetes install: https://learn.hashicorp.com/tutorials/consul/kubernetes-deployment-guide
Documentation
Full, comprehensive documentation is available on the Consul website:
Contributing
Thank you for your interest in contributing! Please refer to CONTRIBUTING.md for guidance. For contributions specifically to the browser based UI, please refer to the UI's README.md for guidance.