3621f7090b
* Cleanup the discovery chain compilation route handling Nothing functionally should be different here. The real difference is that when creating new targets or handling route destinations we use the router config entries name and namespace instead of that of the top level request. Today they SHOULD always be the same but that may not always be the case. This hopefully also makes it easier to understand how the router entries are handled. * Refactor a small bit of the service manager tests in oss We used to use the stringHash function to compute part of the filename where things would get persisted to. This has been changed in the core code to calling the StringHash method on the ServiceID type. It just so happens that the new method will output the same value for anything in the default namespace (by design actually). However, logically this filename computation in the test should do the same thing as the core code itself so I updated it here. Also of note is that newer enterprise-only tests for the service manager cannot use the old stringHash function at all because it will produce incorrect results for non-default namespaces. |
||
|---|---|---|
| .circleci | ||
| .github | ||
| acl | ||
| agent | ||
| api | ||
| bench | ||
| build-support | ||
| command | ||
| connect | ||
| contributing | ||
| demo | ||
| ipaddr | ||
| lib | ||
| logging | ||
| sdk | ||
| sentinel | ||
| service_os | ||
| snapshot | ||
| terraform | ||
| test | ||
| testrpc | ||
| tlsutil | ||
| types | ||
| ui-v2 | ||
| vendor | ||
| version | ||
| website | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .hashibot.hcl | ||
| CHANGELOG.md | ||
| codecov.yml | ||
| GNUmakefile | ||
| go.mod | ||
| go.sum | ||
| INTERNALS.md | ||
| LICENSE | ||
| main.go | ||
| main_test.go | ||
| NOTICE.md | ||
| README.md | ||
| Vagrantfile | ||
Consul 
- Website: https://www.consul.io
- Forum: Discuss
Consul is a tool for service discovery and configuration. Consul is distributed, highly available, and extremely scalable.
Consul provides several key features:
-
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.
-
Multi-Datacenter - Consul is built to be datacenter aware, and can support any number of regions without complex configuration.
-
Service Segmentation/Service Mesh - 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.
Consul runs on Linux, Mac OS X, FreeBSD, Solaris, and Windows. 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://www.consul.io/intro/getting-started/install
- Kubernetes install: https://learn.hashicorp.com/consul/kubernetes/kubernetes-deployment-guide
- Minikube install: https://learn.hashicorp.com/consul/kubernetes/minikube
Documentation
Full, comprehensive documentation is viewable on the Consul website:
Contributing
Thank you for your interest in contributing! Please refer to CONTRIBUTING.md for guidance.