LINUX.ORG.RU

HashiCorp Nomad 1.0

 hashicorp, nomad, ,


1

2

Состоялся выпуск первой стабильной версии минималистичной (относительно Kubernetes и других проектов в этой сфере) системы оркестрации HashiCorp Nomad, поддерживающей оркестрацию контейнеров с помощью Docker и Podman, программ на Java, виртуальных машин QEMU, обычных бинарных файлов, и ряда других способов, поддерживаемых сообществом. Проект написан на языке Go и примечателен тесной интеграцией с другими проектами HashiCorp.

По заявлению самой HashiCorp, по сравнению с Kubernetes их проект является архитектурно более простым, модульным и производительным: если Kubernetes сочетает в себе одновременно планировщик, управление кластерами, обнаружение и мониторинг сервисов, и хранение секретов, представляя собой массивный и ресурсоёмкий сервис, то Nomad поставляется в виде небольшого бинарного файла и занимается только планированием и кластеризацией. Вся остальная функциональность отдана на откуп другим небольшим сервисам компании: например, Consul для обнаружения сервисов и Vault для хранения секретов.

Изменения в этой версии:

  • Dynamic Application Sizing (доступно только в enterprise-версии) — автоматическое определение требуемого количества ресурсов для оптимальной работы сервиса;
  • Consul Namespaces (доступно только в enterprise-версии Consul) — выделение зоны видимости сервисов для Consul внутри одного Nomad-кластера;
  • Namespaces (стало доступно в свободной версии) — выделение зоны видимости и разграничение сервисов между собой внутри кластера;
  • Event Stream — полезный для отладки линейный поток событий, произошедших внутри кластера;
  • HCL2 — новая версия языка конфигурации проектов HashiCorp, теперь с поддержкой выражений и входных переменных;
  • улучшение поддержки Container Networking Interface — теперь адреса, созданные с помощью CNI, могут быть зарегистрированы в Consul;
  • новый интерфейс для отображения информации о запущенных сервисах, их распределению по узлам и потреблению ресурсов внутри кластера.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: demidrol (всего исправлений: 8)
Ответ на: комментарий от alpha

А в nomad ты запустил процесс, замапил порты и ходишь на ноду по http://35.48.123.20:45691 за http и по https://35.48.123.20:37124 на https

Бред какой. Вот ща ты указала ДИНАМИЧЕСКИЕ порты, которые выделяет номад, ставишь Traefik, например или что-то подобное и все у тебя работает + еще и удобно прямо из бэкенда менеджить:

service {
  name = "my-app"
  port = "http"
  tags = [
    "traefik-enable=true",
    "traefik.http.routers.my-app.rule=Host(`my-app.example.com`)",
    "traefik.http.routers.my-app.entrypoints=http"
  ]
}

А сейчас, когда завезли hcl2, так вообще песня просто.

Если тебе нужны статичные порты, как ты привыкла в кубе, то делай port_map:

config {
  image = "artifacts.example.com/app/app:0.0.1"
  port_map {
    http  = 8080
    https = 8443
  }
}

resources {
  network {
    port "http" {
      static = 80
    }
    port "https" {
      static = 443
    }
  }
}

Ну, и ходить все же лучше не по ip, а по http://my-app.service.consul.

Difrex ★★★★
()
Ответ на: комментарий от ugoday

Я не то чтоб спорю, просто ваши слова противоречат картинкам в интернете.

В конце 17 года это было не так.

Difrex ★★★★
()
Ответ на: комментарий от gr_buza

Вдруг у человека ES as a service?

Именно так. Когда кластер желтеет и начинает шарды тащить на другую ноду, то нужно, чтобы эти 20 терабайт юзера перетащились быстрее.

В 2017-2018 калика давала до 15% оверхеда на сеть, что было у них даже на сайте написано. Ну, и я не понимаю к чему вы меня призываете :). На номаде построен конкретный проект, конкретное облако, там больше никто ничего стороннего не запускает. Сам номад по возможности спрятан от оператора.

