If one wanted to define Nomad (created by HashiCorp), it could be described as a scheduler, but in truth, Nomad is more than that.
In this article, we introduce Nomad and try to show how it can be used to simplify the life-cycle management of any type of application, including container-based, legacy and batch applications.
What is Nomad really?
Nomad is an orchestration tool that allows us to deploy and manage different types of applications, such as:
- container-based (with or without Docker);
- legacy applications;
- microservice-oriented applications;
- batch applications.
Viewed from above, Nomad looks like this:
What makes Nomad really useful is a rich set of APIs that:
- help us to automate deployments, app scaling and upgrades;
- empower developers to manage deployments directly;
- automatically manage failures;
- hide complex details such as node management, letting users choose only what is needed to have the application up and running.
As mentioned earlier, Docker is supported, but any type of application can be used, on whatever type of operating system is needed (Linux, Windows, BSD and OSX are all supported). Clusters can be created, adding nodes from different data centers and/or different regions.
Finally, Nomad is a highly scalable tool that allows users to exceed the limits of the standard concept of scaling; indeed, the developers used a case study named “the million container challenge”. Many companies, including CloudFare, PagerDuty, SAP, eBay, and Reaktor have chosen Nomad to provides services to their customers.
Install & Run your first app
Nomad can be installed using a Vagrant file or the installer (more instructions can be found here)
Once Nomad has been installed, we can start it using CLI nomad:
Technically, Nomad has two execution modes: client and server. The first is used to run tasks, the other to manage nodes. Client agents usually register themselves to the server at startup and send all relevant information about the features available on the client machine. Either -server or -client parameters can be used to set the execution mode.
If a dev machine is being used, and the user would like to have a minimal configuration to work with Nomad, the -dev option can be used, as in the following command:
nomad agent -devUsed in this manner, Nomad starts itself in both client and server execution mode.
Starting the creation of a task in Nomad uses the following command nomad job init, which creates a template for a task in a file named example.nomad. This file uses HashiCorp Configuration Language (HCL) to define a simple structure for a job. In this specific case, we are creating a Redis instance; to run this task we can execute nomad job run in the terminal:
$ nomad job run example.nomad
==> Monitoring evaluation "13ebb66d"
Evaluation triggered by job "example"
Allocation "883269bf" created: node "e42d6f19", group "cache"
Evaluation within deployment: "b0a84e74"
Evaluation status changed: "pending" -> "complete"
==> Evaluation "13ebb66d" finished with status "complete"The status of the job can be checked at any time by using nomad status example. This provides information about a task allocation, which is the instance of the task itself. Using the allocation ID allows access to all information about the instance of the task in execution:
$ nomad alloc status 8ba85cef
ID = 8ba85cef
Eval ID = 13ebb66d
Name = example.cache[0]
Node ID = e42d6f19
Job ID = example
Job Version = 0
Client Status = running
Client Description =
Desired Status = run
Desired Description =
Created = 5m ago
Modified = 5m ago
Deployment ID = fa882a5b
Deployment Health = healthy
Task "redis" is "running"
Task Resources
CPU Memory Disk Addresses
8/500 MHz 6.3 MiB/256 MiB 300 MiB db: 127.0.0.1:22672
Task Events:
Started At = 10/31/17 22:58:49 UTC
Finished At = N/A
Total Restarts = 0
Last Restart = N/A
Recent Events:
Time Type Description
10/31/17 22:58:49 UTC Started Task started by client
10/31/17 22:58:40 UTC Driver Downloading image redis:3.2
10/31/17 22:58:40 UTC Task Setup Building Task Directory
10/31/17 22:58:40 UTC Received Task received by clientA task can also be modified while it is running. Once the run is complete, the following commands can be used:
nomad job plan example.nomad: to access differences in the modified file;nomad job run --check-index <ID> example.nomad: to check if the task’s status has been updated after the plan command;nomad job run example.nomad: to apply changes.
Finally, a task can be stopped by using the stop command.
Nomad Cluster Management
Where Nomad really shines is in cluster management. Through the CLI it is very simple to create a cluster adding nodes, thanks to HCL files. These nodes can then be linked to clients using the same CLI. Each server can be added within a specific data center (i.e.: dc1) and a region, if the user wants to organise a node in a specific geographic area.
At least three to five server nodes are suggested if a high availability cluster is desired. When a job is submitted, it can also be spanned across all available nodes or only to a specific number of nodes.
A Nomad cluster can also automatically be bootstrapped using Consul.
Consul is another HashiCorp product, which helps to create a distributed service mesh that facilitates services discovery, health checking and security. Whether Consul is installed on a server or on a client system, it will start to search for nodes and will automatically search for clusters in most cases. Another advanced feature is multi-region clustering: Nomad allows multiple clusters from different regions to work together through built-in federation.
Nomad vs. Kubernetes
Since Nomad is an orchestrator, the simple question can arise: why should users choose Nomad if they already know or use Kubernetes?
The first reason for this choice is Nomad’s ability to work with non-Docker technologies. If it’s necessary to run something that cannot be integrated with Docker, Nomad can help with that.
The second reason for making this choice is that Nomad is primarily a tool for scheduling tasks and carrying out cluster management. Nomad can leverage other tools, such as HashiCorp Consul or HashiCorp Vault, to add functionalities. Kubernetes is a much more complete cluster management software, and includes a lot of built-in tools. The choice really depends on what a user needs to do.
Finally, Nomad can be installed easily, using an executable file, whereas Kubernetes requires much more technical knowledge to be installed in an on-premises environment.
A new way to manage containers
To summarise, Nomad is simply an executable file that helps users to schedule tasks and create clusters of nodes. Nomad makes it easy to manage nodes using CLI, and to create tasks using HCL. The clustering feature is very advanced and also simple to manage. Nomad’s lightness allows for very good performance.