Назад | Перейти на главную страницу

Тестирование состояния соли через Дженкинса

Все,

Мы пытаемся включить автоматические тесты в нашу настройку Jenkins для запуска тестов типа «дым» и «пух» в наших файлах солевого состояния (.sls). Весь google-foo пока дал очень мало информации. Есть способ проверить через test=True в командной строке, но это не работает с учетной записью без оболочки (как это обычно бывает с учетными записями Jenkin).

Я еще не сталкивался с кем-нибудь, занимающимся подобными автоматизированный тестирование состояний SaltStack. Так:

1) Возможно ли

2) Кто-нибудь знает хороший ресурс, где я мог бы посмотреть

TIA.

Докер. Быстрое автоматическое тестирование конфигурации сервера - неоспоримая проблема реального мира, которую решает Docker. Он может предоставить чистый компьютер, уже загруженный и прослушивающий сеть за секунду. Запустите образ с подключенным к привязке / srv / salt, и вы можете запустить salt-call --local state.highstate -l debug тестировать состояния без возни с salt-key.

Я знаю, что SaltStack, Inc использовала LXC примерно так же. Скорее всего, они до сих пор верят.

Что касается теста - если вы умны и осторожны с вашими файлами состояний, вы можете считать второй чистый запуск признаком успеха.

Этого сложно достичь, поскольку некоторые состояния всегда будут запускаться повторно. Salt Stack хорошо исправляет эти состояния по мере их обнаружения. А пока вам придется окружить эти состояния встроенными условными операторами jinja, которые выполняют команды на миньоне во время выполнения:

{% if salt['cmd.retcode']('your test here') %} 
some-identifier:
  some.module:
    - name: some anme
{% endif %}'

Существует плагин jenkins-docker:

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

Кроме того, вы можете автоматизировать все это с помощью новый модуль соли docker-ng:

salt dockhost docker-ng.create states-qa rm=True binds="/srv/salt:/srv/salt"
salt dockhost docker-ng.retcode states-qa 'salt-call --local state.highstate' # run 1
salt dockhost docker-ng.retcode states-qa 'salt-call --local state.highstate' # run 2
salt dockhost docker-ng.stop states-qa

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

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

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

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

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

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

  2. Мы также выполняем работы по линтингу 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
    

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

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

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

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

Подробнее о Testinfra бэкэнд соединения соли, Testinfra солевой модуль.

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

Вы можете взглянуть на TestInfra