16. 프로젝트¶

16.1. 새 프로젝트 추가¶

새 프로젝트를 생성하려면 다음을 수행합니다.

1. 추가 버튼을 클릭합니다. 그러면 프로젝트 생성 창이 시작됩니다.

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

• 이름

• 설명 (선택 사항)

• 조직 - 프로젝트에는 하나 이상의 조직이 있어야 합니다. 하나의 조직을 선택하여 프로젝트를 생성한 다음 프로젝트가 생성된 후 조직을 추가할 수 있습니다.

• 기본 실행 환경 (선택 사항) - 실행 환경의 이름을 입력하거나 이 프로젝트를 실행할 기존 실행 환경 목록에서 검색합니다. 자세한 내용은 |atumg|의 :ref:`upgrade_venv`를 참조하십시오.

• 소스 제어 인증 정보 유형 - 드롭다운 메뉴 목록에서 이 프로젝트와 연결된 SCM 유형을 선택합니다. 후속 섹션의 옵션은 선택한 유형에 따라 제공됩니다. 자세한 내용은 다음 섹션에서 플레이북 수동 관리 또는 :ref:`ug_projects_scm_types`를 참조하십시오.

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

16.2. 소스 제어를 통한 프로젝트 업데이트¶

1. 프로젝트를 선택하고 버튼을 클릭하여 기존 SCM 기반 프로젝트를 업데이트합니다.

참고

소스 제어를 사용하기 위해 프로젝트 설정을 추가하는 즉시 《동기화》가 시작되어 구성된 소스 제어에서 프로젝트 세부 정보를 가져옵니다.

2. 업데이트 프로세스에 대한 자세한 내용을 보려면 상태 열에서 프로젝트의 상태를 클릭합니다.

16.3. 권한 작업¶

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

세부 정보 탭 옆에 있는 액세스 탭을 통해 프로젝트 권한에 액세스할 수 있습니다. 이 화면에는 현재 이 프로젝트에 대한 권한이 있는 사용자 목록이 표시됩니다. 목록은 사용자 이름, 성 또는 **이름**으로 정렬할 수 있습니다.

16.3.1. 권한 추가¶

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

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

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

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

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

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

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

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

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

16.4. 알림 작업¶

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

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

알림이 설정되지 않은 경우 왼쪽 탐색 모음의 알림 링크에서 알림을 구성하여 새 알림을 생성할 수 있습니다.

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

16.5. 작업 템플릿 작업¶

**작업 템플릿**을 클릭하면 이 프로젝트와 연결된 작업 템플릿 또는 워크플로우 템플릿을 추가하고 검토할 수 있습니다.

해당 템플릿을 사용하여 실행된 작업의 상태를 클릭하면 세부 정보 및 기타 유용한 정보가 표시됩니다. 이 목록을 다양한 기준으로 정렬하고 검색하여 관심 있는 템플릿을 필터링할 수 있습니다.

이 보기에서 템플릿 구성을 시작()하거나 편집()할 수도 있습니다.

16.6. 스케줄 작업¶

**스케줄**을 클릭하면 이 프로젝트에 설정된 모든 스케줄을 검토할 수 있습니다.

16.7. Ansible Galaxy 지원¶

프로젝트 업데이트가 종료되면 |at|는 roles 디렉터리의 ``<project-top-level-directory>/roles/requirements.yml``에 있는 ``requirements.yml``이라는 파일을 검색합니다. 이 파일이 있으면 다음 명령이 자동으로 실행됩니다.

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

이 파일을 사용하면 자체 프로젝트와 함께 체크아웃할 수 있는 기타 리포지터리 내의 역할 또는 Galaxy 역할을 참조할 수 있습니다. 이 Ansible Galaxy 지원을 추가하면 해당 결과를 얻기 위해 git 하위 모듈을 생성할 필요가 없습니다. (역할/컬렉션과 함께) SCM 프로젝트를 개인 작업 환경으로 가져와 실행하는 경우 /tmp 내에 해당 프로젝트 전용 <private job directory>가 기본적으로 생성됩니다. 그러나 설정 창의 작업 설정 탭에서 환경에 따라 다른 **작업 실행 경로**를 지정할 수 있습니다.

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

