19. 작업 템플릿¶

19.1. 작업 템플릿 생성¶

새 작업 템플릿을 생성하려면 다음을 수행합니다.

1. 추가 버튼을 클릭한 다음 메뉴 목록에서 **작업 템플릿**을 선택합니다.

2. 다음 필드에 적절한 세부 정보를 입력합니다.

• 이름: 작업의 이름을 입력합니다.

• 설명: 임의의 설명을 적절하게 입력합니다(선택 사항).

• 작업 유형: 작업 유형을 선택합니다.

• 실행: 시작 시 플레이북을 실행하여 선택한 호스트에서 Ansible 작업을 실행합니다.

• 확인: 플레이북의 《시험 실행》을 수행하고 실제로 변경하지 않은 채 변경할 사항을 보고합니다. 확인 모드를 지원하지 않는 작업은 건너뛰고 잠재적인 변경 사항을 보고하지 않습니다.

• 시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 실행 또는 확인 작업 유형을 선택하라는 메시지가 표시됩니다.

참고

작업 유형에 대한 자세한 내용은 Ansible 문서의 Playbooks: Special Topics 섹션에서 확인할 수 있습니다.

• 인벤토리: 현재 로그인한 사용자에게 제공되는 인벤토리에서 이 작업 템플릿에 사용할 인벤토리를 선택합니다.

• 시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 이 작업 템플릿을 실행할 인벤토리를 선택하라는 메시지가 표시됩니다.

• 프로젝트: 현재 로그인한 사용자에게 제공되는 프로젝트에서 이 작업 템플릿에 사용할 프로젝트를 선택합니다.

• SCM 분기: 이 필드는 분기 덮어쓰기를 허용하는 프로젝트를 선택한 경우에만 표시됩니다. 작업 실행에 사용할 덮어쓰기 분기를 지정합니다. 비워 두는 경우 프로젝트의 지정된 SCM 분기(또는 커밋 해시나 태그)가 사용됩니다. 자세한 내용은 :ref:`job branch overriding <ug_job_branching>`를 참조하십시오.

  • 시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 SCM 분기를 선택하라는 메시지가 표시됩니다.

• 플레이북: 사용 가능한 플레이북에서 이 작업 템플릿으로 시작할 플레이북을 선택합니다. 이 필드는 선택한 프로젝트의 프로젝트 기본 경로에 있는 플레이북 이름으로 자동으로 채워집니다. 또는 목록에 없는 경우 해당 플레이북으로 실행하는 데 사용할 파일 이름(예: foo.yml)과 같이 플레이북 이름을 입력하면 됩니다. 유효하지 않은 파일 이름을 입력하면 템플릿에 오류가 표시되거나 작업이 실패합니다.

• 인증 정보: 버튼을 클릭하면 별도의 창이 열립니다. 사용 가능한 옵션에서 이 작업 템플릿에 사용할 인증 정보를 선택합니다. 목록이 긴 경우 드롭다운 메뉴 목록을 사용하여 인증 정보 유형으로 필터링합니다.

• 시작 시 프롬프트: 선택한 경우 기본 머신 인증 정보가 있는 작업 템플릿을 시작할 때 프롬프트 대화 상자의 기본 머신 인증 정보는 작업 템플릿을 시작하기 전에 다른 머신 인증 정보로 교체하는 경우에만 제거할 수 있습니다. 또는 적절하다고 판단되는 인증 정보를 추가할 수 있습니다. 다음은 이러한 메시지의 예입니다.

  

• 포크: 플레이북을 실행하는 동안 사용할 병렬 또는 동시 프로세스 수입니다. 값이 0이면 ``/etc/ansible/ansible.cfg``에서 덮어쓰지 않는 한 Ansible 기본 설정인 병렬 프로세스 5개를 사용합니다.

• 제한: 플레이북에서 관리하거나 영향을 주는 호스트 목록을 추가로 제한하는 호스트 패턴입니다. 패턴이 여러 개인 경우 콜론(《:》)으로 구분할 수 있습니다. 핵심 Ansible과 마찬가지로 《a:b》는 《그룹 a 또는 b에 있음》, 《a:b:&c》는 《a 또는 b에 있으면서 c에 있어야 함》, 《a:!b》는 《a에 있고 b에는 분명히 없음》을 나타냅니다.

• 시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 제한을 선택하라는 메시지가 표시됩니다.

  참고

  자세한 내용 및 예제는 Ansible 문서의 `Patterns <http://docs.ansible.com/intro_patterns.html>`_을 참조하십시오.

• 상세 정보 표시: 플레이북을 실행할 때 Ansible에서 생성하는 출력 수준을 제어합니다. 일반에서 다양한 상세 정보 표시까지 중에서 또는 디버그 설정에서 세부 정보 표시를 선택합니다. 《세부 정보》 보고서 뷰에만 표시됩니다. 상세 로깅에는 모든 명령 출력이 포함됩니다. 디버그 로깅은 매우 상세하며 특정 지원 인스턴스에서 유용할 수 있는 SSH 작업에 대한 정보를 포함합니다. 대부분의 사용자는 디버그 모드 출력을 볼 필요가 없습니다.

  경고

  상세 정보 표시 5를 설정하면 작업이 실행 중일 때 |at|에서 심각하게 차단하여 작업 완료 보고가 지연될 수 있고 브라우저 탭이 잠길 수 있습니다.

• 시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 상세 정보 표시를 선택하라는 메시지가 표시됩니다.

