자동화 실행 사용

자동화 컨트롤러를 사용하면 플레이북이 실시간으로 실행되는 것을 볼 수 있으므로 각 호스트를 확인하는 것을 확인할 수 있습니다. 돌아가서 특정 작업 및 호스트에 대한 결과를 자세히 살펴보거나, 특정 플레이 또는 호스트를 검색하고 해당 결과만 보거나 수정해야 하는 오류를 찾을 수 있습니다.

자동화 컨트롤러를 사용하여 즐겨 찾는 프로젝트에 액세스하고 웹 인터페이스에서 실행을 다시 트리거합니다. 자동화 컨트롤러에서 입력 변수를 요청하고, 인증 정보를 입력하라는 메시지를 표시하고, 작업을 시작 및 모니터링하고, 결과 및 호스트 기록을 표시합니다.

자동화 컨트롤러를 사용하면 다음을 수행할 수 있습니다.

자동화 컨트롤러는 편집된 오브젝트 및 시작된 작업을 포함하여 작업 기록과 작업을 수행한 사용자를 기록합니다.

사용자 또는 팀에 작업 템플릿을 사용할 수 있는 권한을 부여하려면 작업 템플릿에 직접 권한을 할당할 수 있습니다. 인증 정보는 자동화 컨트롤러 RBAC 시스템의 전체 오브젝트이며 많은 사용자 또는 팀에 할당될 수 있습니다.

자동화 컨트롤러에는 감사자 유형이 포함됩니다. 시스템 수준 감사자는 시스템 자동화의 모든 측면을 볼 수 있지만 자동화를 실행하거나 변경할 수 있는 권한은 없습니다. 감사자는 REST API에서 자동화 정보를 스크랩하는 서비스 계정에 유용합니다.

자동화 컨트롤러에는 노드가 필요에 따라 구성을 요청할 수 있는 강력한 선택적 프로비저닝 콜백 기능이 포함되어 있습니다. 이는 클라우드 자동 확장 시나리오에 이상적인 솔루션이며 다음과 같은 기능을 포함합니다.

자동화 컨트롤러 REST API는 시스템 관리 애플리케이션에 이상적인 RESTful API로, 모든 리소스가 완전히 검색 가능하고 페이지가 매겨지고, 잘 모델링됩니다. 스타일 API 브라우저를 사용하면 http://<server name>/api/ 의 API 루트에서 모든 리소스 및 관계를 표시할 수 있습니다. 사용자 인터페이스에서 수행할 수 있는 모든 작업은 API에서 수행할 수 있습니다.

Ansible Automation Platform은 시스템 또는 시스템을 백업 및 복원하여 필요에 따라 인스턴스를 쉽게 백업하고 복제할 수 있습니다.

Ansible Galaxy requirements.yml 파일을 프로젝트 디렉터리에 포함하면 자동화 컨트롤러에서 Galaxy, GitHub 또는 로컬 소스 제어에서 플레이북에 필요한 역할을 자동으로 가져옵니다. 자세한 내용은 Ansible Galaxy 지원을 참조하십시오.

OpenStack에서 동적 인벤토리 지원을 사용할 수 있습니다. 이를 통해 OpenStack 클라우드에서 실행 중인 가상 머신 또는 이미지를 대상으로 지정할 수 있습니다.

자세한 내용은 OpenStack 인증 정보 유형을 참조하십시오.

원격 명령 실행을 사용하여 단일 사용자 추가, 단일 보안 취약점 업데이트 또는 실패한 서비스 재시작과 같은 간단한 작업을 수행합니다. 단일 Ansible 플레이로 설명할 수 있는 모든 작업은 인벤토리의 호스트 또는 호스트 그룹에서 실행할 수 있습니다. 시스템을 빠르고 쉽게 관리할 수 있습니다. RBAC 엔진 및 자세한 감사 로깅으로 인해 어떤 사용자가 특정 작업을 완료했는지 알 수 있습니다.

사실 캐싱 기능을 사용하여 사실을 수집할 수 있습니다. 자세한 내용은 팩트 캐싱 을 참조하십시오.

자동화 상태를 추적합니다.

다음 알림을 구성할 수 있습니다.

다음 알림 소스가 지원됩니다.

이전 알림 유형마다 알림 메시지를 사용자 지정할 수도 있습니다.

자동화 컨트롤러는 다음과 같은 통합을 지원합니다.

자세한 내용은 Red Hat Satellite 6 을 참조하십시오.

자세한 내용은 Red Hat Ansible Automation Platform Remediations용 Red Hat Insights 설정을 참조하십시오.

사용자 지정 Ansible 환경 지원을 통해 다양한 Ansible 환경을 보유하고 다양한 팀 및 작업에 대한 사용자 지정 경로를 지정할 수 있습니다.

자동화 컨트롤러는 다음을 지원합니다.

LDAP 및 SAML 지원을 통해 엔터프라이즈 계정 정보를 보다 유연한 방식으로 통합할 수 있습니다.

토큰 기반 인증을 사용하면 통합된 OAuth 2 토큰 지원을 통해 자동화 컨트롤러에서 타사 툴 및 서비스를 인증할 수 있습니다.

클러스터 그룹의 런타임 관리를 통해 스케일링을 구성할 수 있습니다.

복잡한 프로비저닝, 배포 및 오케스트레이션 워크플로우를 모델링하기 위해 자동화 컨트롤러 확장 워크플로를 여러 가지 방법으로 사용할 수 있습니다.

자세한 내용은 자동화 컨트롤러의 워크플로우를 참조하십시오.

수천 대의 시스템에서 실행되는 사실 수집 또는 구성 작업을 사용하여 자동화 컨트롤러 클러스터에 배포할 수 있는 슬라이스로 나눕니다. 이로 인해 안정성이 증가하고 작업 완료 속도가 빨라지고 클러스터 사용을 개선할 수 있습니다.

예를 들어 대규모 15,000개의 스위치에서 매개변수를 변경하거나 다중 노드 RHEL 자산에서 정보를 수집할 수 있습니다.

자세한 내용은 작업 분할을 참조하십시오.

자동화 컨트롤러는 FIPS와 같은 제한된 모드에서 배포 및 실행

많은 대규모 조직에는 여러 조직에서 공유되는 인스턴스가 있습니다. 한 조직이 라이센스가 부여된 모든 호스트를 사용할 수 없도록 하기 위해 이 기능을 사용하면 슈퍼유저가 각 조직에 할당할 수 있는 라이센스가 부여된 호스트 수에 대해 지정된 상한을 설정할 수 있습니다. 자동화 컨트롤러 알고리즘 요소는 조직의 제한과 모든 조직의 총 호스트 수를 변경합니다. 인벤토리 동기화로 인해 조직이 정책을 준수하지 않는 경우 인벤토리 업데이트가 실패합니다. 또한 슈퍼유저는 경고와 함께 라이센스를 과도하게 할당할 수 있습니다.

다음 인벤토리 플러그인은 업스트림 컬렉션에서 사용됩니다.

시크릿 관리 시스템을 사용하면 외부 인증 정보가 저장되고 자동화 컨트롤러에서 사용할 수 있도록 제공되므로 직접 제공할 필요가 없습니다.

Ansible Automation Platform에 처음 로그인하면 서브스크립션 정보를 추가해야 합니다.

서브스크립션을 이미 추가한 경우 서브스크립션 설정+편집 → 서브스크립션 세부 정보를 업데이트할 수 있습니다.

인프라 메뉴에서는 다음과 같은 자동화 컨트롤러 리소스에 빠르게 액세스할 수 있습니다.

관리 메뉴에서는 자동화 컨트롤러의 관리 옵션에 액세스할 수 있습니다. 여기에서 다음을 생성, 보기 및 편집할 수 있습니다.

사용자 인터페이스의 설정 메뉴를 사용하여 일부 자동화 컨트롤러 옵션을 구성할 수 있습니다.

