25. 작업¶

25.1.1. 인벤토리 동기화 세부 정보¶

세부 정보 탭에 액세스하여 작업 실행에 대한 세부 정보를 제공합니다.

실행된 작업의 주요 세부 사항은 다음과 같습니다.

• 상태: 다음 중 하나일 수 있습니다.

  • 보류 중 - 인벤토리 동기화가 생성되었지만 아직 대기열에 추가되거나 시작되지 않았습니다. 인벤토리 소스 동기화뿐만 아니라 모든 작업은 시스템에서 실제로 실행할 준비가 될 때까지 보류 중 상태로 유지됩니다. 인벤토리 소스 동기화가 준비되지 않은 이유는 현재 실행 중인 종속 항목이 있거나(다음 단계를 실행하려면 모든 종속 항목을 완료해야 함) 구성된 위치에서 실행하는 데 필요한 용량이 충분하지 않기 때문입니다.

  • 대기 중 - 인벤토리 동기화가 대기열에 있으며 실행 대기 중입니다.

  • 실행 중 - 인벤토리 동기화가 현재 진행 중입니다.

  • 성공 - 인벤토리 동기화 작업이 성공했습니다.

  • 실패 - 인벤토리 동기화 작업에 실패했습니다.

• 인벤토리: 연결된 인벤토리 그룹의 이름입니다.

• 소스: 클라우드 인벤토리의 유형입니다.

• 인벤토리 프로젝트: 이 인벤토리 동기화 작업의 소스로 사용되는 프로젝트입니다.

• 실행 환경: execution environment 사용

• 실행 노드: 작업을 실행하는 데 사용하는 노드입니다.

• 인스턴스 그룹: 이 작업에 사용되는 인스턴스 그룹의 이름입니다(컨트롤러는 기본 인스턴스 그룹임).

이러한 항목을 클릭하면(해당되는 경우) 해당 작업 템플릿, 프로젝트 및 기타 오브젝트를 볼 수 있습니다.

25.2.1. SCM 인벤토리 세부 정보¶

세부 정보 탭에 액세스하여 작업 실행 및 관련 프로젝트에 대한 세부 정보를 제공합니다.

실행된 작업의 주요 세부 사항은 다음과 같습니다.

• 상태: 다음 중 하나일 수 있습니다.

  • 보류 중 - SCM 작업이 생성되었지만 아직 대기열에 추가되거나 시작되지 않았습니다. SCM 작업뿐만 아니라 모든 작업은 시스템에서 실제로 실행할 준비가 될 때까지 보류 중 상태로 유지됩니다. SCM 작업이 준비되지 않은 이유는 현재 실행 중인 종속 항목이 있거나(다음 단계를 실행하려면 모든 종속 항목을 완료해야 함) 구성된 위치에서 실행하는 데 필요한 용량이 충분하지 않기 때문입니다.

  • 대기 중 - SCM 작업이 대기열에 있으며 실행 대기 중입니다.

  • 실행 중 - SCM 작업이 현재 진행 중입니다.

  • 성공 - 마지막 SCM 작업에 성공했습니다.

  • 실패 - 마지막 SCM 작업에 실패했습니다.

• 작업 유형: SCM 작업에 소스 제어 업데이트가 표시됩니다.

• 프로젝트: 프로젝트의 이름입니다.

• 프로젝트 상태: 연결된 프로젝트가 성공적으로 업데이트되었는지가 표시됩니다.

• 수정 사항: 이 작업에서 사용된 원본 프로젝트의 수정 사항 번호를 나타냅니다.

• 실행 환경: 이 작업을 실행하는 데 사용되는 |ee|을/를 지정합니다.

• 실행 노드: 작업이 실행된 노드를 나타냅니다.

• 인스턴스 그룹: 지정된 경우 작업이 실행된 인스턴스 그룹을 나타냅니다.

• 작업 태그: 태그는 실행된 다양한 작업 실행 상태를 보여줍니다.