• 작업 태그: 플레이북에서 실행할 부분을 지정하기 위해 쉼표로 구분된 플레이북 태그 목록을 제공합니다. 자세한 내용 및 예제는 Ansible 문서의 `Tags <http://docs.ansible.com/playbooks_tags.html>`_를 참조하십시오.

• 시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 작업 태그를 선택하라는 메시지가 표시됩니다.

• 태그 건너뛰기: 실행할 플레이북의 특정 작업 또는 일부를 건너뛰도록 쉼표로 구분된 플레이북 태그 목록을 제공합니다. 자세한 내용 및 예제는 Ansible 문서의 `Tags <http://docs.ansible.com/playbooks_tags.html>`_를 참조하십시오.

• 시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 건너뛸 태그를 선택하라는 메시지가 표시됩니다.

• 레이블: ‘dev’ 또는 《test》와 같이 이 작업 템플릿을 설명하는 선택적 레이블을 제공합니다. 레이블은 해당 디스플레이에서 작업 템플릿 및 완료된 작업을 그룹화하고 필터링하는 데 사용할 수 있습니다.

• 레이블은 작업 템플릿에 추가할 때 생성됩니다. 레이블은 작업 템플릿에 제공되는 프로젝트를 사용하여 단일 조직에 연결됩니다. 조직 멤버는 편집 권한이 있는 경우(예: 관리자 역할) 작업 템플릿에 레이블을 생성할 수 있습니다.

• 작업 템플릿이 저장되면 작업 템플릿 개요의 펼쳐진 뷰에 레이블이 표시됩니다.

• 제거하려면 레이블 옆에 있는 《x》를 클릭합니다. 제거되어 더 이상 작업 또는 작업 템플릿과 연결되지 않는 레이블은 조직 레이블 목록에서 영구적으로 삭제됩니다.

• 작업은 시작 시 작업 템플릿에서 레이블을 가져옵니다. 작업 템플릿에서 삭제된 레이블은 작업에서도 삭제됩니다.

• 인스턴스 그룹: 버튼을 클릭하면 별도의 창이 열립니다. 이 작업 템플릿을 실행할 인스턴스 그룹을 선택합니다. 목록이 긴 경우 검색을 사용하여 옵션 범위를 좁힙니다.

• 작업 슬라이스: 이 작업 템플릿을 실행할 슬라이스 수를 지정합니다. 각 슬라이스는 인벤토리 일부에 대해 동일한 작업을 실행합니다. 작업 슬라이스에 대한 자세한 내용은 :ref:`ug_job_slice`을 참조하십시오.

• 시간 초과: 작업이 취소되기 전에 작업을 실행할 수 있는 시간(초)을 지정할 수 있습니다. 작업 시간 초과 기본값은 0입니다.

• 변경 사항 표시: Ansible 작업에서 변경한 내용을 볼 수 있습니다.

• 시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 변경 사항 표시 여부를 선택하라는 메시지가 표시됩니다.

• 옵션: 《dev》 또는 《test》와 같이 이 작업 템플릿을 설명하는 선택적 레이블을 제공합니다. 레이블은 해당 디스플레이에서 작업 템플릿 및 완료된 작업을 그룹화하고 필터링하는 데 사용할 수 있습니다.

• 권한 에스컬레이션 활성화: 활성화하면 이 플레이북을 관리자로 실행합니다. 이 설정은 --become 옵션을 ansible-playbook 명령에 전달하는 것과 같습니다.

• 프로비저닝 콜백 활성화: 호스트에서 REST API를 통해 |at|로 콜백하고 이 작업 템플릿에서 작업 시작을 호출하도록 활성화합니다. 자세한 내용은 :ref:`ug_provisioning_callbacks`을 참조하십시오.

• Webhook 활성화: 작업 템플릿을 시작하는 데 사용되는 사전 정의된 SCM 시스템 웹 서비스와 연결하는 기능을 켭니다. 현재 지원되는 SCM 시스템은 GitHub와 GitLab입니다.

Webhook를 활성화하면 다른 필드가 표시되면서 추가 정보를 요청합니다.

• Webhook 서비스: Webhook에서 수신 대기할 서비스를 선택합니다.

• Webhook 인증 정보: 필요한 경우 Webhook 서비스로 상태 업데이트를 다시 보내는 데 사용할 인증 정보로 GitHub 또는 GitLab PAT(개인 액세스 토큰)을 제공합니다. 인증 정보를 선택하려면 인증 정보가 있어야 합니다. 인증 정보를 생성하려면 :ref:`ug_credentials_cred_types`을 참조하십시오.

저장 시 추가 필드가 표시되고 보거나 편집하는 동안 그대로 유지됩니다.

• Webhook URL: 요청을 POST하는 Webhook 서비스의 URL이 자동으로 채워집니다.

• Webhook 키: |at|로 보낸 페이로드에 서명하는 데 Webhook 서비스에서 사용하도록 생성된 공유 비밀입니다. |at|에서 이 서비스의 Webhook를 수락하려면 Webhook 서비스의 설정에 구성해야 합니다.

Webhook 설정에 대한 자세한 내용은 :ref:`ug_webhooks`을 참조하십시오.

• 동시 작업 활성화: 서로 의존하지 않는 경우 대기열의 작업을 동시에 실행할 수 있습니다. 작업 슬라이스를 동시에 실행하려면 이 박스를 선택합니다. 자세한 내용은 :ref:`ug_job_concurrency`을 참조하십시오.

• 사실 캐시 활성화: 활성화하면 |at|에서 작업 실행과 관련된 인벤토리의 모든 호스트에 대해 Ansible 사실 캐시 플러그인을 활성화합니다.

• 추가 변수:

