Глава 6. Условия управления задачами

Хотя условия ошибки могут быть тщательно заданы, всё же могут возникать ситуации при которых на самом деле происходят ошибки. Ansible предоставляет некий подход для реакции на действительно возникающие ошибки, метод, который выполняется всегда, даже когда произошла одна, а то и две. Данный метод является функциональностью объединения в блоки (blocks). Данная функциональность создания блоков была введена в версии Ansible 2.0 и она предоставила дополнительную структуру для её воспроизведения при задаче ожидания (listining). Блоки способны группировать задачи воедино в некий логический элемент, который способен выполнять контроль задач, применяемых к этому блоку целиком. Кроме того некий block задач может иметь необязательные разделы rescue и always.

Раздел rescue некого block определяет какой- то логический элемент задачи, который будет исполняться если внутри какого- то block на самом деле происходит сбой. Так как Ansible выполняет все задачи внутри некоторого block сверху вниз, когда встретится истинный отказ, исполнение перескочит на самую первую задачу имеющегося раздела rescue данного block, если она имеется. Затем задачи выполняются сверху вниз пока не будет достигнут самый конец этого раздела или не произойдёт новая ошибка.

После завершения такого раздела rescue, задача продолжит исполнение с тем, что поступает после данного block, как если бы не было никакой ошибки. Это предоставляет некий способ тщательной обработки ошибок, позволяя определять задачи очистки с тем, чтобы система не оставалась в полностью разрушенном состоянии и оставшееся воспроизведение могло бы продолжиться. Это намного яснее чем некий сложный набор зарегистрированных задачей результатов и задач условных зависимостей на основании состояния ошибки.

Для демонстрации такого решения, давайте создадим некий новый набор задач внутри некоторого block. Этот набор задач будет иметь внутри некую не обрабатываемую ошибку, которая вызовет переключение исполнения в имеющийся раздел rescue, в котором мы выполним некую задачу cleanup.

Мы также предоставим некую задачу после такого block, чтобы обеспечить продолжение исполнения. Мы повторно используем свой плейбук errors.yaml:

---
- name: error handling
  hosts: localhost
  gather_facts: false

  tasks:
    - block:
        - name: delete branch bad
          command: git branch -D badfeature
          args:
            chdir: /srv/app

        - name: this task is lost
          debug:
            msg: "I do not get seen"
 	   

Эти две перечисленные в нашем разделе block задачи исполняются в том порядке, в котором они определены. В случае возникновения в одной из них результата failed, будет исполнен следующий код rescue из block.

      rescue:
        - name: cleanup task
          debug:
            msg: "I am cleaning up"

        - name: cleanup task 2
          debug:
            msg: "I am also cleaning up"
 	   

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

    - name: task after block
      debug:
        msg: "Execution goes on"
 	   

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

 

Рисунок 6.13

Но не только имеющийся раздел rescue будет исполнен, также выполнится и оставшаяся часть данного воспроизведения и всё исполнение ansible-playbook было рассмотрено как успешное.

Помимо раздела rescue доступен и другой раздел с названием always. Этот раздел некоторого block будет всегда исполняться были ли ошибки, или нет. Такая функциональность удобна чтобы обеспечить текущее состояние некоторой системы всегда остающееся рабочим, будь некий block задач успешен или нет. Поскольку некоторые задачи какого- то block могут быть пропущены из- за ошибок, а некий раздел rescue исполняется только когда имеется какая- то ошибка, именно раздел always предоставляет обязательное гарантированное исполнение задачи в любом случае.

Давайте расширим наш предыдущий пример и добавим некий раздел always в наш block:

always:
  - name: most important task
    debug:
      msg: "Never going to let you down"
 	   

Повторно исполнив свой плейбук мы увидим отображённой свою дополнительную задачу:

 

Рисунок 6.14

Чтобы проверить что данный раздел always на самом деле всегда исполняется, мы можем поменять своё воспроизведение с тем чтобы наша задача git рассматривалась как успешная. В следующем фрагменте кода отображена самая первая его часть, подвергшаяся изменению:

---
- name: error handling
  hosts: localhost
  gather_facts: false

  tasks:
    - block:
        - name: delete branch bad
          command: git branch -D badfeature
          args:
            chdir: /srv/app
          register: gitout
          failed_when:
            - gitout.rc != 0
            - not gitout.stderr | search('branch.*not found')
 	   

Обратите внимание на изменённое условие failed_when, которое делает возможным запуск команды git без рассмотрения отказа. Оставшаяся часть данного плейбука (которую теперь следует собрать из предыдущих примеров) остаётся без изменений.

На этот раз, когда мы исполняем свой плейбук, наш раздел rescue пропускается, наша маскированная в прошлый раз задача исполняется, а наш always из block всё равно при этом получает управление:

 

Рисунок 6.15

Обратите внимание, что наша утраченная в прошлый раз задача теперь выполняется, ибо само условие отказа для задачи delete branch bad было изменено так чтобы оно более не претерпевало отказов в данном воспроизведении. Аналогичным образом наш раздел rescue более не требуется, а все прочие задачи (включая раздел always) выполняются ожидаемым образом.

