실행 환경 생성 및 사용
Ansible Builder에서 실행 환경 생성 및 사용
초록
머리말
Ansible Builder를 사용하여 Red Hat Ansible Automation Platform 요구 사항에 맞는 일관되고 재현 가능한 자동화 실행 환경을 생성합니다.
Red Hat 문서에 관한 피드백 제공
이 문서를 개선하기 위한 제안이 있거나 오류를 찾을 수 있는 경우 https://access.redhat.com 에서 기술 지원에 문의하여 docs-product 구성 요소를 사용하여 Ansible Automation Platform Jira 프로젝트에 문제를 생성하십시오.
1장. 자동화 실행 환경 소개
패키지를 각 노드에 설치하고 호스트 시스템에 설치된 다른 소프트웨어와 상호 작용하고 동기화 상태를 유지해야 하기 때문에 기본이 아닌 종속 항목에 의존하는 Ansible 콘텐츠를 사용하는 것이 복잡할 수 있습니다.
자동화 실행 환경은 이 프로세스를 단순화하는 데 도움이 되며 Ansible Builder를 사용하여 쉽게 생성할 수 있습니다.
1.1. 자동화 실행 환경 정보
Red Hat Ansible Automation Platform의 모든 자동화는 자동화 실행 환경이라는 컨테이너 이미지에서 실행됩니다. 자동화 실행 환경은 자동화 종속 항목을 전달하는 공통 언어를 생성하고 자동화 환경을 빌드하고 배포하는 표준 방법을 제공합니다.
자동화 실행 환경에는 다음이 포함되어야 합니다.
- Ansible Core 2.15 이상
- Python 3.8-3.11
- Ansible Runner
- Ansible 콘텐츠 컬렉션 및 해당 종속 항목
- 시스템 종속 항목
1.1.1. 자동화 실행 환경을 사용하는 이유는 무엇입니까?
자동화 실행 환경을 통해 Red Hat Ansible Automation Platform은 컨트롤 플레인을 실행 플레인과 분리하여 분산 아키텍처로 전환되었습니다. 컨트롤 플레인과 독립적으로 자동화 실행을 유지하면 개발 주기가 단축되고 환경 전반에 걸친 확장성, 신뢰성 및 이식성이 향상됩니다. Red Hat Ansible Automation Platform에는 Ansible 콘텐츠 툴에 액세스할 수 있으므로 자동화 실행 환경을 쉽게 구축하고 관리할 수 있습니다.
속도, 이식성 및 유연성 외에도 자동화 실행 환경은 다음과 같은 이점을 제공합니다.
- 이를 통해 자동화가 여러 플랫폼에서 일관되게 실행되고 시스템 수준의 종속 항목과 수집 기반 콘텐츠를 통합할 수 있습니다.
- 이를 통해 Red Hat Ansible Automation Platform 관리자는 다양한 팀의 요구 사항을 충족하기 위해 자동화 환경을 제공하고 관리할 수 있습니다.
- 자동화 환경을 구축하고 배포하는 표준 방법을 제공하여 팀 간 자동화를 쉽게 확장하고 공유할 수 있습니다.
- 이를 통해 자동화 팀은 자동화 환경을 자체적으로 정의, 구축 및 업데이트할 수 있습니다.
- 자동화 실행 환경은 자동화 종속 항목을 전달하는 공통 언어를 제공합니다.
2장. Ansible 빌더 사용
Ansible Builder는 다양한 Ansible 컬렉션에서 정의되거나 사용자가 생성한 메타데이터를 사용하여 자동화 실행 환경을 빌드하는 프로세스를 자동화하는 명령줄 툴입니다.
2.1. Ansible Builder를 사용하는 이유는 무엇입니까?
Ansible Builder가 개발되기 전에 Red Hat Ansible Automation Platform 사용자는 필요한 모든 종속 항목이 포함된 사용자 지정 가상 환경 또는 컨테이너를 생성할 때 종속성 문제 및 오류를 실행할 수 있습니다.
이제 Ansible Builder를 사용하면 Ansible Core, Python, Collections, 타사 Python 요구 사항 및 시스템 수준 패키지와 같은 자동화 실행 환경에 포함할 콘텐츠를 지정하는 사용자 지정 가능한 자동화 실행 환경 정의 파일을 쉽게 생성할 수 있습니다. 이를 통해 필요한 모든 요구 사항과 종속 항목을 충족하여 작업을 실행할 수 있습니다.
2.2. Ansible 빌더 설치
사전 요구 사항
- Podman 컨테이너 런타임을 설치했습니다.
-
호스트에 유효한 서브스크립션이 연결되어 있습니다. 이렇게 하면
ansible-builder
를 설치하는 데 필요한 서브스크립션 전용 리소스에 액세스하고ansible-builder
에 필요한 리포지토리가 자동으로 활성화되어 있는지 확인할 수 있습니다. 자세한 내용은 Red Hat Ansible Automation Platform 서브스크립션 연결을 참조하십시오.
절차
터미널에서 다음 명령을 실행하여 Ansible Automation Platform 리포지터리를 활성화합니다.
# dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms ansible-builder
2.3. 정의 파일 빌드
Ansible Builder를 설치한 후 Ansible Builder에서 자동화 실행 환경 이미지를 생성하는 데 사용하는 정의 파일을 생성할 수 있습니다. Ansible Builder는 정의 파일을 읽고 검증한 다음
을 생성한 다음, 마지막으로 컨테이너 파일을 Podman에 전달하여 자동화 실행 환경 이미지를 패키지하고 자동화 실행 환경 이미지를 생성하여 자동화 실행 환경 이미지를 만듭니다. 생성하는 정의 파일은 Containerfile
yaml
형식이어야 하며 다른 섹션이 포함되어 있어야 합니다. 기본 정의 파일 이름은 제공되지 않는 경우 execution-environment.yml
입니다. 정의 파일의 부분에 대한 자세한 내용은 정의 파일 콘텐츠 분리를 참조하십시오.
다음은 버전 3 정의 파일의 예입니다. 각 정의 파일은 사용하는 Ansible Builder 기능 세트의 주요 버전 번호를 지정해야 합니다. 지정하지 않는 경우 Ansible Builder는 기본적으로 버전 1로 설정되므로 대부분의 새로운 기능과 정의 키워드를 사용할 수 없습니다.
예 2.1. 정의 파일 예
version: 3 build_arg_defaults: 1 ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: '--pre' dependencies: 2 galaxy: requirements.yml python: - six - psutil system: bindep.txt images: 3 base_image: name: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel9:latest # Custom package manager path for the RHEL based images options: 4 package_manager_path: /usr/bin/microdnf additional_build_steps: 5 prepend_base: - RUN echo This is a prepend base command! prepend_galaxy: # Environment variables used for Galaxy client configurations - ENV ANSIBLE_GALAXY_SERVER_LIST=automation_hub - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_URL=https://console.redhat.com/api/automation-hub/content/xxxxxxx-synclist/ - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_AUTH_URL=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token # define a custom build arg env passthru - we still also have to pass # `--build-arg ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN` to get it to pick it up from the env - ARG ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN prepend_final: | RUN whoami RUN cat /etc/os-release append_final: - RUN echo This is a post-install command! - RUN ls -la /etc
추가 리소스
- 정의 파일 콘텐츠에 대한 자세한 내용은 정의 파일 콘텐츠 분리를 참조하십시오.
- Ansible Builder 버전 2와 3의 차이점에 대한 자세한 내용은 Ansible 3 포트 지정 가이드를 참조하십시오.
2.4. 자동화 실행 환경 이미지 빌드
정의 파일을 생성한 후 자동화 실행 환경 이미지를 빌드할 수 있습니다.
사전 요구 사항
- 정의 파일을 생성했습니다.
절차
자동화 실행 환경 이미지를 빌드하려면 명령줄에서 다음을 실행합니다.
$ ansible-builder build
기본적으로 Ansible Builder는 execution-environment.yml
이라는 정의 파일을 찾고 있지만 -f
플래그를 사용하여 다른 파일 경로를 인수로 지정할 수 있습니다.
$ ansible-builder build -f definition-file-name.yml
여기서 definition-file-name 은 정의 파일의 이름을 지정합니다.
2.5. 정의 파일 콘텐츠 분석
자동화 실행 환경 컨테이너 이미지에 포함된 콘텐츠를 지정하므로 Ansible Builder를 사용하여 자동화 실행 환경을 빌드하는 데 정의 파일이 필요합니다.
다음 섹션에서는 정의 파일의 다른 부분을 나눕니다.
2.5.1. 인수 및 기본 이미지 빌드
정의 파일의 build_arg_defaults
섹션은 키가 Ansible 빌더에 인수의 기본값을 제공할 수 있는 사전입니다. build_arg_defaults
에 사용할 수 있는 값 목록은 다음 표를 참조하십시오.
현재의 | 설명 |
---|---|
| 사용자는 컬렉션 설치 단계에서 임의의 인수를 ansible-galvncy CLI에 전달할 수 있습니다. 예를 들어 사전 릴리스 컬렉션을 설치할 수 있는 -pre 플래그 또는 -c는 서버의 SSL 인증서 확인을 비활성화합니다. |
| 사용자가 -no-deps와 같은 플래그를 역할 설치에 전달할 수 있습니다. |
build_arg_defaults
내에 지정된 값은 Containerfile
로 하드 코딩되므로 podman build
를 수동으로 호출하면 이러한 값이 유지됩니다.
CLI --build-arg
플래그에 동일한 변수가 지정되면 CLI 값이 우선 순위가 높습니다.
정의 파일의 dependencies 섹션에 있는 최종 이미지에 설치해야 하는 종속성을 포함할 수 있습니다.
자동화 실행 환경 이미지 문제를 방지하려면 Galaxy, Python 및 시스템의 항목이 유효한 요구 사항 파일을 가리키거나 해당 파일 유형에 유효한 콘텐츠인지 확인하십시오.
2.5.1.1. Galaxy
galaxy
항목은 유효한 요구 사항 파일을 가리키거나 ansible-galaxy 컬렉션 install -r …
명령에 대한 인라인 콘텐츠를 포함합니다.
항목 requirements.yml
은 자동화 실행 환경 정의 폴더의 디렉터리 또는 절대 경로의 상대 경로일 수 있습니다.
콘텐츠는 다음과 같을 수 있습니다.
예 2.2. Galaxy 항목
collections: - community.aws - kubernetes.core
2.5.1.2. Python
정의 파일의 python
항목은 올바른 요구 사항 파일을 가리키거나 pip install -r …
명령의 PEP508 형식의 Python 요구 사항 목록을 가리킵니다.
항목 requirements.txt
는 컬렉션에서 이미 Python 종속 항목으로 나열하는 추가 Python 요구 사항을 설치하는 파일입니다. 자동화 실행 환경 정의 폴더의 디렉터리에서 상대 경로 또는 절대 경로로 나열될 수 있습니다. requirements.txt
파일의 내용은 pip freeze
명령의 표준 출력과 유사하게 다음 예와 같이 포맷해야 합니다.
예 2.3. Python 항목
boto>=2.49.0 botocore>=1.12.249 pytz python-dateutil>=2.7.0 awxkit packaging requests>=2.4.2 xmltodict azure-cli-core==2.11.1 openshift>=0.6.2 requests-oauthlib openstacksdk>=0.13 ovirt-engine-sdk-python>=4.4.10
2.5.1.3. 시스템
정의의 시스템
항목은 bindep 요구 사항 파일 또는 Bindep 항목의 인라인 목록을 가리킵니다. 이 목록은 컬렉션에 이미 포함되어 있는 항목 외부에 있는 시스템 수준 종속성을 설치합니다. 자동화 실행 환경 정의 폴더의 디렉터리에서 상대 경로로 나열하거나 절대 경로로 나열할 수 있습니다. 최소한 컬렉션에서 [platform:rpm]
에 필요한 요구 사항을 지정해야 합니다.
이를 설명하기 위해 다음은 libxml2
및 하위 버전
패키지를 컨테이너에 추가하는 bindep.txt
파일의 예입니다.
예 2.4. 시스템 항목
libxml2-devel [platform:rpm] subversion [platform:rpm]
여러 컬렉션의 항목이 단일 파일로 결합됩니다. 이 작업은 bindep
에 의해 처리된 다음 dnf
로 전달됩니다. 프로파일이 없거나 런타임 요구 사항이 없는 요구 사항만 이미지에 설치됩니다.
2.5.2. 이미지
정의 파일의 images
섹션은 기본 이미지를 식별합니다. podman
컨테이너 런타임에서는 서명된 컨테이너 이미지에 대한 확인이 지원됩니다.
이미지에서
사용할 수 있는 값 목록은 다음 표를 참조하십시오.
현재의 | 설명 |
---|---|
| 기존 이미지를 기반으로 새 이미지를 빌드할 수 있는 자동화 실행 환경의 상위 이미지를 지정합니다. 일반적으로 ee-minimal 또는 ee-supported 와 같은 지원되는 실행 환경 기본 이미지이지만 사용자가 생성하고 추가로 사용자 지정하려는 실행 환경 이미지일 수도 있습니다.
컨테이너 이미지를 사용하려면
기본 이미지는 |
CLI --build-arg
플래그에 동일한 변수가 지정되면 CLI 값이 우선 순위가 높습니다.
2.5.3. 추가 빌드 파일
정의 파일의 additional_build_steps
섹션에 참조하거나 복사하여 외부 파일을 빌드 컨텍스트 디렉터리에 추가할 수 있습니다. 형식은 사전 값 목록으로, 각각 src
및 dest
키와 value가 있습니다.
각 목록 항목은 다음 필수 키가 포함된 사전이어야 합니다.
src
-
빌드 컨텍스트 디렉터리에 복사할 소스 파일을 지정합니다. 절대 경로(예:
/home/user/.ansible.cfg
) 또는 실행 환경 파일과 관련된 경로일 수 있습니다. 상대 경로는 하나 이상의 파일(예:files/*.cfg
)과 일치하는 glob 표현식일 수 있습니다.
절대 경로는 정규식을 포함할 수 없습니다. src
가 디렉터리이면 해당 디렉토리의 전체 콘텐츠가 dest
로 복사됩니다.
dest
-
소스 파일(예:
files/configs
)을 포함하는 빌드 컨텍스트 디렉터리의_build
하위 디렉터리 아래에 하위 디렉터리 경로를 지정합니다. 이는 절대 경로이거나 경로 내에서포함할
수 없습니다. Ansible Builder가 아직 없는 경우 이 디렉터리를 생성합니다.
2.5.4. 추가적인 사용자 지정 빌드 단계
정의 파일의 additional_build_steps
섹션에서 모든 빌드 단계에 대한 사용자 정의 빌드 명령을 지정할 수 있습니다. 이를 통해 빌드 단계를 세부적으로 제어할 수 있습니다.
prepend_
및 append_
명령을 사용하여 기본 빌드 단계가 실행되기 전이나 후에 실행되는 Containerfile
에 지시문을 추가합니다. 명령은 런타임 시스템에 필요한 모든 규칙을 준수해야 합니다.
additional_build_steps
에서 사용할 수 있는 값 목록은 다음 표를 참조하십시오.
현재의 | 설명 |
---|---|
| 기본 이미지를 빌드하기 전에 명령을 삽입할 수 있습니다. |
| 기본 이미지를 빌드한 후 명령을 삽입할 수 있습니다. |
| Galaxy 이미지를 빌드하기 전에 삽입할 수 있습니다. |
| Galaxy 이미지를 빌드한 후 삽입할 수 있습니다. |
| Python 빌더 이미지를 빌드하기 전에 명령을 삽입할 수 있습니다. |
| Python 빌더 이미지를 빌드한 후 명령을 삽입할 수 있습니다. |
| 최종 이미지를 빌드하기 전에 삽입할 수 있습니다. |
| 최종 이미지를 빌드한 후 삽입할 수 있습니다. |
additional_build_steps
구문은 여러 줄 문자열과 목록을 모두 지원합니다. 다음 예제를 참조하십시오.
예 2.5. 여러 줄 문자열 항목
prepend_final: | RUN whoami RUN cat /etc/os-release
예 2.6. 목록 항목
append_final: - RUN echo This is a post-install command! - RUN ls -la /etc
2.5.5. 추가 리소스
- 일반적인 시나리오에 대한 정의 파일의 예는 Ansible Builder 설명서의 일반적인 시나리오 섹션을 참조하십시오.
2.6. 선택적 빌드 명령 인수
-t
플래그는 자동화 실행 환경 이미지에 특정 이름으로 태그를 지정합니다. 예를 들어 다음 명령은 my_first_ee_image
이미지를 빌드합니다.
$ ansible-builder build -t my_first_ee_image
빌드에
-t
를 사용하지 않는 경우 ansible-execution-env
라는 이미지가 생성되어 로컬 컨테이너 레지스트리에 로드됩니다.
여러 정의 파일이 있는 경우 -f
플래그를 포함하여 사용할 파일을 지정할 수 있습니다.
$ ansible-builder build -f another-definition-file.yml -t another_ee_image
이 예제에서 Ansible Builder는 기본 execution-environment.yml
대신 another-definition-file.yml
이라는 파일에 제공된 사양을 사용하여 another_ee_image
라는 자동화 실행 환경 이미지를 빌드합니다.
빌드
명령과 함께 사용할 수 있는 기타 사양 및 플래그의 경우 ansible-builder build --help
를 입력하여 추가 옵션 목록을 확인합니다.
2.7. Containerfile
정의 파일이 생성되면 Ansible Builder는 이를 읽고 검증하고, Containerfile
및 컨테이너 빌드 컨텍스트를 생성하고 선택적으로 Podman에 전달하여 자동화 실행 환경 이미지를 빌드합니다. 컨테이너 빌드는 기본
, galaxy
,빌더
및 최종
등 여러 단계로 수행됩니다. 이미지 빌드 단계( additional_build_단계에 정의된 해당 사용자 정의 prepend_
및 append
단계와 함께 )는 다음과 같습니다.
_
-
기본
빌드 단계에서 지정된 기본 이미지는 Python,pip
,ansible-core
,ansible-runner
를 포함하여 다른 빌드 단계에 필요한 구성 요소로 사용자 지정된 (선택 사항)입니다. 그런 다음 생성된 이미지를 검증하여 필요한 구성 요소를 사용할 수 있는지 확인합니다(기본 이미지에 이미 있을 수 있음). 생성된 사용자 지정기본
이미지의 임시 복사본은 다른 모든 빌드 단계의 기반으로 사용됩니다. -
Galaxy
빌드 단계에서 정의 파일에 지정된 컬렉션이 다운로드되어최종
빌드 단계에서 나중에 설치할 수 있도록 저장됩니다. 컬렉션에서 선언한 Python 및 시스템 종속 항목은 나중에 분석을 위해 수집됩니다. -
빌더
빌드 단계에서 컬렉션에서 선언한 Python 종속성은 정의 파일에 나열된 항목과 병합됩니다. 이 최종 Python 종속 항목 세트는 Python용으로 다운로드 및 빌드되어최종
빌드 단계에서 나중에 설치를 위해 저장됩니다. -
최종
빌드 단계에서 이전에 다운로드한 컬렉션은 컬렉션에 의해 종속성으로 선언되었거나 정의 파일에 나열된 시스템 패키지 및 이전에 빌드된 모든 Python 패키지와 함께 설치됩니다.
2.8. 이미지를 빌드하지 않고 컨테이너 파일 생성
보안상의 이유로 샌드박스 환경에서 빌드된 공유 컨테이너 이미지를 사용해야 하는 경우 공유 가능한 컨테이너 파일을
생성할 수 있습니다.
$ ansible-builder create
3장. 일반적인 자동화 실행 환경 시나리오
다음 예제 정의 파일을 사용하여 일반적인 구성 시나리오를 해결합니다.
3.1. 자동화 허브 CA 인증서 업데이트
이 예제를 사용하여 CA 인증서를 additional-build-files
섹션에 포함하도록 기본 정의 파일을 사용자 지정하고 파일을 적절한 디렉터리로 이동하고 마지막으로 명령을 실행하여 시스템이 이 CA 인증서를 신뢰하도록 CA 인증서의 동적 구성을 업데이트합니다.
사전 요구 사항
-
사용자 정의 CA 인증서(예:
rootCA.crt
)
prepend_base
를 사용하여 CA 인증서를 사용자 정의하면 다른 모든 빌드 단계와 최종 이미지에 결과 CA 구성이 기본 이미지에서 상속되므로 결과 CA 구성이 표시됩니다.
additional_build_files: # copy the CA public key into the build context, we will copy and use it in the base image later - src: files/rootCA.crt dest: configs additional_build_steps: prepend_base: # copy a custom CA cert into the base image and recompute the trust database # because this is in "base", all stages will inherit (including the final EE) - COPY _build/configs/rootCA.crt /usr/share/pki/ca-trust-source/anchors - RUN update-ca-trust options: package_manager_path: /usr/bin/microdnf # downstream images use non-standard package manager [galaxy] server_list = automation_hub
3.2. 자동화 실행 환경을 구축할 때 자동화 허브 인증 세부 정보 사용
다음 예제를 사용하여 최종 자동화 실행 환경 이미지에 노출하지 않고 자동화 허브 인증 세부 정보를 자동화 실행 환경 빌드에 전달하도록 기본 정의 파일을 사용자 지정합니다.
사전 요구 사항
-
자동화 허브 API 토큰을 생성하여 보안 위치(예:
token
.txt 라는 파일에 저장)를 생성했습니다. - 자동화 허브 API 토큰으로 채워지는 빌드 인수를 정의합니다.
export ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN=$(cat <token.txt>)
additional_build_steps: prepend_galaxy: # define a custom build arg env passthru- we still also have to pass # `--build-arg ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN` to get it to pick it up from the host env - ARG ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN - ENV ANSIBLE_GALAXY_SERVER_LIST=automation_hub - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_URL=https://console.redhat.com/api/automation-hub/content/<yourhuburl>-synclist/ - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_AUTH_URL=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
3.3. 추가 리소스
- 자동화 실행 환경 정의 파일의 다른 부분에 대한 자세한 내용은 정의 파일 콘텐츠 분석을 참조하십시오.
- 일반적인 시나리오에 대한 추가 예제 정의 파일은 Ansible Builder 설명서의 일반적인 시나리오 섹션을 참조하십시오.
4장. 자동화 실행 환경 게시
4.1. 기존 자동화 실행 환경 이미지 사용자 정의
Ansible Controller에는 다음과 같은 기본 실행 환경이 포함되어 있습니다.
-
최소
- Ansible Runner와 함께 최신 Ansible-core 2.15 릴리스를 포함하지만 컬렉션 또는 기타 콘텐츠는 포함되지 않습니다. -
EE 지원
- 최소 지원 및 모든 Red Hat 지원 컬렉션 및 종속 항목
이러한 환경은 많은 자동화 사용 사례를 다루지만 추가 항목을 추가하여 특정 요구에 맞게 이러한 컨테이너를 사용자 지정할 수 있습니다. 다음 절차에서는 kubernetes.core
컬렉션을 ee-minimal
기본 이미지에 추가합니다.
절차
Podman을 통해
registry.redhat.io
에 로그인합니다.$ podman login -u="[username]" -p="[token/hash]" registry.redhat.io
필요한 자동화 실행 환경 기본 이미지를 가져올 수 있는지 확인합니다.
podman pull registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8:latest
새 실행 환경 이미지에 추가할 필수 기본 이미지 및 추가 콘텐츠를 지정하도록 Ansible Builder 파일을 구성합니다.
예를 들어 Galaxy의 Kubernetes Core Collection 을 이미지에 추가하려면 Galaxy 항목을 사용합니다.
collections: - kubernetes.core
- 정의 파일 및 해당 콘텐츠에 대한 자세한 내용은 정의 파일 분석 섹션을 참조하십시오.
실행 환경 정의 파일에서 원래
ee-minimal
컨테이너의 URL과EE_BASE_IMAGE
필드에 태그를 지정합니다. 이렇게 하면 최종execution-environment.yml
파일이 다음과 같이 표시됩니다.예 4.1. 사용자 정의된
execution-environment.yml
파일version: 3 images: base_image: 'registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel9:latest' dependencies: galaxy: collections: - kubernetes.core
참고이 예제에서는 자동화 허브의 인증된 컬렉션이 아닌
kubernetes.core
커뮤니티 버전을 사용하므로 정의 파일에서ansible.cfg
파일 또는 참조를 생성할 필요가 없습니다.다음 명령을 사용하여 새 실행 환경 이미지를 빌드합니다.
$ ansible-builder build -t [username]/new-ee
여기서
[username]
은 사용자 이름을 지정하고new-ee
는 새 컨테이너 이미지의 이름을 지정합니다.참고빌드에
-t
를 사용하지 않는 경우ansible-execution-env
라는 이미지가 생성되어 로컬 컨테이너 레지스트리에 로드됩니다.podman images
명령을 사용하여 새 컨테이너 이미지가 해당 목록에 있는지 확인합니다.예 4.2. 이미지
new-ee
를 사용한podman images
명령 출력REPOSITORY TAG IMAGE ID CREATED SIZE localhost/new-ee latest f5509587efbb 3 minutes ago 769 MB
컬렉션이 설치되었는지 확인합니다.
$ podman run [username]/new-ee ansible-doc -l kubernetes.core
자동화 허브에 사용할 이미지를 태그합니다.
$ podman tag [username]/new-ee [automation-hub-IP-address]/[username]/new-ee
Podman을 사용하여 자동화 허브에 로그인합니다.
참고자동화 허브가 컨테이너를 푸시하려면
관리자
또는 적절한 컨테이너 리포지토리 권한이 있어야 합니다. 자세한 내용은 자동화 허브의 콘텐츠 관리의 프라이빗 자동화 허브에서 컨테이너 관리 섹션을 참조하십시오.$ podman login -u="[username]" -p="[token/hash]" [automation-hub-IP-address]
자동화 허브에서 컨테이너 레지스트리로 이미지를 푸시합니다.
$ podman push [automation-hub-IP-address]/[username]/new-ee
새 이미지를 자동화 컨트롤러 인스턴스로 가져옵니다.
- 자동화 컨트롤러로 이동합니다.
- 탐색 패널에서 → 선택합니다.
- 를 클릭합니다.
적절한 정보를 입력한 다음
을 클릭하여 새 이미지를 가져옵니다.참고자동화 허브 인스턴스가 암호 또는 토큰으로 보호되는 경우 적절한 컨테이너 레지스트리 인증 정보를 설정해야 합니다.
4.2. 추가 리소스(또는 다음 단계)
일반적인 시나리오를 기반으로 실행 환경 사용자 지정에 대한 자세한 내용은 Ansible 빌더 설명서 의 다음 항목을 참조하십시오.
5장. 프라이빗 자동화 허브 컨테이너 레지스트리 채우기
기본적으로 프라이빗 자동화 허브에는 컨테이너 이미지가 포함되어 있지 않습니다. 컨테이너 레지스트리를 채우려면 컨테이너 이미지를 푸시해야 합니다.
프라이빗 자동화 허브 컨테이너 레지스트리를 채우려면 특정 워크플로우를 따라야 합니다.
- Red Hat Ecosystem Catalog에서 이미지 가져오기(registry.redhat.io)
- 태그
- 프라이빗 자동화 허브 컨테이너 레지스트리로 푸시
이미지 매니페스트 및 파일 시스템 Blob은 원래 registry.redhat.io
및 registry.access.redhat.com
에서 직접 제공되었습니다. 2023년 5월 1일부터 파일 시스템 Blob은 quay.io
에서 대신 제공됩니다.
- Table 5.10에 나열된 네트워크 포트 및 프로토콜이 있는지 확인합니다. 실행 환경(EE) 을 사용하여 컨테이너 이미지를 가져오는 문제를 방지할 수 있습니다.
구체적으로 registry.redhat.io
또는 registry.access.redhat.com
에 대한 아웃 바운드 연결을 활성화하는 방화벽 구성을 변경합니다.
방화벽 규칙을 구성할 때 IP 주소 대신 호스트 이름을 사용합니다.
이러한 변경을 수행한 후 registry.redhat.io
및 registry.access.redhat.com
에서 이미지를 계속 가져올 수 있습니다. quay.io
로그인이 필요하지 않거나 Red Hat 컨테이너 이미지를 계속 가져오려면 quay.io
레지스트리와 직접 상호 작용해야 합니다.
5.1. 자동화 허브에서 사용할 이미지 가져오기
컨테이너 이미지를 프라이빗 자동화 허브로 푸시하려면 먼저 기존 레지스트리에서 해당 이미지를 가져와서 사용할 태그를 지정해야 합니다. 다음 예제에서는 Red Hat Ecosystem Catalog(registry.redhat.io)에서 이미지를 가져오는 방법을 자세히 설명합니다.
사전 요구 사항
registry.redhat.io에서 이미지를 가져올 수 있는 권한이 있습니다.
절차
registry.redhat.io 인증 정보를 사용하여 Podman에 로그인합니다.
$ podman login registry.redhat.io
- 사용자 이름과 암호를 입력합니다.
컨테이너 이미지를 가져옵니다.
$ podman pull registry.redhat.io/<container_image_name>:<tag>
검증
최근 가져온 이미지가 목록에 포함되어 있는지 확인하려면 다음 단계를 따르십시오.
로컬 스토리지에 이미지를 나열합니다.
$ podman images
- 이미지 이름을 확인하고 태그가 올바른지 확인합니다.
추가 리소스
- 이미지 등록 및 가져오기에 대한 정보는 Red Hat Ecosystem Catalog 도움말을 참조하십시오.
5.2. 자동화 허브에 사용할 이미지 태그
레지스트리에서 이미지를 가져온 후 프라이빗 자동화 허브 컨테이너 레지스트리에 사용하도록 태그를 지정합니다.
사전 요구 사항
- 외부 레지스트리에서 컨테이너 이미지를 가져왔습니다.
- 자동화 허브 인스턴스의 FQDN 또는 IP 주소가 있습니다.
절차
자동화 허브 컨테이너 리포지터리를 사용하여 로컬 이미지에 태그를 지정합니다.
$ podman tag registry.redhat.io/<container_image_name>:<tag> <automation_hub_hostname>/<container_image_name>
검증
로컬 스토리지에 이미지를 나열합니다.
$ podman images
- 최근 자동화 허브 정보에 태그된 이미지가 목록에 포함되어 있는지 확인합니다.
5.3. 개인 자동화 허브로 컨테이너 이미지 푸시
태그된 컨테이너 이미지를 프라이빗 자동화 허브로 푸시하여 새 컨테이너를 생성하고 컨테이너 레지스트리를 채울 수 있습니다.
사전 요구 사항
- 새 컨테이너를 생성할 수 있는 권한이 있습니다.
- 자동화 허브 인스턴스의 FQDN 또는 IP 주소가 있습니다.
절차
자동화 허브 위치 및 인증 정보를 사용하여 Podman에 로그인합니다.
$ podman login -u=<username> -p=<password> <automation_hub_url>
컨테이너 이미지를 자동화 허브 컨테이너 레지스트리로 푸시합니다.
$ podman push <automation_hub_url>/<container_image_name>
문제 해결
푸시
작업에서는 업로드 중에 이미지 계층을 다시 압축하여 재현할 수 없으며 클라이언트에 따라 다릅니다. 이로 인해 이미지 계층 다이제스트 변경 및 실패한 푸시 작업으로 이어질 수 있으므로 오류: 이 이미지를 복사하려면 계층 표현이 필요하므로 (이미지가 서명되거나 대상이 다이제스트를 지정)할 수 없습니다
.
검증
- 자동화 허브에 로그인합니다.
- 컨테이너 .
- 컨테이너 리포지토리 목록에서 컨테이너를 찾습니다.
6장. 컨테이너 리포지토리 설정
컨테이너 리포지토리를 설정할 때 설명을 추가하고 README를 포함하고 리포지토리에 액세스할 수 있는 그룹을 추가하고 이미지를 태그해야 합니다.
6.1. 컨테이너 레지스트리를 설정하기 위한 사전 요구 사항
- 프라이빗 자동화 허브에 로그인되어 있습니다.
- 리포지토리를 변경할 수 있는 권한이 있습니다.
6.2. 컨테이너 리포지토리에 README 추가
컨테이너 리포지토리에 README를 추가하여 컨테이너 작업 방법에 대한 지침을 사용자에게 제공합니다. Automation hub 컨테이너 리포지터리는 README를 생성하기 위해 Markdown을 지원합니다. 기본적으로 README는 비어 있습니다.
사전 요구 사항
- 컨테이너를 변경할 수 있는 권한이 있습니다.
절차
- 자동화 허브에 로그인합니다.
- 탐색 패널에서 .
- 컨테이너 리포지토리를 선택합니다.
- 자세한 정보 탭에서 를 클릭합니다.
- Raw Markdown 텍스트 필드에 Markdown에 README 텍스트를 입력합니다.
- 완료되면 을 클릭합니다.
README를 추가한 후
클릭하고 4단계와 5단계를 반복하여 언제든지 편집할 수 있습니다.6.3. 컨테이너 리포지토리에 대한 액세스 권한 제공
이미지를 사용해야 하는 사용자를 위해 컨테이너 리포지토리에 대한 액세스 권한을 제공합니다. 그룹을 추가하면 그룹이 컨테이너 리포지토리에 보유할 수 있는 권한을 수정할 수 있습니다. 이 옵션을 사용하여 그룹이 할당된 내용에 따라 권한을 확장하거나 제한할 수 있습니다.
사전 요구 사항
- 컨테이너 네임스페이스 권한이 변경됩니다.
절차
- 자동화 허브에 로그인합니다.
- 탐색 패널에서 .
- 컨테이너 리포지토리를 선택합니다.
- 액세스 탭에서 클릭합니다.
- 액세스 권한을 부여할 그룹 또는 그룹을 선택하고 클릭합니다.
- 이 실행 환경에 추가할 역할을 선택하고 클릭합니다.
- 를 클릭합니다.
6.4. 컨테이너 이미지 태그 지정
자동화 허브 컨테이너 리포지토리에 저장된 이미지에 추가 이름을 추가하기 위해 이미지에 태그를 지정합니다. 이미지에 태그가 추가되지 않으면 자동화 허브는 기본적으로 이름에 latest
로 설정됩니다.
사전 요구 사항
- 이미지 태그 권한 변경 사항이 있습니다.
절차
- 탐색 패널에서 .
- 컨테이너 리포지토리를 선택합니다.
- 이미지 탭을 클릭합니다.
- 를 클릭하고 클릭합니다. 아이콘 Cryostat
- 텍스트 필드에 새 태그를 를 클릭합니다.
- 선택 사항: 해당 이미지에 대한 태그 중 를 클릭하여 현재 태그를 제거합니다.
- 을 클릭합니다.
검증
- Activity 탭을 클릭하고 최신 변경 사항을 검토합니다.
6.5. 자동화 컨트롤러에서 인증 정보 생성
암호 또는 토큰 보호 레지스트리에서 컨테이너 이미지를 가져오려면 자동화 컨트롤러에 인증 정보를 생성해야 합니다.
이전 버전의 Ansible Automation Platform에서는 실행 환경 이미지를 저장하기 위해 레지스트리를 배포해야 했습니다. Ansible Automation Platform 2.0 이상에서는 이미 컨테이너 레지스트리가 실행 중인 것처럼 시스템이 작동합니다. 실행 환경 이미지를 저장하려면 선택한 컨테이너 레지스트리의 인증 정보만 추가합니다.
절차
- 자동화 컨트롤러로 이동합니다.
- 탐색 패널에서 선택합니다.
- 를 클릭하여 새 자격 증명을 생성합니다.
- 권한 부여 이름, 설명, 조직을 입력합니다.
- 자격 증명 유형을 선택합니다.
- 인증 URL 을 입력합니다. 이는 컨테이너 레지스트리 주소입니다.
- 컨테이너 레지스트리에 로그인하는 데 필요한 사용자 이름 및 암호 또는 토큰 을 입력합니다.
- 선택 사항: SSL 확인을 활성화하려면 SSL 확인을 선택합니다.
- 을 클릭합니다.
7장. 컨테이너 리포지토리에서 이미지 가져오기
자동화 허브 컨테이너 레지스트리에서 이미지를 가져와 로컬 시스템에 복사합니다. 자동화 허브는 컨테이너 리포지토리의 각 최신
이미지에 대해 podman pull
명령을 제공합니다. 이 명령을 복사하여 터미널에 붙여넣거나 podman pull
을 사용하여 이미지 태그를 기반으로 이미지를 복사할 수 있습니다.
7.1. 이미지 가져오기
자동화 허브 컨테이너 레지스트리에서 이미지를 가져와 로컬 시스템에 복사할 수 있습니다.
사전 요구 사항
- 개인 컨테이너 리포지토리에서 보고 가져올 수 있는 권한이 있어야 합니다.
절차
- 암호 또는 토큰 보호 레지스트리에서 컨테이너 이미지를 가져오는 경우 이미지를 가져오기 전에 자동화 컨트롤러에 인증 정보를 생성합니다.
- 탐색 패널에서 .
- 컨테이너 리포지토리를 선택합니다.
- Pull this image 항목에서 를 클릭합니다.
- 터미널에서 명령을 붙여넣고 실행합니다.
검증
-
podman 이미지를
실행하여 로컬 시스템의 이미지를 봅니다.
7.2. 컨테이너 리포지토리에서 이미지 동기화
자동화 허브 컨테이너 레지스트리에서 이미지를 가져와서 이미지를 로컬 머신에 동기화할 수 있습니다. 원격 컨테이너 레지스트리에서 이미지를 동기화하려면 먼저 원격 레지스트리를 구성해야 합니다.
사전 요구 사항
개인 컨테이너 리포지토리에서 보고 가져올 수 있는 권한이 있어야 합니다.
절차
- 탐색 패널에서 .
- 레지스트리에 https://registry.redhat.io 를 추가합니다.
인증에 필요한 인증 정보를 추가합니다.
참고일부 컨테이너 레지스트리는 속도 제한으로 공격적입니다. Advanced Options 에서 유량 제한을 설정합니다.
- 탐색 패널에서 .
- 페이지 헤더에서 를 클릭합니다.
가져올 레지스트리를 선택합니다. 이름 필드에는 로컬 레지스트리에 표시되는 이미지의 이름이 표시됩니다.
참고Upstream 이름 필드는 원격 서버의 이미지 이름입니다. 예를 들어 업스트림 이름이 "alpine"로 설정되고 Name 필드가 "local/alpine"인 경우 alpine 이미지가 원격에서 다운로드되고 "local/alpine"로 이름이 변경됩니다.
- 포함하거나 제외할 태그 목록을 설정합니다. 많은 수의 태그와 이미지를 동기화하는 것은 시간이 많이 소요되며 많은 디스크 공간을 사용합니다.
추가 리소스
- 레지스트리 목록은 Red Hat Container Registry Authentication 을 참조하십시오.
- 이미지를 가져올 때 사용할 옵션은 What is Podman? 설명서를 참조하십시오.
부록 A. 자동화 실행 환경 우선 순위
프로젝트 업데이트는 기본적으로 컨트롤 플레인 자동화 실행 환경을 사용하지만 작업은 다음과 같이 사용 가능한 첫 번째 자동화 실행 환경을 사용합니다.
-
작업을 생성한 템플릿에 정의된
execution_environment
(작업 템플릿 또는 인벤토리 소스)입니다. -
작업에서 사용하는 프로젝트에 정의된
default_environment
입니다. -
작업 조직에 정의된
default_environment
입니다. -
작업에서 사용하는 인벤토리 조직에 정의된
default_environment
입니다. -
현재
DEFAULT_EXECUTION_ENVIRONMENT
설정(api/v2/settings/jobs/
에서 설정 가능) -
GLOBAL_JOB_EXECUTION_ENVIRONMENTS
설정의 모든 이미지입니다. - 기타 모든 글로벌 실행 환경
둘 이상의 실행 환경이 기준에 맞는 경우(6 및 7에 적용) 가장 최근에 생성된 실행 환경이 사용됩니다.