• 플레이북에 추가 명령행 변수를 전달합니다. 관련 변수인 ansible-playbook의 《-e》 또는 《–extra-vars》 명령행 매개변수는 `Passing Variables on the Command Line <http://docs.ansible.com/playbooks_variables.html#passing-variables-on-the-command-line>`__의 Ansible 문서에 설명되어 있습니다.

• YAML 또는 JSON을 사용하여 키/값 쌍을 제공합니다. 이러한 변수에는 우선순위 최대값이 있으며 다른 위치에 지정된 다른 변수를 덮어씁니다. 값은 다음과 같을 수 있습니다.

  git_branch: production
  release_version: 1.5
  

자세한 내용은 :ref:`ug_jobtemplates_extravars`를 참조하십시오.

• 시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 명령행 변수를 선택하라는 메시지가 표시됩니다.

3. 작업 템플릿 세부 정보 구성을 완료한 경우 **저장**을 클릭합니다.

템플릿을 저장해도 작업 템플릿 페이지는 종료되지 않으며, 필요한 경우 추가 편집을 위해 작업 템플릿 세부 정보 뷰에 남아 있습니다. 템플릿을 저장한 후에는 시작**을 클릭하여 작업을 시작하거나 템플릿에 대한 특성(예: 권한, 알림)을 추가하고, 완료된 작업을 보고, 설문 조사를 추가(작업 유형이 검사가 아닌 경우)할 수 있습니다. 시작하기 전에 템플릿을 먼저 저장해야 합니다. 그러지 않으면 **시작 버튼이 회색으로 유지되어 사용 불가능합니다.

화면 하단의 템플릿 목록에 새로 생성한 템플릿이 표시되면 템플릿이 저장된 것입니다.

19.2. 권한 추가¶

1. 액세스 탭에서 추가 버튼을 클릭합니다.

2. 추가할 사용자 또는 팀을 선택하고 **다음**을 클릭합니다.

3. 이름 옆에 있는 체크박스를 클릭하여 목록에서 하나 이상의 사용자 또는 팀을 선택하여 멤버로 추가하고 **다음**을 클릭합니다.

이 예에서는 두 명의 사용자를 추가하도록 선택했습니다.

4. 선택한 사용자 또는 팀에 부여할 역할을 선택합니다. 전체 역할 목록을 보려면 아래로 스크롤하십시오. 리소스에 따라 다양한 옵션을 사용할 수 있습니다.

5. 저장 버튼을 클릭하여 선택한 사용자 또는 팀에 역할을 적용하고 멤버로 추가합니다.

사용자/팀 추가 창이 닫히고 각 사용자 및 팀에 할당된 역할이 업데이트되어 표시됩니다.

특정 사용자의 역할을 제거하려면 리소스 옆에 있는 연결 해제(x) 버튼을 클릭합니다.

그러면 연결을 해제할지 묻는 확인 대화 상자가 열립니다.

19.3. 알림 작업¶

알림 탭을 클릭하면 설정한 알림 통합을 검토할 수 있습니다.

특정 템플릿에 사용할 알림을 활성화하거나 비활성화하려면 토글을 사용합니다. 자세한 내용은 :ref:`ug_notifications_on_off`를 참조하십시오.

알림이 설정되지 않은 경우 회색 박스 내부에 있는 알림 링크를 클릭하여 새 알림을 생성합니다.

다양한 알림 유형 구성에 대한 자세한 내용은 :ref:`ug_notifications_types`을 참조하십시오.

19.4. 완료된 작업 보기¶

완료된 작업 탭에는 실행된 작업 템플릿 목록이 있습니다. 작업의 상태, ID, 이름을 포함하여 각 작업의 세부 정보(작업 유형, 시작 및 완료 시간, 작업을 시작한 사용자, 사용된 템플릿, 인벤토리, 프로젝트, 인증 정보)를 보려면 **펼치기**를 클릭합니다. 이러한 기준 중 하나를 사용하여 완료된 작업 목록을 필터링할 수 있습니다.

이 목록에 표시되는 분할된 작업에는 실행된 분할 작업 수로 적절하게 레이블이 지정됩니다.

19.5. 스케줄링¶

스케줄 탭에서 특정 작업 템플릿의 스케줄에 액세스합니다.

19.5.1. 작업 템플릿 스케줄¶

작업 템플릿 실행을 스케줄하려면 스케줄 탭을 클릭합니다.

• 스케줄이 이미 설정되어 있는 경우 스케줄 기본 설정을 검토, 편집 또는 활성화/비활성화합니다.

• 스케줄이 설정되지 않은 경우 :ref:`ug_scheduling`에서 자세한 내용을 참조하십시오.

인증 정보 필드에 대해 시작 시 프롬프트**를 선택한 경우 작업 템플릿에 대한 스케줄 정보를 생성하거나 편집하면 스케줄 양식 하단에 **프롬프트 버튼이 표시됩니다. 프롬프트 대화 상자의 기본 머신 인증 정보는 작업 템플릿을 저장하기 전에 다른 머신 인증 정보로 교체하는 경우에만 제거할 수 있습니다. 다음은 이러한 메시지의 예입니다.

참고

스케줄에 ``extra_vars``를 설정하려면 작업 템플릿에서 **추가 변수**에 **시작 시 프롬프트**를 선택하거나, 작업 템플릿에서 설문 조사를 활성화하여 답변이 달린 설문 조사 질문이 ``extra_vars``가 되도록 해야 합니다.

19.6. 설문 조사¶

