Docker’s Voting App on Swarm, Kubernetes and Nomad

TL;DR

When you work in tech you definitely have to be curious, as it’s essential to always keep learning and to stay up to date. Things are moving extremely fast in this area.

Container orchestration is such a hot topic that, even if you have your favorite tool (my heart goes to Docker Swarm), it’s always interesting to see how the other ones work, and learn from them as well.

In this article, we will use Docker’s Voting App and deploy it on Swarm, Kubernetes and HashiCorp Nomad. I hope you’ll have as much fun reading this as I had experimenting with it.

The Voting App

I’ve used (and abused) the Voting App in previous articles. This application follows a micro-services architecture. It is made of five services as illustrated below.

Docker’s voting app architecture (https://github.com/docker/example-voting-app)

• Vote — front end that enables a user to choose between a cat and a dog.
• Redis — database where votes are stored.
• Worker — service that get votes from Redis and store the results in a Postgres database.
• Db — the Postgres database in which vote results are stored.
• Result — front end, displaying the results of the vote.

The Voting App has several compose files as we can see in the GitHub repository.

docker/example-voting-app

docker-stack.yml is the production-ready representation of the application. The content of this file is:

Basically, there are six services defined in this file, but only five services are defined in the Voting App…