:term:`job template`은 Ansible 작업을 실행하는 데 필요한 정의 및 매개변수 세트입니다. 작업 템플릿은 동일한 작업을 여러 번 실행하는 데 유용합니다. 또한 작업 템플릿은 Ansible 플레이북 콘텐츠의 재사용과 팀 간 협업을 권장합니다.
The Templates menu opens a list of the job templates that are currently available. The default view is collapsed (Compact), showing the template name, template type, and the timestamp of last job that ran using that template. You can click Expanded (arrow next to each entry) to expand to view more information. This list is sorted alphabetically by name, but you can sort by other criteria, or search by various fields and attributes of a template.
From this screen, you can launch (), edit (
), and copy (
) a job template. To delete a job template, you must select one or more templates and click the Delete button. Before deleting a job template, be sure it is not used in a workflow job template.
참고
다른 작업 항목에서 사용하는 항목을 삭제하면 삭제의 영향을 받는 항목이 나열된 메시지가 열리고, 삭제를 확인하라는 메시지가 표시됩니다. 일부 화면에는 유효하지 않거나 이전에 삭제된 항목이 포함되며 이러한 항목은 실행되지 않습니다. 다음은 이러한 메시지의 예입니다.
참고
작업 템플릿을 사용하여 워크플로우 템플릿을 빌드할 수 있습니다. 옆에 워크플로우 시각화 도구() 아이콘이 표시되는 템플릿이 워크플로우 템플릿입니다. 이 아이콘을 클릭하면 워크플로우를 그래픽을 통해 빌드할 수 있습니다. 작업 템플릿의 다양한 매개변수를 사용하면 워크플로우 수준에서 수정할 수 있는 **시작 시 프롬프트**를 활성화할 수 있으며, 작업 템플릿 수준에서 할당된 값에는 영향을 미치지 않습니다. 관련 지침은 워크플로우 시각화 도구 섹션을 참조하십시오.
새 작업 템플릿을 생성하려면 다음을 수행합니다.
추가 버튼을 클릭한 다음 메뉴 목록에서 **작업 템플릿**을 선택합니다.
다음 필드에 적절한 세부 정보를 입력합니다.
이름: 작업의 이름을 입력합니다.
설명: 임의의 설명을 적절하게 입력합니다(선택 사항).
작업 유형: 작업 유형을 선택합니다.
실행: 시작 시 플레이북을 실행하여 선택한 호스트에서 Ansible 작업을 실행합니다.
확인: 플레이북의 《시험 실행》을 수행하고 실제로 변경하지 않은 채 변경할 사항을 보고합니다. 확인 모드를 지원하지 않는 작업은 건너뛰고 잠재적인 변경 사항을 보고하지 않습니다.
시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 실행 또는 확인 작업 유형을 선택하라는 메시지가 표시됩니다.
참고
작업 유형에 대한 자세한 내용은 Ansible 문서의 Playbooks: Special Topics 섹션에서 확인할 수 있습니다.
인벤토리: 현재 로그인한 사용자에게 제공되는 인벤토리에서 이 작업 템플릿에 사용할 인벤토리를 선택합니다.
시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 이 작업 템플릿을 실행할 인벤토리를 선택하라는 메시지가 표시됩니다.
프로젝트: 현재 로그인한 사용자에게 제공되는 프로젝트에서 이 작업 템플릿에 사용할 프로젝트를 선택합니다.
SCM 분기: 이 필드는 분기 덮어쓰기를 허용하는 프로젝트를 선택한 경우에만 표시됩니다. 작업 실행에 사용할 덮어쓰기 분기를 지정합니다. 비워 두는 경우 프로젝트의 지정된 SCM 분기(또는 커밋 해시나 태그)가 사용됩니다. 자세한 내용은 :ref:`job branch overriding <ug_job_branching>`를 참조하십시오.
시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 SCM 분기를 선택하라는 메시지가 표시됩니다.
플레이북: 사용 가능한 플레이북에서 이 작업 템플릿으로 시작할 플레이북을 선택합니다. 이 필드는 선택한 프로젝트의 프로젝트 기본 경로에 있는 플레이북 이름으로 자동으로 채워집니다. 또는 목록에 없는 경우 해당 플레이북으로 실행하는 데 사용할 파일 이름(예: foo.yml
)과 같이 플레이북 이름을 입력하면 됩니다. 유효하지 않은 파일 이름을 입력하면 템플릿에 오류가 표시되거나 작업이 실패합니다.
인증 정보: 버튼을 클릭하면 별도의 창이 열립니다. 사용 가능한 옵션에서 이 작업 템플릿에 사용할 인증 정보를 선택합니다. 목록이 긴 경우 드롭다운 메뉴 목록을 사용하여 인증 정보 유형으로 필터링합니다.
참고
Some credential types are not listed because they do not apply to certain job templates.
시작 시 프롬프트: 선택한 경우 기본 머신 인증 정보가 있는 작업 템플릿을 시작할 때 프롬프트 대화 상자의 기본 머신 인증 정보는 작업 템플릿을 시작하기 전에 다른 머신 인증 정보로 교체하는 경우에만 제거할 수 있습니다. 또는 적절하다고 판단되는 인증 정보를 추가할 수 있습니다. 다음은 이러한 메시지의 예입니다.
포크: 플레이북을 실행하는 동안 사용할 병렬 또는 동시 프로세스 수입니다. 값이 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|에서 심각하게 차단하여 작업 완료 보고가 지연될 수 있고 브라우저 탭이 잠길 수 있습니다.
시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 상세 정보 표시를 선택하라는 메시지가 표시됩니다.
Job Tags: Begin typing and selecting the Create x drop-down to specify which parts of the playbook should be executed. For more information and examples refer to Tags in the Ansible documentation.
시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 작업 태그를 선택하라는 메시지가 표시됩니다.
Skip Tags: Begin typing and selecting the Create x drop-down to specify certain tasks or parts of the playbook to skip. For more information and examples refer to Tags in the Ansible documentation.
시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 건너뛸 태그를 선택하라는 메시지가 표시됩니다.
레이블: ‘dev’ 또는 《test》와 같이 이 작업 템플릿을 설명하는 선택적 레이블을 제공합니다. 레이블은 해당 디스플레이에서 작업 템플릿 및 완료된 작업을 그룹화하고 필터링하는 데 사용할 수 있습니다.
레이블은 작업 템플릿에 추가할 때 생성됩니다. 레이블은 작업 템플릿에 제공되는 프로젝트를 사용하여 단일 조직에 연결됩니다. 조직 멤버는 편집 권한이 있는 경우(예: 관리자 역할) 작업 템플릿에 레이블을 생성할 수 있습니다.
작업 템플릿이 저장되면 작업 템플릿 개요의 펼쳐진 뷰에 레이블이 표시됩니다.
Click the 《x》 beside a label to remove it. When a label is removed, it is no longer associated with that particular Job or Job Template, but it will remain associated with any other jobs that reference it.
작업은 시작 시 작업 템플릿에서 레이블을 가져옵니다. 작업 템플릿에서 삭제된 레이블은 작업에서도 삭제됩니다.
인스턴스 그룹: 버튼을 클릭하면 별도의 창이 열립니다. 이 작업 템플릿을 실행할 인스턴스 그룹을 선택합니다. 목록이 긴 경우 검색을 사용하여 옵션 범위를 좁힙니다.
작업 슬라이스: 이 작업 템플릿을 실행할 슬라이스 수를 지정합니다. 각 슬라이스는 인벤토리 일부에 대해 동일한 작업을 실행합니다. 작업 슬라이스에 대한 자세한 내용은 :ref:`ug_job_slice`을 참조하십시오.
시간 초과: 작업이 취소되기 전에 작업을 실행할 수 있는 시간(초)을 지정할 수 있습니다. 작업 시간 초과 기본값은 0입니다.
변경 사항 표시: Ansible 작업에서 변경한 내용을 볼 수 있습니다.
시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 변경 사항 표시 여부를 선택하라는 메시지가 표시됩니다.
Options: Specify options for launching this template, if necessary.
Privilege Escalation: If checked, you enable this playbook to run as an administrator. This is the equivalent of passing the
--become
option to theansible-playbook
command.Provisioning Callbacks: If checked, you enable a host to call back to automation controller via the REST API and invoke the launch of a job from this job template. Refer to 프로비저닝 콜백 for additional information.
Webhook 활성화: 작업 템플릿을 시작하는 데 사용되는 사전 정의된 SCM 시스템 웹 서비스와 연결하는 기능을 켭니다. 현재 지원되는 SCM 시스템은 GitHub와 GitLab입니다.
Webhook를 활성화하면 다른 필드가 표시되면서 추가 정보를 요청합니다.
![]()
Webhook 서비스: Webhook에서 수신 대기할 서비스를 선택합니다.
Webhook URL: 요청을 POST하는 Webhook 서비스의 URL이 자동으로 채워집니다.
Webhook 키: |at|로 보낸 페이로드에 서명하는 데 Webhook 서비스에서 사용하도록 생성된 공유 비밀입니다. |at|에서 이 서비스의 Webhook를 수락하려면 Webhook 서비스의 설정에 구성해야 합니다.
Webhook 인증 정보: 필요한 경우 Webhook 서비스로 상태 업데이트를 다시 보내는 데 사용할 인증 정보로 GitHub 또는 GitLab PAT(개인 액세스 토큰)을 제공합니다. 인증 정보를 선택하려면 인증 정보가 있어야 합니다. 인증 정보를 생성하려면 :ref:`ug_credentials_cred_types`을 참조하십시오.
Webhook 설정에 대한 자세한 내용은 :ref:`ug_webhooks`을 참조하십시오.
Concurrent Jobs: If checked, you are allowing jobs in the queue to run simultaneously if not dependent on one another. Check this box if you want to run job slices simultaneously. Refer to Automation controller Capacity Determination and Job Impact for additional information.
Enable Fact Storage: When checked, automation controller will store gathered facts for all hosts in an inventory related to the job running.
추가 변수:
플레이북에 추가 명령행 변수를 전달합니다. 관련 변수인 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`를 참조하십시오.
시작 시 프롬프트: 선택하는 경우 기본값을 제공해도 시작 시 명령행 변수를 선택하라는 메시지가 표시됩니다.
참고
스케줄에 ``extra_vars``를 지정하려면 작업 템플릿에서 **추가 변수**에 **시작 시 프롬프트**를 선택하거나, 작업 템플릿에서 설문 조사를 활성화하여 답변이 달린 설문 조사 질문이 ``extra_vars``가 되도록 해야 합니다.
작업 템플릿 세부 정보 구성을 완료한 경우 **저장**을 클릭합니다.
Saving the template does not exit the job template page but advances to the Job Template Details tab for viewing. After saving the template, you can click Launch to launch the job, or click Edit to add or change the attributes of the template, such as permissions, notifications, view completed jobs, and add a survey (if the job type is not a scan). You must first save the template prior to launching, otherwise, the Launch button remains grayed-out.
You can verify the template is saved when the newly created template appears on the Templates list view.
액세스 탭에서 추가 버튼을 클릭합니다.
추가할 사용자 또는 팀을 선택하고 **다음**을 클릭합니다.
이름 옆에 있는 체크박스를 클릭하여 목록에서 하나 이상의 사용자 또는 팀을 선택하여 멤버로 추가하고 **다음**을 클릭합니다.
이 예에서는 두 명의 사용자를 추가하도록 선택했습니다.
선택한 사용자 또는 팀에 부여할 역할을 선택합니다. 전체 역할 목록을 보려면 아래로 스크롤하십시오. 리소스에 따라 다양한 옵션을 사용할 수 있습니다.
저장 버튼을 클릭하여 선택한 사용자 또는 팀에 역할을 적용하고 멤버로 추가합니다.
사용자/팀 추가 창이 닫히고 각 사용자 및 팀에 할당된 역할이 업데이트되어 표시됩니다.
특정 사용자의 역할을 제거하려면 리소스 옆에 있는 연결 해제(x) 버튼을 클릭합니다.
그러면 연결을 해제할지 묻는 확인 대화 상자가 열립니다.
Clicking the Notifications tab allows you to review any notification integrations you have setup and their statuses, if they have ran.
특정 템플릿에 사용할 알림을 활성화하거나 비활성화하려면 토글을 사용합니다. 자세한 내용은 :ref:`ug_notifications_on_off`를 참조하십시오.
If no notifications have been set up, click the Add button to create a new notification. Refer to 알림 유형 for additional details on configuring various notification types and extended messaging.
완료된 작업 탭에는 실행된 작업 템플릿 목록이 있습니다. 작업의 상태, ID, 이름을 포함하여 각 작업의 세부 정보(작업 유형, 시작 및 완료 시간, 작업을 시작한 사용자, 사용된 템플릿, 인벤토리, 프로젝트, 인증 정보)를 보려면 **펼치기**를 클릭합니다. 이러한 기준 중 하나를 사용하여 완료된 작업 목록을 필터링할 수 있습니다.
이 목록에 표시되는 분할된 작업에는 실행된 분할 작업 수로 적절하게 레이블이 지정됩니다.
스케줄 탭에서 특정 작업 템플릿의 스케줄에 액세스합니다.
작업 템플릿 실행을 스케줄하려면 스케줄 탭을 클릭합니다.
스케줄이 이미 설정되어 있는 경우 스케줄 기본 설정을 검토, 편집 또는 활성화/비활성화합니다.
스케줄이 설정되지 않은 경우 :ref:`ug_scheduling`에서 자세한 내용을 참조하십시오.
인증 정보 필드에 대해 시작 시 프롬프트**를 선택한 경우 작업 템플릿에 대한 스케줄 정보를 생성하거나 편집하면 스케줄 양식 하단에 **프롬프트 버튼이 표시됩니다. 프롬프트 대화 상자의 기본 머신 인증 정보는 작업 템플릿을 저장하기 전에 다른 머신 인증 정보로 교체하는 경우에만 제거할 수 있습니다. 다음은 이러한 메시지의 예입니다.
실행 또는 확인 작업 유형의 경우 작업 템플릿 생성 또는 편집 화면에서 설문 조사를 설정할 수 있습니다. 설문 조사에서는 〈추가 변수 요청’와 비슷하지만 간편한 질문 및 답변 방식으로 플레이북의 추가 변수를 설정합니다. 또한 설문 조사에서는 사용자 입력을 검증할 수 있습니다. 설문 조사를 생성하려면 설문 조사 탭을 클릭합니다.
설문 조사의 사용 사례는 다양합니다. 예를 들어 고급 Ansible 지식 없이도 실행할 수 있는 《단계로 푸시》 버튼을 개발자에게 제공하려는 작업이 있을 수 있습니다. 이 작업이 시작되면 《릴리스할 태그는 무엇입니까?》와 같은 질문에 응답하도록 요청하는 메시지가 표시될 수 있습니다.
선다형 질문을 포함하여 다양한 유형의 질문을 할 수 있습니다.
설문 조사를 생성하려면 다음을 수행합니다.
Click the Survey tab and click the Add button.
설문 조사는 다양한 질문으로 구성될 수 있습니다. 각 질문에 다음 정보를 입력합니다.
이름: 사용자를 묻는 질문입니다.
설명: 사용자에게 묻는 내용에 대한 설명입니다(선택 사항).
응답 변수 이름: 사용자 응답을 저장할 Ansible 변수 이름입니다. 플레이북에서 사용할 변수이며, 변수 이름에는 공백을 포함할 수 없습니다.
응답 유형: 다음 질문 유형 중에서 선택합니다.
텍스트: 한 행의 텍스트입니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.
텍스트 영역: 여러 행의 텍스트 필드입니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.
암호: 응답은 실제 암호와 유사하게 민감한 정보로 처리됩니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.
다중 선택(단일 선택): 한 번에 하나만 선택할 수 있는 옵션 목록입니다. 다중 선택 옵션 박스에서 한 행에 하나씩 옵션을 입력합니다.
다중 선택(여러 선택): 한 번에 여러 개를 선택할 수 있는 옵션 목록입니다. 다중 선택 옵션 박스에서 한 행에 하나씩 옵션을 입력합니다.
정수: 정수입니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.
부동 값: 10진수입니다. 이 답변에는 최소 및 최대 길이(문자 수)를 설정할 수 있습니다.
필수: 사용자가 이 질문에 응답해야 하는지 여부를 나타냅니다.
Minimum length and Maximum length: Specify if a certain length in the answer is required.
기본 응답: 질문에 대한 기본 응답입니다. 이 값은 인터페이스에 미리 입력되며 사용자가 응답을 제공하지 않은 경우 사용됩니다.
Once you have entered the question information, click Save to add the question.
The survey question displays in the Survey list. For any question, you can click to edit the question, or check the box next to each question and click Delete to delete the question, or use the toggle button at the top of the screen to enable or disable the survey prompt(s).
If you have more than one survey question, use the Edit Order button to rearrange the order of the questions by clicking and dragging on the grid icon.
To add more questions, click the Add button to add additional questions.
설문 조사 질문의 필수 설정에 따라 사용자가 질문에 응답해야 하는지 여부가 결정됩니다.
선택적 설문 조사 변수는 입력하지 않은 경우에도 백그라운드에서 ``extra_vars``의 플레이북에 전달될 수 있습니다.
텍스트가 아닌 변수(입력 유형)가 선택 사항으로 표시되고 미입력 상태인 경우 설문 조사 ``extra_var``이 플레이북에 전달되지 않습니다.
텍스트 입력 또는 텍스트 영역 입력이 선택 사항으로 표시되고 미입력 상태이며 최소 ``length > 0``인 경우 설문 조사 ``extra_var``이 플레이북에 전달되지 않습니다.
텍스트 입력 또는 텍스트 영역 입력이 선택 사항으로 표시되고 미입력 상태이며 최소 ``length === 0``인 경우 설문 조사 ``extra_var``은 값이 빈 문자열(《》)로 설정되어 플레이북에 전달됩니다.
|at|의 주요 이점은 푸시 버튼을 통한 Ansible 플레이북 배포입니다. 플레이북뿐만 아니라 인벤토리, 인증 정보, 추가 변수 그리고 명령행에서 지정할 수 있는 모든 옵션과 설정까지, 일반적으로 명령행에서 Ansible 플레이북에 전달하는 모든 매개변수를 저장할 템플릿을 쉽게 구성할 수 있습니다.
더 쉬워진 배포를 통해 플레이북을 매번 동일한 방식으로 실행함으로써 일관성을 유지하고 책임을 위임할 수 있습니다. Ansible 전문가가 아닌 사용자도 다른 사용자가 작성한 플레이북을 실행할 수 있습니다.
다음 방법 중 하나로 작업 템플릿을 시작합니다.
왼쪽 탐색 모음의 템플릿 메뉴 또는 작업 템플릿 세부 정보 뷰에서 작업 템플릿 목록에 액세스한 후 아래로 스크롤하여 템플릿 목록의 버튼을 클릭합니다.
시작하려는 작업 템플릿의 작업 템플릿 세부 정보 뷰에서 **시작**을 클릭합니다.
작업을 실행하는 데 추가 정보가 필요할 수 있습니다. 시작 시 다음 데이터를 요청할 수 있습니다.
설정된 인증 정보
모든 매개변수에 대해 Prompt on Launch
옵션이 선택됨
**묻기**로 설정된 암호
설문조사(작업 템플릿에 대해 구성된 경우)
추가 변수(작업 템플릿에서 요청하는 경우)
참고
작업에 사용자 제공 값이 있는 경우 다시 시작 시 해당 값이 적용됩니다. 사용자가 값을 지정하지 않은 경우 작업 템플릿의 기본값이 작업에 사용됩니다. 작업은 현상태 그대로 다시 시작되지 않습니다. 사용자 프롬프트가 작업 템플릿에 다시 적용된 상태로 다시 시작됩니다.
다음은 작업 태그를 입력하라는 메시지를 표시하고 :ref:`ug_surveys`에서 생성된 예제 설문 조사를 실행하는 작업 시작 예제입니다.
참고
한 탭에 값을 제공한 후 이전 탭으로 돌아가서 다음 탭을 진행하면 나머지 탭에 값을 다시 제공해야 합니다. 이 문제를 방지하려면 프롬프트가 표시되는 순서대로 탭에 입력합니다.
Along with any extra variables set in the job template and survey, automation controller automatically adds the following variables to the job environment. Also note, awx_``* variables are defined by the system and cannot be overridden. Variables about the job context, like ``awx_job_template_name
are not affected if they are set in extra_vars
.
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
: 해당하는 경우 이 작업에서 사용하는 인벤토리의 이름입니다.
For compatibility, all variables are also given an 《awx》 prefix, for example, awx_job_id
.
시작 시 |at|는 작업 탭 아래에 있는 이 작업의 작업 상태 페이지로 웹 브라우저를 자동으로 리디렉션합니다.
참고
목록 뷰에서 최근 작업을 다시 시작하여 모든 호스트에서 다시 실행하거나 지정된 인벤토리의 실패한 호스트에서만 다시 실행할 수 있습니다. 자세한 내용은 |atu|의 :ref:`ug_jobs`을 참조하십시오.
슬라이스 작업이 실행 중인 경우 작업 목록에 워크플로우 및 작업 슬라이스와 세부 정보를 개별적으로 볼 수 있는 링크가 표시됩니다.
If you choose to copy Job Template, it does not copy any associated schedule, notifications, or permissions. Schedules and notifications must be recreated by the user or admin creating the copy of the Job Template. The user copying the Job Template will be granted the admin permission, but no permissions are assigned (copied) to the Job Template.
왼쪽 탐색 모음의 템플릿 메뉴 또는 작업 템플릿 세부 정보 뷰에서 작업 템플릿 목록에 액세스한 후 아래로 스크롤하여 템플릿 목록에서 액세스합니다.
Click the button associated with the template you want to copy.
The new template with the name of the template from which you copied and a timestamp displays in the list of templates.
Click to open the new template and click Edit.
이름 필드의 내용을 새 이름으로 교체한 후 다른 필드의 항목을 제공하거나 수정하여 이 페이지를 완료합니다.
완료되면 **저장**을 클릭합니다.
스캔 작업은 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로 설정되었습니다.
검사 작업 플레이북, 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을 활성화할 수 있습니다.
scan_facts.yml
플레이북을 사용 사실 캐시와 함께 사용하는 경우 OS가 지원되는지 확인하십시오.
Red Hat Enterprise Linux 5, 6, 7
Ubuntu 16.04(Unbuntu 지원은 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정임)
OEL 6 및 7
SLES 11 및 12
Debian 6, 7, 8
Fedora 22, 23, 24
Amazon Linux 2016.03
Windows Server 2008 이상
이러한 운영 체제 중 일부는 Python을 실행하거나 스캔 모듈에서 사용하는 Python 패키지(예: python-apt
)에 액세스하기 위해 초기 구성이 필요할 수 있습니다.
다음은 검사 작업을 실행할 수 있도록 특정 배포를 구성하는 플레이북의 예입니다.
Bootstrap Ubuntu (16.04)
---
- 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
Bootstrap Fedora (23, 24)
---
- 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
사용자 정의 사실 검사를 위한 플레이북은 위에 있는 사실 검사 플레이북의 예와 유사합니다. 예를 들어, 사용자 정의 scan_foo
Ansible 사실 모듈만 사용하는 플레이북은 다음과 같습니다.
scan_custom.yml:
- hosts: all
gather_facts: false
tasks:
- scan_foo:
scan_foo.py:
def main():
module = AnsibleModule(
argument_spec = dict())
foo = [
{
"hello": "world"
},
{
"foo": "bar"
}
]
results = dict(ansible_facts=dict(foo=foo))
module.exit_json(**results)
main()
사용자 정의 사실 모듈을 사용하려면 검사 작업 템플릿에 사용된 Ansible 프로젝트의 /library/
하위 디렉터리에 해당 모듈이 있어야 합니다. 이 사실 검사 모듈은 매우 간단하며 하드 코딩된 사실 세트를 반환합니다.
[
{
"hello": "world"
},
{
"foo": "bar"
}
]
자세한 내용은 Ansible 문서의 Module Provided 〈Facts〉 섹션을 참조하십시오.
자동화 컨트롤러는 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 팩트로 구성된 사전입니다.
참고
호스트 이름에 슬래시(/
)가 포함된 경우 해당 호스트에서 팩트 캐시가 작동하지 않습니다. 인벤토리에 호스트가 100개 있고 한 호스트의 이름에 ``/``가 있는 경우, 해당 호스트 중 99개의 호스트에서는 계속 팩트를 수집합니다.
팩트 캐싱은 팩트 수집을 실행하는 것보다 상당한 시간이 절약됩니다. 작업에 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``에서 확인할 수 있습니다.
클라우드 인증 정보는 해당 클라우드 인벤토리를 동기화할 때 사용할 수 있습니다. 또한 클라우드 인증 정보는 작업 템플릿과 연결되고 플레이북에서 사용하도록 런타임 환경에 포함될 수도 있습니다. 현재 지원되는 클라우드 인증 정보는 다음과 같습니다.
아래의 샘플 플레이북에서는 nova_compute
Ansible OpenStack 클라우드 모듈을 호출하고, 의미 있는 작업을 수행하려면 인증 정보가 필요한데 특히 auth_url
, username
, password
, project_name
정보가 필요합니다. 이러한 필드는 환경 변수 ``OS_CLIENT_CONFIG_FILE``을 통해 플레이북에 사용할 수 있습니다. 이 변수는 클라우드 인증 정보 내용을 기반으로 컨트롤러에서 작성한 YAML 파일을 가리킵니다. 이 샘플 플레이북은 YAML 파일을 Ansible 변수 공간에 로드합니다.
OS_CLIENT_CONFIG_FILE
예:
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 }}"
Amazon Web Services 클라우드 인증 정보는 플레이북 실행 중에 다음 환경 변수로 노출됩니다(작업 템플릿에서 설정에 필요한 클라우드 인증 정보 선택).
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
모든 AWS 모듈은 aws_access_key_id
또는 aws_secret_access_key
모듈 옵션을 설정하지 않고도 컨트롤러를 통해 실행할 때 이러한 인증 정보를 암시적으로 사용합니다.
Google 클라우드 인증 정보는 플레이북 실행 중에 다음 환경 변수로 노출됩니다(작업 템플릿에서 설정에 필요한 클라우드 인증 정보 선택).
GCE_EMAIL
GCE_PROJECT
GCE_CREDENTIALS_FILE_PATH
모든 Google 모듈은 service_account_email
, project_id
또는 pem_file
모듈 옵션을 설정하지 않고도 컨트롤러를 통해 실행할 때 이러한 인증 정보를 암시적으로 사용합니다.
Azure 클라우드 인증 정보는 플레이북 실행 중에 다음 환경 변수로 노출됩니다(작업 템플릿에서 설정에 필요한 클라우드 인증 정보 선택).
AZURE_SUBSCRIPTION_ID
AZURE_CERT_PATH
모든 Azure 모듈은 subscription_id
또는 management_cert_path
모듈 옵션을 설정하지 않고도 컨트롤러를 통해 실행할 때 이러한 인증 정보를 암시적으로 사용합니다.
VMware 클라우드 인증 정보는 플레이북 실행 중에 다음 환경 변수로 노출됩니다(작업 템플릿에서 설정에 필요한 클라우드 인증 정보 선택).
VMWARE_USER
VMWARE_PASSWORD
VMWARE_HOST
아래 샘플 플레이북에서는 이러한 인증 정보를 사용하는 방법을 보여줍니다.
- 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
프로비저닝 콜백은 사용자가 자동화 컨트롤러 콘솔에서 호스트를 관리하는 작업을 시작할 때까지 기다리는 대신 호스트에서 자체적으로 플레이북 실행을 시작할 수 있는 자동화 컨트롤러의 기능입니다. 프로비저닝 콜백은 호출 호스트에서 플레이북을 실행하는 데에*만* 사용됩니다. 프로비저닝 콜백은 클라우드 버스팅을 위한 것입니다. 즉, 다른 호스트에 대해 작업을 실행하기 위한 것이 아닌, 구성(예: 권한 부여 키 전송 등)을 위해 클라이언트와 서버 간 통신이 필요한 새 인스턴스입니다. 이를 통해 다른 시스템(예: 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 주소로 호스트를 찾지 못하는 경우 요청이 거부됩니다. 작업 템플릿을 이러한 방식으로 실행할 때는 자체 호스트에 대해 플레이북 실행을 시작하는 호스트가 인벤토리에 있어야 합니다. 인벤토리에 호스트가 없으면 작업 템플릿이 실패하고 《일치하는 호스트가 없음》 유형 오류 메시지가 표시됩니다.
참고
호스트가 인벤토리에 없고 인벤토리 그룹에 대해 ``Update on Launch``가 설정된 경우 자동화 컨트롤러는 콜백을 실행하기 전에 클라우드 기반 인벤토리 소스 업데이트를 시도합니다.
요청에 성공하면 작업 탭에 항목이 생성되고 여기에서 결과 및 기록을 볼 수 있습니다.
콜백은 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분 동안 분당 한 번씩 재시도합니다.
참고
위 스크립트는 예제 스크립트입니다. 200을 제외한 오류 코드는 재시도가 필요한 일시적인 오류가 아닐 수 있으므로 실패 시나리오를 탐지할 때 더 동적인 동작이 필요한 경우 이 스크립트를 편집해야 합니다.
대부분은 지원되는 클라우드 공급자 중 하나에서 클라우드 인벤토리 가져오기와 같이 자동화 컨트롤러에서 동적 인벤토리와 함께 콜백을 사용합니다. 이러한 경우 시작 시 업데이트 설정과 함께 인벤토리 소스에 대한 인벤토리 캐시 시간 초과를 구성하여 클라우드의 API 끝점이 손상되지 않도록 해야 합니다. request_tower_configuration.sh
스크립트는 최대 10분 동안 분당 한 번씩 폴링하므로 인벤토리에 권장되는 캐시 무효화 시간(인벤토리 소스 자체에 구성되어 있음)은 1분 또는 2분입니다.
cron 작업에서 request_tower_configuration.sh
스크립트를 실행하지 않는 것이 좋지만 권장되는 cron 간격은 30분 간격입니다. 반복되는 구성은 자동화 컨트롤러에서 스케줄하여 쉽게 처리할 수 있으므로 대부분의 사용자는 주로 온라인 상태가 되면 최신 구성으로 부트스트랩되는 기본 이미지를 활성화하는 데 콜백을 사용합니다. 이렇게 하려면 처음 부팅할 때 실행하는 것이 더 좋습니다. 첫 번째 부팅 스크립트는 일반적으로 자동 삭제되는 단순한 init 스크립트이므로 request_tower_configuration.sh
스크립트 복사본을 호출하는 init 스크립트를 설정하고 이를 자동 확장 이미지로 설정해야 합니다.
일반 작업 템플릿에서 ``extra_vars``를 전달할 수 있는 것과 같이 콜백 프로비저닝에도 전달할 수 있습니다. ``extra_vars``를 전달하려면 전송되는 데이터가 POST 요청 본문에 애플리케이션/json(콘텐츠 유형)으로 포함되어야 합니다. 전달할 고유의 ``extra_vars``를 추가할 때 다음 JSON 형식을 예로 사용할 수 있습니다.
'{"extra_vars": {"variable1":"value1","variable2":"value2",...}}'
다음 예제와 같이 ``curl``을 사용하여 작업 템플릿 호출에 추가 변수를 전달할 수도 있습니다.
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
자세한 내용은 :ref:`Launching Jobs with Curl<administration:launch_jobs_curl>`을 참조하십시오.
참고
작업 시작 API에 전달된 ``extra_vars``는 다음 중 하나에 해당하는 경우에만 적용됩니다.
활성화된 설문 조사의 변수에 해당함
``ask_variables_on_launch``가 True로 설정되어 있음
설문 조사 변수를 전달하면 자동화 컨트롤러 내에서 추가 변수(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|의 변수 우선순위 동작(계층 구조)을 보여 줍니다.
자동화 컨트롤러 변수 우선순위 계층 구조(마지막 항목이 우선순위가 높음)
작업을 수동으로 다시 시작하는 대신 ``launch_type``을 ``relaunch``로 설정하여 다시 시작할 수 있습니다. 다시 시작 동작은 ``extra_vars``를 상속하지 않는다는 점에서 시작 동작과 다릅니다.
작업 다시 시작은 상속 논리를 거치지 않습니다. 다시 시작되는 작업에 대해 계산된 것과 동일한 ``extra_vars``를 사용합니다.
예를 들어, extra_vars
없이 작업 템플릿을 시작하여 **j1**이라는 작업이 생성된다고 가정해 보겠습니다. 다음으로 작업 템플릿을 편집하고 일부 extra_vars``를 추가(예: ``"{ "hello": "world" }"
추가)한다고 가정하겠습니다.
**j1**을 다시 시작하면 **j2**가 생성되지만 상속 논리가 없고 **j1**에 ``extra_vars``가 없기 때문에 **j2**에 ``extra_vars``가 포함되지 않습니다.
이 예제를 계속 진행하기 위해 j1 생성 후 추가한 ``extra_vars``로 작업 템플릿을 시작한 경우 생성된 다시 시작 작업(j3)에 ``extra_vars``가 포함됩니다. 그리고 **j3**를 다시 시작하면 **j4**가 생성되고 ``extra_vars``도 포함됩니다.