실행 또는 확인 작업 유형의 경우 작업 템플릿 생성 또는 편집 화면에서 설문 조사를 설정할 수 있습니다. 설문 조사에서는 〈추가 변수 요청’와 비슷하지만 간편한 질문 및 답변 방식으로 플레이북의 추가 변수를 설정합니다. 또한 설문 조사에서는 사용자 입력을 검증할 수 있습니다. 설문 조사를 생성하려면 설문 조사 탭을 클릭합니다.

설문 조사의 사용 사례는 다양합니다. 예를 들어 고급 Ansible 지식 없이도 실행할 수 있는 《단계로 푸시》 버튼을 개발자에게 제공하려는 작업이 있을 수 있습니다. 이 작업이 시작되면 《릴리스할 태그는 무엇입니까?》와 같은 질문에 응답하도록 요청하는 메시지가 표시될 수 있습니다.

선다형 질문을 포함하여 다양한 유형의 질문을 할 수 있습니다.

19.6.1. 설문 조사 생성¶

설문 조사를 생성하려면 다음을 수행합니다.

1. 설문 조사 탭을 클릭하여 설문 조사 추가 창을 불러옵니다.

화면 상단에 있는 켜짐/꺼짐 토글 버튼을 사용하여 이 설문 조사 프롬프트를 신속하게 활성화하거나 비활성화할 수 있습니다.

2. 설문 조사는 다양한 질문으로 구성될 수 있습니다. 각 질문에 다음 정보를 입력합니다.

• 이름: 사용자를 묻는 질문입니다.

• 설명: 사용자에게 묻는 내용에 대한 설명입니다(선택 사항).

• 응답 변수 이름: 사용자 응답을 저장할 Ansible 변수 이름입니다. 플레이북에서 사용할 변수이며, 변수 이름에는 공백을 포함할 수 없습니다.

• 응답 유형: 다음 질문 유형 중에서 선택합니다.

  • 텍스트: 한 행의 텍스트입니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.

  • 텍스트 영역: 여러 행의 텍스트 필드입니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.

  • 암호: 응답은 실제 암호와 유사하게 민감한 정보로 처리됩니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.

  • 다중 선택(단일 선택): 한 번에 하나만 선택할 수 있는 옵션 목록입니다. 다중 선택 옵션 박스에서 한 행에 하나씩 옵션을 입력합니다.

  • 다중 선택(여러 선택): 한 번에 여러 개를 선택할 수 있는 옵션 목록입니다. 다중 선택 옵션 박스에서 한 행에 하나씩 옵션을 입력합니다.

  • 정수: 정수입니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.

  • 부동 값: 10진수입니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.

• 기본 응답: 질문에 대한 기본 응답입니다. 이 값은 인터페이스에 미리 입력되며 사용자가 응답을 제공하지 않은 경우 사용됩니다.

• 필수: 사용자가 이 질문에 응답해야 하는지 여부를 나타냅니다.

3. 질문 정보를 입력했으면 추가 버튼을 클릭하여 질문을 추가합니다.

스타일이 지정된 설문 조사 버전이 프리뷰 창에 표시됩니다. 각 질문에서 편집 버튼을 클릭하여 질문을 편집하거나, 삭제 버튼을 클릭하여 질문을 삭제하거나, 그리드 아이콘을 클릭하고 드래그하여 질문 순서를 바꿀 수 있습니다.

4. 질문을 추가하려면 왼쪽 창으로 돌아갑니다.

5. 완료되면 **저장**을 클릭하여 설문 조사를 저장합니다.

19.7. 작업 템플릿 시작¶

|at|의 주요 이점은 푸시 버튼을 통한 Ansible 플레이북 배포입니다. 플레이북뿐만 아니라 인벤토리, 인증 정보, 추가 변수 그리고 명령행에서 지정할 수 있는 모든 옵션과 설정까지, 일반적으로 명령행에서 Ansible 플레이북에 전달하는 모든 매개변수를 저장할 템플릿을 쉽게 구성할 수 있습니다.

더 쉬워진 배포를 통해 플레이북을 매번 동일한 방식으로 실행함으로써 일관성을 유지하고 책임을 위임할 수 있습니다. Ansible 전문가가 아닌 사용자도 다른 사용자가 작성한 플레이북을 실행할 수 있습니다.

다음 방법 중 하나로 작업 템플릿을 시작합니다.

• 왼쪽 탐색 모음의 템플릿 메뉴 또는 작업 템플릿 세부 정보 뷰에서 작업 템플릿 목록에 액세스한 후 아래로 스크롤하여 템플릿 목록의 버튼을 클릭합니다.

• 시작하려는 작업 템플릿의 작업 템플릿 세부 정보 뷰에서 **시작**을 클릭합니다.

작업을 실행하는 데 추가 정보가 필요할 수 있습니다. 시작 시 다음 데이터를 요청할 수 있습니다.

• 설정된 인증 정보

• 모든 매개변수에 대해 Prompt on Launch 옵션이 선택됨

• **묻기**로 설정된 암호

• 설문조사(작업 템플릿에 대해 구성된 경우)

• 추가 변수(작업 템플릿에서 요청하는 경우)

다음은 작업 태그를 입력하라는 메시지를 표시하고 :ref:`ug_surveys`에서 생성된 예제 설문 조사를 실행하는 작업 시작 예제입니다.

|at|는 작업 템플릿 및 설문 조사에 설정된 추가 변수와 함께 다음 변수를 작업 환경에 자동으로 추가합니다.

• awx_job_id: 이 작업 실행의 작업 ID

