В Сольте, как я могу условно и итеративно ( jinja) применить включенное состояние

Question

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

Я рассмотрел несколько возможных подходов

• реактор
• оркестровщик

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

• пользовательские состояния

Это то, чего я ДЕЙСТВИТЕЛЬНО хотел бы избежать, поскольку это повторяющийся рабочий процесс, и я не хочу создавать подобные настройки. Там слишком много места для неразборчивости, если я пойду по этому пути со своими товарищами по команде.

• требует / часы

У них нет концепции (которую я знаю) о повторном применении состояния или в логическом порядке / рабочем процессе.

И несколько других я не буду упоминать.

Без дальнейшего обсуждения, вот моя дилемма.

Цели:

• Дженкинс Мастер получает развертывание
• Мы можем приступить к тестированию развертывания по мере его продолжения.
• Мы только перезапускаем Tomcat, когда это необходимо
• Мы можем обновить плагины для каждого пакета
• Большой упор на хорошие чистые интуитивно понятные солевые конфиги

Развертывание Jenkins довольно простое. Мы бросаем в пакеты, и конфиги, и мы настроены.

Модульное тестирование сложнее. В качестве примера у меня есть этот файл состояния.

Действия / ve rsion.sls:

# Hit's the jenkins CLI interface to check for version info
# This can be used to verify that jenkins is active and the version we want

# Import some info
{%- from 'jenkins/init.sls' import jenkins_home with context %}

# Install plugins in jenkins_plugins list
jenkins_version:
  cmd.run:
    - name: java -jar jenkins-cli.jar -s "http://127.0.0.1:8080" version
    - cwd: /var/lib/tomcat/webapps/ROOT/WEB-INF/
    - user: jenkins

actions.ve rsion в основном проверяет, что jenkins запущен и работает с запросами. мы хотим быть уверены в этом во время сборки в нескольких точках.

пример... коту нужно время, чтобы раскрутиться. мы должны были добавить задержку к этой операции перезапуска. Если вы посмотрите на start.sls ниже, вы увидите, что эта операция происходит. Обратите внимание на ошибку, открытую при init_delay:.

Действия / start.sls:

# Starts the tomcat service
tomcat_start:
  service.running:
    - name: tomcat
    - enable: True
    - full_restart: True
# Not functional atm see --> https://github.com/saltstack/salt/issues/20631
#    - init_delay: 120

# initiate a 120 second delay after any service start to let tomcat come up.
tomcat_wait:
  module.run:
    - name: test.sleep
    - length: 60

include:
  - jenkins.actions.version

Теперь у нас есть возможность перезагрузки, выполнив Actions.stop и Actions.start. У нас есть это состояние actions.ve rsion, которое мы можем использовать для проверки того, что система готова продолжить работу с конкретными рабочими процессами состояния jenkins.

Я хочу сделать что-то вроде этого...

 Install Jenkins --> Grab yaml of plugins --> install plugins that need it

Довольно прямо вперед.

За исключением того, чтобы пройтись по цепочке плагинов, я использую Jinja.
И теперь у меня нет возможности позвонить и быть уверенным, что состояния start.sls и ve rsion.sls можно применять повторно.

Я ищу, хороший способ сделать это.

Это было бы что-то вроде jenkins.sls

{% set repo_username = "foo" -%}
{% set repo_password = "bar" -%}

include:
  - jenkins.actions.version
  - jenkins.actions.stop
  - jenkins.actions.start

# Install Jenkins
jenkins:
  pkg:
    - installed

# Import Jenkins Plugins as List, and Working Path
{%- from 'jenkins/init.sls' import jenkins_home with context %}
{%- import_yaml "jenkins/plugins.sls" as jenkins_plugins %}
{%- import_yaml "jenkins/custom-plugins.sls" as custom_plugins %}
# Grab updated package list
jenkins-contact-update-server:
  cmd.run:
    - name: curl -L http://updates.jenkins-ci.org/update-center.json | sed '1d;$d' > {{ jenkins_home }}/updates/default.json
    - unless: test -d {{ jenkins_home }}/updates/default.json
    - require:
      - pkg: jenkins
      - service: tomcat
# Install plugins in jenkins_plugins list
{% for plugin in jenkins_plugins %}
jenkins-plugin-{{ plugin }}:
  cmd.run:
    - name: java -jar jenkins-cli.jar -s "http://127.0.0.1:8080" install-plugin "{{ plugin }}"
    - unless: java -jar jenkins-cli.jar -s "http://127.0.0.1:8080" list-plugins | grep "{{ plugin }}"
    - cwd: /var/lib/tomcat/webapps/ROOT/WEB-INF/
    - user: jenkins
    - require:
      - pkg: jenkins
      - service: tomcat

Вот где я застрял. Требовать не буду этого делать. и списки действий, кажется, не планируются линейно в соли. Мне нужно иметь возможность просто проверить, что Дженкинс готов и готов. Мне нужно иметь возможность перезапустить Tomcat после добавления одного плагина в итерации. Мне нужно быть в состоянии сделать это, чтобы удовлетворить зависимости в порядке плагинов.

      - sls: jenkins.actions.version
      - sls: jenkins.actions.stop
      - sls: jenkins.actions.start