이러한 항목을 클릭하면(해당되는 경우) 해당 작업 템플릿, 프로젝트 및 기타 오브젝트를 볼 수 있습니다.

25.3.1. 검색¶

검색을 사용하여 특정 이벤트, 호스트 이름 및 해당 상태를 조회합니다. 특정 상태의 특정 호스트만 필터링하려면 다음의 유효한 상태 중 하나를 지정합니다.

• OK: 플레이북 작업에서 《Ok》를 반환했습니다.

• 변경됨: 플레이북 작업이 실제로 실행되었습니다. Ansible 작업은 멱등이 되도록 작성되어야 하므로 작업이 호스트에서 아무것도 실행하지 않고도 성공적으로 종료될 수 있습니다. 이 경우 작업에서 OK를 반환하지만 변경됨은 반환하지 않습니다.

• 실패: 작업에 실패했습니다. 이 호스트에 대한 추가 플레이북 실행이 중지되었습니다.

• 연결할 수 없음: 호스트에서 네트워크에 연결할 수 없거나 호스트와 연결된 다른 치명적인 오류가 있습니다.

• 건너뜀: 호스트가 대상 상태에 도달하는 데 필요한 변경 사항이 없기 때문에 플레이북 작업을 건너뛰었습니다.

• 복구됨: Ansible 2.8에 도입된 것으로, 실패한 작업을 표시한 다음 복구 섹션을 실행합니다.

• 무시됨: Ansible 2.8에 도입된 것으로, 실패하고 ``ignore_errors: yes``로 구성된 작업을 표시합니다.

이러한 상태는 각 표준 출력 창의 맨 아래에 호스트 요약 필드라는 《통계》 그룹에 표시됩니다.

아래 예제는 연결할 수 없는 호스트만 포함하는 검색을 보여 줍니다.

검색 사용법에 대한 자세한 내용은 검색 장을 참조하십시오.

표준 출력 뷰에는 특정 작업에서 발생하는 모든 이벤트가 표시됩니다. 기본적으로 모든 세부 정보가 표시되도록 모든 행이 펼쳐져 있습니다. 플레이 및 작업의 헤더만 포함된 뷰로 전환하려면 모두 접기 버튼()을 사용합니다. 표준 출력의 모든 행을 보려면 버튼을 클릭합니다.

또는 특정 플레이나 작업 옆에 있는 화살표 아이콘을 클릭하여 모든 세부 정보를 표시할 수 있습니다. 화살표를 클릭하여 옆쪽 화살표가 아래쪽을 향하면 해당 플레이 또는 작업과 연결된 행이 펼쳐집니다. 화살표를 다시 클릭하여 옆쪽을 향하면 해당 행이 접히고 숨겨집니다.

펼치기/접기 모드에서 세부 정보를 볼 때 유의해야 할 사항은 다음과 같습니다.

• 접히지 않고 표시되는 각 행에는 해당 행 번호와 시작 시간이 있습니다.

• 펼치기/접기 아이콘은 플레이 또는 작업이 완료된 후 플레이 또는 작업 시작 부분에 있습니다.

• 특정 플레이 또는 작업을 쿼리하는 경우에는 완료된 프로세스의 끝부분에 접힌 상태로 표시됩니다.

• 경우에 따라 출력이 너무 커서 표시할 수 없다는 오류 메시지가 표시됩니다. 이러한 오류는 이벤트가 4000개를 초과할 때 발생합니다. 특정 이벤트에서 오류를 바이패스하려면 검색 및 필터링을 사용합니다.

표준 아웃 창에서 이벤트 행을 클릭하면 호스트 이벤트 대화 상자가 별도의 창에 표시됩니다. 이 창에는 특정 이벤트의 영향을 받는 호스트가 표시됩니다.

25.3.2. 호스트 세부 정보¶

호스트 세부 정보 대화 상자에는 선택한 이벤트 및 연결된 플레이와 작업의 영향을 받는 호스트에 대한 정보가 표시됩니다.

