Ansible 빌더 가이드

Red Hat Ansible Automation Platform 2.1

실행 환경 빌더를 통해 Red Hat Ansible Automation Platform에 대한 일관되고 재현 가능한 자동화 실행 환경을 생성합니다.

Red Hat Customer Content Services

초록

피드백 제공:
이 문서를 개선하기 위한 제안이 있거나 오류를 발견한 경우, Docs 구성 요소를 사용하여 Ansible Automation Platform Jira 프로젝트에서 문제를 생성하기 위해 기술 지원에 문의하십시오 https://access.redhat.com.

머리말

Ansible Builder를 사용하여 Red Hat Ansible Automation Platform 요구 사항에 맞는 일관되고 재현 가능한 자동화 실행 환경을 생성합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. Ansible 빌더 소개

1.1. Ansible 빌더 정보

Ansible Builder는 사용자가 다양한 Ansible 컬렉션에 정의된 메타데이터를 사용하여 자동화 실행 환경을 빌드하는 프로세스를 자동화하는 명령줄 툴입니다.

1.1.1. Ansible Builder를 사용하는 이유는 무엇입니까?

Ansible Builder가 개발되기 전에 Automation Platform 사용자는 필요한 모든 종속 항목이 설치된 사용자 정의 가상 환경 또는 컨테이너를 만들려고 하면 종속성 문제 및 여러 오류 메시지에 대해 잠재적으로 실행될 수 있었습니다.

Ansible Builder는 쉽게 사용자 지정할 수 있는 정의 파일을 사용하여 Ansible, 지정된 컬렉션 및 해당 종속 항목을 설치하여 작업을 실행하는 데 필요한 모든 요구 사항이 백그라운드에서 충족되도록 합니다.

2장. Ansible 빌더 사용

2.1. Ansible 빌더 설치

RHSM(Red Hat Subscription Management)을 사용하여 Ansible Builder를 설치하여 Red Hat Ansible Automation Platform 서브스크립션을 연결할 수 있습니다. Red Hat Ansible Automation Platform 서브스크립션을 연결하면 ansible-builder 를 설치하는 데 필요한 서브스크립션 전용 리소스에 액세스할 수 있습니다. 서브스크립션을 연결하면 ansible-builder 에 필요한 리포지토리가 자동으로 활성화됩니다.

참고

ansible-builder 를 설치하기 전에 호스트에 유효한 서브스크립션이 연결되어 있어야 합니다.

절차

  1. 터미널에서 다음 명령을 실행하여 Ansible Automation Platform 리포지터리를 활성화합니다. 

    $ dnf config-manager --enable ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms

  2. 다음 명령을 입력하여 Ansible Builder를 설치합니다. 

    $ dnf install ansible-builder

2.2. 정의 파일 빌드

Ansible Builder가 설치되면 Ansible Builder가 자동화 실행 환경 이미지를 생성하는 데 사용할 정의 파일을 생성해야 합니다. 자동화 실행 환경 이미지를 빌드하는 상위 수준 프로세스는 Ansible Builder에서 정의 파일을 읽고 검증한 다음 Containerfile 을 Podman에 생성한 다음, 자동화 실행 환경 이미지를 패키징하고 생성하는 것입니다. Ansible Builder에 대해 생성할 정의 파일은 yaml 형식이며 이에 대해 자세히 설명하는 다양한 섹션이 포함되어 있습니다.

다음은 정의 파일의 예입니다.

예 2.1. 정의 파일

version: 1

build_arg_defaults: 1
  ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "-v"

ansible_config: 'ansible.cfg' 2

dependencies: 3
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt

additional_build_steps: 4
  prepend: |
    RUN whoami
    RUN cat /etc/os-release
  append:
    - RUN echo This is a post-install command!
    - RUN ls -la /etc
1
빌드 인수의 기본값 나열
2
ansible.cfg 파일 경로를 지정합니다.
3
다양한 요구 사항 파일의 위치를 지정합니다.
4
추가 사용자 정의 빌드 단계를 위한 명령

이러한 정의 파일 매개변수에 대한 자세한 내용은 이 섹션을 참조하십시오.

2.3. 빌드 실행 및 명령 생성

사전 요구 사항

  • 정의 파일을 생성했습니다.

절차

자동화 실행 환경 이미지를 빌드하려면 다음을 실행합니다. 

$ ansible-builder build

기본적으로 Ansible Builder는 execution-environment.yml 이라는 정의 파일을 검색하지만 -f 플래그를 통해 다른 파일 경로를 인수로 지정할 수 있습니다. 