기본적으로 |at|에는 SCM 프로젝트의 roles/requirements.yml 파일에서 역할을 동적으로 다운로드할 수 있는 시스템 전체 설정이 있습니다. 설정 메뉴의 작업 설정 화면에서 역할 다운로드 활성화 토글 버튼을 **끄기**로 전환하여 이 설정을 끌 수 있습니다.

프로젝트 동기화가 실행될 때마다 |at|에서 프로젝트 소스와 Galaxy 및/또는 컬렉션의 역할이 프로젝트에서 오래되었는지 확인합니다. 프로젝트를 업데이트하면 업데이트 내에서 해당 역할이 다운로드됩니다.

작업에서 업스트림 역할에 대한 변경 사항을 선택해야 하는 경우 프로젝트를 업데이트하면 이러한 상황이 발생합니다. 역할 변경은 새 커밋이 provision-role 소스 제어에 푸시되었음을 의미합니다. 이러한 변경 사항을 작업에 적용하기 위해 playbooks 리포지터리에 새 커밋을 푸시할 필요는 없지만, 프로젝트를 **업데이트**하여 역할을 로컬 캐시에 다운로드해야 합니다. 예를 들어, 소스 제어에 두 개의 Git 리포지터리가 있다고 가정합니다. 첫 번째는 playbooks*이고 |at|의 프로젝트는 이 URL을 가리킵니다. 두 번째는 *provision-role*이며 *playbooks Git 리포지터리 내부의 roles/requirements.yml 파일에서 참조합니다.

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

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

requirements.yml 파일 구문에 대한 자세한 내용 및 예제는 Ansible 문서의 `role requirements section`_을 참조하십시오.

특별히 노출해야 하는 디렉터리가 있는 경우 **격리된 작업에 노출할 경로**에 있는 설정 화면의 작업 섹션에 지정하거나 설정 파일에서 다음 항목을 업데이트하여 해당 디렉터리를 지정할 수 있습니다.

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

참고

플레이북에서 경로에 정의된 키 또는 설정을 사용해야 하는 경우 AWX_ISOLATION_SHOW_PATHS``에 ``/var/lib/awx/.ssh 파일을 추가하는 것이 좋습니다.

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

사용자 인터페이스의 작업 설정 창에서 이러한 설정을 구성할 수 있습니다.

16.8. 컬렉션 지원¶

Automation controller supports project-specific Ansible collections in job runs. If you specify a collections requirements file in the SCM at collections/requirements.yml, automation controller will install collections in that file in the implicit project sync before a job run.

기본적으로 |at|에는 SCM 프로젝트의 collections/requirements.yml 파일에서 컬렉션을 동적으로 다운로드할 수 있는 시스템 전체 설정이 있습니다. 설정 메뉴의 작업 설정 탭에서 컬렉션 다운로드 활성화 토글 버튼을 **끄기**로 전환하여 이 설정을 끌 수 있습니다.

역할 및 컬렉션은 성능상의 이유로 로컬로 캐시되고, 프로젝트 SCM 업데이트 옵션에서 다음과 같이 **시작 시 버전 업데이트**를 선택해야 합니다.

16.8.1. Hub를 통해 컬렉션 사용¶

|at|에서 컬렉션 콘텐츠의 기본 소스로 |ah|를 사용하려면 |at|에서 지정할 수 있도록 |ah| UI에서 API 토큰을 생성해야 합니다. 비공개 Automation Hub 또는 공개 Automation Hub 컬렉션에 연결할 수도 있으며, 유일한 차이점은 지정하는 URL입니다.

1. https://cloud.redhat.com/ansible/automation-hub/token으로 이동하여 **토큰 로드**를 클릭합니다.

2. 복사 아이콘을 클릭하여 API 토큰을 클립보드에 복사합니다.

3. 공개 |ah|를 사용하려면 복사한 토큰을 사용하고 토큰 페이지의 **서버 URL** 및 **SSO URL** 필드에 표시된 URL을 가리키는 |ah| 인증 정보를 생성합니다.

• Galaxy Server URL = https://cloud.redhat.com/api/automation-hub/

• AUTH SEVER URL = https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token

4. 비공개 |ah|를 사용하려면 다음과 같이 로컬 |ah|의 리포지터리 관리 대시보드에서 검색되는 토큰을 사용하고 게시된 리포지터리 URL을 가리키는 |ah| 인증 정보를 생성합니다.

