With my previous post I demonstrated how simple it is to connect services through Nomad’s service discovery support. I promised to follow-up showing this with Consul providing the service registry and use Consul’s service discovery.

Le’s look into the service stanza documentation. The provider key allows 2 different values. We already used nomad implementing the Nomad service registry. Before Nomad 1.3 only consul was a supported service registry. This was the default for this key and would register the service with the Consul service registry. So we would go ahead and just would set provider = "consul" for the api and the db service.

With the recently released Nomad 1.3 a service registry backed by Nomad was added. This is making building complex services dependent on others really easy. Earlier we typically would have added Hashicorp Consul as service registry. In a production environment that would have meant to a add a Consul cluster running along with the Nomad cluster. Obviously this comes with some costs even when running such a cluster is really made simple by Hashicorp.

In the past 2 years I successfully architected and developed a new product for a customer and brought it to production. This product uses Hashicorp’s job scheduler Nomad for managing workload.

Nomad is an excellent alternative to Kubernetes. It is known for its simplicity in regard to usage and maintainability and allows to schedule containerized and non-containerized applications.

This is the last post in the series of posts about TDD for infrastructure. If you wanted to follow along I recommend first reading TDD for infrastructure with Vagrant and then TDD for infrastructure with footloose.

In the previous post TDD for infrastructure with footloose I explored weaveworks' footloose to start containers that look like virtual machines. Containers do no quite cope with the isolation that a real virtual machine can provide. So in case we must use a real virtual machine we can go back to the approach with VirtualBox (or any other product) or investigate into other options.

In the previous post TDD for infrastructure with Vagrant I explored Vagrant, VirtualBox and Chef Inspec for implementing a simple workflow for test driven development of infrastructure code. I showed that using virtual machines as target machines for testing is just not fast enough and probably hard to run in a build environment.

With this post we close the series of articles taking a deep dive on building Docker images. We look at a building Docker images for running Java applications in a Docker container with Jib which is part of the Google Container Tools.