설정 페이지를 사용하면 관리자가 다음을 구성할 수 있습니다.

이러한 검색 팁에서는 호스트를 검색하지 않는 것으로 가정합니다.

다음은 검색에 사용되는 구문의 예입니다.

"related_search_fields": [
       "modified_by__search",
       "project__search",
       "project_update__search",
       "credentials__search",
       "unified_job_template__search",
       "created_by__search",
       "inventory__search",
       "labels__search",
       "schedule__search",
       "webhook_credential__search",
       "job_template__search",
       "job_events__search",
       "dependent_jobs__search",
       "launch_config__search",
       "unifiedjob_ptr__search",
       "notifications__search",
       "unified_job_node__search",
       "instance_group__search",
       "hosts__search",
       "job_host_summaries__search"

"related_search_fields": [
       "modified_by__search",
       "project__search",
       "project_update__search",
       "credentials__search",
       "unified_job_template__search",
       "created_by__search",
       "inventory__search",
       "labels__search",
       "schedule__search",
       "webhook_credential__search",
       "job_template__search",
       "job_events__search",
       "dependent_jobs__search",
       "launch_config__search",
       "unifiedjob_ptr__search",
       "notifications__search",
       "unified_job_node__search",
       "instance_group__search",
       "hosts__search",
       "job_host_summaries__search"

해당하는 경우 각 열의 화살표를 사용하여 오름차순으로 정렬합니다. 다음은 스케줄 목록의 예입니다.

화살표 방향은 열의 정렬 순서를 나타냅니다.

인벤토리 동기화가 실행되면 결과가 출력 탭에 표시됩니다.

인벤토리 동기화에 대한 자세한 내용은 구성된 인벤토리를 참조하십시오.

사용하는 경우 Ansible CLI에 동일한 정보가 표시됩니다. 이는 디버깅에 유용할 수 있습니다. 모든 플레이북 실행에 대해 ANSIBLE_DISPLAY_ARGS_TO_STDOUT 매개변수가 False 로 설정됩니다. 이 매개변수는 Ansible의 기본 동작과 일치하며, 특정 민감한 모듈 매개변수를 stdout 에 유출하지 않도록 작업 세부 정보 인터페이스의 작업 헤더에 작업 인수를 표시하지 않습니다. 이전 동작을 복원하려면 AWX_TASK_ENV 구성 설정을 통해 ANSIBLE_DISPLAY_ARGS_TO_STDOUT 을 True 로 설정합니다.

자세한 내용은 Ansible 구성 설정의 ANSIBLE_DISPLAY_ARGS_TO_STDOUT 을 참조하십시오.

작업을 다시 시작하거나, 작업을 취소하거나, 작업 출력을 하거나, 작업을 삭제할 수 있습니다.

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

링크 복사

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

실행된 작업에 대한 다음 세부 정보를 볼 수 있습니다.

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

  • 보류 중: 인벤토리 동기화가 생성되었지만 아직 대기열에 추가되거나 시작되지 않았습니다. 인벤토리 소스 동기화뿐만 아니라 모든 작업은 시스템에서 실행할 준비가 될 때까지 보류 중 상태로 유지됩니다. 인벤토리 소스 동기화가 준비되지 않은 이유는 다음과 같습니다.

    • 현재 실행 중인 종속 항목(다음 단계를 실행하려면 모든 종속 항목을 완료해야 함)
    • 구성된 위치에서 실행할 용량이 충분하지 않습니다.
  • waiting: 인벤토리 동기화가 대기열에 있으며 실행 대기 중입니다.
  • running: 인벤토리 동기화가 현재 진행 중입니다.
  • successful: 인벤토리 동기화 작업이 성공했습니다.
  • failed: 인벤토리 동기화 작업이 실패했습니다.
• inventory: 연결된 인벤토리 그룹의 이름입니다.
• Source: 클라우드 인벤토리의 유형입니다.
• 인벤토리 소스 프로젝트: 이 인벤토리 동기화 작업의 소스로 사용되는 프로젝트입니다.
• 실행 환경: 사용된 실행 환경입니다.
• execution node: 작업을 실행하는 데 사용되는 노드입니다.
• 인스턴스 그룹: 이 작업에 사용되는 인스턴스 그룹의 이름입니다(자동화 컨트롤러는 기본 인스턴스 그룹임).

이러한 항목을 선택하면 해당 작업 템플릿, 프로젝트 및 기타 오브젝트를 볼 수 있습니다.

SCM에서 소싱된 인벤토리(예: git)가 실행되면 결과가 출력 탭에 표시됩니다. 사용하는 경우 Ansible CLI에 동일한 정보가 표시됩니다. 이는 디버깅에 유용할 수 있습니다.

탐색 메뉴를 사용하여 작업 다시 시작,작업 취소, 작업 출력 을 다운로드하거나 작업을 삭제합니다.

플레이북이 실행되면 결과가 출력 탭에 표시됩니다. 사용하는 경우 Ansible CLI에 동일한 정보가 표시됩니다. 이는 디버깅에 유용할 수 있습니다.

이벤트 요약에는 이 플레이북의 일부로 실행되는 다음 이벤트가 표시됩니다.

작업을 다시 시작하거나, 작업을 취소하거나, 작업 출력을 하거나, 작업을 삭제할 수 있습니다.

출력 보기에서 호스트 상태 표시줄 섹션 위로 마우스를 가져가면 해당 상태와 연결된 호스트 수가 표시됩니다.

플레이북 작업의 출력은 작업 템플릿 페이지의 작업 탭에서 작업을 시작한 후에도 사용할 수 있습니다. 출력에서 행 항목 작업을 클릭하여 호스트 세부 정보를 확인합니다.

5.3.1. 검색

링크 복사

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

OK

작업이 성공적으로 완료되었지만 호스트에서 변경 사항이 실행되지 않았음을 나타냅니다.

changed

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

failed

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

연결할 수 없음

호스트는 네트워크에서 연결할 수 없거나 복구할 수 없는 다른 오류가 연결되어 있습니다.

건너뛴

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

rescued

여기에는 실패한 작업이 표시된 다음 rescue 섹션을 실행합니다.

무시됨

여기에는 실패한 작업이 표시되고 ignore_errors: yes가 구성된 작업이 표시됩니다.

다음 예제에서는 연결할 수 없는 호스트만 있는 검색을 보여줍니다.

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

표준 출력 뷰에는 특정 작업에서 발생하는 이벤트가 표시됩니다.

Stdout 창에서 이벤트 행을 클릭하면 Host Events 창이 별도의 창에 표시됩니다. 이 창에는 특정 이벤트의 영향을 받는 호스트가 표시됩니다.

참고

Ansible Automation Platform의 최신 버전으로 업그레이드하려면 모든 기록 플레이북 출력 및 이벤트를 점진적으로 마이그레이션해야 합니다. 이 마이그레이션 프로세스는 점진적이며 설치가 완료된 후 백그라운드에서 자동으로 수행됩니다. 매우 많은 양의 기록 작업 출력(일반적으로 또는 수백GB의 출력)이 있는 설치는 마이그레이션이 완료될 때까지 작업 출력이 누락될 수 있습니다. 가장 최근 데이터가 출력 맨 위에 표시되고 이전 이벤트가 표시됩니다.

5.3.2. 플레이북 실행 세부 정보

링크 복사

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

실행된 작업에 대한 다음 세부 정보를 볼 수 있습니다.

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

  • 보류 중: 플레이북 실행이 생성되었지만 아직 대기열에 추가되거나 시작되지 않았습니다. 플레이북 실행뿐만 아니라 모든 작업은 시스템에서 실행할 준비가 될 때까지 보류 중 상태로 유지됩니다. 플레이북 실행이 준비되지 않은 이유는 현재 실행 중인 종속 항목이 있거나(다음 단계를 실행하려면 모든 종속 항목을 완료해야 함) 구성된 위치에서 실행하는 데 필요한 용량이 충분하지 않기 때문입니다.
  • waiting: 플레이북 실행이 대기열에 있으며 실행 대기 중입니다.
  • running: 플레이북 실행이 현재 진행 중입니다.
  • 성공: 마지막 플레이북 실행에 성공했습니다.
  • failed: 마지막 플레이북 실행에 실패했습니다.
• 작업 템플릿: 이 작업이 시작된 작업 템플릿의 이름입니다.
• inventory: 이 작업을 실행하도록 선택한 인벤토리입니다.
• project: 시작된 작업과 연결된 프로젝트의 이름입니다.
• Project Status: 시작된 작업과 관련된 프로젝트의 상태입니다.
• playbook: 이 작업을 시작하는 데 사용되는 플레이북입니다.
• execution environment: 이 작업에 사용된 실행 환경의 이름입니다.
• credentials: 이 작업에 사용되는 인증 정보입니다.
• 추가 변수: 작업 템플릿을 생성할 때 전달된 모든 추가 변수가 여기에 표시됩니다.

이러한 항목 중 하나를 선택하여 해당 작업 템플릿, 프로젝트 및 기타 오브젝트를 확인합니다.

5.3.4. 격리 기능 및 변수

링크 복사

자동화 컨트롤러는 컨테이너 기술을 사용하여 작업을 서로 분리합니다. 기본적으로 현재 프로젝트만 작업 템플릿을 실행하는 컨테이너에 노출됩니다.

추가 디렉터리를 노출해야 하는 경우 플레이북 실행을 사용자 지정해야 합니다. 작업 격리를 구성하려면 변수를 설정할 수 있습니다.

기본적으로 자동화 컨트롤러는 시스템의 tmp 디렉토리(기본적으로/tmp )를 스테이징 영역으로 사용합니다. 작업 설정 페이지의 작업 실행 경로 필드 또는 /api/v2/settings /jobs 의 REST API에서 이 값을 변경할 수 있습니다.

AWX_ISOLATION_BASE_PATH = "/opt/tmp"

Copy to Clipboard Toggle word wrap

구체적으로 호스트에서 플레이북이 실행되는 컨테이너로 노출되어야 하는 추가 디렉터리가 있는 경우 작업 설정 페이지의 분리된 작업 필드에 노출할 경로 또는 /api/v2/settings/jobs 의 REST API에서 지정할 수 있습니다.

AWX_ISOLATION_SHOW_PATHS = ['/list/of/', '/paths']

Copy to Clipboard Toggle word wrap

참고

• 특정 파일의 경로가 입력되면 해당 파일이 포함된 전체 디렉터리가 실행 환경 내에 마운트됩니다.
• 플레이북에서 AWX_ISOLATION_SHOW_PATHS 에 정의된 키 또는 설정을 사용해야 하는 경우 이 파일을 /var/lib/awx/.ssh 에 추가합니다.

여기에서 설명하는 필드는 작업 설정 페이지에서 확인할 수 있습니다.

자동화 컨트롤러 용량 시스템은 인스턴스에 사용할 수 있는 리소스 양과 실행 중인 작업의 크기( impact라고 함)를 기준으로 인스턴스에서 실행할 수 있는 작업 수를 결정합니다. 이를 결정하는 데 사용되는 알고리즘은 다음 두 가지를 기반으로 합니다.

용량은 인스턴스 그룹에도 영향을 미칩니다. 그룹은 인스턴스로 구성되므로 인스턴스를 여러 그룹에 할당할 수도 있습니다. 즉, 한 인스턴스에 미치는 영향은 다른 그룹의 전체 용량에 영향을 미칠 수 있습니다.

인스턴스 자체가 아닌 인스턴스 그룹을 다양한 수준의 작업에서 사용하도록 할당할 수 있습니다. 자세한 내용은 자동화 실행 구성 의 구성을 참조하십시오.

작업 관리자가 그래프를 준비하여 작업이 실행되는 그룹을 결정할 때 인스턴스 그룹의 용량을 아직 시작할 준비가 되지 않은 작업으로 커밋합니다.

소규모 구성에서 작업에 하나의 인스턴스만 사용할 수 있는 경우, 작업 관리자를 사용하면 인스턴스를 용량 이상으로 푸시하더라도 해당 작업을 인스턴스에서 실행할 수 있습니다. 이렇게 하면 under-provisioned 시스템의 결과로 작업이 중단되지 않습니다.

(mem - 2048) / mem_per_fork

(mem - 2048) / mem_per_fork

(4096 - 2048) / 100 == ~20

(4096 - 2048) / 100 == ~20

cpus * fork_per_cpu

cpus * fork_per_cpu

4 * 4 == 16

4 * 4 == 16

16 + (20 - 16) * 0.5 = 18

16 + (20 - 16) * 0.5 = 18

프로젝트는 scm_branch 필드의 소스 제어에서 사용할 분기, 태그 또는 참조를 지정합니다. 이러한 값은 유형 세부 정보 필드에 지정된 값으로 표시됩니다.

작업을 생성하거나 편집할 때 분기 덮어쓰기를 허용하는 옵션이 있습니다. 이 옵션을 선택하면 프로젝트 관리자가 분기 선택을 해당 프로젝트를 사용하는 작업 템플릿에 위임할 수 있으며 프로젝트 use_role 만 있으면 됩니다.

자동화 템플릿 페이지에는 현재 사용 가능한 작업 템플릿 과 워크플로우 작업 템플릿이 모두 표시됩니다.

자동화 템플릿은 복잡한 IT 작업을 자동화하고 오케스트레이션하기 위한 강력한 블루프린트 역할을 합니다.

작업 템플릿 또는 워크플로우 템플릿으로 정의하든, 일상적인 작업을 표준화하고 간소화하여 다양한 환경에서 일관되게 실행할 수 있습니다.

플레이북, 인벤토리, 인증 정보 및 기타 구성 세부 정보를 지정하면 자동화 템플릿에서 수동 개입을 제거하고 오류를 줄이며 작업 완료를 가속화합니다.

또한 워크플로우 템플릿에서 여러 작업을 연결할 수 있도록 하여 여러 시스템 및 프로세스에 걸쳐 있을 수 있는 정교한 자동화 사용 사례를 지원하여 유연성을 제공합니다.

이를 통해 IT 팀은 높은 효율성과 제어를 유지하면서 자동화를 안정적으로 확장할 수 있습니다.

기본 뷰는 접혀 있으며(콤팩트) 템플릿 이름, 템플릿 유형 및 해당 템플릿을 사용하여 실행된 마지막 작업의 타임스탬프를 표시합니다. 각 항목 옆에 있는 아이콘을 클릭하여 자세한 정보를 확장하고 볼 수 있습니다. 이 목록은 이름에 따라 알파벳순으로 정렬되지만 다른 기준에 따라 정렬하거나 템플릿의 다양한 필드 및 속성으로 검색할 수 있습니다.

이 화면에서 를 시작하고 를 편집하고 을/를 복제할 수 있습니다.

템플릿 이름을 선택하여 마지막으로 실행된 시기를 포함하여 템플릿에 대한 자세한 정보를 표시합니다.

이 목록은 이름에 따라 알파벳순으로 정렬되지만 다른 기준에 따라 정렬하거나 템플릿의 다양한 필드 및 속성으로 검색할 수 있습니다.

워크플로우 템플릿에는 워크플로우 편집기에 액세스하기 위한 바로 가기로 워크플로우 시각화 프로그램 아이콘이 있습니다.

도메인 필터링을 사용하면 자동화 실행의 작업 및 템플릿 하위 섹션에 표시된 콘텐츠를 사용자 지정할 수 있습니다. 작업 및 템플릿은 설명 레이블에 연결됩니다. 레이블을 선택하면 덜 관련 리소스를 필터링하여 관심 영역과 관련된 리소스에 쉽게 액세스할 수 있습니다.

템플릿을 생성하면 작업 템플릿 페이지가 종료되지 않고 작업 템플릿 세부 정보 탭으로 이동합니다. 템플릿을 저장한 후 템플릿 시작을 클릭하여 작업을 시작할 수 있습니다. 편집 을 클릭하여 권한, 알림, 완료된 작업 보기, 설문 조사(작업 유형이 검사가 아닌 경우)와 같은 템플릿 속성을 추가하거나 변경할 수도 있습니다. 시작하기 전에 템플릿을 먼저 저장해야 합니다. 그러지 않으면 시작 템플릿 은 비활성화된 상태로 유지됩니다.

확인

다음 단계를 사용하여 팀에 대한 권한을 추가합니다.

사용자와 팀을 추가하는 창은 각 사용자 및 팀에 할당된 업데이트된 역할을 표시합니다.

특정 사용자의 역할을 제거하려면 리소스 옆에 있는 아이콘을 클릭합니다.

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

작업 템플릿을 삭제하기 전에 워크플로우 작업 템플릿에 사용되지 않는지 확인합니다.

탐색 패널에서 자동화 실행 → 관리 → 알림 을 선택합니다. 설정한 알림 통합과 해당 상태가 실행된 경우 검토할 수 있습니다.

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

알림이 설정되지 않은 경우 알림 추가 를 클릭하여 새 알림을 만듭니다. 다양한 알림 유형 및 확장 메시징을 구성하는 방법에 대한 자세한 내용은 알림 유형을 참조하십시오.

Jobs (작업) 탭에는 실행된 작업 템플릿 목록이 있습니다. 각 작업 옆에 있는 확장 아이콘을 클릭하여 다음 세부 정보를 확인합니다.

이러한 기준 중 하나를 사용하여 완료된 작업 목록을 필터링할 수 있습니다.

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

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

인증 정보 시작 시 프롬프트 를 선택하고 작업 템플릿에 대한 스케줄링 정보를 생성하거나 편집하면 스케줄 양식에 프롬프트 옵션이 표시됩니다.

프롬프트 대화 상자에서 기본 머신 인증 정보를 저장하기 전에 다른 머신 인증 정보로 교체하지 않고 제거할 수 없습니다.

실행 또는 확인 작업 유형은 작업 템플릿 생성 또는 편집 화면에서 설문 조사를 설정하는 방법을 제공합니다. 설문 조사에서는 추가 변수에 대한 프롬프트와 유사하지만 사용자에게 친숙한 질문 및 답변 방식으로 플레이북에 대한 추가 변수 를 설정합니다. 또한 설문 조사에서는 사용자 입력을 검증할 수 있습니다. 설문조사 탭을 선택하여 설문 조사를 생성합니다.

예

여러 상황에서 설문 조사를 사용할 수 있습니다. 예를 들어, 작업은 개발자에게 Ansible에 대한 사전 지식 없이 실행할 수 있는 "단계로 푸시" 버튼을 제공하려고 합니다. 이 작업이 시작되면 "릴리스할 태그"와 같은 질문에 대한 답변을 요청할 수 있습니다.

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

자동화 컨트롤러의 이점은 푸시 버튼을 통한 Ansible 플레이북 배포입니다. 일반적으로 명령줄에서 Ansible 플레이북에 전달하는 모든 매개 변수를 저장하도록 템플릿을 구성할 수 있습니다. 플레이북 외에도 템플릿은 인벤토리, 인증 정보, 추가 변수, 명령줄에서 지정할 수 있는 모든 옵션 및 설정을 전달합니다.

더 쉬운 배포는 플레이북을 매번 동일한 방식으로 실행하여 일관성을 높이며 책임을 위임할 수 있도록 합니다.

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

한 탭에 값을 지정하면 이전 탭으로 돌아가 다음 탭을 진행하면 나머지 탭에서 값을 다시 제공해야 합니다. 프롬프트가 표시되는 순서대로 탭을 완료했는지 확인합니다.

자동화 컨트롤러가 시작될 때 작업 탭에서 이 작업의 작업 상태 페이지로 웹 브라우저를 자동으로 리디렉션합니다.

목록 뷰에서 최근 작업을 다시 시작하여 모든 호스트에서 다시 실행하거나 지정된 인벤토리의 실패한 호스트에서만 다시 실행할 수 있습니다. 자세한 내용은 자동화 컨트롤러의 작업 섹션을 참조하십시오.

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

작업 템플릿을 복제하면 연결된 일정, 알림 또는 권한이 중복되지 않습니다. 스케줄 및 알림은 작업 템플릿의 중복을 생성하는 사용자 또는 관리자가 다시 생성해야 합니다. 작업 템플릿을 분할하는 사용자에게는 관리자 권한이 부여되지만 작업 템플릿에는 권한이 할당(중복됨)되지 않습니다.

자동화 컨트롤러는 Ansible 팩트 캐시 플러그인을 통해 호스트별로 사실을 저장하고 검색할 수 있습니다. 이 동작은 작업별 템플릿을 기반으로 구성할 수 있습니다. 팩트 캐싱은 기본적으로 꺼져 있지만 실행 중인 작업과 관련된 인벤토리의 모든 호스트에 대한 사실 요청을 처리하기 위해 활성화할 수 있습니다. 이를 통해 호스트 팩트의 전체 인벤토리에 계속 액세스하는 동안 --limit 와 함께 작업 템플릿을 사용할 수 있습니다. 플러그인이 탐색 패널에서 호스트별로 강제 적용하는 글로벌 시간 초과 설정을 지정하고(초) 탐색 패널에서 Settings → Automation Execution → Job 을 선택하고 Per-Host Ansible Fact Cache Timeout 필드를 편집할 수 있습니다.

팩트 캐시를 사용하는 작업(use_fact_cache=True)을 시작한 후 각 호스트의 ansible_facts 는 모두 컨트롤러의 작업 인벤토리에 저장됩니다.

자동화 컨트롤러가 포함된 Ansible 사실 캐시 플러그인은 팩트 캐시가 활성화된 작업에서 활성화됩니다(use_fact_cache=True).

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

신규 및 변경된 사실은 자동화 컨트롤러의 로깅 기능을 통해 기록됩니다. 특히 system_tracking 네임스페이스 또는 로거에 대해 다음을 수행합니다. 로깅 페이로드에는 다음 필드가 포함됩니다.

Ansible 사실은 자동화 컨트롤러 인벤토리 inventory, inventory_id 의 host_name 에 대한 모든 Ansible 사실로 이루어진 사전입니다.

사실 캐싱은 팩트 수집을 실행하는 데 걸리는 시간을 절약할 수 있습니다. 작업에 1,000개의 호스트 및 포크에 대해 실행되는 플레이북이 있는 경우 해당 호스트 전체에서 팩트를 수집하는 데 10분을 할애할 수 있습니다. 그러나 작업을 정기적으로 실행하는 경우 첫 번째 실행에서는 이러한 팩트를 캐시하고 다음 실행에서는 데이터베이스에서 해당 작업을 가져옵니다. 이렇게 하면 대규모 인벤토리에 대한 작업 런타임이 줄어듭니다.

작업 템플릿을 생성하거나 편집할 때 사실 스토리지 활성화 옵션을 선택하여 작업에 캐시된 팩트를 사용하도록 선택할 수 있습니다.

팩트를 지우려면 Ansible clear_facts 메타 작업을 실행합니다. 다음은 Ansible clear_facts 메타 작업을 사용하는 플레이북의 예입니다.

- hosts: all
  gather_facts: false
  tasks:
    - name: Clear gathered facts from all currently targeted hosts
      meta: 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 클라우드 모듈을 호출하고 인증 정보가 필요합니다.

이러한 필드는 환경 변수 OS_CLIENT_CONFIG_FILE 을 통해 플레이북에 사용할 수 있습니다. 이 변수는 클라우드 인증 정보의 콘텐츠를 기반으로 컨트롤러에서 작성한 YAML 파일을 가리킵니다. 다음 샘플 플레이북은 YAML 파일을 Ansible 변수 공간에 로드합니다.

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

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 }}"

