Documentation

14. Execution Environments

자동화를 위한 Python 가상 환경을 빌드하고 배포하는 기능이 Ansible 실행 환경으로 교체되었습니다. 기존의 가상 환경과 달리 실행 환경은 시스템 수준의 종속 항목과 컬렉션 기반 콘텐츠를 통합할 수 있는 컨테이너 이미지입니다. 각 실행 환경에서는 사용자 정의 이미지로 작업을 실행할 수 있으며, 각 실행 환경에는 작업을 실행할 때 필요한 항목만 포함됩니다.

14.1. Execution Environment 빌드

기본이 아닌 종속 항목(사용자 정의 가상 환경)에 의존하는 Ansible 콘텐츠를 사용하는 것은 까다로울 수 있습니다. 패키지가 각 노드에 설치되어 있어야 하고 호스트 시스템에 설치된 다른 소프트웨어와 함께 잘 재생되어야 하며 동기화된 상태를 유지해야 합니다. 이전 버전에서는 기본적으로 ``/var/lib/awx/venv/ansible``의 가상 환경 내부에서 작업이 실행되었는데, 이 가상 환경은 ansible-runner 및 Ansible 제어 머신에서 사용하는 특정 유형의 Ansible 콘텐츠를 위한 종속 항목과 함께 사전 로드되었습니다.

이 프로세스를 단순화하기 위해 Ansible `control nodes <https://docs.ansible.com/ansible/latest/network/getting_started/basic_concepts.html#control-node>`_로 사용되는 컨테이너 이미지를 빌드할 수 있습니다. 이러한 컨테이너 이미지를 자동화 |ees|이라고 하며, ansible-builder를 사용하여 생성하면 ansible-runner에서 해당 이미지를 사용할 수 있습니다.

14.1.1. ansible-builder 설치

이미지를 빌드하려면 ansible-builder Python 패키지와 함께 Podman 또는 Docker를 설치해야 합니다. --container-runtime 옵션은 사용하려는 Podman/Docker 실행 파일과 일치해야 합니다.

PyPi에서 설치하려면 다음을 수행합니다.

$ pip install ansible-builder

주요 개발 분기에서 설치하려면 다음을 수행합니다.

$ pip install https://github.com/ansible/ansible-builder/archive/devel.zip

특정 태그 또는 분기에서 설치하려면 다음 예제에서 ``<ref>``를 교체합니다.

$ pip install https://github.com/ansible/ansible-builder/archive/<ref>.zip

14.1.2. execution environment 빌드

ansible-builder는 |ee|를 생성하는 데 사용됩니다.

|ee|에는 다음이 포함되어야 합니다.

  • Ansible

  • Ansible Runner

  • Ansible 컬렉션

  • Python 및/또는 시스템 종속 항목:

    • 컬렉션의 모듈/플러그인

    • ansible-base의 콘텐츠

    • 사용자 정의 사용자 요구 사항

새로운 |ee|를 빌드하려면 컬렉션, Python 요구 사항, 시스템 수준 패키지와 같이 |ee|에 포함할 콘텐츠를 지정하는 정의(.yml 파일)가 필요합니다. 마이그레이션에서 |ees|로 생성된 출력 콘텐츠에는 파일로 파이프하거나 이 정의 파일에 붙여넣을 수 있는 몇 가지 필수 데이터가 있습니다. 자세한 내용은 :ref:`migrate_new_venv`을 참조하십시오. 가상 환경에서 마이그레이션하지 않은 경우 :ref:`ref_ee_definition`에 설명된 필수 데이터로 정의 파일을 생성할 수 있습니다.

컬렉션 개발자는 적절한 메타데이터를 제공하여 콘텐츠에 대한 요구 사항을 선언할 수 있습니다. 자세한 내용은 :ref:`ref_collections_metadata`를 참조하십시오.

14.1.3. 빌더 실행

정의를 생성한 후에는 다음 절차를 사용하여 |ee|를 빌드합니다.

ansible-builder build 명령은 execution environment 정의를 입력으로 사용합니다. execution environment 이미지를 빌드하는 데 필요한 빌드 컨텍스트를 출력하고 해당 이미지 빌드를 진행합니다. 이미지는 빌드 컨텍스트를 사용하여 다른 위치에 다시 빌드하고 동일한 결과를 생성할 수 있습니다. 기본적으로 현재 디렉터리에서 ``execution-environment.yml``이라는 파일을 찾습니다.

설명을 위해 다음 예제 execution-environment.yml 파일은 시작점으로 사용됩니다.

---
version: 1
dependencies:
  galaxy: requirements.yml

``requirements.yml``의 콘텐츠는 다음과 같습니다.

---
collections:
  - name: awx.awx

위 파일을 사용하여 |ee|를 빌드하려면 다음을 실행합니다.

$ ansible-builder build
...
STEP 7: COMMIT my-awx-ee
--> 09c930f5f6a
09c930f5f6ac329b7ddb321b144a029dbbfcc83bdfc77103968b7f6cdfc7bea2
Complete! The build context can be found at: context

즉시 사용 가능한 컨테이너 이미지를 생성할 뿐만 아니라 빌드 컨텍스트가 유지되므로 docker build 또는 ``podman build``와 같이 선택한 툴을 사용하여 다른 시간 및/또는 위치에 다시 빌드할 수 있습니다.

14.2. 작업에서 execution environment 사용

|ee|가 전역적으로 제공되는지 아니면 조직에 연결되어 있는지에 따라 적절한 수준의 관리자 권한이 있어야 작업에서 |ee|를 사용할 수 있습니다. 조직에 연결된 |Ees|에서는 조직 관리자가 해당 |ees|에서 작업을 실행할 수 있어야 합니다.