$ ansible-builder build -f definition-file-name.yml

여기서 definition-file-name 은 정의 파일의 이름을 지정합니다.

2.4. 정의 파일 콘텐츠 분석

Ansible Builder를 사용하여 자동화 실행 환경을 빌드하는 데 정의 파일은 자동화 실행 환경 컨테이너 이미지에 포함될 콘텐츠를 지정하므로 필요합니다.

다음 섹션에서는 정의 파일의 다른 부분을 나눕니다.

2.4.1. 인수 및 기본 이미지 빌드

정의 파일의 build_arg_defaults 섹션은 키가 Ansible 빌더에 인수의 기본값을 제공할 수 있는 사전입니다. build_arg_defaults 에 사용할 수 있는 값 목록은 다음 표를 참조하십시오.

현재의설명

ANSIBLE_GALAXY_CLI_COLLECTION_OPTS

  • 사용자가 -pre 플래그를 전달하여 사전 릴리스 컬렉션을 설치할 수 있습니다.
  • -c 는 verify_ssl 을 false로 설정하는 것과 동일합니다.

EE_BASE_IMAGE

자동화 실행 환경의 상위 이미지를 지정하여 기존 이미지를 기반으로 새 이미지를 빌드할 수 있습니다.

EE_BUILDER_IMAGE

컴파일 유형 작업에 사용되는 이미지를 지정합니다.

build_arg_defaults 내에 지정된 값은 Containerfile 로 하드 코딩되므로 podman build 를 수동으로 호출하면 이러한 값이 유지됩니다.

참고

CLI --build-arg 플래그에 동일한 변수가 지정되면 CLI 값이 우선 순위가 높습니다.

2.4.2. Ansible 구성 파일 경로

ansible.cfg 파일을 사용하여 개인 계정의 토큰 및 기타 설정을 자동화 허브 서버에 전달하는 경우 구성 파일 경로( 정의 파일이 있는 위치)를 문자열로 나열하여 빌드 초기 단계에서 빌드 인수로 활성화합니다.

ansible.cfg 파일은 다음 예와 같이 포맷해야 합니다.

예 2.2. ansible.cfg 파일

[galaxy]
server_list = automation_hub

[galaxy_server.automation_hub]
url=https://cloud.redhat.com/api/automation-hub/
auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
token=my_ah_token

자동화 허브에서 컬렉션을 다운로드하는 방법에 대한 자세한 내용은 관련 Ansible 설명서 페이지를 참조하십시오.

2.4.3. 종속 항목

2.4.3.1. Galaxy

gal xxx y 항목은 ansible-galxxxy 컬렉션 install -r …​ 명령에 대해 유효한 요구 사항 파일을 가리킵니다.

항목 requirements.yml 은 자동화 실행 환경 정의 폴더의 디렉터리 또는 절대 경로의 상대 경로일 수 있습니다.

requirements.yml 파일의 내용은 다음과 같을 수 있습니다.

예 2.3. Galaxy에 대한 requirements.yml 파일

collections:
  - geerlingguy.java
  - kubernetes.core

2.4.3.2. Python

정의 파일의 python 항목은 pip install -r …​ 명령에 대해 유효한 요구 사항 파일을 가리킵니다.

항목 requirements.txt 는 컬렉션에서 이미 Python 종속 항목으로 나열하는 추가 Python 요구 사항을 설치하는 파일입니다. 자동화 실행 환경 정의 폴더의 디렉터리에서 상대 경로 또는 절대 경로로 나열될 수 있습니다. requirements.txt 파일의 내용은 pip freeze 명령의 표준 출력과 유사하게 다음 예와 같이 포맷해야 합니다.

예 2.4. Python용 requirements.txt 파일

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
python_version >= '2.7'
collection community.vmware
google-auth
openshift>=0.6.2
requests-oauthlib
openstacksdk>=0.13
ovirt-engine-sdk-python>=4.4.10

2.4.3.3. 시스템

정의의 시스템 항목은 bindep 요구 사항 파일을 가리키며, 이 파일은 컬렉션이 이미 종속 항목으로 포함된 시스템 수준 종속 항목을 설치합니다. 자동화 실행 환경 정의 폴더의 디렉터리에서 상대 경로 또는 절대 경로로 나열될 수 있습니다.

이를 설명하기 위해 다음은 libxml2 및 하위 버전 패키지를 컨테이너에 추가하는 bindep.txt 파일의 예입니다.

예 2.5. bindep.txt 파일