- 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

- 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

프로비저닝 콜백은 사용자가 자동화 컨트롤러 콘솔에서 호스트를 관리하는 작업을 시작할 때까지 기다리는 대신 호스트에서 자체적으로 플레이북 실행을 시작할 수 있는 자동화 컨트롤러의 기능입니다.

프로비저닝 콜백은 호출 호스트에서 플레이북을 실행하는 데만 사용되며 클라우드 버스팅을 위한 것입니다. 클라우드 버스팅은 컴퓨팅에 수요가 급증할 때 프라이빗 클라우드가 퍼블릭 클라우드에 "버그"를 통해 퍼블릭 클라우드 리소스에 액세스할 수 있는 클라우드 컴퓨팅 구성입니다.

시작된 작업 템플릿은 프로비저닝을 요청하는 호스트에 대해서만 실행됩니다.

이는 종종 firstboot 유형 스크립트 또는 cron 을 사용하여 액세스할 수 있습니다.

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

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

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

기본적으로 extra_vars 는 작업 템플릿의 추가 변수 섹션에 지정하지 않는 한 !safe 로 표시됩니다. 이는 작업 템플릿을 추가하거나 편집할 수 있는 충분한 권한이 있는 사용자만 추가할 수 있기 때문에 신뢰할 수 있습니다. 예를 들어 Jinja 대괄호는 문자열로 처리되므로 중첩된 변수가 프롬프트로 입력되면 확장되지 않습니다. 안전하지 않은 변수에 대한 자세한 내용은 안전하지 않은 변수 또는 원시 문자열을 참조하십시오.

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

