Исправление alpha, (текущая версия) :
В общем этот спор идет как обычно не туда.
Разумеется всё решается. Я даже начала этот разговор что я эту проблему таки решила.
Но есть разница - решать своими средствами или следовать общему стандарту. Банально когда ты начинаешь заниматься тегами в consul и traefik тебе нужно сформировать свои схемы именования этих тегов, задокументировать их, и донести до всех участников проекта. Потом осознать что первый вариант получился не очень удачным, переделать подчеркивания на дефисы или наоборот и ещё раз всё это согласовать. И в процессе этого согласования придти к концепции namespaces например, и сервисов, и replica set, и deployment configs,..
Потом осознать что документацию-то по этому делу никто так и не написал, и новому инженеру только что пришедшему в команду всю эту накостыленную структуру должен обяснить ты.
Разумеется это тоже всё можно сделать. Но это всё тоже работа. И работа будет посложнее чем баш скрипты писать.
Наверное если у тебя уже есть бОльшая часть отлаженной инфраструктуры, которую ты хочешь оставить как есть, и тебе для счастья не хватает только добавить в неё оркестратор, то nomad как встраиваемый блок подойдет.
Но если у тебя ничего своего пока нет кроме отдельных кубиков для конструктора, а задача ничем особенным не отличается от типичной задачи k8s, то надеяться на то что номад позволит тебе выстроить из них какую-то свою особую магию не стоит. Скорее всего получится просто плохой k8s.
Исходная версия alpha, :
В общем этот спор идет как обычно не туда.
Разумеется всё решается. Я даже начала этот разговор что я эту проблему таки решила.
Но есть разница - решать своими средставми или следовать общему стандарту. Банально когда ты начинаешь заниматься тегами в consul и traefik тебе нужно сформировать свои схемы именования этих тегов, задокументировать их, и донести до всех участников проекта. Потом осознать что первый вариант получился не очень удачным, переделать подчеркивания на дефисы или наоборот и ещё раз всё это согласовать. И в процессе этого согласования придти к концепции namespaces например, и сервисов, и replica set, и deployment configs,..
Потом осознать что документацию-то по этому делу никто так и не написал, и новому инженеру только что пришедшему в команду всю эту накостыленную структуру должен обяснить ты.
Разумеется это тоже всё можно сделать. Но это всё тоже работа. И работа будет посложнее чем баш скрипты писать.
Наверное если у тебя уже есть бОльшая часть отлаженной инфсраструктуры, которую ты хочешь оставить как есть, и тебе для счастья не хватает только добавить в неё оркестратор, то nomad как встраиваемый блок подойдет.
Но если у тебя ничего своего пока нет кроме отдельных кубиков для конструктора, а задача ничем особенным не отличается от типичной задачи k8s, то надеяться на то что номад позволит тебе выстроить из них какую-то свою особую магию не стоит. Скорее всего получится просто плохой k8s.