Состояние Linting Salt без их запуска

Проблемы синтаксиса в Salt многоуровневые (например, Jinja -> YAML -> аргументы функции состояния), и нет инструмента, чтобы охватить их все.

Быстрый ответ, основанный на этой связанной проблеме, состоит в том, чтобы запустить многоуровневый разбор:

salt-call state.show_highstate      | tee highstate.output.yaml
salt-call state.show_sls [state_id] | tee state_id.output.yaml

Функции show_* отображают данные состояния так, как их видит миньон перед выполнением.

Использование salt-call на стороне миньона (вместо salt на стороне мастера) часто обеспечивает лучшие параметры отладки — в основном это предпочтение.

Проблемы также могут быть в столбе или зернах (проверьте, что все необходимые данные скомпилированы и существуют, как ожидалось):

salt-call pillar.items | tee pillar.output.yaml
salt-call grains.items | tee grains.output.yaml

Точно так же, как уже упоминалось @cyfur01, непосредственное выполнение состояний (с тестовым режимом или без него) является последним шагом к устранению неполадок:

salt-call state.highstate      test=True | tee highstate.output.yaml
salt-call state.sls [state_id] test=True | tee state_id.output.yaml

Соляные состояния поддерживают интерфейс тестирования. Например:

salt '*' state.highstate test=True

Это должно запускать состояния и сообщать вам обо всем, что они будут делать, фактически ничего не изменяя — по сути, это пробный прогон. Хотя это не инструмент для линтинга, он проверяет, что Salt может анализировать и запускать все.

Опция test тяжела для линтинга конфигураций YAML. Вместо этого попробуйте создать сценарий предварительной регистрации, который включает что-то вроде этого:

salt-call state.highstate --file-root=$PWD --local --retcode-passthrough mocked=True

• --file-root позволяет указать местоположение вашей текущей кассы
• --local указывает, что действие не должно выполняться через мастер
• --retcode-passthrough заставляет эту команду выйти из ненулевого значения, если какое-либо правило не может быть создано
• mock=True обрабатывает все правила, но не инициирует соединения. Это новая функция в 2015.8.5. Альтернативный метод — запустить state.show_highstate

Я некоторое время искал хороший способ добиться этого материала QA в солевом состоянии, и мой лучший ответ на данный момент:

1. Использование jenkins для запуска заданий (через ssh) на основе ветки dev git, которая:

   • Подготовьте lxc в частном облаке proxmox в нашей лаборатории (точно так же, как мы это делаем в prod)

   • Используя соляные реакторы, контейнер получает свою конфигурацию (как и в случае с prod).

   • Использование testinfra для запуска модульного теста на построенном и настроенном контейнере

   • Наконец, если все прошло хорошо, уничтожьте контейнер, если не оставьте его в живых для утреннего сеанса отладки :)

2. Мы также запускаем задания linting jenkins как:

   for state in $(sudo /usr/bin/salt-call cp.list_states | awk '{print $2}' | grep -v "^top$"); do sudo /usr/bin/salt-call --retcode-passthrough state.show_sls ${state} ; done
   

У меня все еще есть проблема с получением правильного кода возврата для этого последнего задания linting (из-за ssh и т. д.).

Этот процесс в целом обеспечивает:

1. Наш процесс подготовки в порядке
2. Наша кодовая база (состояние + столп) работает, как и ожидалось.
3. Мы можем объединить разработку и производство с большим коэффициентом достоверности

Настоящим достоинством testinfra является то, что он может использовать бэкенд солевого соединения, который позволяет testinfra подключаться к контейнеру без необходимости развертывания ключа ssh или чего-либо еще (поскольку мы используем соляное облако для первоначальной подготовки)

Подробнее о тестовой инфраструктуре базе соединения с солью, testinfra модуль соли.

Это не идеально, но все же это делает довольно хорошую работу.