До сих пор в этой главе мы сосредотачивались на аккуратной обработке ошибок, а также на изменении установленного по умолчанию поведения Ansible в соответствии с изменениями и отказами. Это всё хорошо подходит для задач, но что если вы запускаете Ansible в некой ненадёжной среде? Например, для достижения управляемых хостов может применяться плохая или имеющаяся лишь временно связь, либо хосты могут постоянно отключаться по какой- либо причине. Этот последний пример может быть динамически масштабируемой средой, которая способна увеличивать размеры при высокой нагрузке и отыгрывать обратно при более низких запросах для сбережения ресурсов.

К счастью, для обработки именно таких ситуаций было введено новое ключевое слово плейбука, ignore_unreachable, и оно гарантирует будут испробованы все задачи из нашей описи даже для хостов, которые помечены как недостижимые при самом исполнении некой задачи. Это лучше пояснит неким примером, а потому давайте опять воспользуемся своим плейбуком error.yaml для создания такой ситуации:

---
- name: error handling
  hosts: all
  gather_facts: false

  tasks:
  - name: delete branch bad
    command: git branch -D badfeature
    args:
      chdir: /srv/app
  - name: important task
    debug:
      msg: It is important we attempt this task!
 	   

Мы теперь намерены попытаться удалить подразделение badfeature из некого репозитория Git в двух удалённых хостах, определённых в нашей описи. Эти два хоста не существуют, естественно; они вымышленные, а потому мы знаем что они будут помечены как unreachable после попытки самой первой задачи. Несмотря на это, существует вторая задача, которая точно должна предпринять попытку если это вообще возможно. Давайте запустим этот плейбук и посмотрим что произойдёт:

 

Рисунок 6.16

Обратите внимание, что никогда не осуществлялась попытка important task - наше воспроизведение обрывалось после самой первой задачи, так как эти хосты вне досягаемости. Тем не менее, давайте воспользуемся нашим вновь выявленным флагом для изменения такого поведения. изменим свой код с тем, чтобы она выглядит как приведённый здесь код:

---
- name: error handling
  hosts: all
  gather_facts: false

  tasks:
  - name: delete branch bad
    command: git branch -D badfeature
    args:
      chdir: /srv/app
    ignore_unreachable: true
  - name: important task
    debug:
      msg: It is important we attempt this task!
 	   

На этот раз отметим, что даже хотя наши хосты и не достижимы при самой первой попытке, наша вторя задача всё же выполняется:

 

Рисунок 6.17

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

Циклы заслуживают особого упоминания в данной главе. До сих пор мы были сосредоточены на упралвении самим потоком некого плейбука в стиле его прохождения сверху вниз - мы изменяли различные условия, которые можно было вычислять по мере исполнения плейбука, а также нам приходилось сосредотачиваться на создании компактного действенного кода. Что же произойдёт, тем не менее, если у нас имеется отдельная задача, но её требуется исполнять для некого перечня данных; например, создание определённых учётных записей пользователей, или каталогов, а то и ещё нечто более сложное.

Циклы были изменены в Ansible 2.5 - вплоть до этого циклы обычно создавались такими ключевыми словами как with_items. Хотя и остаётся некая обратная совместимость, имеется также возможность перехода вместо этого к новому ключевому слову loop.

Давайте рассмотрим простой пример - нам требуется создать два каталога. Создадим loop.yaml следующим образом:

---
- name: looping demo
  hosts: localhost
  gather_facts: false

  tasks:
  - name: create a directory
    file:
      path: /srv/whiskey/alpha
      state: directory
  - name: create another directory
    file:
      path: /srv/whiskey/beta
      state: directory
 	   

После его исполнения, как и ожидалось, будут созданы два каталога:

 

Рисунок 6.18

Однако мы можем видеть что этот код повторяется и неэффективен. Вместо него мы можем внести изменения как- то так:

---
- name: looping demo
  hosts: localhost
  gather_facts: false

  tasks:
  - name: create a directory
    file:
      path: "{{ item }}"
      state: directory
    loop:
      - /srv/whiskey/alpha
      - /srv/whiskey/beta
 	   

Обратите внимание на применение специальной переменной item, которая теперь применяется для задания значения пути из элементов loop внизу каждой задачи. Теперь, когда мы запустим этот код, вывод будет выглядеть иначе:

 

Рисунок 6.19

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

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

Как результат, вы теперь должны быть способными изменять любую определённую задачу для предоставления особых условий после отказа Ansible в ней или рассматривать изменение как успешное. Это в особенности ценно когда выполняются команды оболочки, как мы уже продемонстрировали это в данной главе, а также при задании особых вариантов применения для имеющихся модулей. Теперь вы также должны иметь возможность организовывать свои задачи в блоки, гарантируя что при возникновении сбоев можно предпринять действия по восстановлению, которые в противном случае не стоило бы вовсе запускать. Наконец, теперь вы сможете писать компактные, эффективные плейбуки Ansible с применением циклов, устраняя необходимость в повторяющемся коде и длинных неэффективных плейбуках.

В своей следующей главе мы изучим применение ролей для организации задач, файлов, переменных и прочего содержимого.