작업에서 |ee|를 사용하려면 |ab|를 사용하여 실행 환경을 생성해야 합니다. 자세한 내용은 :ref:`build_ee`를 참조하십시오. |ee|이 생성되면 이를 사용하여 작업을 실행할 수 있습니다. |at| 사용자 인터페이스를 사용하여 작업 템플릿에서 사용할 |ee|를 지정하십시오.

참고

인증 정보가 할당된 execution environment 를 사용하는 작업 또는 작업 템플릿을 실행하기 전에 인증 정보에 사용자 이름, 호스트, 암호가 포함되어 있어야 합니다.

  1. 왼쪽 탐색 모음에서 **실행 환경**을 클릭합니다.

  2. 추가 버튼을 선택하여 |ee|를 추가합니다.

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

  • 이름: |ee|의 이름을 입력합니다(필수).

  • 이미지: 이미지 이름을 입력합니다(필수). 이미지 이름에는 예제 형식 ``quay.io/ansible/awx-ee:latestrepo/project/image-name:tag``의 전체 위치(repo), 레지스트리, 이미지 이름, 버전 태그가 필요합니다.

  • 작업 유형: 필요한 경우 작업을 실행할 때 가져오기 유형을 선택합니다.

  • 실행하기 전에 항상 컨테이너 가져오기: 컨테이너의 최신 이미지 파일을 가져옵니다.

  • 가져오기 옵션이 선택되지 않음: 가져오기가 지정되지 않았습니다.

  • 실행하기 전에 컨테이너를 가져오지 않음: 최신 버전의 컨테이너 이미지를 가져오지 않습니다.

  • 설명 (선택 사항)

  • 조직: 필요한 경우 조직에서 특별히 이 |ee|를 사용하도록 지정합니다. 여러 조직에서 |ee|를 사용할 수 있도록 하려면 이 필드를 비워 둡니다.

  • 레지스트리 인증 정보: 이미지에 보호된 컨테이너 레지스트리가 있는 경우 액세스할 수 있도록 인증 정보를 제공합니다.

_images/ee-new-ee-form-filled.png

  1. **저장**을 클릭합니다.

이제 새로 추가된 |ee|를 작업 템플릿에서 사용할 준비가 되었습니다. 작업 템플릿에 |ee|를 추가하려면 아래 예제와 같이 작업 템플릿의 실행 환경 필드에 지정합니다. 작업 템플릿 설정에 대한 자세한 내용은 |atu|의 :ref:`ug_JobTemplates`을 참조하십시오.

_images/job-template-with-example-ee-selected.png

작업 템플릿에 |ee|를 추가하면 |ee|의 템플릿 탭에 나열된 템플릿을 확인할 수 있습니다.

_images/ee-details-templates-list.png

14.3. Execution Environment 마운트 옵션

execution environment 를 다시 빌드하는 것은 인증서를 추가하는 한 가지 방법이지만 호스트의 인증서 상속은 보다 편리한 솔루션을 제공합니다. VM 기반 설치의 경우 컨트롤러는 작업이 실행될 때 execution environment 에 시스템 신뢰 저장소를 자동으로 마운트합니다.

또한 podman-style 볼륨 마운트 구문을 지원하는 작업 설정 페이지의 격리된 작업에 노출할 경로 필드에 execution environment 마운트 옵션 및 마운트 경로를 사용자 지정할 수 있습니다. 자세한 내용은 `Podman documentation <https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-volume-host-dir-container-dir-options>`_을 참조하십시오.

|ee|의 사용자 지정으로 인해 ``/etc/ssh/*`` 파일이 |ee| 이미지에 추가된 경우 SSH 오류가 발생할 수 있습니다. 예를 들어 /etc/ssh/ssh_config.d:/etc/ssh/ssh_config.d:O 경로를 노출하면 컨테이너를 마운트할 수 있지만 소유권 권한이 올바르게 매핑되지 않습니다.

이 오류가 발생하거나 이전 버전의 컨트롤러(예: 3.8.x)에서 업그레이드된 경우 다음 단계를 수행합니다.

  1. 마운트된 볼륨의 컨테이너 소유권을 root 로 변경합니다.

  2. 작업 설정 페이지의 격리된 작업에 노출할 경로 필드에서 현재 예를 사용하여 다음과 같이 경로를 노출하십시오.

_images/settings-paths2expose-iso-jobs.png

참고

:O 옵션은 디렉터리에 대해서만 지원됩니다. 특히 시스템 경로를 지정할 때 최대한 구체적으로 사용하는 것이 좋습니다. /etc 또는 /usr 을 직접 마운트하면 문제 해결이 어렵습니다.

그러면 podman이 아래 예제와 유사한 명령을 실행하도록 알립니다. 여기서 구성이 마운트되고 ssh 명령이 예상대로 작동합니다.

podman run -v /ssh_config:/etc/ssh/ssh_config.d/:O ...

OpenShift 또는 Kubernetes 컨테이너에 격리된 경로를 HostPath로 공개하려면 다음 구성을 가정합니다.

_images/settings-paths2expose-iso-jobs-mount-containers.png

컨테이너 그룹에 대한 호스트 경로 노출 토글을 사용하여 활성화합니다.

플레이북이 실행되면 결과 Pod 사양이 아래 예제와 유사하게 표시됩니다. volumeMounts 및 volumes 섹션에 대한 세부 정보를 확인합니다.

_images/mount-containers-playbook-run-podspec.png