ALLOW_JINJA_IN_EXTRA_VARS 매개변수를 지정하는 경우 자동화 실행 구성 의 ALLOW_JINJA_IN_EXTRA_VARS 변수 섹션을 참조하십시오.

작업 템플릿 추가 변수 사전은 설문 조사 변수와 병합됩니다.

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

launch_to_orbit: true
satellites:
  - sputnik
  - explorer
  - satcom

launch_to_orbit: true
satellites:
  - sputnik
  - explorer
  - satcom

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

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

다음 표에서는 Ansible의 변수 우선순위와 비교하여 자동화 컨트롤러에서 변수 우선순위의 동작(계층 구조)을 설명합니다.

작업 슬라이스를 설정할 때 다음을 고려하십시오.

분할된 작업은 모든 노드에서 실행할 수 있습니다. 시스템에서 용량이 충분하지 않으면 다른 시간에 일부 실행이 발생할 수 있습니다. 슬라이스 작업이 실행 중인 경우 작업 세부 정보에 현재 실행 중인 워크플로우 및 작업 슬라이스와 세부 정보를 개별적으로 볼 수 있는 링크가 표시됩니다.

기본적으로 작업 템플릿은 일반적으로 동시에 실행되도록 구성되지 않습니다(API 또는 UI에서 allow_simultaneous 를 확인해야 함). 분할은 이 동작을 재정의하고 해당 설정이 명확한 경우에도 allow_simultaneous 를 의미합니다. 이 작업을 지정하는 방법과 작업 템플릿 구성의 작업 슬라이스 수에 대한 자세한 내용은 작업 템플릿을 참조하십시오.

