2015-11-24 15 views
1

У меня есть получил анзибль сборник пьес для развертывания Дженкинс, где Дженкинс config.xml шаблон jinja2 файл содержит этот фрагмент кода для аутентификации AD:Как сделать этот незаменимый сценарий jenkins idempotent, когда jenkins переписывает свою конфигурацию?

<securityRealm class="hudson.plugins.active_directory.ActiveDirectorySecurityRealm" plugin="[email protected]"> 
    <domain>{{ ldap_hostname }}/domain> 
    <bindName>{{ ldap_bind_user }}</bindName> 
    <bindPassword>{{ ldap_password }}</bindPassword> 
    <server>{{ ldap_hostname }}:{{ ldap_port }}</server> 
    <groupLookupStrategy>RECURSIVE</groupLookupStrategy> 
    <removeIrrelevantGroups>false</removeIrrelevantGroups> 
</securityRealm> 

{{ ldap_password }} является открытым текстом пароль приходит из хранилища.

Проблема заключается в том, что, когда jenkins запускается после развертывания config.xml, он перезаписывает его, заменяя чистый текстовый пароль на хэш-код пароля. (Хэш, похоже, зависит от целевого хоста, так как мы получаем разные хэши на разных виртуальных машинах). В то время как это хорошо в целом, это заставляет каждое исполнение playbook отмечать операцию шаблона как измененную.

Как я могу сделать этот скрипт идемпотент?

ответ

4

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

У вас есть несколько вариантов здесь, в зависимости от того, как «правильно» вы хотите быть с этим.

Прежде всего, вы можете просто сказать Ansible, что вас не волнует, внесли ли вы какие-либо изменения в этот файл, и поэтому всегда отмечайте неизменным (зеленый). Вы можете сделать это с помощью changed_when: False по задаче.

В качестве альтернативы вы можете сказать, что хотите только создать шаблон для этого файла при первом запуске, а после этого он находится вне рук Ansible. Такой подход полезен при загрузке объектов, которые затем хотят управлять своими собственными файлами, и вы никогда не захотите снова их менять. Для этого вы могли бы уйти с чем-то вроде:

- name: check if jenkins config.xml file is there 
    stat: 
    path: path/to/config.xml 
    register: config-xml_stat 

- name: template jenkins config.xml if not already there 
    template: 
    src: path/to/config.xml.j2 
    dest: path/to/config.xml 
    when: config-xml_stat.exists == false 

Думая о проблеме вы шаблонирования что-то и затем активно ожидая определенную линию, чтобы изменить из-за пределов контроля анзибль в. Другим вариантом здесь будет шаблон файла в поле для другого пути к файлу, чем ожидал Дженкинс (который затем может быть идемпотентом, как обычно), diff это с файлом, который использует Дженкинс, а затем, если что-то другое, кроме этой строки, отличается скопируйте верхнюю часть файла Jenkins. Вы могли бы использовать что-то вроде этого, чтобы сделать это:

- name: template jenkins config.xml.template 
    template: 
    src: path/to/config.xml.j2 
    dest: path/to/config.xml.template 

# We are expecting bindPassword to have changed so we can exclude this from the diff line count 
- name: diff jenkins config.xml and config.xml.template 
    shell: diff path/to/config.xml.template path/to/config.xml | grep -v bindPassword | wc -l 
    register: config-xml_diff 

# Diff will also output 2 extra lines that we don't care about. If there's more lines than this then we need to retemplate the config.xml 
- name: template jenkins config.xml 
    template: 
    src: path/to/config.xml.j2 
    dest: path/to/config.xml 
    when: config-xml_diff.stdout != 2 

Последний является немного более неуклюжим и громоздким, но «правильнее», как он активно проверять, если файл изменился больше, чем мы ожидаем, что для и если так изменить шаблон.

Если вы решите спуститься по третьему маршруту, я бы предложил объединить чек, чтобы узнать, существует ли он из второго варианта, чтобы сделать его более очевидным в том, что он делает. Без него, если файл config.xml не существует, ваша задача diff выведет одну строку (diff: config.xml: No such file or directory), которая тогда все равно будет означать, что условная оценка вашей третьей задачи в порядке, но это немного вводит в заблуждение.

+0

За исключением «changed_when: false», который я не намерен использовать в этом сценарии, я думаю, что ваши предложения имеют большой смысл. Я поеду на третий вариант и посмотрю, как он себя ведет. –