• awx_job_launch_type: 작업 시작 방법을 나타내는 설명

  • 수동: 사용자가 수동으로 작업을 시작했습니다.

  • 다시 시작: 작업이 다시 시작을 통해 시작되었습니다.

  • 콜백: 작업이 호스트 콜백을 통해 시작되었습니다.

  • 스케줄링됨: 작업이 스케줄을 통해 시작되었습니다.

  • 종속성: 작업이 다른 작업의 종속 항목으로 시작되었습니다.

  • 워크플로우: 작업이 워크플로우 작업에서 시작되었습니다.

  • 동기화: 작업이 프로젝트 동기화에서 시작되었습니다.

  • scm: 작업이 인벤토리 SCM 동기화로 생성되었습니다.

• awx_job_template_id: 이 작업 실행에서 사용하는 작업 템플릿 ID

• awx_job_template_name: 이 작업에서 사용하는 작업 템플릿 이름

• awx_project_revision: 이 특정 작업에서 사용하는 소스 트리의 버전 ID(작업의 scm_revision 필드와 같음)

• awx_project_scm_branch: 작업 템플릿에서 사용하는 프로젝트에 대해 구성된 기본 프로젝트 SCM 분기

• awx_job_scm_branch: 작업에서 SCM 분기를 덮어쓰는 경우 값이 여기에 표시됩니다.

• awx_user_email: 이 작업을 시작한 컨트롤러 사용자의 사용자 이메일 콜백 또는 스케줄링된 작업에는 제공되지 않습니다.

• awx_user_first_name: 이 작업을 시작한 컨트롤러 사용자의 사용자 이름입니다. 콜백 또는 스케줄링된 작업에는 제공되지 않습니다.

• awx_user_id: 이 작업을 시작한 컨트롤러 사용자의 사용자 ID입니다. 콜백 또는 스케줄링된 작업에는 제공되지 않습니다.

• awx_user_last_name: 이 작업을 시작한 컨트롤러 사용자의 사용자 성입니다. 콜백 또는 스케줄링된 작업에는 제공되지 않습니다.

• awx_user_name: 이 작업을 시작한 컨트롤러 사용자의 사용자 이름입니다. 콜백 또는 스케줄링된 작업에는 제공되지 않습니다.

• awx_schedule_id: 해당하는 경우 이 작업을 시작한 스케줄의 ID입니다.

• awx_schedule_name: 해당하는 경우 이 작업을 시작한 스케줄의 이름입니다.

• awx_workflow_job_id: 해당하는 경우 이 작업을 시작한 워크플로우 작업의 ID입니다.

• awx_workflow_job_name: 해당하는 경우 이 작업을 시작한 워크플로우 작업의 이름입니다. 워크플로우 작업 템플릿과도 동일합니다.

• awx_inventory_id: 해당하는 경우 이 작업에서 사용하는 인벤토리의 ID입니다.

• awx_inventory_name: 해당하는 경우 이 작업에서 사용하는 인벤토리의 이름입니다.

호환성을 위해 모든 변수에 《tower》 접두사(예: tower_job_id)도 제공됩니다.

시작 시 |at|는 작업 탭 아래에 있는 이 작업의 작업 상태 페이지로 웹 브라우저를 자동으로 리디렉션합니다.

슬라이스 작업이 실행 중인 경우 작업 목록에 워크플로우 및 작업 슬라이스와 세부 정보를 개별적으로 볼 수 있는 링크가 표시됩니다.

19.8. 작업 템플릿 복사¶

automation controller 3.0에는 작업 템플릿을 복사하는 기능이 도입되었습니다. 작업 템플릿을 복사하도록 선택하면 연결된 스케줄, 알림 또는 권한이 복사되지 않습니다. 스케줄 및 알림은 작업 템플릿의 복사본을 생성하는 사용자나 관리자가 다시 생성해야 합니다. 작업 템플릿을 복사하는 사용자에게는 관리자 권한이 부여되지만 작업 템플릿에는 권한이 할당(복사)되지 않습니다.

1. 왼쪽 탐색 모음의 템플릿 메뉴 또는 작업 템플릿 세부 정보 뷰에서 작업 템플릿 목록에 액세스한 후 아래로 스크롤하여 템플릿 목록에서 액세스합니다.

2. 버튼을 클릭합니다.

복사한 템플릿의 이름과 타임스탬프가 포함된 새 템플릿이 열립니다.

3. 이름 필드의 내용을 새 이름으로 교체한 후 다른 필드의 항목을 제공하거나 수정하여 이 페이지를 완료합니다.

4. 완료되면 **저장**을 클릭합니다.

19.9. 작업 템플릿 검사¶

스캔 작업은 automation controller 3.2부터 더 이상 지원되지 않습니다. 이 시스템 추적 기능은 사실을 기록 데이터로 캡처하고 저장하는 방법으로 사용되었습니다. 이제 사실은 사실 캐싱을 통해 컨트롤러에 저장됩니다. 자세한 내용은 :ref:`ug_fact_caching`을 참조하십시오.

automation controller 3.2 이전 시스템의 작업 템플릿 검사 작업은 실행 유형(예: 일반 작업 템플릿)으로 변환되고 관련 리소스(즉, 인벤토리, 인증 정보)가 유지됩니다. 관련 프로젝트가 없는 작업 템플릿 검사 작업에는 기본적으로 특수 플레이북이 할당되거나 자체 검사 플레이북을 사용하여 프로젝트를 지정할 수 있습니다. https://github.com/ansible/tower-fact-modules을 가리키는 각 조직에 대해 프로젝트가 생성되었으며 작업 템플릿은 플레이북 https://github.com/ansible/tower-fact-modules/blob/master/scan_facts로 설정되었습니다.