작업 템플릿 섹션에서는 UI에서 다음 작업을 수행하는 방법에 대한 추가 세부 정보를 제공합니다.

슬라이스 작업을 더 쉽게 찾으려면 검색 기능을 사용하여 다음에 검색 필터를 적용합니다.

새 워크플로우 작업 템플릿을 생성하려면 다음 단계를 완료합니다.

템플릿을 저장하면 워크플로우 템플릿 페이지가 종료되고 워크플로우 시각화 프로그램이 열립니다. 워크플로우를 빌드할 수 있습니다. 자세한 내용은 워크플로우 시각화 프로그램 섹션을 참조하십시오. 그렇지 않으면 다음 방법 중 하나를 선택합니다.

팀 액세스 또는 사용자 액세스 탭을 클릭하여 팀 멤버와 함께 사용자의 관련 권한을 검토, 대규모, 편집 및 제거합니다.

역할 추가 를 클릭하여 프롬프트에 따라 이 워크플로우 템플릿에 대한 새 권한을 생성합니다.

워크플로우 작업 템플릿에서 알림 작업 작업에 대한 자세한 내용은 알림 작업을 참조하십시오.

Jobs (작업) 탭에는 실행된 작업 템플릿 목록이 있습니다. 각 작업 옆에 있는 아이콘을 클릭하여 각 작업의 세부 정보를 확인합니다.

이 보기에서 작업 ID, 워크플로우 작업의 이름을 클릭하고 해당 그래프를 볼 수 있습니다. 다음 예제에서는 워크플로우 작업의 세부 정보를 보여줍니다.

노드를 식별하는 데 도움이 되도록 라벨이 표시됩니다. 자세한 내용은 워크플로우 시각화 프로그램 섹션의 범례를 참조하십시오.

일정 탭을 선택하여 특정 워크플로우 작업 템플릿의 스케줄에 액세스합니다.

워크플로우 작업 템플릿 실행 예약에 대한 자세한 내용은 작업 템플릿 예약 섹션을 참조하십시오.

중첩된 워크플로우에 사용된 워크플로우 작업 템플릿에 설문 조사가 있거나 인벤토리 옵션에 대한 프롬프트 가 선택되어 있는 경우 일정 양식의 PROMPT 옵션 옆에 PROMPT 옵션이 표시됩니다. PROMPT 를 클릭하여 인벤토리를 제공하거나 제거하거나 변경 사항 없이 단계를 건너뛸 수 있는 선택적 INVENTORY 단계를 표시합니다.

실행 또는 확인 작업 유형이 포함된 워크플로우에서는 워크플로우 작업 템플릿 생성 또는 편집 화면에서 설문 조사를 설정하는 방법을 제공합니다.

워크플로우 작업 템플릿에서 설문 조사 및 선택적 설문 조사를 생성하는 방법을 포함하여 작업 설문 조사에 대한 자세한 내용은 작업 템플릿의 설문 조사 섹션을 참조하십시오.

워크플로우 시각화 도구를 사용하면 그래프를 사용해 작업 템플릿, 워크플로우 템플릿, 프로젝트 동기화, 인벤토리 동기화를 하나로 연결하여 워크플로우 템플릿을 빌드할 수 있습니다. 워크플로우 템플릿을 빌드하기 전에 상위 노드, 자식 노드 및 형제 노드 의 다양한 시나리오와 관련된 고려 사항은 자동화 컨트롤러의 워크플로우 섹션을 참조하십시오.

8.7.2. 승인 노드

링크 복사

승인 노드를 선택하려면 워크플로우를 진행하기 위한 개입이 필요합니다. 이 기능은 플레이북 간 워크플로우를 일시 중지하여 워크플로우의 다음 플레이북으로 계속 진행할 수 있는 승인을 제공할 수 있도록 합니다. 이렇게 하면 사용자가 개입할 수 있는 지정된 시간을 제공하지만 다른 트리거를 기다리지 않고도 최대한 빨리 계속할 수 있습니다.

시간 초과의 기본값은 none이지만 요청이 만료되고 자동으로 거부되기 전의 시간을 지정할 수 있습니다. 승인 노드에 대한 정보를 선택하고 제공하면 그래프 보기에 일시 중지 아이콘이 표시됩니다.

승인자는 다음 기준을 충족하는 모든 사람입니다.

