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