21. 워크플로우¶

21.1. 워크플로우 시나리오 및 고려 사항¶

워크플로우를 빌드하는 경우 다음 시나리오를 고려하십시오.

• 기본적으로 루트 노드는 ‘항상’으로 설정되어 있으며 편집할 수 없습니다.

• 한 노드에 상위가 여러 개 있을 수 있고 하위는 성공, 실패 또는 항상 상태와 연결될 수 있습니다. ‘항상’ 상태는 성공도 실패도 아닙니다. 상태는 워크플로우 작업 템플릿 수준이 아닌 노드 수준에서 적용됩니다. 워크플로우 작업은 취소되거나 오류가 발생하지 않는 한 성공으로 표시됩니다.

• 워크플로우 내의 작업 또는 워크플로우 템플릿을 제거하면 이 삭제된 노드에 이전에 연결되었던 노드가 자동으로 업스트림에 연결되고 아래와 같이 에지 유형을 유지합니다.

• 여러 작업이 하나로 수렴되는 통합 워크플로우가 있을 수 있습니다. 이 시나리오에서는 아래와 같이 다음 항목이 실행되기 전에 특정 작업 또는 모든 작업을 완료해야 합니다.

  

제공된 예에서 |at|는 처음 두 개의 작업 템플릿을 병렬로 실행합니다. 지정된 대로 둘 다 완료하고 성공하면 세 번째 다운스트림(convergence node)이 트리거됩니다.

• 워크플로우 작업 템플릿의 워크플로우 노드에는 인벤토리 및 설문 조사에 대한 입력 요청이 적용됩니다.

• API에서 시작하는 경우 get 명령을 실행하면 경고 목록이 표시되고 누락된 구성 요소가 강조 표시됩니다. 워크플로우 작업 템플릿의 기본 워크플로우는 다음과 같습니다.

• 여러 워크플로우를 동시에 시작하고 시작 스케줄을 설정할 수 있습니다. 작업 템플릿과 유사하게 워크플로우에 대한 알림(예: 작업 완료 시)을 설정할 수 있습니다.

• 재귀 워크플로우를 빌드할 수는 있지만 |at|에서 오류를 탐지하는 경우 중첩된 워크플로우가 실행되려고 할 때 중지됩니다.

• Artifacts gathered in jobs in the sub-workflow will be passed to downstream nodes.

• 인벤토리는 워크플로우 수준에서 설정하거나 시작 시 인벤토리를 입력하도록 요청할 수 있습니다.

• 시작된 경우 ``ask_inventory_on_launch=true``가 설정된 워크플로우의 모든 작업 템플릿에서 워크플로우 수준 인벤토리를 사용합니다.

• 인벤토리를 입력하도록 요청하지 않는 작업 템플릿은 워크플로우 인벤토리를 무시하고 자체 인벤토리에 대해 실행됩니다.

• 워크플로우에서 인벤토리를 입력하도록 요청하는 경우 스케줄 및 기타 워크플로우 노드에서 인벤토리를 제공할 수 있습니다.

• 워크플로우 통합 시나리오에서는 set_stats 데이터가 정의되지 않은 방식으로 병합되므로 고유 키를 설정하는 것이 좋습니다.

21.2. 추가 변수¶

워크플로우는 작업 템플릿과 유사하게 설문 조사를 사용하여 워크플로우의 플레이북에서 사용할 extra_vars라는 변수를 지정합니다. 설문 조사 변수는 워크플로우 작업 템플릿에 정의된 extra_vars와 결합되고, 워크플로우 작업 extra_vars에 저장됩니다. 워크플로우 작업의 extra_vars는 워크플로우 내에서 작업을 생성할 때 작업 템플릿 변수와 결합됩니다.

워크플로우는 세 가지 추가 변수를 제외하고 작업 템플릿과 동일한 변수 우선순위 동작(계층 구조)을 사용합니다. 이 가이드의 작업 템플릿 장, 추가 변수 섹션에서 변수 우선순위 계층 구조를 참조하십시오. 세 가지 추가 변수는 다음과 같습니다.

