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

> HashiCorp Nomad оркеструє контейнери і процеси одним бінарником без складного control plane Kubernetes. Встановлення, job-файл і кластер із серверів.

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](https://www.zevshost.net/uk/kb/consul-service-discovery/), а не несе це всередині себе.

## Встановлення 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](https://www.zevshost.net/uk/kb/docker-swarm-nastroika/) чи легким кластером на базі [k3s](https://www.zevshost.net/uk/kb/k3s-kubernetes-vps/), якщо екосистема Kubernetes все ж потрібна.

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

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

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

---

Джерело: https://www.zevshost.net/uk/kb/nomad-orkestraciya/