• 승인 노드가 포함된 워크플로우 작업 템플릿을 실행할 수 있는 사용자입니다.
• 조직 관리자 또는 이상의 권한이 있는 사용자(해당 워크플로우 작업 템플릿과 연결된 조직의 경우)
• 해당 특정 워크플로우 작업 템플릿 내에서 승인 권한이 명시적으로 할당된 사용자입니다.

만료가 할당된 경우 지정된 제한 시간 내에 보류 중인 승인 노드가 승인되지 않거나 거부되는 경우 "시간 초과" 또는 "실패"로 표시되고 다음 "실패 시 노드" 또는 "항상 노드"로 이동합니다. 승인되면 "성공 시" 경로가 사용됩니다. API에서 이미 승인, 거부 또는 시간 초과된 노드에 POST 를 시도하면 이 작업이 중복되었음을 알리는 오류 메시지가 표시되고 추가 단계가 수행되지 않습니다.

다음 표에서는 승인 워크플로우에 허용되는 다양한 권한 수준을 보여줍니다.

워크플로우 작업 템플릿에 추가된 변수는 워크플로우 작업 템플릿 및 설문 조사에 설정된 추가 변수와 함께 시작 시 자동화 컨트롤러에 자동으로 추가됩니다.

워크플로우 승인과 관련된 이벤트는 승인 요청에 대한 자세한 정보와 함께 활동 스트림( )에 표시됩니다.

자동화 컨트롤러를 사용하면 워크플로우 작업 템플릿을 복제할 수 있습니다. 워크플로우 작업 템플릿을 복제하면 연결된 일정, 알림 또는 권한이 중복되지 않습니다. 스케줄 및 알림은 워크플로우 템플릿의 중복을 생성하는 사용자 또는 시스템 관리자가 다시 생성해야 합니다. 워크플로우 템플릿을 분할하는 사용자에게는 관리자 권한이 부여되지만 워크플로우 템플릿에는 권한이 할당(복사됨)되지 않습니다.

자세한 내용은 Extra variables 섹션을 참조하십시오.

워크플로우를 빌드할 때 다음을 고려하십시오.

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

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

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

워크플로우 extra_vars 외에도 워크플로우의 일부로 실행되는 작업과 워크플로우는 워크플로우에서 상위 작업의 아티팩트 사전의 변수를 상속할 수 있습니다(해당 분기의 상위 항목과도 결합). set_stats Ansible 모듈에서 정의할 수 있습니다.

플레이북에서 set_stats 모듈을 사용하는 경우 다른 작업에서 다운스트림을 사용할 수 있는 결과를 생성할 수 있습니다.

---
- 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 }}"

---
- 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 }}"

---
- 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 }}"

---
- 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 모듈은 이 워크플로우를 다음과 같이 처리합니다.

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

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

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

사용자에게 부여된 권한에 따라 중복 복사 또는 워크플로우 다시 시작과 같은 기타 작업을 수행할 수도 있습니다. 작업 템플릿을 다시 시작하거나 복사하기 전에 워크플로우에 사용된 모든 리소스에 대한 권한이 있어야 합니다.

자세한 내용은 역할 기반 액세스 제어를 사용하여 액세스 관리를 참조하십시오.

설명된 작업을 수행하는 방법에 대한 자세한 내용은 워크플로우 작업 템플릿을 참조하십시오.

템플릿, 프로젝트 또는 인벤토리 소스에서 스케줄을 생성하고 기본 일정 페이지에서 직접 생성할 수 있습니다.

일정 페이지에서 새 일정을 생성하려면 다음을 수행합니다.

리소스 페이지에서 새 일정을 생성하려면 다음을 수행합니다.

자동화 컨트롤러에서 projects라고 하는 플레이북의 논리 컬렉션을 생성할 수 있습니다.

프로젝트를 정기적으로 업데이트하면 Git, Subversion 또는 기타 통합 SCM 리포지토리에서 변경한 내용을 반영하여 환경에서 플레이북, 역할 및 컬렉션의 최신 버전에 액세스할 수 있습니다. 이 프로세스는 SCM과 Ansible Automation Platform 간의 동기화를 유지 관리하는 데 중요합니다.

프로젝트(역할 기반 액세스 제어)에 할당되어 프로젝트, 인벤토리, 작업 템플릿 및 기타 요소를 읽고, 변경하고, 관리하는 기능을 제공하는 권한 세트는 권한입니다.

프로젝트 권한에 액세스하려면 프로젝트 페이지의 사용자 액세스 또는 팀 액세스 탭을 선택합니다. 이 화면에는 현재 이 프로젝트에 대한 권한이 있는 사용자 목록이 표시됩니다.

사용자 이름, 이름 또는 성으로 이 목록을 정렬하고 검색할 수 있습니다.

프로젝트 업데이트가 끝나면 자동화 컨트롤러는 < project-top-level-directory>/ roles /requirements.yml 에 있는 roles 디렉터리에서 requirements.yml 파일을 검색합니다.

이 파일이 있으면 다음 명령이 자동으로 실행됩니다.

ansible-galaxy role install -r roles/requirements.yml -p <project-specific cache location>/requirements_roles -vvv

ansible-galaxy role install -r roles/requirements.yml -p <project-specific cache location>/requirements_roles -vvv

이 파일을 사용하면 자체 프로젝트와 함께 확인할 수 있는 다른 리포지토리 내의 Ansible Galaxy 역할 또는 역할을 참조할 수 있습니다. Ansible Galaxy 액세스를 추가하면 이 결과를 얻기 위해 git 하위 모듈을 생성할 필요가 없습니다. 역할 또는 컬렉션과 함께 SCM 프로젝트를 개인 작업 환경으로 가져와 실행하는 경우 /tmp 내의 프로젝트와 관련된 < private 작업 디렉터리 >가 기본적으로 생성됩니다.

캐시 디렉터리는 글로벌 프로젝트 폴더 내부의 하위 디렉터리입니다. 캐시 위치의 콘텐츠를 < job 개인 디렉터리>/requirements_roles 에 복사할 수 있습니다.

기본적으로 자동화 컨트롤러에는 SCM 프로젝트의 roles/requirements.yml 파일에서 역할을 동적으로 다운로드할 수 있는 시스템 전체 설정이 있습니다. 역할 다운로드 사용 확인란을 선택 해제하여 탐색 패널에서 작업 설정 화면에서 이 설정을 끌 수 있습니다.

프로젝트 동기화가 실행될 때마다 자동화 컨트롤러에서 프로젝트 소스 및 Galaxy 또는 Collections의 역할이 프로젝트에서 최신 상태가 아닌지를 결정합니다. 프로젝트 업데이트는 업데이트 내의 역할을 다운로드합니다.

작업에서 업스트림 역할에 대한 변경 사항을 선택해야 하는 경우 프로젝트를 업데이트하면 이러한 상황이 발생합니다. 역할에 대한 변경 사항은 새 커밋이 provision-role 소스 제어로 푸시되었음을 의미합니다.

이 변경 사항을 작업에 적용하기 위해 새 커밋을 playbooks 리포지토리로 푸시할 필요가 없습니다. 역할을 로컬 캐시에 다운로드하는 프로젝트를 업데이트해야 합니다.

예를 들어, 소스 제어에 두 개의 Git 리포지터리가 있다고 가정합니다. 첫 번째는 플레이북 이며 자동화 컨트롤러의 프로젝트는 이 URL을 가리킵니다. 두 번째는 provision-role 이며 Playbook Git 리포지토리 내부의 roles/requirements.yml 파일에서 참조합니다.

작업은 모든 작업을 실행하기 전에 최신 역할을 다운로드합니다. 역할 및 컬렉션은 성능상의 이유로 로컬로 캐시됩니다. 프로젝트 옵션에서 시작 시 버전 업데이트를 선택하여 각 작업을 실행하기 전에 업스트림 역할을 다시 다운로드해야 합니다.