19.9.1. 사실 검사 플레이북¶

검사 작업 플레이북, scan_facts.yml``에는 Ansible의 표준 사실 수집과 함께 세 가지 ``fact scan modules``(패키지, 서비스, 파일) 호출이 포함되어 있습니다. ``scan_facts.yml 플레이북 파일은 다음과 같습니다.

- hosts: all
  vars:
    scan_use_checksum: false
    scan_use_recursive: false
  tasks:
    - scan_packages:
    - scan_services:
    - scan_files:
        paths: '{{ scan_file_paths }}'
        get_checksum: '{{ scan_use_checksum }}'
        recursive: '{{ scan_use_recursive }}'
      when: scan_file_paths is defined

scan_files 사실 모듈은 검사 작업 템플릿의 ``extra_vars``를 통해 전달되는 매개변수를 허용하는 유일한 모듈입니다.

scan_file_paths: '/tmp/'
scan_use_checksum: true
scan_use_recursive: true

• scan_file_paths 매개변수에는 여러 개의 설정이 있을 수 있습니다(예: /tmp/ 또는 /var/log).

• scan_use_checksum 및 scan_use_recursive 매개변수를 False로 설정하거나 생략할 수도 있습니다. 생략은 False 설정과 동일합니다.

검사 작업 템플릿은 ``become``을 활성화하고 가능한 ``become``의 인증 정보를 사용해야 합니다. 옵션 메뉴에서 **권한 에스컬레이션 활성화**를 선택하여 become을 활성화할 수 있습니다.

참고

automation controller 3.1.x에서 검사 작업 템플릿을 유지한 다음 automation controller 3.2로 업그레이드하면 새 《Tower Fact Scan - Default》 프로젝트가 자동으로 생성됩니다. 이 프로젝트에는 이전 버전의 |at|에서 이전에 사용한 이전 검사 플레이북이 포함되어 있습니다.

---

- name: Get Ubuntu 16, and on ready
 hosts: all
 sudo: yes
 gather_facts: no

 tasks:

 - name: install python-simplejson
   raw: sudo apt-get -y update
   raw: sudo apt-get -y install python-simplejson
   raw: sudo apt-get install python-apt

---

- name: Get Fedora ready
 hosts: all
 sudo: yes
 gather_facts: no

 tasks:

 - name: install python-simplejson
   raw: sudo dnf -y update
   raw: sudo dnf -y install python-simplejson
   raw: sudo dnf -y install rpm-python

- hosts: all
  gather_facts: false
  tasks:
    - scan_foo:

def main():
    module = AnsibleModule(
        argument_spec = dict())

    foo = [
      {
        "hello": "world"
      },
      {
        "foo": "bar"
      }
    ]
    results = dict(ansible_facts=dict(foo=foo))
    module.exit_json(**results)

main()

[
   {
     "hello": "world"
   },
   {
     "foo": "bar"
   }
 ]

19.10. 팩트 캐싱¶

자동화 컨트롤러는 Ansible 팩트 캐시 플러그인을 통해 호스트별로 사실을 저장하고 검색할 수 있습니다. 이 동작은 작업별 템플릿을 기반으로 구성할 수 있습니다. 팩트 캐싱은 기본적으로 꺼져 있지만 실행 중인 작업과 관련된 인벤토리의 모든 호스트에 대한 사실 요청을 처리하기 위해 활성화할 수 있습니다. 이렇게 하면 전체 호스트 사실 인벤토리에 계속 액세스하면서 ``–limit``과(와) 함께 작업 템플릿을 사용할 수 있습니다. 플러그인이 호스트별로 적용하는 글로벌 시간 초과 설정은 작업 설정 메뉴를 통해 (초 단위로) 지정할 수 있습니다.

팩트 캐시를 사용하는 작업(use_fact_cache=True)을 시작하면 컨트롤러는 작업과 관련된 인벤토리의 각 호스트와 연관된 모든 ansible_facts``를 저장합니다.  |at|와 함께 제공되는 Ansible 팩트 캐시 플러그인은 사실 캐시가 활성화된 작업(``use_fact_cache=True)에서만 활성화됩니다.

팩트 캐시가 활성화된 작업(use_fact_cache=True)의 실행이 완료되면 컨트롤러는 인벤토리의 호스트에 대한 모든 레코드를 복원합니다. 호스트별로 현재 저장되어 있는 사실보다 업데이트 시간이 *최신*인 모든 레코드가 데이터베이스에서 업데이트됩니다.

신규 및 변경된 팩트는 컨트롤러의 로깅 기능을 통해 기록됩니다. 구체적으로 system_tracking 네임스페이스 또는 로거에 기록됩니다. 로깅 페이로드에는 다음 필드가 포함됩니다.

• host_name

• inventory_id

• ansible_facts

여기서 ``ansible_facts``는 컨트롤러 인벤토리, ``inventory_id``의 ``host_name``에 대한 모든 Ansible 팩트로 구성된 사전입니다.

19.10.1. 팩트 캐싱의 이점¶

팩트 캐싱은 팩트 수집을 실행하는 것보다 상당한 시간이 절약됩니다. 작업에 1,000개의 호스트와 포크에 대해 실행되는 플레이북이 있다면 호스트 전체에서 사실을 수집하는 데 10분 이상 걸릴 수 있습니다. 그러나 작업을 정기적으로 실행하면 첫 번째 실행에서 이러한 팩트를 캐시하고 다음 실행에서는 데이터베이스에서 가져오기만 합니다. 이렇게 하면 스마트 인벤토리를 비롯하여 대규모 인벤토리에 대한 작업 런타임이 크게 단축됩니다.

