HashiCorp Nomad — оркестратор контейнерів і звичайних процесів, який ставлять замість Kubernetes, коли кластер невеликий, а складність control plane K8s не виправдана. Один бінарник, один конфіг-файл, декларативні job-файли у форматі HCL. Розберемо встановлення, структуру job-файлу і типовий кластер з кількох VDS.

Що таке Nomad і чим він відрізняється від Kubernetes

Nomad вирішує те саме завдання, що й Kubernetes: розмістити контейнери на придатних серверах, стежити, що вони живі, і перезапускати при падінні. Але Nomad не тягне за собою окремий мережевий шар, вбудований DNS і десятки CRD — це один статичний бінарник на Go, який запускається і як сервер кластера, і як агент на робочій машині.

Головна відмінність для VDS-інфраструктури: Nomad однаково добре планує не лише Docker-контейнери, а й звичайні бінарники, Java-застосунки і віртуальні машини через драйвери завдань. Для service discovery і мережі Nomad спирається на окремий продукт — Consul, а не несе це всередині себе.

Встановлення Nomad на один сервер

На Ubuntu Nomad встановлюється з офіційного репозиторію HashiCorp однією послідовністю команд:

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install nomad
nomad agent -dev -bind=0.0.0.0 -log-level=INFO

Режим -dev запускає Nomad як єдиний вузол одразу з роллю сервера і клієнта — для тесту цього достатньо. Веб-інтерфейс піднімається на порту 4646, там видно вузли кластера і запущені джоби.

Job-файл: як описати запуск контейнера

Одиниця роботи в Nomad — job, описаний у HCL. Мінімальний приклад для запуску nginx у контейнері:

job "web" {
  datacenters = ["dc1"]
  type        = "service"

  group "web" {
    count = 2

    network {
      port "http" {
        static = 80
      }
    }

    task "nginx" {
      driver = "docker"

      config {
        image = "nginx:1.27"
        ports = ["http"]
      }

      resources {
        cpu    = 200
        memory = 256
      }
    }
  }
}

Команда nomad job run web.nomad.hcl запускає job, а count = 2 означає два екземпляри завдання, розміщені Nomad на доступних серверах кластера автоматично.

Кластер з кількох серверів: ролі server і client

У продакшені Nomad розділяє ролі: вузли server зберігають стан кластера і приймають рішення про планування, вузли client реально виконують завдання. Рекомендована кількість серверів — 3 чи 5 для кворуму за алгоритмом Raft, клієнтів — стільки, скільки потрібно під навантаження.

Критерій	Nomad	Kubernetes
Встановлення	Один бінарник, конфіг у кілька рядків	kubeadm, control plane з кількох компонентів
Типи завдань	Docker, exec, Java, QEMU-віртуалки	Переважно контейнери
Service discovery	Через окремий Consul	Вбудований DNS і kube-proxy
Поріг входу	Низький, один YAML-подібний job-файл	Високий, десятки понять і об'єктів API

Інтеграція з Consul для service discovery

Сам по собі Nomad не знає, як одне завдання знайде адресу іншого. Consul закриває це завдання: кожне завдання Nomad реєструється в Consul як сервіс з health-check, а інші завдання знаходять його за DNS-іменем виду web.service.consul. Зв'язка Nomad плюс Consul закриває і планування, і виявлення сервісів без жодного рядка Kubernetes YAML.

Оновлення джобів без простою

Стратегія rolling update описується прямо в job-файлі блоком update: Nomad піднімає нові екземпляри завдання поступово, перевіряє їхнє здоров'я і лише потім гасить старі.

max_parallel = 1 — оновлювати по одному екземпляру за раз
health_check = "checks" — вважати екземпляр здоровим за результатами health-check, а не просто за фактом запуску
auto_revert = true — автоматично відкотити job, якщо нова версія не пройшла перевірку здоров'я

Коли Nomad не підходить

Якщо команда вже користується екосистемою Kubernetes — Helm-чарти, оператори, готові CRD, — перехід на Nomad означає переписування всього цього з нуля, і вигода не виправдовує витрат. Для одного-двох серверів без потреби в кворумі та складному плануванні простіше обійтися Docker Swarm чи легким кластером на базі k3s, якщо екосистема Kubernetes все ж потрібна.

Підсумок: короткий чекліст

Nomad варто брати, якщо потрібна оркестрація різнорідних завдань — не лише Docker — за мінімального порогу входу і без обв'язки повноцінного Kubernetes.

Один бінарник замість десятків компонентів control plane
3 чи 5 серверів для кворуму Raft у продакшені
Consul для service discovery, якщо завданням потрібно знаходити одне одного
Блок update у job-файлі для оновлення без простою

HashiCorp Nomad: оркестрація контейнерів без Kubernetes