Platform engineers and build pipeline engineers constantly are faced with the challenge of building container images for providing images to be used as application base or for running pipeline tasks. Probably such images have to be provided as multiple variants for multiple versions of software packages to be included.
The Arm CPU architecture is getting more and more popular even on desktop developer devices.
A comparative analysis of Arm, AMD, and Intel costs in the Amazon cloud has shown that Graviton2 processors can be significantly more cost-efficient than other platforms. The study compared the 16xlarge instances based on the m6g (Graviton2, Arm), m5a (EPYC1, AMD), and m5n (Xeon Cascade Lake, Intel) for the 64-vCPU count. Not only are the Arm-based instances cheaper than AMD and Intel, they can achieve 40% better performance per dollar when translating the time to completion of SPEC tests to hours and multiplying the result by hourly cost.
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.
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.
Jib is highly opinionated about building Java Docker containers using Maven or Gradle as build tool. So it offers plugin support for the above mentioned build tools.
In the previous blog post of the building docker images series we had a look at Docker image build pipelines. We revealed typical problems and looked at how to overcome some by utilizing multistage builds.
In part 4 of this series we work with an addition to the Docker tooling which is BuildKit.