참고

팩트 캐싱을 적용하려면 ansible.cfg 파일을 수정하지 마십시오. 사용자 정의 팩트 캐싱은 컨트롤러의 사실 캐싱 기능과 충돌할 수 있습니다. |at|와 함께 제공되는 팩트 캐싱 모듈을 사용하는 것이 좋습니다. 격리된 노드에는 팩트 캐싱이 지원되지 않습니다.

작업 템플릿 창의 옵션 필드에서 해당 항목을 활성화하면 작업에 캐시된 팩트를 사용하도록 선택할 수 있습니다.

팩트를 정리하려면 Ansible clear_facts meta task`_을 실행해야 합니다. 다음은 Ansible ``clear_facts` 메타 작업을 사용하는 플레이북의 예입니다.

- hosts: all
  gather_facts: false
  tasks:
    - name: Clear gathered facts from all currently targeted hosts
      meta: clear_facts

팩트 캐싱을 위한 API 끝점은 ``http://<controller server name>/api/v2/hosts/x/ansible_facts``에서 확인할 수 있습니다.

19.11. 클라우드 인증 정보 활용¶

클라우드 인증 정보는 해당 클라우드 인벤토리를 동기화할 때 사용할 수 있습니다. 또한 클라우드 인증 정보는 작업 템플릿과 연결되고 플레이북에서 사용하도록 런타임 환경에 포함될 수도 있습니다. 현재 지원되는 클라우드 인증 정보는 다음과 같습니다.

clouds:
  devstack:
    auth:
      auth_url: http://devstack.yoursite.com:5000/v2.0/
      username: admin
      password: your_password_here
      project_name: demo

- hosts: all
  gather_facts: false
  vars:
    config_file: "{{ lookup('env', 'OS_CLIENT_CONFIG_FILE') }}"
    nova_tenant_name: demo
    nova_image_name: "cirros-0.3.2-x86_64-uec"
    nova_instance_name: autobot
    nova_instance_state: 'present'
    nova_flavor_name: m1.nano

    nova_group:
      group_name: antarctica
      instance_name: deceptacon
      instance_count: 3
  tasks:
    - debug: msg="{{ config_file }}"
    - stat: path="{{ config_file }}"
      register: st
    - include_vars: "{{ config_file }}"
      when: st.stat.exists and st.stat.isreg

    - name: "Print out clouds variable"
      debug: msg="{{ clouds|default('No clouds found') }}"

    - name: "Setting nova instance state to: {{ nova_instance_state }}"
      local_action:
        module: nova_compute
        login_username: "{{ clouds.devstack.auth.username }}"
        login_password: "{{ clouds.devstack.auth.password }}"

- vsphere_guest:
    vcenter_hostname: "{{ lookup('env', 'VMWARE_HOST') }}"
    username: "{{ lookup('env', 'VMWARE_USER') }}"
    password: "{{ lookup('env', 'VMWARE_PASSWORD') }}"
    guest: newvm001
    from_template: yes
    template_src: linuxTemplate
    cluster: MainCluster
    resource_pool: "/Resources"
    vm_extra_config:
      folder: MyFolder

19.12. 프로비저닝 콜백¶

프로비저닝 콜백은 사용자가 자동화 컨트롤러 콘솔에서 호스트를 관리하는 작업을 시작할 때까지 기다리는 대신 호스트에서 자체적으로 플레이북 실행을 시작할 수 있는 자동화 컨트롤러의 기능입니다. 프로비저닝 콜백은 호출 호스트에서 플레이북을 실행하는 데에*만* 사용됩니다. 프로비저닝 콜백은 클라우드 버스팅을 위한 것입니다. 즉, 다른 호스트에 대해 작업을 실행하기 위한 것이 아닌, 구성(예: 권한 부여 키 전송 등)을 위해 클라이언트와 서버 간 통신이 필요한 새 인스턴스입니다. 이를 통해 다른 시스템(예: AWS 자동 확장 또는 kickstart 또는 preseed와 같은 OS 프로비저닝 시스템)에서 프로비저닝한 시스템을 자동으로 구성하거나 자동화 컨트롤러 API를 직접 호출하지 않고 프로그래밍 방식으로 작업을 시작할 수 있습니다. 시작된 작업 템플릿은 프로비저닝을 요청하는 호스트에 대해서만 실행됩니다.

대부분 firstboot 유형 스크립트를 통해 또는 cron에서 액세스할 수 있습니다.

콜백을 활성화하려면 작업 템플릿에서 프로비저닝 콜백 체크박스를 선택합니다. 그러면 이 작업 템플릿에 대한 **프로비저닝 콜백 URL**이 표시됩니다.

URL이 있는 외부 호스트에서 구성을 요청할 수 없도록 하기 위해 콜백에는 호스트 구성 키도 있어야 합니다. Host Config Key에 대한 사용자 정의 값을 제공하십시오. 호스트 키를 여러 호스트에서 다시 사용하여 이 작업 템플릿을 여러 호스트에 적용할 수 있습니다. 구성을 요청할 수 있는 호스트를 제어하려는 경우 언제든지 키를 변경할 수 있습니다.

REST를 통해 수동으로 콜백하려면 UI의 콜백 URL을 확인합니다. 형식은 다음과 같습니다.

https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback/

이 샘플 URL에서 〈1’은 자동화 컨트롤러의 작업 템플릿 ID입니다.

호스트의 요청은 POST여야 합니다. 다음은 curl을 사용하는 예입니다(모두 한 행에 있음).

curl -k -f -i -H 'Content-Type:application/json' -XPOST -d '{"host_config_key": "redhat"}' \
                  https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback/