• 호스트

• 상태

• 플레이 필드에서 실행 유형

• 작업 유형

• 해당하는 경우 작업의 Ansible 모듈 및 해당 모듈의 모든 인수

결과를 JSON 형식으로 보려면 JSON 탭을 클릭합니다. 작업 출력을 보려면 **표준 출력**을 클릭합니다. 출력에서 오류를 보려면 **표준 오류**를 클릭합니다.

25.3.3. 플레이북 실행 세부 정보¶

세부 정보 탭에 액세스하여 작업 실행에 대한 세부 정보를 제공합니다.

실행된 작업의 주요 세부 사항은 다음과 같습니다.

• 상태: 다음 중 하나일 수 있습니다.

  • 보류 중 - 플레이북 실행이 생성되었지만 아직 대기열에 추가되거나 시작되지 않았습니다. 플레이북 실행뿐만 아니라 모든 작업은 시스템에서 실제로 실행할 준비가 될 때까지 보류 중 상태로 유지됩니다. 플레이북 실행이 준비되지 않은 이유는 현재 실행 중인 종속 항목이 있거나(다음 단계를 실행하려면 모든 종속 항목을 완료해야 함) 구성된 위치에서 실행하는 데 필요한 용량이 충분하지 않기 때문입니다.

  • 대기 중 - 플레이북 실행이 대기열에 있으며 실행 대기 중입니다.

  • 실행 중 - 플레이북 실행이 현재 진행 중입니다.

  • 성공 - 마지막 플레이북 실행에 성공했습니다.

  • 실패 - 마지막 플레이북 실행에 실패했습니다.

• 작업 템플릿: 이 작업이 시작된 작업 템플릿의 이름입니다.

• 인벤토리: 이 작업을 실행하도록 선택한 대상 인벤토리입니다.

• 프로젝트: 시작된 작업과 관련된 프로젝트의 이름입니다.

• 프로젝트 상태: 시작된 작업과 관련된 프로젝트의 상태입니다.

• 플레이북: 이 작업을 시작하는 데 사용되는 플레이북입니다.

• 실행 환경: 이 작업에서 사용되는 execution environment 의 이름입니다.

• 컨테이너 그룹: 이 작업에 사용된 컨테이너 그룹의 이름입니다.

• 인증 정보: 이 작업에서 사용되는 인증 정보입니다.

• 추가 변수: 작업 템플릿을 생성할 때 전달된 모든 추가 변수가 여기에 표시됩니다.

이러한 항목을 클릭하면(해당되는 경우) 해당 작업 템플릿, 프로젝트 및 기타 오브젝트를 볼 수 있습니다.

25.4.1. 용량 알고리즘의 리소스 결정¶

용량 알고리즘은 시스템에서 동시에 실행할 수 있는 포크 수를 결정하기 위해 정의합니다. 이 알고리즘은 Ansible 자체에서 동시에 통신할 시스템 수를 제어합니다. 일반적으로 automation controller 시스템이 실행 중인 포크 수를 늘리면 더 많은 작업을 병렬로 수행하여 작업을 더 빠르게 실행할 수 있습니다. 단점은 이로 인해 시스템 부하가 증가하여 작업 속도가 전반적으로 느려질 수 있다는 것입니다.

|At|는 용량을 결정할 때 두 가지 모드로 작동할 수 있습니다. ``mem_capacity``(기본값)를 사용하면 시스템의 메모리 부족을 방지하면서 CPU 리소스를 오버 커밋할 수 있습니다. 대부분의 작업이 CPU 종속이 아닌 경우 이 모드를 선택하면 포크 수가 최대화됩니다.

(mem - 2048) / mem_per_fork

(4096 - 2048) / 100 == ~20

cpus * fork_per_cpu

4 * 4 == 16

25.4.2. 작업이 용량에 미치는 영향¶

용량을 선택할 때는 각 작업 유형이 용량에 미치는 영향을 이해하는 것이 중요합니다.

