Best practices for testing against services in Nomad/Consul Connect?

Hi there!

My team is - like many here, it seems - in the midst of migrating from a kludge of Docker-Compose stuff over to Nomad. I came here with a best practice question!

Let’s say I have:

  • 2 services in Nomad that are Consul Connect’d
  • 2 integration-test containers that we want to interface with those two services, respectively

Question 1 is: Should these integration test containers themselves be deployed to Nomad? Is that the simplest/most idiomatic way to let them service-discover the services they depend on?
The alternatives I can think of would be:

  • run them bare on the host OS and just do some static port stuff - seems messy
  • run them bare on the host OS and include some Consul Connect library in the container - also seems messy

Question 2 is: let’s assume the answer to question 1 is “yes, use Nomad”.
What’s the best way to deploy a one-shot job and retrieve an exit code/logs from it?

For example, In the docker-compose world, we could just docker-compose run <an integration test> and receive a nice exit code at the end.
In Nomad, so far it looks like the best thing to do is a no-restarts-no-reschedules-Batch-job + poll for status on that job.

Thanks in advance!

Hi @wimax-grapl :wave:

Glad to hear you’re evaluating Nomad :slightly_smiling_face:

I would say yes, specially since you are using Consul Connect, it will be easier for your integration test containers to also be connected to the service mesh.

Otherwise you would need to manually setup Consul Connect for them, or deploy an ingress gateway to be able to accept outside traffic into your mesh.

If possible, it would be better to just deploy these services within the mesh.

Sounds like a parameterized batch job would be the best option. It would allow you to run the same batch job multiple times, and have each run potentially parameterized with some kind of input.

To retrieve the status and log you would need to query the Nomad API, but you don’t need to poll, you can use blocking queries to create a long-lived request that responds when the status changes.

I hope these answer your questions, but let me know if there’s anything that’s still not clear.

Awesome, thank you for the reply. The paramaterized batch job + blocking query seems perfect :slight_smile:

1 Like

Great! Feel free to reach out if anything else comes up :slightly_smiling_face:

Am I correct that the Nomad CLI doesn’t seem to support blocking queries, I need to write a bespoke http request?

I think that some commands do, but none of the ones you would need :sweat_smile:

So yeah, you would need to write specific HTTP requests.