09e4c2995b
* Fix CA pruning when CA config uses string durations.
The tl;dr here is:
- Configuring LeafCertTTL with a string like "72h" is how we do it by default and should be supported
- Most of our tests managed to escape this by defining them as time.Duration directly
- Out actual default value is a string
- Since this is stored in a map[string]interface{} config, when it is written to Raft it goes through a msgpack encode/decode cycle (even though it's written from server not over RPC).
- msgpack decode leaves the string as a `[]uint8`
- Some of our parsers required string and failed
- So after 1 hour, a default configured server would throw an error about pruning old CAs
- If a new CA was configured that set LeafCertTTL as a time.Duration, things might be OK after that, but if a new CA was just configured from config file, intialization would cause same issue but always fail still so would never prune the old CA.
- Mostly this is just a janky error that got passed tests due to many levels of complicated encoding/decoding.
tl;dr of the tl;dr: Yay for type safety. Map[string]interface{} combined with msgpack always goes wrong but we somehow get bitten every time in a new way :D
We already fixed this once! The main CA config had the same problem so @kyhavlov already wrote the mapstructure DecodeHook that fixes it. It wasn't used in several places it needed to be and one of those is notw in `structs` which caused a dependency cycle so I've moved them.
This adds a whole new test thta explicitly tests the case that broke here. It also adds tests that would have failed in other places before (Consul and Vaul provider parsing functions). I'm not sure if they would ever be affected as it is now as we've not seen things broken with them but it seems better to explicitly test that and support it to not be bitten a third time!
* Typo fix
* Fix bad Uint8 usage
|
||
|---|---|---|
| .github/ISSUE_TEMPLATE | ||
| acl | ||
| agent | ||
| api | ||
| bench | ||
| build-support | ||
| command | ||
| connect | ||
| demo | ||
| ipaddr | ||
| lib | ||
| logger | ||
| sentinel | ||
| service_os | ||
| snapshot | ||
| terraform | ||
| test | ||
| testrpc | ||
| testutil | ||
| tlsutil | ||
| types | ||
| ui | ||
| ui-v2 | ||
| vendor | ||
| version | ||
| watch | ||
| website | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| CHANGELOG.md | ||
| GNUmakefile | ||
| INTERNALS.md | ||
| LICENSE | ||
| NOTICE.md | ||
| README.md | ||
| Vagrantfile | ||
| main.go | ||
| main_test.go | ||
README.md
Consul 
- Website: https://www.consul.io
- Chat: Gitter
- Mailing list: Google Groups
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 - Consul Connect enables secure service-to-service communication with automatic TLS encryption and identity-based authorization.
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
An extensive quick start is viewable on the Consul website:
https://www.consul.io/intro/getting-started/install.html
Documentation
Full, comprehensive documentation is viewable on the Consul website:
Developing Consul
If you wish to work on Consul itself, you'll first need Go installed (version 1.10+ is required). Make sure you have Go properly installed, including setting up your GOPATH.
Next, clone this repository into $GOPATH/src/github.com/hashicorp/consul and
then just type make. In a few moments, you'll have a working consul executable:
$ make
...
$ bin/consul
...
Note: make will build all os/architecture combinations. Set the environment variable CONSUL_DEV=1 to build it just for your local machine's os/architecture, or use make dev.
Note: make will also place a copy of the binary in the first part of your $GOPATH.
You can run tests by typing make test. The test suite may fail if
over-parallelized, so if you are seeing stochastic failures try
GOTEST_FLAGS="-p 2 -parallel 2" make test.
If you make any changes to the code, run make format in order to automatically
format the code according to Go standards.
Vendoring
Consul currently uses govendor for
vendoring and vendorfmt for formatting
vendor.json to a more merge-friendly "one line per package" format.