boulder/test/consul
Phil Porada 2fe77e630e
Add additional service resolution strategy to consul doc (#7244)
While working on https://github.com/letsencrypt/boulder/pull/7238, I dug
into why the consul services config has, for example, `[ca-a, ca-b]` in
addition to `[ca1, ca2]`. Boulder test configs use `ca.service.consul`
which will return both CAs (`[ca-a, ca-b]`). For `[ca1, ca2]` though, a
grpc load balancing [integration
test](a55bf19ea0/test/integration-test.py (L121-L143))
individually targets services such as to verify that each backend is
working correctly.
2024-01-09 13:46:44 -08:00
..
README.md Add additional service resolution strategy to consul doc (#7244) 2024-01-09 13:46:44 -08:00
config.hcl Implement DoH for validation queries (#7178) 2023-12-11 10:49:00 -08:00

README.md

Consul in Boulder

We use Consul in development mode (flag: -dev), which configures Consul as an in-memory server and client with persistence disabled for ease of use.

Configuring the Service Registry

  • Open ./test/consul/config.hcl

  • Add a services stanza for each IP address and (optional) port combination you wish to have returned as an DNS record. The following stanza will return two records when resolving foo-purger. (docs).

    services {
      id      = "foo-purger-a"
      name    = "foo-purger"
      address = "10.77.77.77"
      port    = 1338
    }
    
    services {
      id      = "foo-purger-b"
      name    = "foo-purger"
      address = "10.88.88.88"
      port    = 1338
    }
    
  • To target individual foo-purger's, add these additional service sections which allow resolving foo-purger-1 and foo-purger-2 respectively.

    services {
      id      = "foo-purger-1"
      name    = "foo-purger-1"
      address = "10.77.77.77"
      port    = 1338
    }
    
    services {
      id      = "foo-purger-2"
      name    = "foo-purger-2"
      address = "10.88.88.88"
      port    = 1338
    }
    
  • For RFC 2782 (SRV RR) lookups to work ensure you that you add a tag for the supported protocol (usually "tcp" and or "udp") to the tags field. Consul implemented the the Proto field as a tag filter for SRV RR lookups. For more information see the docs.

    services {
      id      = "foo-purger-a"
      name    = "foo-purger"
      address = "10.77.77.77"
      port    = 1338
      tags    = ["udp", "tcp"]
    }
    ...
    
  • Services are not live-reloaded. You will need to cycle the container for every Service Registry change.

Accessing the web UI

Linux

Consul should be accessible at http://10.55.55.10:8500.

Mac

Docker desktop on macOS doesn't expose the bridge network adapter so you'll need to add the following port lines (temporarily) to docker-compose.yml:

  bconsul:
    ports:
      - 8500:8500 # forwards 127.0.0.1:8500 -> 10.55.55.10:8500

For testing DNS resolution locally using dig you'll need to add the following:

  bconsul:
    ports:
      - 53:53/udp # forwards 127.0.0.1:53 -> 10.55.55.10:53

The next time you bring the container up you should be able to access the web UI at http://127.0.0.1:8500.