Тихие сбои в автономном соляном миньоне

Я начинаю проект, который использует Salt Stack для координации подготовки. Но сейчас это не работает - файл журнала (на миньоне, в /var/log/salt/minion) не показывает никаких ошибок, но миньон не делает то, что я прошу.

По сути, я создаю SaltStack с парой основных файлов и как минимум двумя конфигурациями миньонов. В частности, я отлаживаю миньона, который я вызываю bootstrap (потому что он должен запускать мастер соли на миньоне):

master: localhost
file_client: local
file_roots:
  base:
    - /srv/salt/base
    - /srv/salt/states
  master:
    - /srv/salt/master
    - /srv/salt/master/states

Насколько я могу судить, Salt отлично загружает верхние файлы и анализирует их в действительные объекты, но Salt не выполняет никаких команд в ответ на объекты. Действительно, файл журнала миньона говорит:

2014-03-01 23:00:09,644 [salt.utils.jinja ][DEBUG   ] Jinja search path: '['/srv/salt/base', '/srv/salt/state
2014-03-01 23:00:09,651 [salt.template    ][DEBUG   ] Rendered data from file: /srv/salt/base/top.sls:
base:
  '*':
    - edit.vim
    - essential
    - users.root

2014-03-01 23:00:09,656 [salt.loaded.int.render.yaml][DEBUG   ] Results of YAML rendering:
OrderedDict([('base', OrderedDict([('*', ['edit.vim', 'essential', 'users.root'])]))])

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

2014-03-01 23:00:09,661 [salt.utils.jinja ][DEBUG   ] Jinja search path: '['/srv/salt/master', '/srv/salt/mas
2014-03-01 23:00:09,662 [salt.template    ][DEBUG   ] Rendered data from file: /srv/salt/master/top.sls:
master:
  '10.47.94.0/24':
     - match: ipcidr
     - master
     - srv.dns.unbound

2014-03-01 23:00:09,665 [salt.loaded.int.render.yaml][DEBUG   ] Results of YAML rendering:
OrderedDict([('master', OrderedDict([('10.47.94.0/24', [OrderedDict([('match', 'ipcidr')]), 'master', 'srv.dns.unbound'])]))])

Во всем остальном файле журнала база больше никогда не упоминается. И команды/состояния, связанные с базой, не запускаются. Я вижу записи журнала для edit.vim, srv.dns.unbound и т. д. Но все они следуют одному и тому же шаблону: анализировать и ничего не делать.

Что я делаю не так? У меня смутное впечатление, что это связано с наличием нескольких файловых_корней в моей конфигурации миньона, но я бы не хотел вносить архитектурные изменения, пока не узнаю, какой должна быть архитектура. (Я уже однажды пытался использовать Salt, столкнулся с «этой» молчаливой ошибкой, начал заново и теперь снова столкнулся с ней)


salt-stack
person nomen    schedule 02.03.2014    source источник
comment
Можете ли вы попробовать запустить salt * test.ping, чтобы убедиться, что мастер соли может общаться с миньоном (а также проверить, был ли ключ миньона принят мастером)?   -  person Jason Zhu    schedule 03.03.2014
comment
@JasonZhu: у меня еще нет мастера. Предполагается, что этот стек определяет миньона без мастера, который управляет мастером. Итак, идея в том, что я бы предоставил эту машину, а остальные мои соляные стеки использовали бы ее в качестве мастера.   -  person nomen    schedule 04.03.2014
comment
Вы решили это? Вы можете попробовать запустить salt-call --local test.ping, чтобы узнать, звонит ли он в колокольчик.   -  person leonardinius    schedule 11.08.2014

Ответы (2)


arrow_upward
1
arrow_downward 

master: localhost
file_client: local

Параметры «master: localhost» и «file_client: local» являются взаимоисключающими.

Если у вас 'file_client: local', то локальная соль-миньон вообще не будет искать мастера.

Если вы хотите запустить мастер соли и миньон соли на одном компьютере, вы должны использовать «мастер: локальный хост» в конфигурации миньона и оставить «file_client» закомментированным. В этом случае вы также должны хранить конфигурации миньонов и мастеров отдельно.

Что касается вашего вопроса о рендеринге файлов top.sls. Это согласно дизайну. Salt будет искать и отображать каждый файл top.sls в корне каждой файловой среды. Таким образом, поскольку у вас есть две среды, он всегда будет отображать оба файла top.sls, а затем оценивать их для каждого миньона, чтобы определить, какие файлы sls выполнять на каждом миньоне.

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

salt-call state.show_highstate -l debug
person Utah_Dave    schedule 08.09.2014

arrow_upward
1
arrow_downward

Это обычная путаница, когда я начинаю читать документ с солью.

  1. Всегда придерживайтесь расстановки мастер-миньон, избегайте любых попыток играть или даже «думать как без хозяина». Going Masterless не сэкономит вам много ресурсов ЦП и памяти, но создаст больше путаницы в процессе обучения/сборки соленого стека.

  2. Всегда рисуйте логическую диаграмму, а не «думайте прямо в соляной стеке».

  3. Всегда записывайте правильный/явный путь и имя файла, когда задаете вопрос, т.е. для файлов конфигурации, состояний и т. д. не используйте ярлык.

Я хотел бы сделать то же самое, т. е. использовать имя мастера соли в интрасети AA, предоставить мастер соли X в центре обработки данных D, а затем начать предоставление миньона из мастера соли X, чтобы контролировать все миньоны внутри центра обработки данных D.

Так что логично так сделать

Salt master AA ‹-> (ЦОД D

Server XYZ [Salt master X, Salt minion X to AA ],
 Server S_1 [Salt minion S_1, salt-master X ], 
 Server S_2 [Salt minion S_2, salt-master X ],
 Server S_3 [Salt minion S_3, salt-master X ]

)

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

person mootmoot    schedule 09.03.2016