linux:ansible:changed_when_and_failed_when []

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Ansible changed_when and failed_when examples ======

В этом посте мы увидим, как использовать условные операторы Ansible, такие как **when**, **changed_when**, **failed_when**, а также где их правильно использовать и как это работает. С помощью этих условных модулей Ansible предоставляет нам возможность определить, когда Ansible должен запускать определенную задачу или считать выполненную задачу успешной или неудачной.

Короче говоря, эти модули дают нам возможность заставить ansible что-то делать, когда определенное условие выполнено или удовлетворено.

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


===== Оператор Ansible when =====


Оператор Ansible when больше похож на оператор if в любом данном языке программирования. Он оценивает, выполнено ли условие.

Считайте, что у вас есть любое из следующих требований

- Вы хотите запускать задачу только в определенном окне
- Вы хотите запускать задачу на основе выходных данных другой задачи
- Вы хотите пропустить или продолжить установку, если версия операционной системы Linux или Ubuntu
- Вы хотите выполнять некоторые задачи по очистке диска при достижении порогового значения
- Вы хотите контролировать выполнение при достижении определенного значения в цикле

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

 

===== Как использовать оператор ansible when =====


Мы собираемся предоставить различные примеры того, как использовать ansible when statement , Вы можете выбрать для чтения любой пример, который вы хотели бы прочитать

 

==== Пример 1: Завершение работы серверов под управлением Debian ====

В следующем руководстве мы использовали инструкцию when и команду для выполнения. Команда будет выполняться только тогда, когда будет выполнено определенное условие, то есть именно тогда, когда операционной системой хоста является Debian

<code yaml>
tasks:
  - name: "shut down Debian flavored systems"
    command: /sbin/shutdown -t now
    when: ansible_os_family == "Debian"
</code>

 

 

==== Пример 2: Установите HTTPD, если httpd еще не установлен ====

Зная, что shell вернет сообщение об ошибке ** не найдено **, когда данная команда не установлена. Мы используем это как ключевое слово для поиска, чтобы определить установку httpd.В этом примере мы сначала проверяем, установлен ли уже “Apache httpd”, выполнив команду httpd через командную оболочку.  Выходные данные команды сохраняются в регистровой переменной с именем “'validatedhttpd'”.

Когда мы запустим следующий сборник задач, первая задача запустит команду httpd, и результат выполнения команды будет сохранен в регистровой переменной “validatehttpd'”.


Затем вторая задача, которая заключается в установке httpd с помощью модуля yum. Сначала выполним указанное нами условие when и посмотрим, ВЕРНО ли оно.

Следовательно, если в переменной register ошибка “не найдено”. Будет установлен HTTPD. Если есть что-то еще.  HTTPD не будет установлен, и задача будет пропущена.

<code>
--- 
- hosts: web
  tasks:
  - name: "Determine if the HTTPD is installed"
    register: validatehttpd
    shell: httpd

  - name: Ensure Apache is at the Latest version
    become: yes
    become_user: root
    yum:
      name: httpd
      state: latest
    when: 'not found' in validatehttpd.stdout
</code>

 

==== Пример 3: [Несколько условий в одном операторе when] Завершение работы только для CentOS-6 и Debian-7  ====

Наше требование здесь заключается в отключении только систем с ОС CentOS6 и Debian7. Итак, наш условный оператор должен быть следующим, как говорилось ранее, when больше похож на оператор if, поэтому он должен поддерживать несколько условий в одной проверке.

<code yaml>
(ansible_distribution == "CentOS" and ansible_distribution_major_version == "6") or
(ansible_distribution == "Debian" and ansible_distribution_major_version == "7")
</code>

 

> Здесь мы использовали функцию parenthesis ( ) для groupin

Playbook приведен ниже

<code yaml>
---
- hosts: all
  tasks:
  - name: "shut down CentOS 6 and Debian 7 systems"
    command: /sbin/shutdown -t now
    when: (ansible_distribution == "CentOS" and ansible_distribution_major_version == "6") or
          (ansible_distribution == "Debian" and ansible_distribution_major_version == "7")