업데이트는 프로세스에서 동기화보다 훨씬 일찍 수행되므로 오류 및 세부 정보가 더 논리적인 위치에서 더 빠르게 식별됩니다.

requirements.yml 파일의 구문에 대한 자세한 내용 및 예제는 Ansible 문서의 역할 요구 사항 섹션을 참조하십시오.

특별히 노출해야 하는 디렉터리가 있는 경우 탐색 패널 설정 자동화 실행 작업의 작업 설정 화면에서 해당 디렉터리를 분리된 작업에 노출하는 경로로 지정할 수 있습니다. 설정 파일에서 다음 항목을 업데이트할 수도 있습니다.

AWX_ISOLATION_SHOW_PATHS = ['/list/of/', '/paths']

AWX_ISOLATION_SHOW_PATHS = ['/list/of/', '/paths']

설정 파일을 변경한 경우 변경 사항을 저장한 후 automation-controller-service restart 명령을 사용하여 서비스를 다시 시작하십시오.

UI의 작업 설정 창에서 이러한 설정을 구성할 수 있습니다.

자동화 컨트롤러는 작업 실행에서 프로젝트별 Ansible 컬렉션을 지원합니다. collections/requirements.yml 에서 SCM에 컬렉션 요구 사항 파일을 지정하는 경우 자동화 컨트롤러는 작업을 실행하기 전에 암시적 프로젝트 동기화에 해당 파일에 컬렉션을 설치합니다.

자동화 컨트롤러에는 SCM 프로젝트의 collections/requirements.yml 파일에서 컬렉션을 동적으로 다운로드할 수 있는 시스템 전체 설정이 있습니다. 탐색 패널에서 작업 설정 화면의 설정 → 자동화 실행 → 작업 에서는 컬렉션 다운로드 사용 확인란을 선택 취소하여 이 설정을 끌 수 있습니다.

역할 및 컬렉션은 성능상의 이유로 로컬로 캐시되고 프로젝트 옵션에서 시작 시 버전 업데이트를 선택하여 다음을 확인합니다.

프로젝트 유지 관리자의 경우 콘텐츠에 서명하는 데 지원되는 방법은 제공된 CLI( 명령줄 인터페이스)를 사용하여 ansible- sign 유틸리티를 사용하는 것입니다.

CLI는 GPG( GNU Privacy Guard )와 같은 암호화 기술을 사용하여 프로젝트 내의 파일이 어떤 방식으로든 변조되지 않았는지 확인하는 것을 목표로 합니다. 현재 GPG는 서명 및 유효성 검사에 지원되는 유일한 수단입니다.

자동화 컨트롤러는 서명된 콘텐츠를 확인하는 데 사용됩니다. 일치하는 공개 키가 서명된 프로젝트와 연결되면 자동화 컨트롤러에서 서명 중에 포함된 파일이 변경되지 않았는지 확인하고 파일이 예기치 않게 추가 또는 제거되었는지 확인합니다. 서명이 유효하지 않거나 파일이 변경된 경우 프로젝트가 업데이트되지 않고 프로젝트를 사용하는 작업이 시작되지 않습니다. 프로젝트의 확인 상태는 수정되지 않은 안전한 콘텐츠만 작업에서 실행할 수 있도록 합니다.

리포지토리가 이미 서명 및 확인을 위해 구성된 경우 프로젝트 변경을 위한 일반적인 워크플로는 다음과 같습니다.

프로젝트를 동기화하고 자동화 컨트롤러에서 새 변경 사항을 가져오고, 자동화 컨트롤러의 프로젝트와 연결된 공개 키가 체크섬 매니페스트가 서명된 개인 키와 일치하는지 확인한 다음(이렇게 하면 체크섬 매니페스트 자체를 변조하지 않음) 매니페스트에서 각 파일의 체크섬을 다시 계산하여 체크섬이 변경되지 않았는지 확인합니다(따라서 파일이 변경되지 않음). 또한 모든 파일이 다음에 대한 책임이 있는지 확인합니다.

파일은 MANIFEST.in 파일에 포함되거나 제외되어야 합니다. 이 파일에 대한 자세한 내용은 프로젝트 서명 을 참조하십시오. 파일이 예기치 않게 추가되거나 제거된 경우 확인에 실패합니다.

자동화 컨트롤러에서 콘텐츠 서명 및 검증에 GPG 키를 사용하려면 CLI에서 다음 명령을 실행하여 추가합니다.

gpg --list-keys
gpg --export --armour <key fingerprint> > my_public_key.asc

$ gpg --list-keys
$ gpg --export --armour <key fingerprint> > my_public_key.asc

ansible-sign 유틸리티를 사용하여 프로젝트에 서명하고 프로젝트의 서명 여부를 확인할 수 있는 옵션을 제공합니다.

프로젝트에 서명하려면 Ansible 프로젝트 디렉터리가 필요합니다. 프로젝트 디렉터리 구조에 대한 자세한 내용은 Ansible 문서의 샘플 Ansible 설정을 참조하십시오.

다음 샘플 프로젝트에는 인벤토리 파일과 플레이북 디렉터리에 있는 두 개의 작은 플레이북이라는 매우 간단한 구조가 있습니다.

cd sample-project/
tree -a .
.
├── inventory
└── playbooks
    └── get_uptime.yml
    └── hello.yml

    1 directory, 3 files

$ cd sample-project/
$ tree -a .
.
├── inventory
└── playbooks
    └── get_uptime.yml
    └── hello.yml

    1 directory, 3 files

Ansible-sign 은 프로젝트의 모든 보안 파일의 체크섬(SHA256)을 사용하고 체크섬 매니페스트 파일로 컴파일한 다음 해당 매니페스트 파일에 서명하여 콘텐츠를 변조하지 않도록 보호합니다.

콘텐츠에 서명하려면 프로젝트 루트 디렉터리에 보호할 파일을 ansible-sign 에 알리는 MANIFEST.in 파일을 생성합니다.

내부적으로 ansible-sign 은 Python의 distlib 라이브러리의 distlib.manifest 모듈을 사용하므로 MANIFEST.in 은 이 라이브러리에서 지정하는 구문을 따라야 합니다. MANIFEST.in 파일 지시문에 대한 설명은 Python 패키징 사용자 가이드를 참조하십시오.

샘플 프로젝트에서 두 개의 지시문이 포함되어 결과적으로 다음 MANIFEST.in 파일이 생성됩니다.

include inventory
recursive-include playbooks *.yml

include inventory
recursive-include playbooks *.yml

이 파일을 사용하여 체크섬 매니페스트 파일을 생성하고 서명하십시오. 다음 두 단계는 모두 단일 ansible-sign 명령으로 수행됩니다.

ansible-sign project gpg-sign .

$ ansible-sign project gpg-sign .

실행에 성공하면 다음과 유사한 출력이 표시됩니다.

[OK   ] GPG signing successful!
[NOTE ] Checksum manifest: ./.ansible-sign/sha256sum.txt
[NOTE ] GPG summary: signature created

[OK   ] GPG signing successful!
[NOTE ] Checksum manifest: ./.ansible-sign/sha256sum.txt
[NOTE ] GPG summary: signature created

이제 프로젝트에 서명되었습니다.

gpg-sign 하위 명령은 project 하위 명령에 있습니다.

프로젝트 콘텐츠에 서명하기 위해 모든 명령은 ansible-sign 프로젝트 로 시작합니다.

모든 ansible-sign 프로젝트 명령은 프로젝트 루트 디렉터리 . 를 최종 인수로 사용합니다.

Ansible-sign 은 기본 인증 키를 사용하고 프로젝트에 서명하기 위해 찾을 수 있는 첫 번째 사용 가능한 시크릿 키를 찾습니다. --fingerprint 옵션과 함께 사용할 특정 시크릿 키를 지정하거나 --gnupg-home 옵션을 사용하여 완전히 독립적인 GPG 홈 디렉터리도 지정할 수 있습니다.