하나의 워크플로우에 포함된 여러 워크플로우는 동일한 변수 우선순위를 따르고, 특별히 요청하거나 설문 조사의 일부로 정의한 경우에만 변수를 상속합니다.

워크플로우 extra_vars 외에도 워크플로우의 일부로 실행된 작업과 워크플로우는 워크플로우의 상위 작업 아티팩트 사전에 있는 변수를 상속할 수 있습니다(해당 분기에서 더 업스트림에 있는 상위와도 결합). 해당 사항은 set_stats `Ansible module`_로 정의할 수 있습니다.

플레이북에서 set_stats 모듈을 사용하면 다른 작업에서 다운스트림으로 사용할 수 있는 결과를 생성할 수 있습니다(예: 사용자에게 통합 실행의 성공 또는 실패에 대해 알림). 이 예제에는 아티팩트를 전달하도록 워크플로우에 결합할 수 있는 두 개의 플레이북이 있습니다.

• invoke_set_stats.yml: 워크플로우의 첫 번째 플레이북

---
- hosts: localhost
  tasks:
    - name: "Artifact integration test results to the web"
      local_action: 'shell curl -F "file=@integration_results.txt" https://file.io'
      register: result

    - name: "Artifact URL of test results to Workflows"
      set_stats:
        data:
          integration_results_url:  "{{ (result.stdout|from_json).link }}"

• use_set_stats.yml: 워크플로우의 두 번째 플레이북

---
- hosts: localhost
  tasks:
    - name: "Get test results from the web"
      uri:
        url: "{{ integration_results_url }}"
        return_content: true
      register: results

    - name: "Output test results"
      debug:
        msg: "{{ results.content }}"

set_stats 모듈은 이 워크플로우를 다음과 같이 처리합니다.

1. 통합 결과 내용(예: 아래의 integration_results.txt)은 먼저 웹에 업로드됩니다.

the tests are passing!

2. 그러면 invoke_set_stats 플레이북을 통해 ``set_stats``가 호출되어 업로드된 integration_results.txt의 URL이 Ansible 변수 《integration_results_url》로 전환됩니다.

3. 워크플로우의 두 번째 플레이북에서는 Ansible 추가 변수 《integration_results_url》을 사용합니다. uri 모듈로 웹을 호출하여 이전 작업 템플릿 작업에서 업로드한 파일의 내용을 가져옵니다. 그런 다음 가져온 파일의 내용을 간단히 출력합니다.

21.3. 워크플로우 상태¶

워크플로우 작업에는 다음과 같은 상태가 있을 수 있습니다(실패 상태 없음).

• 대기 중

• 실행 중

• 성공(완료)

• 취소

• 오류

• 실패

워크플로우 구성에서 작업을 취소하면 분기가 취소되고, 워크플로우 작업을 취소하면 전체 워크플로우가 취소됩니다.

21.4. 역할 기반 액세스 제어¶

워크플로우 작업 템플릿을 편집하고 삭제하려면 관리자 역할이 있어야 합니다. 워크플로우 작업 템플릿을 생성하려면 조직 관리자 또는 시스템 관리자여야 합니다. 그러나 권한이 없는 작업 템플릿이 포함된 워크플로우 작업 템플릿을 실행할 수 있습니다. 프로젝트와 유사하게 조직 관리자는 빈 워크플로우를 생성한 다음 하위 수준 사용자에게 〈admin_role’을 부여한 후 더 많은 액세스 권한을 위임하고 그래프를 빌드할 수 있습니다. 작업 템플릿을 워크플로우 작업 템플릿에 추가하려면 작업 템플릿에 대한 실행 액세스 권한이 있어야 합니다.

특정 사용자에게 부여된 권한 종류에 따라 워크플로우 복제 및 다시 시작 기능과 같은 기타 작업도 수행할 수 있습니다. 일반적으로 다시 시작하거나 복사하려면 워크플로우에서 사용되는 모든 리소스(예: 작업 템플릿)에 대한 권한이 있어야 합니다.

이 섹션에 설명된 작업을 수행하는 방법에 대한 자세한 내용은 :ref:`Administration Guide <administration:ag_start>`를 참조하십시오.