24. 작업¶
:term:`job`은 호스트 인벤토리에 대해 Ansible 플레이북을 시작하는 |at|의 인스턴스입니다.
The Jobs link displays a list of jobs and their statuses–shown as completed successfully or failed, or as an active (running) job. The default view is collapsed (Compact) with the job name, status, job type, and start/finish times, but you can expand to see more information. You can sort this list by various criteria, and perform a search to filter the jobs of interest.
Actions you can take from this screen include viewing the details and standard output of a particular job, relaunching (
) jobs, or removing selected jobs. The relaunch operation only applies to relaunches of playbook runs and does not apply to project/inventory updates, system jobs, workflow jobs, etc.
When a job relaunches, you are directed the Jobs Output screen as the job runs. Clicking on any type of job also takes you to the Job Output View for that job, where you can filter jobs by various criteria:
The Stdout option is the default display that shows the job processes and output
The Event option allows you to filter by the event(s) of interest, such as errors, host failures, host retries, items skipped, etc. You can include as many events in the filter as necessary.
The Advanced option is a refined search that allows you a combination of including or excluding criteria, searching by key, or by lookup type. For details about using Search, refer to the 검색 chapter.
24.1. Inventory Sync Jobs¶
When an inventory sync is executed, the full results automatically display in the Output tab. This shows the same information you would see if you ran it through the Ansible command line, and can be useful for debugging. The ANSIBLE_DISPLAY_ARGS_TO_STDOUT is set to False by default for all playbook runs. This matches Ansible’s default behavior. This does not display task arguments in task headers in the Job Detail interface to avoid leaking certain sensitive module parameters to stdout. If you wish to restore the prior behavior (despite the security implications), you can set ANSIBLE_DISPLAY_ARGS_TO_STDOUT to True via the AWX_TASK_ENV configuration setting. For more details, refer to the ANSIBLE_DISPLAY_ARGS_TO_STDOUT.
The icons at the top right corner of the Output tab allow you to relaunch (), download (
) the job output, or delete (
) the job.
참고
An inventory update can be performed while a related job is running. In cases where you have a big project (around 10 GB), disk space on /tmp may be an issue.
24.1.1. Inventory sync details¶
Access the Details tab to provide details about the job execution.
Notable details of the job executed are:
상태: 다음 중 하나일 수 있습니다.
보류 중 - 인벤토리 동기화가 생성되었지만 아직 대기열에 추가되거나 시작되지 않았습니다. 인벤토리 소스 동기화뿐만 아니라 모든 작업은 시스템에서 실제로 실행할 준비가 될 때까지 보류 중 상태로 유지됩니다. 인벤토리 소스 동기화가 준비되지 않은 이유는 현재 실행 중인 종속 항목이 있거나(다음 단계를 실행하려면 모든 종속 항목을 완료해야 함) 구성된 위치에서 실행하는 데 필요한 용량이 충분하지 않기 때문입니다.
대기 중 - 인벤토리 동기화가 대기열에 있으며 실행 대기 중입니다.
실행 중 - 인벤토리 동기화가 현재 진행 중입니다.
성공 - 인벤토리 동기화 작업이 성공했습니다.
실패 - 인벤토리 동기화 작업에 실패했습니다.
인벤토리: 연결된 인벤토리 그룹의 이름입니다.
소스: 클라우드 인벤토리의 유형입니다.
Inventory Source Project: The project used as the source of this inventory sync job.
Execution Environment: The execution environment used.
실행 노드: 작업을 실행하는 데 사용하는 노드입니다.
인스턴스 그룹: 이 작업에 사용되는 인스턴스 그룹의 이름입니다(컨트롤러는 기본 인스턴스 그룹임).
이러한 항목을 클릭하면(해당되는 경우) 해당 작업 템플릿, 프로젝트 및 기타 오브젝트를 볼 수 있습니다.
24.2. SCM Inventory Jobs¶
When an inventory sourced from an SCM is executed, the full results automatically display in the Output tab. This shows the same information you would see if you ran it through the Ansible command line, and can be useful for debugging. The icons at the top right corner of the Output tab allow you to relaunch (), download () the job output, or delete () the job.
24.2.1. SCM inventory details¶
Access the Details tab to provide details about the job execution and its associated project.
Notable details of the job executed are:
상태: 다음 중 하나일 수 있습니다.
보류 중 - SCM 작업이 생성되었지만 아직 대기열에 추가되거나 시작되지 않았습니다. SCM 작업뿐만 아니라 모든 작업은 시스템에서 실제로 실행할 준비가 될 때까지 보류 중 상태로 유지됩니다. SCM 작업이 준비되지 않은 이유는 현재 실행 중인 종속 항목이 있거나(다음 단계를 실행하려면 모든 종속 항목을 완료해야 함) 구성된 위치에서 실행하는 데 필요한 용량이 충분하지 않기 때문입니다.
대기 중 - SCM 작업이 대기열에 있으며 실행 대기 중입니다.
실행 중 - SCM 작업이 현재 진행 중입니다.
성공 - 마지막 SCM 작업에 성공했습니다.
실패 - 마지막 SCM 작업에 실패했습니다.
Job Type: SCM jobs display Source Control Update.
프로젝트: 프로젝트의 이름입니다.
Project Status: Indicates whether the associated project was successfully updated.
Revision: Indicates the revision number of the sourced project that was used in this job.
Execution Environment: Specifies the execution environment used to run this job.
Execution Node: Indicates the node on which the job ran.
Instance Group: Indicates the instance group on which the job ran, if specified.
Job Tags: Tags show the various job operations executed.
이러한 항목을 클릭하면(해당되는 경우) 해당 작업 템플릿, 프로젝트 및 기타 오브젝트를 볼 수 있습니다.
24.3. Playbook Run Jobs¶
When a playbook is executed, the full results automatically display in the Output tab. This shows the same information you would see if you ran it through the Ansible command line, and can be useful for debugging.
이벤트 요약에는 이 플레이북의 일부로 실행된 이벤트의 총계가 포함됩니다.
the number of times this playbook has ran in the Plays field
the number of tasks associated with this playbook in the Tasks field
the number of hosts associated with this playbook in the Hosts field
the amount of time it took to complete the playbook run in the Elapsed field
The icons next to the events summary allow you to relaunch (), download () the job output, or delete () the job.
The host status bar runs across the top of the Output view. Hover over a section of the host status bar and the number of hosts associated with that particular status displays.
The output for a Playbook job is also accessible after launching a job from the Jobs tab of its Job Templates page.
Clicking on the various line item tasks in the output, you can view its host details.
24.3.1. 검색¶
검색을 사용하여 특정 이벤트, 호스트 이름 및 해당 상태를 조회합니다. 특정 상태의 특정 호스트만 필터링하려면 다음의 유효한 상태 중 하나를 지정합니다.
OK: 플레이북 작업에서 “Ok”를 반환했습니다.
변경됨: 플레이북 작업이 실제로 실행되었습니다. Ansible 작업은 멱등이 되도록 작성되어야 하므로 작업이 호스트에서 아무것도 실행하지 않고도 성공적으로 종료될 수 있습니다. 이 경우 작업에서 OK를 반환하지만 변경됨은 반환하지 않습니다.
실패: 작업에 실패했습니다. 이 호스트에 대한 추가 플레이북 실행이 중지되었습니다.
연결할 수 없음: 호스트에서 네트워크에 연결할 수 없거나 호스트와 연결된 다른 치명적인 오류가 있습니다.
건너뜀: 호스트가 대상 상태에 도달하는 데 필요한 변경 사항이 없기 때문에 플레이북 작업을 건너뛰었습니다.
복구됨: Ansible 2.8에 도입된 것으로, 실패한 작업을 표시한 다음 복구 섹션을 실행합니다.
무시됨: Ansible 2.8에 도입된 것으로, 실패하고 ``ignore_errors: yes``로 구성된 작업을 표시합니다.
These statuses also display at bottom of each Stdout pane, in a group of “stats” called the Host Summary fields.
The example below shows a search with only unreachable hosts.
검색 사용법에 대한 자세한 내용은 검색 장을 참조하십시오.
표준 출력 뷰에는 특정 작업에서 발생하는 모든 이벤트가 표시됩니다. 기본적으로 모든 세부 정보가 표시되도록 모든 행이 펼쳐져 있습니다. 플레이 및 작업의 헤더만 포함된 뷰로 전환하려면 모두 접기 버튼(
)을 사용합니다. 표준 출력의 모든 행을 보려면 
버튼을 클릭합니다.
또는 특정 플레이나 작업 옆에 있는 화살표 아이콘을 클릭하여 모든 세부 정보를 표시할 수 있습니다. 화살표를 클릭하여 옆쪽 화살표가 아래쪽을 향하면 해당 플레이 또는 작업과 연결된 행이 펼쳐집니다. 화살표를 다시 클릭하여 옆쪽을 향하면 해당 행이 접히고 숨겨집니다.
펼치기/접기 모드에서 세부 정보를 볼 때 유의해야 할 사항은 다음과 같습니다.
접히지 않고 표시되는 각 행에는 해당 행 번호와 시작 시간이 있습니다.
펼치기/접기 아이콘은 플레이 또는 작업이 완료된 후 플레이 또는 작업 시작 부분에 있습니다.
특정 플레이 또는 작업을 쿼리하는 경우에는 완료된 프로세스의 끝부분에 접힌 상태로 표시됩니다.
경우에 따라 출력이 너무 커서 표시할 수 없다는 오류 메시지가 표시됩니다. 이러한 오류는 이벤트가 4000개를 초과할 때 발생합니다. 특정 이벤트에서 오류를 바이패스하려면 검색 및 필터링을 사용합니다.
표준 아웃 창에서 이벤트 행을 클릭하면 호스트 이벤트 대화 상자가 별도의 창에 표시됩니다. 이 창에는 특정 이벤트의 영향을 받는 호스트가 표시됩니다.
참고
최신 버전의 |aap|으로 업그레이드하려면 모든 기록 플레이북 출력 및 이벤트를 점진적으로 마이그레이션해야 합니다. 이 마이그레이션 프로세스는 점진적이며 설치가 완료된 후 백그라운드에서 자동으로 수행됩니다. 기록 작업 출력 양이 매우 많은(수십 또는 수백 GB의 출력) 설치에서는 마이그레이션이 완료될 때까지 작업 출력이 누락되었을 수 있습니다. 최근 데이터가 출력 맨 위에 표시되고 오래된 이벤트가 아래에 표시됩니다. 많은 양의 이벤트가 포함된 작업을 마이그레이션하는 것은 적은 양의 작업보다 더 오래 걸릴 수 있습니다.
24.3.2. Host Details¶
The Host Details dialog shows information about the host affected by the selected event and its associated play and task:
호스트
상태
the type of run in the Play field
the type of Task
해당하는 경우 작업의 Ansible 모듈 및 해당 모듈의 모든 인수
To view the results in JSON format, click on the JSON tab. To view the output of the task, click the Standard Out. To view errors from the output, click Standard Error.
24.3.3. Playbook run details¶
Access the Details tab to provide details about the job execution.
Notable details of the job executed are:
상태: 다음 중 하나일 수 있습니다.
Pending - The playbook run has been created, but not queued or started yet. Any job, not just playbook runs, will stay in pending until it is actually ready to be run by the system. Reasons for playbook runs not being ready include dependencies that are currently running (all dependencies must be completed before the next step can execute), or there is not enough capacity to run in the locations it is configured to.
대기 중 - 플레이북 실행이 대기열에 있으며 실행 대기 중입니다.
실행 중 - 플레이북 실행이 현재 진행 중입니다.
성공 - 마지막 플레이북 실행에 성공했습니다.
실패 - 마지막 플레이북 실행에 실패했습니다.
Job Template: The name of the job template from which this job was launched.
인벤토리: 이 작업을 실행하도록 선택한 대상 인벤토리입니다.
Project: The name of the project associated with the launched job.
Project Status: The status of the project associated with the launched job.
Playbook: The playbook used to launch this job.
Execution Environment: The name of the execution environment used in this job.
Container Group: The name of the container group used in this job.
Credentials: The credential(s) used in this job.
추가 변수: 작업 템플릿을 생성할 때 전달된 모든 추가 변수가 여기에 표시됩니다.
이러한 항목을 클릭하면(해당되는 경우) 해당 작업 템플릿, 프로젝트 및 기타 오브젝트를 볼 수 있습니다.
24.4. Automation controller Capacity Determination and Job Impact¶
이 섹션에서는 인스턴스 그룹의 용량과 해당 용량이 작업에 미치는 영향에 대해 설명합니다. 컨테이너 그룹의 경우 |ata|의 :ref:`ag_container_capacity`를 참조하십시오.
automation controller 용량 시스템은 인스턴스에 사용할 수 있는 리소스 양과 실행 중인 작업의 크기(*영향*이라고 함)를 기준으로 인스턴스에서 실행할 수 있는 작업 수를 결정합니다. 이를 결정하는 데 사용되는 알고리즘은 전적으로 다음 두 가지를 기반으로 합니다.
시스템에 사용할 수 있는 메모리의 양(
mem_capacity)시스템에 사용할 수 있는 CPU의 양(
cpu_capacity)
용량은 인스턴스 그룹에도 영향을 미칩니다. 그룹은 인스턴스로 구성되므로 인스턴스를 여러 그룹에 할당할 수도 있습니다. 즉, 한 인스턴스에 대한 영향이 다른 그룹의 전체 용량에 잠재적으로 영향을 미칠 수 있습니다.
Instance Groups (not instances themselves) can be assigned to be used by jobs at various levels (see 클러스터링). When the Task Manager is preparing its graph to determine which group a job will run on, it will commit the capacity of an Instance Group to a job that hasn’t or isn’t ready to start yet.
마지막으로 더 작은 구성에서 작업을 실행할 수 있는 인스턴스가 하나만 있는 경우, 작업 관리자는 해당 작업이 인스턴스를 용량 이상으로 푸시하더라도 인스턴스에서 실행되도록 허용합니다. 이렇게 하면 시스템이 프로비저닝되지 않아 작업 자체가 중단되지 않습니다.
따라서 용량과 영향은 작업과 인스턴스/인스턴스 그룹에 대한 제로섬 시스템이 아닙니다.
분할된 작업 및 용량에 미치는 영향에 대한 자세한 내용은 :ref:`ug_job_slice_execution`을 참조하십시오.
24.4.1. 용량 알고리즘의 리소스 결정¶
용량 알고리즘은 시스템에서 동시에 실행할 수 있는 포크 수를 결정하기 위해 정의합니다. 이 알고리즘은 Ansible 자체에서 동시에 통신할 시스템 수를 제어합니다. 일반적으로 automation controller 시스템이 실행 중인 포크 수를 늘리면 더 많은 작업을 병렬로 수행하여 작업을 더 빠르게 실행할 수 있습니다. 단점은 이로 인해 시스템 부하가 증가하여 작업 속도가 전반적으로 느려질 수 있다는 것입니다.
|At|는 용량을 결정할 때 두 가지 모드로 작동할 수 있습니다. ``mem_capacity``(기본값)를 사용하면 시스템의 메모리 부족을 방지하면서 CPU 리소스를 오버 커밋할 수 있습니다. 대부분의 작업이 CPU 종속이 아닌 경우 이 모드를 선택하면 포크 수가 최대화됩니다.
24.4.1.1. 메모리 상대 용량¶
``mem_capacity``는 포크당 필요한 메모리 양을 기준으로 계산됩니다. 내부 구성 요소의 오버헤드를 고려하면 포크당 약 100MB가 됩니다. 용량 알고리즘에서는 Ansible 작업에 사용할 수 있는 메모리의 양을 검토할 때 다른 서비스의 존재를 고려하여 2GB의 메모리를 예약합니다. 이에 대한 알고리즘 공식은 다음과 같습니다.
(mem - 2048) / mem_per_fork
예를 들면 다음과 같습니다.
(4096 - 2048) / 100 == ~20
따라서 메모리가 4GB인 시스템은 20개의 포크를 실행할 수 있습니다. 값 ``mem_per_fork``는 설정 값(또는 환경 변수) ``SYSTEM_TASK_FORKS_MEM``을 설정하여 제어할 수 있으며, 기본값은 100입니다.
24.4.1.2. CPU 상대 용량¶
Ansible 워크로드는 상당히 CPU 종속적인 경우가 많습니다. 이러한 경우 동시 워크로드를 줄이면 더 많은 작업을 더 빠르게 실행하고 해당 작업의 평균 완료 시간을 줄일 수 있습니다.
mem_capacity 알고리즘이 포크당 필요한 메모리 양을 사용하는 것처럼 cpu_capacity 알고리즘은 포크당 필요한 CPU 리소스의 양을 확인합니다. 기준 값은 코어당 포크 4개입니다. 이에 대한 알고리즘 공식은 다음과 같습니다.
cpus * fork_per_cpu
예를 들어 4코어 시스템은 다음과 같습니다.
4 * 4 == 16
값 ``fork_per_cpu``는 설정 값(또는 환경 변수) ``SYSTEM_TASK_FORKS_CPU``를 설정하여 제어할 수 있으며, 기본값은 4입니다.
24.4.2. 작업이 용량에 미치는 영향¶
용량을 선택할 때는 각 작업 유형이 용량에 미치는 영향을 이해하는 것이 중요합니다.
그러면 https://www.ansible.com/blog/ansible-performance-tuning에서 포크가 Ansible에 의미하는 바를 이해하는 데 도움이 됩니다(“포크 알아보기” 섹션 참조).
Ansible의 기본 포크 값은 5입니다. 그러나 |at|에서 그보다 적은 수의 시스템에 대해 실행 중임을 확인하는 경우 실제 동시성 값은 더 낮아집니다.
작업이 실행되면 |at|에서 Ansible 상위 프로세스를 보완하기 위해 선택된 포크 수에 1을 추가합니다. 따라서 포크 값이 5인 시스템 5개에 대해 플레이북을 실행하는 경우, 작업이 미치는 영향의 관점에서의 실제 포크 값은 6이 됩니다.
24.4.2.1. 자동화 컨트롤러에서 작업 유형이 미치는 영향¶
jobs 및 임시 작업은 위 모델인 포크 수 + 1을 따릅니다. 작업 템플릿에 포크 값을 설정하면 작업 용량 값은 제공한 포크 값의 최솟값과 보유한 호스트 수에 1을 더한 값이 됩니다. 추가된 하나는 상위 Ansible 프로세스를 고려한 것입니다.
인스턴스 용량에 따라 특정 인스턴스에 할당되는 작업이 결정됩니다. 작업 및 임시 명령은 해당 포크 값이 높을수록 용량을 더 많이 사용합니다.
기타 작업 유형의 영향은 다음과 같이 정해져 있습니다.
인벤토리 업데이트: 1
프로젝트 업데이트: 1
시스템 작업: 5
작업 템플릿에 포크 값을 설정하지 않으면 작업에서 Ansible의 기본 포크 값인 5를 사용합니다. Ansible은 기본적으로 포크 5개로 기본 설정되지만 작업의 호스트가 5개 미만인 경우 더 적게 사용됩니다. 일반적으로 포크 값을 시스템에서 사용할 수 있는 것보다 높게 설정하면 메모리가 부족하거나 CPU를 오버 커밋하여 문제가 발생할 수 있습니다. 따라서 사용하는 작업 템플릿 포크 값이 시스템에 적합해야 합니다. 포크를 1000개 사용하는 플레이북이 있지만 개별적으로 이렇게 많은 용량이 있는 시스템이 없는 경우, 시스템 크기가 부족하여 성능 또는 리소스 문제가 발생할 위험이 있습니다.
24.4.2.2. 적절한 용량 선택¶
CPU 종속 또는 메모리 종속 용량 제한 중에서 용량을 선택하는 일은 본질적으로 최소 또는 최대 포크 수 중에서 선택하는 것과 같습니다. 위 예에서 CPU 용량은 최대 16개의 포크를 허용하는 반면 메모리 용량은 20개를 허용합니다. 일부 시스템의 경우 이러한 용량 차이가 클 수 있으며 종종 이 둘 사이의 균형을 유지해야 할 수도 있습니다.
인스턴스 필드 ``capacity_adjustment``를 사용하면 어느 쪽의 용량을 고려할지 선택할 수 있습니다. 이 필드는 0.0에서 1.0 사이의 값으로 표시됩니다. 값을 1.0으로 설정하면 가장 큰 값이 사용됩니다. 위 예제에서는 메모리 용량을 사용하므로 포크 값 20개가 선택됩니다. 값을 0.0으로 설정하면 가장 작은 값이 사용됩니다. 값 0.5는 두 알고리즘을 50/50 비율로 적용하여 18개가 됩니다.
16 + (20 - 16) * 0.5 == 18
사용자 인터페이스에서 용량을 보거나 편집하려면 인스턴스 그룹의 인스턴스 탭을 선택합니다.
24.5. 작업 분기 덮어쓰기¶
프로젝트는 scm_branch 필드의 소스 제어에서 사용할 분기, 태그 또는 참조를 지정합니다. 해당 항목은 표시된 것처럼 프로젝트 세부 정보 필드에 지정된 값으로 표시됩니다.
프로젝트에는 ‘분기 덮어쓰기 허용’ 옵션이 있습니다. 이를 선택하면 프로젝트 관리자가 분기 선택을 해당 프로젝트를 사용하는 작업 템플릿에 위임할 수 있습니다(use_role 프로젝트만 필요).
24.5.1. 소스 트리 복사 동작¶
모든 작업 실행에는 자체 개인 데이터 디렉터리가 있습니다. 이 디렉터리에는 작업이 실행되고 있는 지정된 ``scm_branch``의 프로젝트 소스 트리 사본이 포함되어 있습니다. 작업에서는 프로젝트 폴더를 변경하고 실행이 계속되는 동안 이러한 변경 사항을 활용할 수 있습니다. 이 폴더는 임시이며 작업 실행이 끝날 때 정리됩니다.
**정리**를 선택하면 |at|에서 git 또는 Subversion`_과 관련된 각 Ansible 모듈에서 ``force` 매개변수를 사용하여 리포지터리의 로컬 사본에 있는 수정된 파일을 삭제합니다.
24.5.2. 프로젝트 버전 동작¶
Typically, during a project update, the revision of the default branch (specified in the SCM Branch field of the project) is stored when updated, and jobs using that project will employ this revision. Providing a non-default SCM Branch (not a commit hash or tag) in a job, the newest revision is pulled from the source control remote immediately before the job starts. This revision is shown in the Source Control Revision field of the job and its respective project update.
결과적으로 기본이 아닌 분기에는 오프라인 작업을 실행할 수 없습니다. 작업이 소스 제어에서 정적 버전을 실행 중인지 확인하려면 태그 또는 커밋 해시를 사용합니다. 프로젝트 업데이트에서는모든 분기의 버전을 저장하지 않고 프로젝트 기본 분기만 저장합니다.
SCM 분기 필드가 검증되지 않았으므로 유효성 확인을 위해 프로젝트를 업데이트해야 합니다. 이 필드가 제공되거나 메시지가 표시되면 작업 템플릿의 플레이북 필드가 검증되지 않으며 필요한 플레이북이 있는지 확인하려면 작업 템플릿을 시작해야 합니다.
24.5.3. Git 참조 사양¶
SCM 참조 사양 필드는 업데이트 중 원격에서 다운로드해야 하는 추가 참조를 지정합니다. 예를 들면 다음과 같습니다.
대규모 프로젝트의 경우 첫 번째 또는 두 번째 예제를 사용할 때 성능에 미치는 영향을 고려해야 합니다.
SCM 참조 사양 매개변수는 프로젝트 분기의 가용성에 영향을 미치며, 이 매개변수가 없으면 사용할 수 없는 참조에 대한 액세스를 허용할 수 있습니다. 위 예제에서는 사용자가 SCM 분기**에서 가져오기 요청을 제공할 수 있도록 허용하는데, **SCM 참조 사양 필드 없이는 수행할 수 없습니다.
Ansible Git 모듈은 기본적으로 refs/heads/*``를 가져옵니다. 즉, **SCM 참조 사양**이 비어 있는 경우 프로젝트의 분기 및 태그(그 안의 커밋 해시 포함)를 SCM 분기로 사용할 수 있습니다. **SCM 참조 사양** 필드에 지정된 값은 덮어쓰기로 사용할 수 있는 *SCM 분기** 필드에 영향을 미칩니다. 프로젝트 업데이트(모든 유형)는 추가 ``git fetch 명령을 수행하여 원격에서 해당 참조 사양을 가져옵니다.
예: 첫 번째 또는 두 번째 참조 사양 예에서 분기 덮어쓰기를 허용하는 프로젝트를 설정할 수 있습니다. –> **SCM 분기**를 묻는 작업 템플릿에 이 프로젝트를 사용합니다. –> 새 가져오기 요청이 생성되면 클라이언트가 작업 템플릿을 시작하여 분기 ``pull/N/head``를 제공할 수 있습니다. –> 작업 템플릿이 제공된 GitHub 가져오기 요청 참조에 대해 실행됩니다.
Ansible Git 모듈에 대한 자세한 내용은 https://docs.ansible.com/ansible/latest/modules/git_module.html을 참조하십시오.