Difrex ★★★★
()
Последнее исправление: Difrex (всего исправлений: 1)
Ответ на: комментарий от Difrex

Да Господь с вами, какие призывы. Простое любопытство отчего чужой опыт отличается от своего.

ugoday ★★★★★
()
Ответ на: комментарий от Difrex

Соглашусь с угодаем - мне тоже просто интересно :)

gr_buza ★★★★
()
Ответ на: комментарий от ugoday

На nomad реально удобно строить свои кастомные решения. Ну, и не линуксом единым и не только контейнерами мир живет.

Сейчас спустя три года я бы может и посмотрел в сторону куба для этого проекта. Остальные наши проекты пускаются, как раз таки в кубе.

Вот тут рассказывал про nomad, если интересно https://www.youtube.com/watch?v=ouloiciOlqc

Difrex ★★★★
()
Ответ на: комментарий от gr_buza

по моему скромному мнению лучше тюнить JVM, чем париться насчёт десятых долей процента

У меня тогда тоже главный админ ныл что «джава в контейнерах просто не заработает, это вы хипстеры мне голову дурите». Поэтому собственно напирал на номад, чобы jar-ники гонять без изоляции.

Но когда запустили в контейнерах, оказалось что просто за счет немного другой архитектуры мы с помощью 15 контейнеров на трёх железных нодах держим тот же трафик что держат 25 железные серверов гоняющий «нативное» приложение без контейнерного оверхеда.

И сразу хайлоад которым все так гордились как-то резко перестал им быть. Вдруг стало ясно что это был не хайлоад а бардак :)

Потому что оказывается за счет более гибкой системы разработки и развертывания гораздо проще оптимизировать архитектуру сервиса. И выигрыш от неё скорее всего будет на порядок выше, чем те доли процентов, за которые можно бороться оптимизируя инфраструктуру и считая приложение черным ящиком.

alpha ★★★★★
()
Ответ на: комментарий от Difrex

Посмотрю, спасибо.

Правда сейчас у меня ES нигде рядом нет и не предвидится, но кто знает… :)

gr_buza ★★★★
()
Ответ на: комментарий от Difrex

Если тебе нужны статичные порты, как ты привыкла в кубе, то делай port_map

На один IP-адрес порт 80 можно повесить только один раз.

Nomad вешает все приложения на айпишник ноды.

Когда у меня 20 экземпляров одного web-приложения на одной ноде и всем им нужен порт 80, то мне придется добавлять к номаду какую-то абстракцию и маршрутизатор, который будет это разруливать.

В k8s каждый pod имеет свой собственный адрес. Это кстати сказать кровью и потом инженеров гугла полученное требование. Поэтому оно там вшито в дизайн.

И да, поначалу кажется что это мелочь. Нужно «просто написать скрипт». Но она потом вылезает в таком количестве мест, начиная от того что надо научить приложения разговарить друг с другом, и желательно не ходить при этом дальней дорогой через внешнюю сеть, и не заканчивая тем, что надо будет 100500 раз объяснять разработчику приложения на какой именно порт он должен подключать свой жабный дебаггер.

alpha ★★★★★
()
Ответ на: комментарий от ugoday

не обязательно istio. ingress контроллеры и без service mesh могут уметь в canary.

anonymous
()
Ответ на: комментарий от Difrex

Сейчас спустя три года я бы может и посмотрел в сторону куба для этого проекта.

а я бы кстати не стал (хоть я и не люблю номад). по-моему там, где много данных, и их надо зачем-то туда-сюда перетаскивать, куб не очень.

anonymous
()
Ответ на: комментарий от alpha

Когда у меня 20 экземпляров одного web-приложения на одной ноде и всем им нужен порт 80, то мне придется добавлять к номаду какую-то абстракцию и маршрутизатор, который будет это разруливать.