</code>

Если нашим требованием является просто проверка, если дистрибутив ОС ** CentOS ** и версия **6 **, мы могли бы написать это следующим образом

<code bash>
tasks:
  - name: "shut down CentOS 6 systems"
    command: /sbin/shutdown -t now
    when:
      - ansible_distribution == "CentOS"
      - ansible_distribution_major_version == "6"
</code>


Что мы здесь делаем, так это указываем наши условия в списке, и ВСЕ ОНИ ДОЛЖНЫ БЫТЬ ИСТИННЫМИ для выполнения этой задачи



===== Операторы Ansible failed_when и changed_when =====

Операторы Ansible failed_when и changed_when аналогичны оператору ansible when.  Единственное отличие заключается в том, что при выполнении определенного условия задача будет помечена как ** failed ** или **Success **[изменено].

Основная цель операторов 'failed_when' и 'changed_when' - определить, действительно ли задача выполнена успешно или неудачно

Предположим, вы запускаете модуль 'command' или 'shell' с каким-то сложным скриптом или простой командой.

> Ansible сообщит об этом как об 'измененном' до тех пор, пока команда (или) скрипт не выдаст НУЛЕВОЙ код возврата.

Но как бы вы определили, была ли команда или скрипт выполнены успешно? или соответствовали вашим потребностям?

Например, когда вы запускаете серверы Weblogic (или) Tomcat с помощью некоторого сценария оболочки или команды. Ansible вызовет сценарий и сочтет его выполненным (или) измененным. Но вы никогда не узнаете, действительно ли это так, пока не выполните повторную проверку с помощью модуля 'wait_for' или 'debug'

Давайте посмотрим несколько практических примеров в реальном времени для операторов failed_when и changed_when в следующем разделе


===== Как использовать оператор ansible changed_when =====

==== Пример 1: Запустите HTTPD (или) сервер Apache, который уже запущен ====

Сказав это, давайте начнем с нашей пробной версии - мы собираемся запустить HTTPD (или) сервер Apache, который уже запущен. В идеале, если он уже запущен, он не должен сообщать как ** измененный**

** Шаг 1: ** Убедитесь, что он уже запущен, вызвав команду 'ps -eaf | grep -i httpd' как 'ad-hoc'

{{ :linux:ansible:screen-shot-2018-09-23-at-12.24.43-am.png |}}

** Шаг 2: ** Используйте следующую инструкцию с заданием для запуска сервера HTTPD

<code yaml>
--- 
- hosts: web
  tasks:
   - name: "Start the Apache HTTPD Server"
     become: true
     become_user: root
     shell: "httpd -k start"
</code>

{{ :linux:ansible:screen-shot-2018-09-23-at-12.30.58-am.png |}}

Как вы могли видеть на предыдущем снимке выходных данных выполнения, задача запуска httpd-сервера была помечена как измененная, несмотря на то, что на самом деле она не запускала apache, а он уже был запущен.

** Шаг 2a: ** Модифицированный сборник пьес с включенной отладкой

Чтобы узнать правду, вы должны изменить playbook с помощью debug и зарегистрироваться следующим образом

<code yaml>
--- 
- hosts: web
  tasks:
    - name: "Start the Apache HTTPD Server"
      become: true
      become_user: root
      register: starthttpdout
      shell: "httpd -k start"
      

    - debug:
        msg: "{{starthttpdout.stdout}}"
</code>

Результаты выполнения предыдущей пьесы приведены ниже

{{ :linux:ansible:screen-shot-2018-09-23-at-12.37.52-am.png |}}

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

Здесь появляется 'changed_when', чтобы явно указать ansible, когда считать задачу успешной (или) измененной.

Давайте повторно модифицируем наш тот же Сценарий с помощью 'changed_when'.

** Шаг 3: ** Измененный сборник пьес с помощью changed_when.