그러면 https://www.ansible.com/blog/ansible-performance-tuning에서 포크가 Ansible에 의미하는 바를 이해하는 데 도움이 됩니다(《포크 알아보기》 섹션 참조).

Ansible의 기본 포크 값은 5입니다. 그러나 |at|에서 그보다 적은 수의 시스템에 대해 실행 중임을 확인하는 경우 실제 동시성 값은 더 낮아집니다.

작업이 실행되면 |at|에서 Ansible 상위 프로세스를 보완하기 위해 선택된 포크 수에 1을 추가합니다. 따라서 포크 값이 5인 시스템 5개에 대해 플레이북을 실행하는 경우, 작업이 미치는 영향의 관점에서의 실제 포크 값은 6이 됩니다.

25.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

사용자 인터페이스에서 용량을 보거나 편집하려면 인스턴스 그룹의 인스턴스 탭을 선택합니다.

25.5.1. 소스 트리 복사 동작¶

모든 작업 실행에는 자체 개인 데이터 디렉터리가 있습니다. 이 디렉터리에는 작업이 실행되고 있는 지정된 ``scm_branch``의 프로젝트 소스 트리 사본이 포함되어 있습니다. 작업에서는 프로젝트 폴더를 변경하고 실행이 계속되는 동안 이러한 변경 사항을 활용할 수 있습니다. 이 폴더는 임시이며 작업 실행이 끝날 때 정리됩니다.

**정리**를 선택하면 |at|에서 git 또는 Subversion`_과 관련된 각 Ansible 모듈에서 ``force` 매개변수를 사용하여 리포지터리의 로컬 사본에 있는 수정된 파일을 삭제합니다.

25.5.2. 프로젝트 버전 동작¶

일반적으로 프로젝트를 업데이트하는 동안 기본 분기의 버전(프로젝트의 SCM 분기 필드에 지정되어 있음)이 업데이트되면 해당 버전이 저장되고 해당 프로젝트를 사용하는 작업에 이 버전이 사용됩니다. 작업에 기본이 아닌 SCM 분기 (커밋 해시 또는 태그가 아님)를 제공하면 작업이 시작되기 직전 소스 제어 원격에서 최신 버전을 가져옵니다. 이 버전은 작업의 소스 컨트롤 버전 및 각각의 해당 프로젝트 업데이트에 표시됩니다.

결과적으로 기본이 아닌 분기에는 오프라인 작업을 실행할 수 없습니다. 작업이 소스 제어에서 정적 버전을 실행 중인지 확인하려면 태그 또는 커밋 해시를 사용합니다. 프로젝트 업데이트에서는모든 분기의 버전을 저장하지 않고 프로젝트 기본 분기만 저장합니다.

SCM 분기 필드가 검증되지 않았으므로 유효성 확인을 위해 프로젝트를 업데이트해야 합니다. 이 필드가 제공되거나 메시지가 표시되면 작업 템플릿의 플레이북 필드가 검증되지 않으며 필요한 플레이북이 있는지 확인하려면 작업 템플릿을 시작해야 합니다.

25.5.3. Git 참조 사양¶

SCM 참조 사양 필드는 업데이트 중 원격에서 다운로드해야 하는 추가 참조를 지정합니다. 예를 들면 다음과 같습니다.

1. refs/*:refs/remotes/origin/*: 원격의 원격을 포함하여 모든 참조를 가져옵니다.

2. ``refs/pull/*:refs/remotes/origin/pull/*``(GitHub 관련): 모든 가져오기 요청에 대해 모든 참조를 가져옵니다.

3. refs/pull/62/head:refs/remotes/origin/pull/62/head: 하나의 GitHub 가져오기 요청에 대한 참조를 가져옵니다.

대규모 프로젝트의 경우 첫 번째 또는 두 번째 예제를 사용할 때 성능에 미치는 영향을 고려해야 합니다.

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을 참조하십시오.