Вешаешь на динамический порт выделенный номадом и ставишь Traefik. В кубе ты тоже через ингрес ходишь, а не напрямую.

Но она потом вылезает в таком количестве мест, начиная от того что надо научить приложения разговарить друг с другом, и желательно не ходить при этом дальней дорогой через внешнюю сеть

Consul connect из коробки.

то надо будет 100500 раз объяснять разработчику приложения на какой именно порт он должен подключать свой жабный дебаггер.

Расшаришаваешь порт тегом в сервисе на Traefik и отдаешь разрабу человекочитаемый адрес для подключения. Как и в кубе в общем.

Difrex ★★★★
()
Ответ на: комментарий от alpha

В k8s каждый pod имеет свой собственный адрес. Это кстати сказать кровью и потом инженеров гугла полученное требование. Поэтому оно там вшито в дизайн.

Это кстати сказать кровью и потом инженеров гугла полученное требование.

Лол, оно так еще в Borg было.

Difrex ★★★★
()
Ответ на: комментарий от ugoday

с каликой в другом беда. она гадина временами необъяснимо и недебажиемо поглюкивает. или, может, не она, но глючит в ее присутствии. заменили на cilium, волосы стали гладкие и шелковистые. пока что нравится.

anonymous
()
Ответ на: комментарий от anonymous

Не встречал такого. Учитывая, что она по-максимуму использует родные линуксовые сетевые средства … А как конкретно „подглюкивала“?

ugoday ★★★★★
()
Ответ на: комментарий от Difrex

В кубе ты тоже через ингрес ходишь, а не напрямую. здрасьте. ингрес для внешнего трафика. внутри кластера все роутится без его участия.

anonymous
()
Ответ на: комментарий от anonymous

Альфа говорила про разраба, которому нужно жабовский дебагер подключить - это внешний трафик.

Difrex ★★★★
()
Ответ на: комментарий от ugoday

А как конкретно „подглюкивала“

не могу точно сказать. какие-то рандомные подвисания были, по-моему, еще какой-то трудноуловимый тупняк. деталей уже не помню. в итоге подумали, а не попробовать ли подающий надежды cilium, и оказалось, что все збс.

вообще k8s со всеми его запчастями и перделками из миллиона сторонних тюнинг-ателье довольно трудно дебажится. это из списка того немногого, что мне в нем неприятно. часто вместо того, чтобы докопаться до корня проблемы, проще и эффективнее оказывается заменить компонент альтернативным, что мы и сделали, например, с сетью. винда-стайл.

поэтому у кого-то, может, и cilium будет глючить, а калика будет работать отлично. трудности слишком сложных систем. еще, вероятно, зависит от того, где оно все крутится. в нашем случае это aws, например. может, в другой тучке все было бы иначе.

anonymous
()
Ответ на: комментарий от Difrex

В общем этот спор идет как обычно не туда.

Разумеется всё решается. Я даже начала этот разговор что я эту проблему таки решила.

Но есть разница - решать своими средствами или следовать общему стандарту. Банально когда ты начинаешь заниматься тегами в consul и traefik тебе нужно сформировать свои схемы именования этих тегов, задокументировать их, и донести до всех участников проекта. Потом осознать что первый вариант получился не очень удачным, переделать подчеркивания на дефисы или наоборот и ещё раз всё это согласовать. И в процессе этого согласования придти к концепции namespaces например, и сервисов, и replica set, и deployment configs,..

Потом осознать что документацию-то по этому делу никто так и не написал, и новому инженеру только что пришедшему в команду всю эту накостыленную структуру должен обяснить ты.

Разумеется это тоже всё можно сделать. Но это всё тоже работа. И работа будет посложнее чем баш скрипты писать.

Наверное если у тебя уже есть бОльшая часть отлаженной инфраструктуры, которую ты хочешь оставить как есть, и тебе для счастья не хватает только добавить в неё оркестратор, то nomad как встраиваемый блок подойдет.

