Add a new boulder service, email-exporter, which uses the Pardot API client added in #8016 and the email.Exporter gRPC service added in #8017. Add pardot-test-srv, a test-only service for mocking communication with Salesforce OAuth and Pardot APIs in non-production environments. Since Salesforce does not provide Pardot functionality in developer sandboxes, pardot-test-srv must run in all non-production environments (e.g., sre-development and staging). Integrate the email-exporter service with the WFE and modify WFE.NewAccount and WFE.UpdateAccount to submit valid email contacts. Ensure integration tests verify that contacts eventually reach pardot-test-srv. Update configuration where necessary to: - Build pardot-test-srv as a standalone binary. - Bring up pardot-test-srv and cmd/email-exporter for integration testing. - Integrate WFE with cmd/email-exporter when running test/config-next. Closes #7966 |
||
|---|---|---|
| .. | ||
| README.md | ||
| config.hcl | ||
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
servicesstanza 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 resolvingfoo-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.77.77.77" port = 1438 } -
To target individual
foo-purger's, add these additionalservicesections which allow resolvingfoo-purger-1andfoo-purger-2respectively.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.77.77.77" port = 1438 } -
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 thetagsfield. Consul implemented theProtofield 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.