libxml2-devel [platform:rpm]
subversion [platform:rpm]

2.4.4. 추가적인 사용자 지정 빌드 단계

additional_build_steps 섹션에 prepend 및 append 명령을 지정할 수 있습니다. 이러한 명령은 기본 빌드 단계가 실행되기 전 또는 후에 실행될 Containerfile 에 명령을 추가합니다.

additional_build_steps 의 구문은 다음 중 하나여야 합니다.

  • 여러 줄 문자열

    예 2.6. 여러 줄 문자열 항목

    RUN whoami
RUN cat /etc/os-release

  • 공지 사항

    예 2.7. 목록 항목

    - RUN echo This is a post-install command!
- RUN ls -la /etc

2.5. 선택적 빌드 명령 인수

-t 플래그는 자동화 실행 환경 이미지에 특정 이름을 지정합니다. 예를 들어 다음 명령은 my_first_ee_image 이미지를 빌드합니다. 

$ ansible-builder build -t my_first_ee_image

여러 정의 파일이 있는 경우 -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 라는 자동화 실행 환경 이미지를 빌드합니다.

build 명령과 함께 사용할 수 있는 다른 사양 및 플래그의 경우 ansible-builder build --help 를 입력하여 추가 옵션 목록을 확인합니다.

2.6. 이미지를 빌드하지 않고 컨테이너 파일 생성

이미지를 빌드하지 않고 공유 가능한 컨테이너 파일을 생성하려면 다음을 실행합니다. 

$ ansible-builder create

3장. 자동화 실행 환경 게시

3.1. 실행 환경 컨테이너 이미지를 자동화 허브로 푸시

사전 요구 사항

  • 자동화 허브에서 실행 환경 권한이 있으므로 새 컨테이너를 만들거나 기존 컨테이너로 내보낼 수 있습니다.

컨테이너 레지스트리는 컨테이너 이미지를 저장하기 위한 리포지토리입니다. 자동화 실행 환경 이미지를 빌드하면 자동화 허브 인스턴스의 레지스트리 부분으로 해당 컨테이너 이미지를 푸시할 준비가 된 것입니다.

자동화 허브 URL을 사용하여 다음 명령을 실행하여 Podman에 로그인하여 사용자 이름, 암호 및 자동화 허브 URL을 대체합니다. 

$ podman login -u=username -p=password automation-hub-url

Podman에 로그인한 후 다음 명령을 실행하여 컨테이너 이미지를 자동화 허브의 컨테이너 레지스트리로 내보냅니다. 

$ podman push automation-hub-url/ee-image-name
참고

자동화 실행 환경 이미지 이름은 ansible-builder 빌드 명령에 - t 인수로 지정합니다. -t 플래그를 사용하여 사용자 정의 이미지 이름을 지정하지 않은 경우 기본 이미지 태그는 ansible-execution-env:latest 입니다.

3.2. 보호되는 레지스트리에서 가져오기

암호 또는 토큰 보호 레지스트리에서 컨테이너 이미지를 가져오려면 자동화 컨트롤러에서 인증 정보를 생성합니다.

절차

  1. 자동화 컨트롤러로 이동합니다.
  2. 사이드 메뉴 표시줄에서 리소스 → 자격 증명을 클릭합니다.
  3. 추가 를 클릭하여 새 자격 증명을 생성합니다.
  4. 권한 부여 URL, 사용자 이름, 암호를 제공합니다. 저장을 클릭합니다.

자세한 내용은 실행 환경 설명서의 Protected Registries에서 Pulling 섹션을 참조하십시오.

4장. Red Hat Ansible Automation Platform에서 제공하는 기존 기본 EE 빌드

4.1. 시스템 수준 종속 항목 수집

bindep 형식을 사용하면 플랫폼 간 요구 사항을 지정할 수 있습니다. 최소 기대치는 컬렉션이 [platform:rpm] 에 필요한 요구 사항을 지정하는 것입니다.

다음은 유효한 bindep.txt 파일의 예입니다.

예 4.1. bindep.txt 파일

python38-devel [platform:rpm compile]
subversion [platform:rpm]
git-lfs [platform:rpm]

여러 컬렉션의 항목은 단일 파일로 결합됩니다. 이 작업은 bindep 에 의해 처리되고 dnf 로 전달됩니다. 프로파일이 없거나 런타임 요구 사항이 없는 요구 사항만 이미지에 설치됩니다.

4.2. 기존 실행 환경 이미지 사용자 정의