Но если у тебя ничего своего пока нет кроме отдельных кубиков для конструктора, а задача ничем особенным не отличается от типичной задачи k8s, то надеяться на то что номад позволит тебе выстроить из них какую-то свою особую магию не стоит. Скорее всего получится просто плохой k8s.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

а напомните как называется альтернатива traefik но какая-то на букву L. которая позволяет разделять трафик и регулировать.

А то тут такой ностальгический тред получился, почти всё вспомнила, а этих забыла.

alpha ★★★★★
()
Ответ на: комментарий от Difrex

куб тоже допиливать нужно

С этим никто не спорит. Дело в том, что там со стандартами и апи получше. Хочешь запускать jar на freebsd - вот тебе апи кубелета, делай virtual kubelet. Хочешь хранилку секретов - вот https://github.com/hashicorp/vault-k8s, а лучше https://github.com/Azure/secrets-store-csi-driver-provider-azure. Рестарт контейнера при смене конфигмапа - тут и операторы, и https://github.com/stakater/Reloader.

А в номаде ешьте hcl, никакого вам пулуми и прочей автоматизации там не предвидиться

vrutkovs ★★
()
Последнее исправление: vrutkovs (всего исправлений: 2)
Ответ на: комментарий от vrutkovs

Azure лучше

Ага конечно. Облачные люди уже забыли что бывает bare metal и собственные облака:).

А в номаде ешьте hcl, никакого вам пулуми и прочей автоматизации там не предвидиться

Можешь тераформ взять - он умеет в номад. О, ты тот самый единственный человек, что использует пулуми в проде? Как оно тебе?

Difrex ★★★★
()
Ответ на: комментарий от vrutkovs

со стандартами и апи получше

Ага, beta1, alpha2 и прочие апи :)

Difrex ★★★★
()
Ответ на: комментарий от Difrex

тераформ взять - он умеет в номад

Я пыталась кстати.

Но во-первых terraform - это издевательство, у него совершенно безумный подход к областям видимости переменных.

А во-вторых когда я этим занималась, hashicorp умудрились зарелизить новую версию nomad-а несовместимую с предыдущей. А поддержку в терраформе для неё выкатили только через полгода.

В итоге ansible оказался удобнее.

alpha ★★★★★
()
Ответ на: комментарий от Difrex

Облачные люди

Все же ридми до конца дочитайте, там и волт есть.

О, ты тот самый единственный человек, что использует пулуми в проде? Как оно тебе?

Не использую, но идея нравится.

Можешь тераформ взять

Отож, только отобранные Митчеллом продукты, я понял.

По основному пункту возражений нет?

vrutkovs ★★
()
Ответ на: комментарий от vrutkovs

Не использую, но идея нравится.

Вот и мне тоже нравитсяно не использую.

Отож, только отобранные Митчеллом продукты, я понял.

Ansible возьми. Или тоже не ок?

По основному пункту возражений нет?

А какой основной пункт?

Difrex ★★★★
()
Ответ на: комментарий от alpha

Это во времена 0.4 что ли было? Это как взять куб 1.3 и страдать от того, что у тебя разваливается etcd раз в день.

Difrex ★★★★
()
Ответ на: комментарий от alpha

И что?

Ну сделай маршрутизируемую сеть, будет у тебя по ip на каждый контейнер, и ходи по этим ip. Просто тупо оверлей сеть. Я трогал Nomad, на каждый контейнер у меня был собственный ip, сеть ты там сам можешь делать какую хочешь.

chemistmail
()
Ответ на: комментарий от Difrex

Nomad умеет в quemu-kvm, умеет ли в него k8s

Умеет, и не тупо запускать а полный фичерсет - миграции, пробросы, оптимизация и т.д.

dyasny ★★★★★
()
Ответ на: комментарий от Difrex

