boulder/test/consul
Jacob Hoffman-Andrews ce5632b480
Remove `service1` / `service2` names in consul (#7266)
These names corresponded to single instances of a service, and were
primarily used for (a) specifying which interface to bind a gRPC port on
and (b) allowing `health-checker` to check individual instances rather
than a service as a whole.

For (a), change the `--grpc-addr` flags to bind to "all interfaces." For
(b), provide a specific IP address and port for health checking. This
required adding a `--hostOverride` flag for `health-checker` because the
service certificates contain hostname SANs, not IP address SANs.

Clarify the situation with nonce services a little bit. Previously we
had one nonce "service" in Consul and got nonces from that (i.e.
randomly between the two nonce-service instances). Now we have two nonce
services in consul, representing multiple datacenters, and one of them
is explicitly configured as the "get" service, while both are configured
as the "redeem" service.

Part of #7245.

Note this change does not yet get rid of the rednet/bluenet distinction,
nor does it get rid of all use of 10.88.88.88. That will be a followup
change.
2024-01-22 09:34:20 -08:00
..
README.md Add additional service resolution strategy to consul doc (#7244) 2024-01-09 13:46:44 -08:00
config.hcl Remove `service1` / `service2` names in consul (#7266) 2024-01-22 09:34:20 -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.