콜백이 성공하려면 요청하는 호스트를 인벤토리에 정의해야 합니다. 자동화 컨트롤러에서 사용자가 정의한 인벤토리 중 하나에서 이름 또는 IP 주소로 호스트를 찾지 못하는 경우 요청이 거부됩니다. 작업 템플릿을 이러한 방식으로 실행할 때는 자체 호스트에 대해 플레이북 실행을 시작하는 호스트가 인벤토리에 있어야 합니다. 인벤토리에 호스트가 없으면 작업 템플릿이 실패하고 《일치하는 호스트가 없음》 유형 오류 메시지가 표시됩니다.

요청에 성공하면 작업 탭에 항목이 생성되고 여기에서 결과 및 기록을 볼 수 있습니다.

콜백은 REST를 통해 액세스할 수 있지만, 권장되는 콜백 사용 방법은 자동화 컨트롤러와 함께 제공되는 예제 스크립트, 즉 /usr/share/awx/request_tower_configuration.sh``(Linux/UNIX) 또는 ``/usr/share/awx/request_tower_configuration.ps1``(Windows) 중 하나를 사용하는 것입니다. 사용법은 다음과 같이 ``-h 플래그를 전달하여 파일의 소스 코드에 설명되어 있습니다.

./request_tower_configuration.sh -h
Usage: ./request_tower_configuration.sh <options>

Request server configuration from Ansible Tower.

OPTIONS:
 -h      Show this message
 -s      Controller server (e.g. https://ac.example.com) (required)
 -k      Allow insecure SSL connections and transfers
 -c      Host config key (required)
 -t      Job template ID (required)
 -e      Extra variables

이 스크립트는 명령을 재시도하는 방법을 알고 있다는 점에서 지능적이며, 단순한 curl 요청보다 더 강력한 콜백 사용 방법입니다. 스크립트는 작성된 대로 최대 10분 동안 분당 한 번씩 재시도합니다.

대부분은 지원되는 클라우드 공급자 중 하나에서 클라우드 인벤토리 가져오기와 같이 자동화 컨트롤러에서 동적 인벤토리와 함께 콜백을 사용합니다. 이러한 경우 시작 시 업데이트 설정과 함께 인벤토리 소스에 대한 인벤토리 캐시 시간 초과를 구성하여 클라우드의 API 끝점이 손상되지 않도록 해야 합니다. request_tower_configuration.sh 스크립트는 최대 10분 동안 분당 한 번씩 폴링하므로 인벤토리에 권장되는 캐시 무효화 시간(인벤토리 소스 자체에 구성되어 있음)은 1분 또는 2분입니다.

cron 작업에서 request_tower_configuration.sh 스크립트를 실행하지 않는 것이 좋지만 권장되는 cron 간격은 30분 간격입니다. 반복되는 구성은 자동화 컨트롤러에서 스케줄하여 쉽게 처리할 수 있으므로 대부분의 사용자는 주로 온라인 상태가 되면 최신 구성으로 부트스트랩되는 기본 이미지를 활성화하는 데 콜백을 사용합니다. 이렇게 하려면 처음 부팅할 때 실행하는 것이 더 좋습니다. 첫 번째 부팅 스크립트는 일반적으로 자동 삭제되는 단순한 init 스크립트이므로 request_tower_configuration.sh 스크립트 복사본을 호출하는 init 스크립트를 설정하고 이를 자동 확장 이미지로 설정해야 합니다.

'{"extra_vars": {"variable1":"value1","variable2":"value2",...}}'

root@localhost:~$ curl -f -H 'Content-Type: application/json' -XPOST \
                 -d '{"host_config_key": "redhat", "extra_vars": "{\"foo\": \"bar\"}"}' \
                 https://<CONTROLLER_SERVER_NAME>/api/v2/job_templates/7/callback

19.13. 추가 변수¶

설문 조사 변수를 전달하면 자동화 컨트롤러 내에서 추가 변수(extra_vars)로 전달됩니다. 이 작업은 설문 조사와 마찬가지로 작업 템플릿에 추가 변수를 전달하면 인벤토리 및 프로젝트에서 전달되는 다른 변수를 덮어쓸 수 있으므로 까다로울 수 있습니다.

예를 들어, debug = true``의 인벤토리에 대해 정의된 변수가 있다고 가정해 보겠습니다. ``debug = true 변수는 작업 템플릿 설문 조사에서 덮어쓸 수 있습니다.

전달해야 하는 변수를 덮어쓰지 않도록 하려면 해당 변수를 다시 정의하여 설문 조사에 포함해야 합니다. 추가 변수는 인벤토리, 그룹, 호스트 수준에서 정의할 수 있습니다.

ALLOW_JINJA_IN_EXTRA_VARS 매개변수를 지정하는 경우 |ata|의 Controller Tips and Tricks 섹션을 참조하여 컨트롤러 UI의 작업 설정 화면에서 구성합니다.

다음은 YAML 및 JSON 형식으로 된 몇 가지 간단한 extra_vars의 예입니다.

YAML 형식의 구성:

launch_to_orbit: true
satellites:
  - sputnik
  - explorer
  - satcom

JSON 형식의 구성:

{
  "launch_to_orbit": true,
  "satellites": ["sputnik", "explorer", "satcom"]
}

다음 표에서는 Ansible의 변수 우선순위와 비교한 |at|의 변수 우선순위 동작(계층 구조)을 보여 줍니다.

자동화 컨트롤러 변수 우선순위 계층 구조(마지막 항목이 우선순위가 높음)