Частично решается через topologySpreadConstraints, но конкретным нодам веса назначать нельзя.

anonymous
()
Ответ на: комментарий от Difrex

берешь openshift и там в целом все есть из коробки. правда их тоже понесло и вместе с переходом на операторы они успешно умудрились потерять кучу функционала. Потихоньку возвращают конечно, но гораздо медленнее чем хотелось бы

user_undefined
()
Ответ на: комментарий от Difrex

spec.metadata.annotations.checksum/config - вписать сумму конфигмапы и сам все следит.

Управление весами - nodeSelector или DaemonSet чтобы на каждом узле крутить.

Blue/Green - насколько помню, несколько предидущих ReplicaSet остается, они же содержат старые версии. Перекатывание происходит автоматически если все настроить.

Для канарейки нужно, например, Istio.

Соглашусь, не все так гладко, но все на нем куда не плюнь.

dtm
()
Ответ на: комментарий от anonymous

не могу точно сказать. какие-то рандомные подвисания были

Боюсь, с таким анамнезом сложно сказать что-то определённое.

вообще k8s со всеми его запчастями и перделками из миллиона сторонних тюнинг-ателье

K8S прямой как палка и простой как полено. Не согласны? Поработайте с OpenStack’ом. :-)

Но в чём я с вами частично согласен, k8s — это js в мире админов. Каждый первый делает какой-то свой инструментарий и приходится бежать изо всех сил, чтобы просто остоваться на месте.

ugoday ★★★★★
()

Вы заметили, как пони и прочее дивёрсити любит контейнеры?

anonymous
()

Nomad vs. Kubernetes

Сравнение неверное учитывая что в бесплатном nomad-е нет даже неймспейсов что кубер дает прям из коробки. https://www.hashicorp.com/products/vault/pricing Цену они тоже не показывают

Nomad has not provided pricing information for this product or service. This is common practice for software sellers and service providers. Contact Nomad to obtain current pricing.

anonymous
()
Ответ на: комментарий от dtm

spec.metadata.annotations.checksum/config - вписать сумму конфигмапы и сам все следит.

Значит, придется костыли городить, т.к. helm такое не умеет. У нас и так уже Ansible генерирует values для helm, так что можно впихнуть. Спасибо, не знал про такое.

Управление весами - nodeSelector или DaemonSet чтобы на каждом узле крутить.

DaemonSet это несколько другое. Так же как и nodeSelector. Федерации же нет, я не могу в yaml прописать запустить 20% пода в dc1, а остальное в dc2.

Blue/Green - насколько помню, несколько предидущих ReplicaSet остается, они же содержат старые версии. Перекатывание происходит автоматически если все настроить.

Там же роллинг простой по умолчанию. Для blue/green нужно навешивать что-то сбоку, типа istio.

Опять же я не против куба, даже наоборот. Просто Nomad тоже хорош, особенно на голом железе и в федерации. А так же для построения какого-либо сервиса, где оркестратор требуется только, как некая запускалка чего угодно, которая следит за тем, чтобы все было хорошо.

Difrex ★★★★
()
Ответ на: комментарий от anonymous

Неймспейсы завезли в 1.0 в open source редакцию.

Difrex ★★★★
()
Ответ на: комментарий от Difrex

А так же для построения какого-либо сервиса

Пожалуй да, это существенное отличие.

Ты строишь сервис, на облачной платформе, но эта облачная платформа скрыта от пользователя.

А мне нужен был не один конкретный сервис а наоборот, PaaS. Потому что мне надо было не скрыть от пользователя внутреннюю структуру облака, а позволить пользователю (разработчику приложения) в ней разобраться и использовать при планировании своих микросервисов.

С этой точки зрения K8s предоставляет не только техническую возможность протащить трафик от сюда туда, или смасштабировать нагрузку. Но он предоставляет язык и набор абстракций с помощью которых об этой инфраструктуре можно говорить, и интерфейс как этими абстракциями обмениваться.