다양한 네임스페이스/컬렉션을 사용하여 다양한 리포지터리를 생성할 수 있습니다. 그러나 |ah|의 리포지터리별로 서로 다른 |ah| 인증 정보를 생성해야 합니다. Automation Hub UI에서 https://$<hub_url>/api/galaxy/content/<repo you want to pull from> 형식으로 Ansible CLI URL**을 *인증 정보 생성* 양식의 **Galaxy 서버 URL 필드에 복사합니다.

Automation Hub UI 관련 지침은 `Managing Red Hat Certified and Ansible Galaxy Collections in Ansible Hub <https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/1.2/html/managing_red_hat_certified_and_ansible_galaxy_collections_in_automation_hub/index>`_를 참조하십시오.

5. |ah|에서 콘텐츠를 동기화할 수 있는 조직으로 이동하여 새 |ah| 인증 정보를 조직에 추가합니다. 이 단계를 통해 각 조직을 콘텐츠를 사용하기 원하는 Automation Hub 인증 정보(즉, 리포지터리)와 연결할 수 있습니다.

참고

두 개의 리포지터리가 있다고 가정합니다.

• Prod: Namespace 1 및 Namespace 2, 각각 컬렉션이 A 및 B``이므로 ``namespace1.collectionA:v2.0.0 및 ``namespace2.collectionB:v2.0.0``입니다.

• 단계: 컬렉션 ``A``만 있는 ``Namespace 1``으로, |ah|의 ``namespace1.collectionA:v1.5.0``에 Prod 및 *단계*에 대한 리포지터리 URL이 있습니다.

각각에 대해 Automation Hub 인증 정보를 생성할 수 있습니다. 그런 다음 다양한 조직에 서로 다른 수준의 액세스 권한을 할당할 수 있습니다. 예를 들어, 개발자 조직은 두 리포지터리에 모두 액세스할 수 있는 반면 운영 조직은 |ah|**Prod** 리포지터리에만 액세스하도록 생성할 수 있습니다.

Automation Hub UI 관련 지침은 `Managing User Access in Ansible Hub <https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/1.0/html/managing_user_access_in_automation_hub/index>`_를 참조하십시오.

6. |ah|에 자체 서명된 인증서가 있는 경우 토글을 클릭하여 Ansible Galaxy SSL 인증서 확인 무시 설정을 활성화합니다. 서명된 인증서를 사용하는 **공용 자동화 허브**의 경우 토글을 클릭하여 대신 비활성화합니다. 이는 글로벌 설정입니다.

7. 소스 리포지터리에서 collections/requirements.yml 파일에 있는 요구 사항 파일의 필수 컬렉션을 지정하는 프로젝트를 생성합니다. Ansible 설명서에 설명된 구문 ( https://docs.ansible.com/ansible/latest/user_guide/collections_using html#install-multiple-collections-with-a-requirements-file)을 참조하십시오.

8. 프로젝트 목록 뷰에서 |update|을 클릭하여 이 프로젝트에 대한 업데이트를 실행합니다. |At|는 collections/requirements.yml 파일에서 Galaxy 컬렉션을 가져와서 변경된 것으로 보고합니다. 그러면 이 프로젝트를 사용하는 모든 작업 템플릿에 컬렉션이 설치됩니다.

참고

Galaxy 또는 Collections의 업데이트가 필요한 경우 필수 역할을 다운로드하는 동기화가 수행되며, /tmp 파일의 더 많은 공간이 사용됩니다. 큰 프로젝트(약 10GB)가 있는 경우 ``/tmp``의 디스크 공간이 문제가 될 수 있습니다.

컬렉션에 대한 자세한 내용은 Using Collections <https://docs.ansible.com/ansible/latest/user_guide/collections_using.html>`_을 참조하십시오. Red Hat이 자체적으로 |at| 설치를 직접 자동화하는 데 사용할 수 있는 이러한 공식 컬렉션 중 하나를 게시하는 방법에 대한 자세한 내용은 `AWX Ansible Collection 문서를 참조하십시오. 이 페이지는 Red Hat Ansible Automation Platform 서브스크립션의 일부로 Red Hat 고객 인증 정보를 사용하여 액세스할 수 있습니다.