<code yaml>
--- 
- hosts: web
  tasks:
  - name: "Start the Apache HTTPD Server"
    become: true
    become_user: root
    register: starthttpdout
    shell: "httpd -k start"
    changed_when: "'already running' not in starthttpdout.stdout"

  - debug:
      msg: "{{starthttpdout.stdout}}"
</code>

Мы только что добавили одну строку в нашу предыдущую версию playbook.

> changed_when: “‘уже запущенный’ отсутствует в starthttpdout.стандартный вывод”

Результаты выполнения нашего нового сборника приведены ниже

{{ :linux:ansible:screen-shot-2018-09-23-at-12.51.01-am.png |}}

Теперь вы можете заметить, что задание ЗЕЛЕНОГО цвета, а не ЖЕЛТОГО. Другими словами, оно ** без изменений**

===== Пример 2: Установка зависимостей с помощью PHP Composer =====

При использовании PHP Composer в качестве команды для установки зависимостей проекта полезно знать, когда Composer что-то установил или когда ничего не изменилось. Вот пример:

<code yaml>
- name: Install dependencies via Composer.
  command: "/usr/local/bin/composer global require phpunit/phpunit --prefer-dist"
  register: composer
  changed_when: "'Nothing to install or update' not in composer.stdout"
</code>

 

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

Только когда Composer ничего не делает, он выводит “Ничего для установки или обновления”, поэтому мы используем эту строку, чтобы определить или сообщить Ansible, привела ли задача к изменению.


===== Как использовать оператор ansible failed_when =====

==== Пример 1: Проверка системных требований / предварительных условий перед установкой ====

 
Это сценарий более реального времени, с которым каждый из нас, возможно, сталкивался во время установки программного обеспечения, на полпути мастер установки завершается сбоем, сообщая, что недостаточно памяти (или) не соблюдены минимальные системные требования для установки этого конкретного программного обеспечения.

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

В нашем случае мы собираемся взять установку сервера приложений weblogic в качестве примера.

Согласно рекомендациям oracle, для правильной работы weblogic 12c и беспроблемной установки система должна соответствовать следующим требованиям:

  * 2 ГБ физической памяти (RAM)
  * Минимум 4 ГБ дискового пространства в каталоге домена '/opt'
  * Минимум 1 ГБ дискового пространства в каталоге '/tmp'

Теперь мы собираемся выполнить быструю предварительную проверку с помощью ansible **failed_when ** и определить, выполнены ли системные требования, указанные выше.

Рассмотрим следующий план действий.

<code yaml>
---
- hosts: app
  tasks:
  - name: Making sure the /tmp has more than 1gb
    shell: "df -h /tmp|grep -v Filesystem|awk '{print $4}'|cut -d G -f1"
    register: tmpspace
    failed_when: "tmpspace.stdout|float < 1"

  - name: Making sure the /opt has more than 4gb
    shell: "df -h /opt|grep -v Filesystem|awk '{print $4}'|cut -d G -f1"
    register: tmpspace
    failed_when: "tmpspace.stdout|float < 4"

  - name: Making sure the Physical Memory more than 2gb
    shell: "cat /proc/meminfo|grep -i memtotal|awk '{print $2/1024/1024}'"
    register: memory
    failed_when: "memory.stdout|float < 2"
</code>

Руководство по воспроизведению было создано именно для проверки того, соответствует ли система рекомендованным oracle системным требованиям.

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

Результаты выполнения сборника пьес приведены ниже

{{ :linux:ansible:ansible_failedwhen-1024x254.png |}}

Как показано на предыдущем снимке, последнее требование - физической памяти недостаточно (или) не соответствует нашему требованию в 2 ГБ. Вы можете заметить, что система построена с использованием 1 ГБ в 'стандартном выводе' сообщения об ошибке.

Мы приходим к выводу, поскольку мы уже подробно обсуждали все три условных оператора, такие как when, failed_when и changed_when, с примерами.

Надеюсь, это полезно и имеет смысл.
Инструменты пользователя

Инструменты сайта

Инструменты страницы