С тем же консулом например - мне не надо было чтобы моему приложению кто-то проставил тег и настроил DNS. Мне надо было чтобы любой человек в команде разработчиков разворачивая любое новое приложение на этой платформе мог указать параметры и порты этого приложения не обращаясь к админам кластера. При этом я совершенно не хочу открывать разработчикам полный доступ к консулу чтобы они там насочиняли своих собственных конфигов. Мне нужен интерфейс и протокол в рамках которого они могут действовать. K8s даёт такой протокол.

Короче говоря Nomad - это оркестратор. А K8s - это PaaS.

alpha ★★★★★
()
Ответ на: комментарий от apmucm

блин, чувак даже ссылку на доклад давал, там всё есть. Всего-то не полениться и сходить по ссылке.

gr_buza ★★★★
()

(офигеть, кстати, девочка-девопс, еще и с кубернетесом и всем чем положено.)

anonymous
()
Ответ на: комментарий от anonymous

офигеть, кстати, девочка-девопс, еще и с кубернетесом и всем чем положено.

А чего офигевать? Это нормальное положение вещей. Видишь макбук/тхинкпадик с наклеечками, обои с понями или моэ - понимаешь, что перед тобой любитель контейнеров и js, опционально из среды с identity politics.

Только вот всему этому так и не светит вылезти из js и yaml.

anonymous
()
Ответ на: комментарий от alpha

с помощью 15 контейнеров на трёх железных нодах держим тот же трафик что держат 25 железные серверов гоняющий «нативное» приложение без контейнерного оверхеда.

А можно поподробнее, просто даже интересно как это так. Это просто оптимизировали приложение почти в 10 раз что ли?

vitalif ★★★★★
()

Жалко что spark-over-nomad бросили. В целом логично. Но жалко.

ei-grad ★★★★★
()
Ответ на: комментарий от vitalif

Там была плавающая по времени нагрузка. Иногда она приходит на один шард, потом переезжает на другой, потом на третий. Такой роутинг трафика, но не динамический, а захардкоженный на уровне базовой инфры настолько, что поменять конфигурацию шарда занимало неделю, а добавить новый шард было невозможно вообще.

И в старом варианте каждый шард обрабатывался грубо говоря отдельно стоящим приложением. И если этому приложению среди ночи или раз в неделю вдруг не хватало памяти - админы молча шли и добавляли ему RAM. Когда RAM уже некуда было добавлять, они добавляли сервак.

В итоге за несколько лет роста компании админы вырастили «ферму» серверов и гордо рапортовали о своих масштабах и нагрузках начальству.

А мы распилили этот сервис до такой степени что там можно было чуть не индивидуально по каждому запросу масштабировать, что куда отправляется в реальном режиме. И кроме этого мы обложили приложения real-time-метриками и, главное, на метрики эти стали смотреть не админы серверов, а сами разработчики.

Когда один из старших разработчиков увидел наконец прод-метрики которые я им отрисовала по каждому контейнеру, он сначала завис на полчаса, а потом потребовал дебаггер прямо туда. Следующую неделю мы с ним вместе занимались тем что подкручивали параметры JVM наживую, выкатывали canary с поправками, и отслеживали какой эффект это даёт на живом трафике.

Так что тут даже не скажешь что сами по себе контейнеры всех спасли. Спасло то что выкатывать изменения, перенаправлять живой трафик и мониторить результат стали разработчики, сами, получая обратную связь в реальном времени.

Вообще у нас тогда получился просто идеальный сферический в вакууме девопсо-микросервисный проект, по которому учебники можно писать. Так даже и не поверишь сразу что оно так в реальном мире может быть.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Конечно не поверю. Ох и врать же ты! Все неудобные особенности опустила, все остальное раздула до неприличия. Свое участие выпятила до предела. Если бы не знал про что, как и где ты говоришь - может быть и купился бы.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.