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

## Итог: короткий чек-лист

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

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

---

Источник: https://www.zevshost.net/ru/kb/nomad-orkestraciya/