20장. 실행 환경
기존의 가상 환경과 달리 실행 환경은 시스템 수준의 종속 항목과 컬렉션 기반 콘텐츠를 통합할 수 있는 컨테이너 이미지입니다. 각 실행 환경을 사용하면 작업을 실행할 수 있는 사용자 지정 이미지를 사용할 수 있으며 작업을 실행할 때 필요한 항목만 있습니다.
20.1. 실행 환경 빌드
Ansible 콘텐츠가 기본 환경 대신 사용자 지정 가상 환경에 종속되는 경우 추가 단계를 수행해야 합니다. 각 노드에 패키지를 설치하고 호스트 시스템에 설치된 다른 소프트웨어와 잘 상호 작용하며 동기화 상태로 유지해야 합니다.
이 프로세스를 단순화하기 위해 Ansible Control 노드 역할을 하는 컨테이너 이미지를 빌드할 수 있습니다. 이러한 컨테이너 이미지를 자동화 실행 환경이라고 하며 ansible-builder를 사용하여 생성할 수 있습니다. 그러면 Ansible-runner에서 해당 이미지를 사용할 수 있습니다.
20.1.1. ansible-builder 설치
이미지를 빌드하려면 ansible-builder
Python 패키지와 함께 Podman 또는 Docker가 설치되어 있어야 합니다.
--container-runtime
옵션은 사용하려는 Podman 또는 Docker 실행 파일에 해당해야 합니다.
실행 환경 이미지를 빌드할 때 Ansible Automation Platform이 배포된 아키텍처를 지원해야 합니다.
20.1.2. 실행 환경에 필요한 콘텐츠
ansible-builder는 실행 환경을 생성하는 데 사용됩니다.
실행 환경에는 다음이 포함되어야 합니다.
- Ansible
- Ansible Runner
- Ansible 컬렉션
Python 및 시스템 종속 항목:
- 컬렉션의 모듈 또는 플러그인
- ansible-base의 콘텐츠
- 사용자 정의 사용자 요구 사항
새 실행 환경을 빌드하려면 컬렉션, Python 요구 사항, 시스템 수준 패키지와 같은 실행 환경에 포함할 콘텐츠를 지정하는 정의가 포함됩니다. 정의는 .yml 파일이어야 합니다.
마이그레이션에서 실행 환경으로 생성되는 출력 콘텐츠에는 파일로 파이프하거나 이 정의 파일에 붙여넣을 수 있는 몇 가지 필수 데이터가 있습니다.
추가 리소스
자세한 내용은 레거시 venvs를 실행 환경으로 마이그레이션을 참조하십시오. 가상 환경에서 마이그레이션하지 않은 경우 실행 환경 설정 참조에 설명된 필수 데이터로 정의 파일을 만들 수 있습니다.
컬렉션 개발자는 적절한 메타데이터를 제공하여 콘텐츠에 대한 요구 사항을 선언할 수 있습니다.
자세한 내용은 종속성 을 참조하십시오.
20.1.3. 이미지를 빌드하는 YAML 파일의 예
ansible-builder build
명령은 실행 환경 정의를 입력으로 사용합니다. 실행 환경 이미지를 빌드하는 데 필요한 빌드 컨텍스트를 출력한 다음 해당 이미지를 빌드합니다. 이미지는 빌드 컨텍스트를 사용하여 다른 위치에 다시 빌드하고 동일한 결과를 생성할 수 있습니다. 기본적으로 빌더는 현재 디렉터리에서 execution-environment.yml
이라는 파일을 검색합니다.
다음 예제 execution-environment.yml
파일을 시작점으로 사용할 수 있습니다.
--- version: 3 dependencies: galaxy: requirements.yml
requirements.yml
내용:
--- collections: - name: awx.awx
이전 파일을 사용하여 실행 환경을 빌드하고 다음 명령을 실행합니다.
ansible-builder build ... STEP 7: COMMIT my-awx-ee --> 09c930f5f6a 09c930f5f6ac329b7ddb321b144a029dbbfcc83bdfc77103968b7f6cdfc7bea2 Complete! The build context can be found at: context
즉시 사용할 수 있는 컨테이너 이미지를 생성하는 것 외에도 빌드 컨텍스트가 유지됩니다. docker build
또는 podman build
와 같은 툴을 사용하여 다른 시간이나 위치에 다시 빌드할 수 있습니다.
추가 리소스
ansible-builder 빌드
명령에 대한 자세한 내용은 Ansible의 CLI 사용 설명서를 참조하십시오.
20.1.4. 실행 환경 마운트 옵션
실행 환경을 다시 빌드하는 것이 인증서를 추가하는 한 가지 방법이지만 호스트에서 인증서를 상속하면 보다 편리한 솔루션을 제공합니다. VM 기반 설치의 경우 자동화 컨트롤러는 작업이 실행될 때 실행 환경에 시스템 신뢰 저장소를 자동으로 마운트합니다.
실행 환경 마운트 옵션 및 작업 설정 페이지의 격리된 작업에 노출할 경로 의 마운트 경로를 사용자 지정할 수 있습니다. 여기서 Podman 스타일 볼륨 마운트 구문이 지원됩니다.
추가 리소스
자세한 내용은 Podman 설명서 를 참조하십시오.
20.1.4.1. 실행 환경 마운트 옵션 문제 해결
실행 환경의 사용자 지정으로 인해 /etc/ssh/*
파일이 실행 환경 이미지에 추가된 경우 SSH 오류가 발생할 수 있습니다. 예를 들어 /etc/ssh/ssh_config.d:/etc/ssh/ssh_config.d:O
경로를 노출하면 컨테이너를 마운트할 수 있지만 소유권 권한이 올바르게 매핑되지 않습니다.
이 오류를 충족하거나 이전 버전의 자동화 컨트롤러에서 업그레이드한 경우 다음 절차를 사용하십시오.
프로세스
-
마운트된 볼륨의 컨테이너 소유권을
root
로 변경합니다. -
탐색 패널에서
을 선택합니다. - 클릭합니다.
현재 예제를 사용하여 격리된 작업에 노출할 경로 의 경로를 노출합니다.
[ "/ssh_config:/etc/ssh/ssh_config.d/:0" ]
참고:O
옵션은 디렉터리에 대해서만 지원됩니다. 특히 시스템 경로를 지정할 때 최대한 자세히 설명하십시오./etc
또는/usr
을 직접 마운트하면 문제를 해결하기가 어렵습니다.이렇게 하면 다음 예와 유사한 명령을 실행하도록 Podman에 알립니다. 여기서 구성이 마운트되고
ssh
명령이 예상대로 작동합니다.podman run -v /ssh_config:/etc/ssh/ssh_config.d/:O ...
OpenShift 또는 Kubernetes 컨테이너의 격리된 경로를 HostPath로 공개하려면 다음 구성을 사용합니다.
[ "/mnt2:/mnt2", "/mnt3", "/mnt4:/mnt4:0" ]
컨테이너 그룹의 Expose 호스트 경로를 On 으로 설정하여 활성화합니다.
플레이북이 실행되면 결과 Pod 사양이 다음 예와 유사합니다. volumeMounts
및 volumes
섹션에 대한 세부 정보를 확인합니다.
20.1.4.2. 실행 환경 컨테이너에 실행 노드의 디렉터리 마운트
Ansible Automation Platform 2.1.2에서는 O
및 z
옵션만 사용할 수 있었습니다. Ansible Automation Platform 2.2 이후 rw
와 같은 추가 옵션을 사용할 수 있습니다. 이는 NFS 스토리지를 사용할 때 유용합니다.
프로세스
-
탐색 패널에서
을 선택합니다. 격리된 작업에 노출할 경로를 편집합니다.
- 볼륨이 실행 노드에서 컨테이너로 마운트되는 경로 목록을 입력합니다.
- 행당 하나의 경로를 입력합니다.
지원되는 형식은
HOST-DIR[:CONTAINER-DIR[:OPTIONS]
입니다. 허용되는 경로는z
,O
,ro
,rw
입니다.예
[ "/var/lib/awx/.ssh:/root/.ssh:O" ]
rw
옵션의 경우 SELinux 레이블을 올바르게 구성합니다. 예를 들어/foo
디렉토리를 마운트하려면 다음 명령을 완료합니다.sudo su
mkdir /foo
chmod 777 /foo
semanage fcontext -a -t container_file_t "/foo(/.*)?"
restorecon -vvFR /foo
awx
사용자는 최소한 이 디렉토리에서 읽거나 쓸 수 있어야 합니다. 현재 권한을 777
로 설정합니다.
추가 리소스
마운트 볼륨에 대한 자세한 내용은 Podman 설명서 의 podman-run(1) 섹션의 --volume 옵션을 참조하십시오.