• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
Codemotion Magazine

Codemotion Magazine

We code the future. Together

  • Discover
    • Live
    • Tech Communities
    • Hackathons
    • Coding Challenges
    • For Kids
  • Watch
    • Talks
    • Playlists
    • Edu Paths
  • Magazine
    • Backend
    • Frontend
    • AI/ML
    • DevOps
    • Dev Life
    • Soft Skills
    • Infographics
  • Talent
    • Discover Talent
    • Jobs
  • Partners
  • For Companies
Home » Backend » Nomad vs Kubernetes without the complexity
Backend

Nomad vs Kubernetes without the complexity

What is Nomad? Discover this useful tool with an introductory guide that explains how to use it, and the differences between Kubernetes and Docker.

July 13, 2020 by Antonio Turibbio Liccardi

Table Of Contents
  1. What is Nomad really?
  2. Install & Run your first app
  3. Nomad Cluster Management
  4. Nomad vs. Kubernetes
  5. A new way to manage containers

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:

Nomad architecture

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:

Nomad CLI

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 -dev

Used 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"
Code language: PHP (php)

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 client
Code language: PHP (php)

A 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.

facebooktwitterlinkedinreddit
Share on:facebooktwitterlinkedinreddit

Tagged as:Kubernetes

How To Choose Between Developer Or Consultant?
Previous Post
Being A Tech Lead: How Much Tech, How Much Lead?
Next Post

Related articles

  • Infrastructure as Code
  • When Lambdas take control: The service of serverless
  • From 0 to Kubernetes using .NET Core, Angular e Jenkins
  • Akka and Kubernetes – Technologies give their best when combined
  • Cloud Native and the next 20 years of application development
  • How to foster effective distributed teams
  • Digital Developer Conference: Cloud-Native Security
  • Cloud-native, Containers-based development: Quarkus revamps Java
  • From Code to Production With No Manual Deployment
  • Black Friday: How to Manage Huge Traffic on Your App

Primary Sidebar

Codemotion Talent · Remote Jobs

Java Developer & Technical Leader

S2E | Solutions2Enterprises
Full remote · Java · Spring · Docker · Kubernetes · Hibernate · SQL

AWS Cloud Architect

Kirey Group
Full remote · Amazon-Web-Services · Ansible · Hibernate · Kubernetes · Linux

Front-end Developer

Wolters Kluwer Italia
Full remote · Angular-2+ · AngularJS · TypeScript

Flutter Developer

3Bee
Full remote · Android · Flutter · Dart

Latest Articles

developer skills

Trending Hard Skills and Soft Skills In Software Development

IT Careers

API security, equifax

5 Tips for Boosting API Security

Cybersecurity

automating AWS releases, TerraformCloud, cloud, cloud automation.

Automating AWS Releases Without Cloud Expertise

Cloud

web accessibility standards, guidelines, WCAG

Implementing Web Accessibility in the Right Way

Web Developer

Footer

  • Magazine
  • Events
  • Community
  • Learning
  • Kids
  • How to use our platform
  • Contact us
  • Become a Contributor
  • About Codemotion Magazine
  • How to run a meetup
  • Tools for virtual conferences

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • YouTube
  • RSS

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • RSS