Ansible Controller는 세 가지 기본 실행 환경과 함께 제공됩니다.

  • Ansible 2.9 - 컨트롤러 모듈 이외의 컬렉션도 설치되지 않습니다.
  • minimal - Ansible Runner와 함께 최신 Ansible 2.12 릴리스가 포함되어 있지만 컬렉션이나 기타 추가 콘텐츠가 포함되어 있지 않습니다.
  • EE 지원 - 모든 Red Hat 지원 컨텐츠 포함

이러한 환경은 많은 자동화 사용 사례를 다루지만 추가 항목을 추가하여 특정 요구에 맞게 이러한 컨테이너를 사용자 지정할 수 있습니다. 다음 절차에서는 kubernetes.core 컬렉션을 ee-minimal 기본 이미지에 추가합니다.

절차

  1. Podman을 통해 registry.redhat.io 에 로그인합니다. 

    $ podman login -u="[username]" -p="[token/hash]" registry.redhat.io

  2. 자동화 실행 환경 이미지 가져오기 

    podman pull registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:latest

  3. ee-minimal 을 기반으로 하는 새 실행 환경 이미지에 추가할 추가 콘텐츠를 지정하도록 Ansible Builder 파일을 구성합니다.

    1. 예를 들어 Galaxy의 Kubernetes Core Collection 을 이미지에 추가하려면 requirements.yml 파일을 다음과 같이 작성합니다. 

      collections:
  - kubernetes.core
    2. 정의 파일 및 콘텐츠에 대한 자세한 내용은 정의 파일 분석 섹션을 참조하십시오.

  4. 실행 환경 정의 파일에서 EE_BASE_IMAGE 필드의 원래 ee-minimal 컨테이너에 대한 filepath를 지정합니다. 이렇게 하면 최종 execution-environment.yml 파일이 다음과 같이 표시됩니다.

    예 4.2. 사용자 정의된 execution-environment.yml 파일

    version: 1

build_arg_defaults:
  EE_BASE_IMAGE: 'example.registry.com/my-base-ee'

dependencies:
  galaxy: requirements.yml
    참고

    이 예제에서는 자동화 허브의 인증된 컬렉션이 아닌 kubernetes.core 커뮤니티 버전을 사용하므로 정의 파일에서 ansible.cfg 또는 참조를 생성할 필요가 없습니다.

  5. 다음 명령을 사용하여 새 실행 환경 이미지를 빌드합니다. 

    $ ansible-builder build -t registry.redhat.io/[username]/new-ee

    여기서 [username] 은 사용자 이름을 지정하고 new-ee 는 새 컨테이너 이미지의 이름을 지정합니다.

    1. podman images 명령을 사용하여 새 컨테이너 이미지가 해당 목록에 있는지 확인합니다.

      예 4.3. 이미지 new-ee를 사용한 podman images 명령 출력

      REPOSITORY          TAG     IMAGE ID      CREATED        SIZE
localhost/new-ee    latest  f5509587efbb  3 minutes ago  769 MB
  6. Ansible Navigator를 통해 새로 생성된 실행 환경 이미지를 확인합니다.

  7. 자동화 허브에 사용할 이미지를 태그합니다. 

    $ podman tag registry.redhat.io/_[username]_/_new-ee_ [automation-hub-IP-address]/_[username]_/_new-ee_

  8. Podman을 사용하여 자동화 허브에 로그인합니다.

    참고

    자동화 허브가 컨테이너를 푸시하려면 관리자 또는 적절한 컨테이너 리포지토리 권한이 있어야 합니다. 자세한 내용은 Red Hat Ansible Automation Platform 설명서 의 프라이빗 자동화 허브에서 컨테이너 관리를 참조하십시오. 

    $ podman login -u="[username]" -p="[token/hash]" [automation-hub-IP-address]

  9. 자동화 허브에서 컨테이너 레지스트리로 이미지를 푸시합니다. 

    $ podman push [automation-hub-IP-address]/_[username]_/_new-ee_

  10. 새 이미지를 자동화 컨트롤러 인스턴스로 가져옵니다.

    1. 자동화 컨트롤러로 이동합니다.
    2. 사이드-navig#188 표시줄에서 Administration → Execution Environments 를 클릭합니다.
    3. 추가 를 클릭합니다.

    4. 적절한 정보를 입력한 다음 저장 을 클릭하여 새 이미지를 가져옵니다.

      참고

      자동화 허브 인스턴스가 암호 또는 토큰으로 보호되는 경우 적절한 컨테이너 레지스트리 인증 정보를 설정해야 합니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.