.ansible-sign 디렉터리가 프로젝트 디렉터리에 생성되었습니다. 이 디렉터리에는 체크섬 매니페스트 및 GPG 분리 서명이 포함되어 있습니다.

tree -a .
.
├── .ansible-sign
│   ├── sha256sum.txt
│   └── sha256sum.txt.sig
├── inventory
├── MANIFEST.in
└── playbooks
    ├── get_uptime.yml
    └── hello.yml

$ tree -a .
.
├── .ansible-sign
│   ├── sha256sum.txt
│   └── sha256sum.txt.sig
├── inventory
├── MANIFEST.in
└── playbooks
    ├── get_uptime.yml
    └── hello.yml

서명된 Ansible 프로젝트가 변경되지 않았는지 확인하려면 ansible-sign 을 사용하여 서명이 유효한지 여부와 파일의 체크섬이 해당 체크섬 매니페스트와 일치하는지 확인할 수 있습니다. ansible-sign 프로젝트 gpg-verify 명령을 사용하여 이러한 두 조건을 자동으로 확인할 수 있습니다.

ansible-sign project gpg-verify .
[OK   ] GPG signature verification succeeded.
[OK   ] Checksum validation succeeded.

$ ansible-sign project gpg-verify .
[OK   ] GPG signature verification succeeded.
[OK   ] Checksum validation succeeded.

어떤 이유로든 확인이 실패하면 원인을 디버깅하는 데 도움이 되는 정보가 표시됩니다. 명령에서 ansible-sign 직후 글로벌 --debug 플래그를 전달하여 더 자세한 정보를 활성화할 수 있습니다.

OpenShift 또는 Jenkins와 같은 신뢰할 수 있는 CI( 지속적 통합 ) 환경이 있는 환경에서는 서명 프로세스를 자동화할 수 있습니다.

예를 들어 선택한 CI 플랫폼에 GPG 개인 키를 시크릿으로 저장하고 CI 환경에서 GnuPG로 가져올 수 있습니다. 그런 다음 일반 CI 환경 내에서 서명 워크플로를 통해 실행할 수 있습니다.

GPG를 사용하여 프로젝트에 서명할 때 ANSIBLE_SIGN_GPG_PASSPHRASE 환경 변수를 서명 키의 암호로 설정할 수 있습니다. 이는 CI 파이프라인에서 삽입 및 마스크 또는 보안될 수 있습니다.

시나리오에 따라 ansible-sign 은 서명 및 확인 중에 다른 종료 코드로 돌아갑니다. CI 환경이 실패에 따라 다르게 작동할 수 있으므로 이는 CI 및 자동화의 맥락에서도 유용할 수 있습니다. 예를 들어 일부 오류에 대한 경고를 보낼 수 있지만 다른 오류에는 자동으로 실패합니다.

다음은 ansible-sign 에서 사용되는 현재 종료 코드이며 안정적인 것으로 간주될 수 있습니다.

다음 절차를 사용하여 자동화 컨트롤러 UI에서 토폴로지 뷰어에 액세스합니다.

스마트 인벤토리는 저장된 검색으로 정의된 호스트 컬렉션으로, 표준 인벤토리처럼 볼 수 있으며 작업 실행과 함께 쉽게 사용할 수 있습니다. 조직 관리자에게는 조직의 인벤토리에 대한 관리자 권한이 있으며 스마트 인벤토리를 생성할 수 있습니다.

스마트 인벤토리는 KIND=smart 로 식별됩니다.

검색에 사용되는 것과 동일한 방법을 사용하여 스마트 인벤토리를 정의할 수 있습니다. 인벤토리 소스 는 인벤토리와 직접 연결됩니다.

인벤토리 모델에는 기본적으로 비어 있지만 스마트 인벤토리에 대해 적절하게 설정된 다음과 같은 새 필드가 있습니다.

호스트 모델에는 호스트가 연결된 모든 스마트 인벤토리 세트를 식별하는 관련 끝점인 smart_inventories 가 있습니다. 멤버십 테이블은 작업이 스마트 인벤토리에 대해 실행될 때마다 업데이트됩니다.

편집할 수 없는 인벤토리를 볼 수 있습니다.

일반 인벤토리와 마찬가지로 스마트 인벤토리 호스트 끝점(/inventories/N/hosts/)에서 호스트를 생성할 수 없습니다. 스마트 인벤토리 관리자는 이름, 설명, 변수, 삭제 기능과 같은 필드를 편집할 수 있는 권한이 있지만, 이는 스마트 인벤토리에 포함된 호스트(다른 인벤토리에 기본 멤버십이 있는)에 영향을 미치기 때문에 host_filter 를 수정할 수 있는 권한이 없습니다.

host_filter 는 스마트 인벤토리 조직 내부의 인벤토리 내부의 호스트에만 적용됩니다.

host_filter 를 수정하려면 인벤토리 조직의 조직 관리자여야 합니다. 조직 관리자에게는 조직 내부의 모든 인벤토리에 대한 암시적 "관리자" 액세스 권한이 있으므로 아직 소유하지 않은 권한은 전달되지 않습니다.

스마트 인벤토리 관리자는 다른 사용자(조직 관리자가 아닌 사용자)에게 스마트 인벤토리에 대한 "사용" 및 "임시"와 같은 권한을 부여할 수 있습니다. 이러한 작업에서는 다른 표준 인벤토리와 마찬가지로 역할에 표시된 작업을 허용합니다. 그러나 (다른 인벤토리에 있는) 호스트에는 특별한 권한을 부여하지 않습니다. 호스트에 대한 직접 읽기 권한을 허용하지 않거나 스마트 인벤토리 호스트 목록에 있는 호스트를 계속 볼 수 있지만 /#/hosts/ 아래의 추가 호스트를 볼 수 있도록 허용하지 않습니다.

경우에 따라 다음을 수정할 수 있습니다.

스마트 인벤토리와 연결된 호스트는 조회 시 표시됩니다. 스마트 인벤토리 결과에 호스트 이름이 동일한 호스트가 두 개 이상 포함된 경우 일치하는 호스트 중 하나만 호스트 ID로 정렬되어 스마트 인벤토리의 일부로 포함됩니다.

/api/v2/hosts?host_filter=ansible_facts__ansible_processor_vcpus=8

/api/v2/hosts?host_filter=ansible_facts__ansible_processor_vcpus=8

/api/v2/hosts/?host_filter=name=localhost
/api/v2/hosts/?host_filter=ansible_facts__ansible_date_time__weekday_number="3"
/api/v2/hosts/?host_filter=ansible_facts__ansible_processor[]="GenuineIntel"
/api/v2/hosts/?host_filter=ansible_facts__ansible_lo__ipv6[]__scope="host"
/api/v2/hosts/?host_filter=ansible_facts__ansible_processor_vcpus=8
/api/v2/hosts/?host_filter=ansible_facts__ansible_env__PYTHONUNBUFFERED="true"
/api/v2/hosts/?host_filter=(name=localhost or name=database) and (groups__name=east or groups__name="west coast") and ansible_facts__an

/api/v2/hosts/?host_filter=name=localhost
/api/v2/hosts/?host_filter=ansible_facts__ansible_date_time__weekday_number="3"
/api/v2/hosts/?host_filter=ansible_facts__ansible_processor[]="GenuineIntel"
/api/v2/hosts/?host_filter=ansible_facts__ansible_lo__ipv6[]__scope="host"
/api/v2/hosts/?host_filter=ansible_facts__ansible_processor_vcpus=8
/api/v2/hosts/?host_filter=ansible_facts__ansible_env__PYTHONUNBUFFERED="true"
/api/v2/hosts/?host_filter=(name=localhost or name=database) and (groups__name=east or groups__name="west coast") and ansible_facts__an

groups.name:groupA

groups.name:groupA

ansible_facts.ansible_fips:false

ansible_facts.ansible_fips:false