#    This can't work for several reasons
#    - watch_in:
#      - sls: jenkins-safe-restart
{% endfor %}

# Install custom plugins in the custom_plugins list
{% for cust_plugin,cust_plugin_url in custom_plugins.iteritems() %}
# manually downloading the plugin, because jenkins-cli.jar doesn't seem to work direct to artifactory URLs.
download-plugin-{{ cust_plugin }}:
  cmd.run:
    - name: curl -o {{ cust_plugin }}.jpi -O "https://{{ repo_username }}:{{ repo_password }}@{{ cust_plugin_url }}"
    - unless: java -jar jenkins-cli.jar -s "http://127.0.0.1:8080" list-plugins | grep "{{ cust_plugin }}"
    - cwd: /tmp
    - user: jenkins
    - require:
      - pkg: jenkins
      - service: tomcat
# installing the plugin ( REQUIRES TOMCAT RESTART AFTER )
custom-plugin-{{ cust_plugin }}:
  cmd.run:
    - name: java -jar jenkins-cli.jar -s "http://127.0.0.1:8080" install-plugin /tmp/{{ cust_plugin }}.jpi
    - unless: java -jar jenkins-cli.jar -s "http://127.0.0.1:8080" list-plugins | grep "{{ cust_plugin }}"
    - cwd: /var/lib/tomcat/webapps/ROOT/WEB-INF/
    - user: jenkins
    - require:
      - pkg: jenkins
      - service: tomcat
{% endfor %}

Answer 1

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

Дженкинс Мастер получает развертывание

Напишите исполняемый модуль jenkins на python с функцией install(...):, В этой функции вы управляете любыми зависимостями, либо вызывая существующие исполняющие модули, либо сами их записывая.

Мы можем приступить к тестированию развертывания по мере его продолжения.

Внутри функции установки модуля jenkins вы запускаете определенные события в зависимости от результатов установки.

if not _run_deployment_phase(...):
    __salt__['event.send']('jenkins/install/error', {
            'finished': False,
            'message': "Something failed during the deployment!",
    })

Вы бы отобразили это событие в файлы slat реактора и обработали его.

Мы только перезапускаем Tomcat, когда это необходимо

Напишите модуль Tomcat. Добавить _is_up(...) Функция, в которой вы можете проверить, работает ли tomcat, путем анализа логов tomcat на результат. Вызовите функцию внутри модуля состояния и добавьте функцию mod_watch.

def mod_watch():
    # required dict to return
    return_dict = {
           "name": "Tomcat install",
           "changes": {}, 
           "result": False,
           "comment": "",
            }
    if __salt__["tomcat._is_up"]():
      return_dict["result"] = True
      return_dict["comment"] = "Tomcat is up."

    if __opts__["test"]:
        return_dict["result"] = None
        return_dict["comment"] = "comment here about what will change"
        return return_dict

    # execute changes now

    return return_dict

Используйте свой модуль состояния внутри файла состояния.

install tomcat:
  tomcat.install:
    - name: ...
    - user: ...
    ...

wait until tomcat is up:
  cmd.run:
    - name: ...
    - watch:
      - tomcat: install tomcat

Мы можем обновить плагины для каждого пакета

Добавьте в свой исполняющий модуль jenkins функцию с именем install_plugin. Посмотрите код pkg.install для репликации интерфейса.

Большой упор на хорошие чистые, интуитивно понятные солевые конфиги

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

Answer 2

Это довольно старый вопрос, но если вы измените процедуру запуска / остановки Jenkins / tomcat на стандартную службу init/systemd/windows (как и все хорошо работающие службы), вы можете получить service.running для службы Jenkins и добавьте это к каждому из ваших пользовательских плагинов -{{ cust_plugin }} состояний.

require_in: 
  - svc: jenkins
watch_in: 
  - svc: jenkins

Вы можете продолжать использовать модуль cmd.run с onchanges. Вам нужно добавить onchanges_in: к каждому из пользовательских плагинов -{{ cust_plugin }} состояний, но вам нужно иметь хотя бы один элемент в списке изменений, или команда будет срабатывать при каждом запуске состояния.

Answer 3

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

Вместо того, чтобы все это включать / требовать, что вы делаете, вы должны просто поместить весь код в один файл sls и генерировать состояния посредством итерации jinja.

Если то, что вы пытаетесь сделать, это добавить несколько плагинов, добавить файлы конфигурации, а затем в конце перезапустить, тогда вам действительно нужно просто выполнить все по порядку, не использовать require и использовать listen или listen_in, а не смотреть или смотреть

listen/listen_in приводит к тому, что инициируемые действия происходят в конце запуска состояния. Они похожи на концепцию обработчиков в Ansible.

Answer 4

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

Watch / watch_in также переупорядочит ваши состояния. Если вместо этого вы используете listen / listen_in, он будет ставить в очередь триггерные действия для выполнения в том порядке, в котором они были запущены в конце выполнения состояния.

Увидеть:

http://ryandlane.com/blog/2014/07/14/truly-ordered-execution-using-saltstack/ http://ryandlane.com/blog/2015/01/06/truly-ordered-execution-using-saltstack-part-2/