실행 환경 생성 및 사용

Red Hat Ansible Automation Platform 2.4

Ansible Builder에서 실행 환경 생성 및 사용

Red Hat Customer Content Services

초록

이 가이드에서는 Red Hat Ansible Automation Platform을 위한 일관되고 재현 가능한 자동화 실행 환경을 생성하는 방법을 보여줍니다.

머리말

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

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

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

Red Hat 문서에 관한 피드백 제공

Red Hat의 기술 콘텐츠에 대한 귀하의 피드백에 감사드리며, 귀하가 생각하는 것을 알려 주시기 바랍니다. 주석을 추가하거나, 인사이트를 제공하거나, 오타를 수정하거나, 질문을 하려면 문서에서 직접 이 작업을 수행할 수 있습니다.

참고

Red Hat 계정이 있어야 하며 고객 포털에 로그인해야 합니다.

고객 포털에서 문서 피드백을 제출하려면 다음을 수행하십시오.

  1. 다중 페이지 HTML 형식을 선택합니다.
  2. 문서 오른쪽 상단에 있는 피드백 버튼을 클릭합니다.
  3. 피드백을 제공하려는 텍스트 섹션을 강조 표시합니다.
  4. 강조 표시된 텍스트 옆에 있는 피드백 추가 대화 상자를 클릭합니다.
  5. 페이지 오른쪽에 있는 텍스트 상자에 피드백을 입력한 다음 제출을 클릭합니다.

피드백을 제출할 때마다 추적 문제가 자동으로 생성됩니다. Submit 을 클릭한 후 표시되는 링크를 열고 문제 모니터링을 시작하거나 의견을 더 추가합니다.

1장. 자동화 실행 환경 소개

패키지를 각 노드에 설치하고 호스트 시스템에 설치된 다른 소프트웨어와 상호 작용하고 동기화 상태를 유지해야 하기 때문에 기본이 아닌 종속 항목에 의존하는 Ansible 콘텐츠를 사용하는 것이 복잡할 수 있습니다.

자동화 실행 환경은 이 프로세스를 단순화하는 데 도움이 되며 Ansible Builder를 사용하여 쉽게 생성할 수 있습니다.

1.1. 자동화 실행 환경 정보

자동화 실행 환경은 Red Hat Ansible Automation Platform의 모든 자동화가 실행되는 컨테이너 이미지입니다. 자동화 실행 환경은 자동화 종속 항목을 전달하는 공통 언어를 생성하고 자동화 환경을 빌드하고 배포하는 표준 방법을 제공합니다.

자동화 실행 환경에는 다음이 포함되어야 합니다.

  • Ansible 2.9 또는 Ansible Core 2.11-2.13
  • Python 3.8-3.10
  • Ansible Runner
  • Ansible 콘텐츠 컬렉션
  • 컬렉션, Python 또는 시스템 종속 항목

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를 사용하면, 컬렉션, 요구 사항 및 시스템 수준 패키지와 같은 자동화 실행 환경에 포함된 콘텐츠를 지정하는 사용자 지정 가능한 자동화 실행 환경 정의 파일을 쉽게 생성할 수 있습니다. 이를 통해 필요한 모든 요구 사항과 종속 항목을 충족하여 작업을 실행할 수 있습니다.

2.2. 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 install --enablerepo=ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms ansible-builder

2.3. 정의 파일 빌드

Ansible Builder가 설치되면 Ansible Builder에서 자동화 실행 환경 이미지를 생성하는 데 사용하는 정의 파일을 생성할 수 있습니다. 자동화 실행 환경 이미지를 빌드하는 상위 수준 프로세스는 Ansible Builder에서 정의 파일을 읽고 검증한 다음 Containerfile 을 Podman에 생성한 다음, 자동화 실행 환경 이미지를 패키징하고 생성하는 것입니다. 생성된 정의 파일은 yaml 형식이며 다른 섹션이 포함되어 있습니다. 정의 파일 콘텐츠에 대한 자세한 내용은 정의 파일 내용 중단 참조하십시오.

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

예 2.1. 정의 파일

version: 1

build_arg_defaults: 1
  ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "-v"

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

additional_build_steps: 3
  prepend: |
    RUN whoami
    RUN cat /etc/os-release
  append:
    - RUN echo This is a post-install command!
    - RUN ls -la /etc
1
빌드 인수의 기본값 나열
2
다양한 요구 사항 파일의 위치를 지정합니다.
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_GALAXY_CLI_COLLECTION_OPTS

사용자는 컬렉션 설치 단계에서 임의의 인수를 ansible-galvncy CLI에 전달할 수 있습니다. 예를 들어 사전 릴리스 컬렉션을 설치할 수 있는 -pre 플래그 또는 -c는 서버의 SSL 인증서 확인을 비활성화합니다.

EE_BASE_IMAGE

자동화 실행 환경의 상위 이미지를 지정하여 기존 이미지를 기반으로 새 이미지를 빌드할 수 있습니다. 일반적으로 ee-minimal 또는 ee-supported과 같이 지원되는 실행 환경 기본 이미지이지만 이전에 생성한 실행 환경 이미지일 수도 있으며 추가로 사용자 지정할 수도 있습니다.

기본 이미지는 registry.redhat.io/ansible-automation-platform-23/ee-minimal-rhel8:latest 입니다.

EE_BUILDER_IMAGE

Python 종속성 컬렉션 및 컴파일에 사용되는 중간 빌더 이미지를 지정합니다. EE_BASE_IMAGE 와 일치하는 Python 버전을 포함해야 하며 ansible-builder가 설치되어 있어야 합니다.

기본 이미지는 registry.redhat.io/ansible-automation-platform-23/ansible-builder-rhel8:latest 입니다.

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

참고

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

2.5.2. Ansible 구성 파일 경로

ansible_config 지시문을 사용하면 빌드의 Collection 설치 단계에서 개인 계정의 토큰 및 기타 설정을 자동화 허브 서버에 전달할 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.5.3. 종속 항목

자동화 실행 환경 이미지에 대한 문제를 방지하려면 Galaxy, Python 및 시스템 항목이 유효한 요구 사항 파일을 가리키는지 확인하십시오.

2.5.3.1. Galaxy

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

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

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

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

collections:
  - community.aws
  - kubernetes.core

2.5.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.5.3.3. 시스템

정의의 시스템 항목은 bindep 요구 사항 파일을 가리키며, 이 파일은 컬렉션이 이미 종속 항목으로 포함된 시스템 수준 종속 항목을 설치합니다. 자동화 실행 환경 정의 폴더의 디렉터리에서 상대 경로 또는 절대 경로로 나열할 수 있습니다. 최소 기대치는 컬렉션이 [platform:rpm] 에 필요한 요구 사항을 지정하는 것입니다.

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

예 2.5. bindep.txt 파일

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

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

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

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

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

  • 여러 줄 문자열

    예 2.6. 여러 줄 문자열 항목

    prepend: |
       RUN whoami
       RUN cat /etc/os-release
  • 공지 사항

    예 2.7. 목록 항목

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

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 라는 자동화 실행 환경 이미지를 빌드합니다.

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

2.7. Containerfile

정의 파일이 생성되면 Ansible Builder에서 읽고 검증한 다음 Containerfile 을 Podman에 전달하고 마지막으로 다음 지침을 사용하여 자동화 실행 환경 이미지를 생성합니다.

  1. 기본 이미지 가져오기
  2. 기본 이미지의 임시 사본에서 컬렉션이 다운로드되고 선언된 Python 및 시스템 종속 항목 목록(있는 경우)은 나중에 수집됩니다.
  3. 임시 빌더 이미지에서 정의 파일에 나열된 모든 Python 종속성에 대한 Python 문제 해결은 정의 파일에 나열된 컬렉션에서 선언한 모든 Python 종속성을 포함하여(필요한 대로) 다운로드 및 빌드됩니다.
  4. 정의 파일에서 additional_build_steps 전이 실행됩니다.
  5. 최종 자동화 실행 환경 이미지에서 정의 파일에 나열된 모든 시스템 종속성을 포함하여 정의 파일에 나열된 시스템 종속성이 설치됩니다.
  6. 최종 자동화 실행 환경 이미지에서 다운로드한 컬렉션은 복사되고 이전에 가져온 Python 종속성이 설치됩니다.
  7. 정의 파일에서 additional_build_steps에 대한 지원이 실행됩니다.

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

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

$ ansible-builder create

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

3.1. 기존 자동화 실행 환경 이미지 사용자 정의

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

  • Ansible 2.9 - 컨트롤러 모듈 이외의 컬렉션도 설치되지 않습니다.
  • minimal - Ansible Runner와 함께 최신 Ansible 2.13 릴리스가 포함되어 있지만 컬렉션이나 기타 추가 콘텐츠가 포함되어 있지 않습니다.
  • 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-22/ee-minimal-rhel8:latest
  3. 원하는 기본 이미지와 새 실행 환경 이미지에 추가할 추가 콘텐츠를 지정하도록 Ansible Builder 파일을 구성합니다.

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

      collections:
        - kubernetes.core
    2. 정의 파일 및 콘텐츠에 대한 자세한 내용은 정의 파일 분석 섹션을 참조하십시오.
  4. 실행 환경 정의 파일에서 원래 ee-minimal 컨테이너의 URL과 EE_BASE_IMAGE 필드에 태그를 지정합니다. 이렇게 하면 최종 execution-environment.yml 파일이 다음과 같이 표시됩니다.

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

    version: 1
    
    build_arg_defaults:
      EE_BASE_IMAGE: 'registry.redhat.io/ansible-automation-platform-22/ee-minimal-rhel8:latest'
    
    dependencies:
      galaxy: requirements.yml
    참고

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

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

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

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

참고

빌드에 -t 를 사용하지 않는 경우 ansible-execution-env 라는 이미지가 생성되어 로컬 컨테이너 레지스트리에 로드됩니다.

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

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

    REPOSITORY          TAG     IMAGE ID      CREATED        SIZE
    localhost/new-ee    latest  f5509587efbb  3 minutes ago  769 MB
    1. 컬렉션이 설치되었는지 확인합니다.

      $ podman run registry.redhat.io/[username]/new-ee ansible-doc -l kubernetes.core
    2. 자동화 허브에 사용할 이미지를 태그합니다.

      $ podman tag registry.redhat.io/[username]/new-ee [automation-hub-IP-address]/[username]/new-ee
    3. Podman을 사용하여 자동화 허브에 로그인합니다.

      참고

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

      $ podman login -u="[username]" -p="[token/hash]" [automation-hub-IP-address]
    4. 자동화 허브에서 컨테이너 레지스트리로 이미지를 푸시합니다.

      $ podman push [automation-hub-IP-address]/[username]/new-ee
    5. 새 이미지를 자동화 컨트롤러 인스턴스로 가져옵니다.
  2. 자동화 컨트롤러로 이동합니다.
  3. 사이드-navig#188 표시줄에서 AdministrationExecution Environments 를 클릭합니다.
  4. 추가 를 클릭합니다.
  5. 적절한 정보를 입력한 다음 저장 을 클릭하여 새 이미지를 가져옵니다.

    참고

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

4장. 프라이빗 자동화 허브 컨테이너 레지스트리 채우기

기본적으로 프라이빗 자동화 허브에는 컨테이너 이미지가 포함되어 있지 않습니다. 컨테이너 레지스트리를 채우려면 컨테이너 이미지를 푸시해야 합니다. 이 섹션의 절차에서는 Red Hat Ecosystem Catalog(registry.redhat.io)에서 이미지를 가져오고 태그를 지정한 후 프라이빗 자동화 허브 컨테이너 레지스트리로 푸시하는 방법을 설명합니다.

중요

이미지 매니페스트 및 파일 시스템 Blob은 registry.redhat.ioregistry.access.redhat.com 에서 직접 제공됩니다. 그러나 2023년 5월 1일부터 파일 시스템 Blob은 quay.io 에서 대신 제공됩니다. 컨테이너 이미지를 가져오는 데 문제가 발생하지 않도록 하려면 다음 호스트 이름에 대한 아웃바운드 연결을 활성화해야 합니다.

  • cdn.quay.io
  • cdn01.quay.io
  • cdn02.quay.io
  • cdn03.quay.io

registry.redhat.io 또는 registry.access.redhat.com 에 대한 아웃바운드 연결을 가능하게 하는 방화벽 구성에 대해 이 변경을 수행해야 합니다.

방화벽 규칙을 구성할 때 IP 주소 대신 호스트 이름을 사용합니다.

이러한 변경을 수행한 후 registry.redhat.ioregistry.access.redhat.com 에서 이미지를 계속 가져올 수 있습니다. quay.io 로그인이 필요하지 않거나 Red Hat 컨테이너 이미지를 계속 가져오려면 quay.io 레지스트리와 직접 상호 작용해야 합니다.

4.1. 사전 요구 사항

  • 새 컨테이너를 만들고 컨테이너를 프라이빗 자동화 허브로 푸시할 수 있는 권한이 있습니다.

4.2. 자동화 허브에 사용할 이미지 가져오기

컨테이너 이미지를 프라이빗 자동화 허브로 푸시하려면 먼저 기존 레지스트리에서 해당 이미지를 가져와서 사용할 태그를 지정해야 합니다. 이 예에서는 Red Hat Ecosystem Catalog(registry.redhat.io)에서 이미지를 가져오는 방법을 자세히 설명합니다.

사전 요구 사항

registry.redhat.io에서 이미지를 가져올 수 있는 권한이 있습니다.

절차

  1. registry.redhat.io 인증 정보를 사용하여 Podman에 로그인합니다.

    $ podman login registry.redhat.io
  2. 프롬프트에 사용자 이름과 암호를 입력합니다.
  3. 컨테이너 이미지를 가져옵니다.

    $ podman pull registry.redhat.io/<container_image_name>:<tag>

검증

  1. 로컬 스토리지에 이미지를 나열합니다.

    $ podman images
  2. 최근에 가져온 이미지가 목록에 포함되어 있는지 확인합니다.
  3. 태그가 올바른지 확인합니다.

추가 리소스

4.3. 자동화 허브에 사용할 이미지 태그

레지스트리에서 이미지를 가져온 후 프라이빗 자동화 허브 컨테이너 레지스트리에 사용하도록 태그를 지정합니다.

사전 요구 사항

  • 외부 레지스트리에서 컨테이너 이미지를 가져왔습니다.
  • 자동화 허브 인스턴스의 FQDN 또는 IP 주소가 있습니다.

절차

  • 자동화 허브 컨테이너 리포지터리를 사용하여 로컬 이미지에 태그 지정

    $ podman tag registry.redhat.io/<container_image_name>:<tag> <automation_hub_URL>/<container_image_name>

검증

  1. 로컬 스토리지에 이미지를 나열합니다.

    $ podman images
  2. 최근 자동화 허브 정보에 태그된 이미지가 목록에 포함되어 있는지 확인합니다.

4.4. 개인 자동화 허브로 컨테이너 이미지 푸시

태그된 컨테이너 이미지를 프라이빗 자동화 허브로 푸시하여 새 컨테이너를 생성하고 컨테이너 레지스트리를 채울 수 있습니다.

사전 요구 사항

  • 새 컨테이너를 생성할 수 있는 권한이 있습니다.
  • 자동화 허브 인스턴스의 FQDN 또는 IP 주소가 있습니다.

절차

  1. 자동화 허브 위치 및 인증 정보를 사용하여 Podman에 로그인합니다.

    $ podman login -u=<username> -p=<password> <automation_hub_url>
  2. 컨테이너 이미지를 자동화 허브 컨테이너 레지스트리로 푸시합니다.

    $ podman push <automation_hub_url>/<container_image_name>
    참고

    registry.redhat.io에서 자동화 허브 컨테이너 레지스트리로 서명된 이미지를 푸시하는 경우 --remove-signatures 플래그가 필요합니다. 푸시 작업은 업로드 중에 이미지 계층을 다시 압축합니다. 이는 재현할 수 없으며 클라이언트 구현에 따라 다릅니다. 이로 인해 이미지 계층 다이제스트 변경 및 실패한 푸시 작업으로 이어질 수 있습니다. 오류가 발생할 수 있습니다. 이 이미지를 복사하려면 계층 표현을 변경해야 합니다(이미지는 서명되거나 대상이 다이제스트를 지정함 ).

검증

  1. 자동화 허브에 로그인합니다.
  2. 컨테이너 레지스트리로 이동합니다.
  3. 컨테이너 리포지토리 목록에서 컨테이너를 찾습니다.

5장. 컨테이너 리포지토리 설정

컨테이너 리포지토리를 설정하여 설명을 추가하고 README를 포함하고 리포지토리에 액세스할 수 있는 그룹을 추가하고 이미지에 태그를 지정할 수 있습니다.

5.1. 사전 요구 사항

  • 리포지토리를 변경할 수 있는 권한이 있는 개인 자동화 허브에 로그인했습니다.

5.2. 컨테이너 리포지토리에 README 추가

컨테이너 리포지토리에 README를 추가하여 컨테이너 작업 방법에 대한 지침을 사용자에게 제공합니다. Automation hub 컨테이너 리포지터리는 README를 생성하기 위해 Markdown을 지원합니다. 기본적으로 README는 비어 있습니다.

사전 요구 사항

  • 컨테이너를 변경할 수 있는 권한이 있습니다.

절차

  1. 실행 환경 으로 이동합니다.
  2. 컨테이너 리포지토리를 선택합니다.
  3. 자세한 정보 탭에서 추가 를 클릭합니다.
  4. Raw Markdown 텍스트 필드에 Markdown에 README 텍스트를 입력합니다.
  5. 완료되면 저장 을 클릭합니다.

README를 추가하면 편집을 클릭하고 4단계와 5단계를 반복하여 언제든지 편집 할 수 있습니다.

5.3. 컨테이너 리포지토리에 대한 액세스 권한 제공

이미지를 작업해야 하는 사용자를 위해 컨테이너 리포지토리에 대한 액세스 권한을 제공합니다. 그룹을 추가하면 그룹이 컨테이너 리포지토리에 보유할 수 있는 권한을 수정할 수 있습니다. 이 옵션을 사용하여 그룹이 할당된 내용에 따라 권한을 확장하거나 제한할 수 있습니다.

사전 요구 사항

  • 컨테이너 네임스페이스 권한이 변경됩니다.

절차

  1. 실행 환경 으로 이동합니다.
  2. 컨테이너 리포지토리를 선택합니다.
  3. 창 오른쪽 상단에 있는 편집 을 클릭합니다.
  4. 액세스 권한이 있는 그룹 아래에서 액세스 권한을 부여할 그룹 또는 그룹을 선택합니다.

    • 선택 사항: 해당 그룹 이름 아래의 드롭 다운을 사용하여 특정 그룹의 권한을 추가하거나 제거합니다.
  5. 저장을 클릭합니다.

5.4. 컨테이너 이미지 태그 지정

자동화 허브 컨테이너 리포지토리에 저장된 이미지에 추가 이름을 추가하기 위해 이미지에 태그를 지정합니다. 이미지에 태그가 추가되지 않으면 자동화 허브는 기본적으로 이름에 latest 로 설정됩니다.

사전 요구 사항

  • 이미지 태그 권한 변경 사항이 있습니다.

절차

  1. 실행 환경 으로 이동합니다.
  2. 컨테이너 리포지토리를 선택합니다.
  3. 이미지 탭을 클릭합니다.
  4. More Actions 아이콘 Cryostat 클릭한 다음 태그 관리를 클릭합니다.
  5. 텍스트 필드에 새 태그를 추가하고 추가 를 클릭합니다.

    • 선택 사항: 해당 이미지에 대한 태그 중 x 를 클릭하여 현재 태그를 제거합니다.
  6. 저장을 클릭합니다.

검증

  • Activity 탭을 클릭하고 최신 변경 사항을 검토합니다.

5.5. 자동화 컨트롤러에서 인증 정보 생성

이전에는 실행 환경 이미지를 저장하기 위해 레지스트리를 배포해야 했습니다. Ansible Automation Platform 2.0 이상에서는 컨테이너 레지스트리가 실행 중이라고 가정합니다. 따라서 실행 환경 이미지를 저장하기 위해 선택한 컨테이너 레지스트리의 인증 정보만 추가해야 합니다.

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

절차

  1. 자동화 컨트롤러로 이동합니다.
  2. 사이드 메뉴 표시줄에서 리소스자격 증명을 클릭합니다.
  3. 추가 를 클릭하여 새 자격 증명을 생성합니다.
  4. 권한 부여 이름, 설명, 조직을 입력합니다.
  5. 자격 증명 유형을 선택합니다.
  6. 인증 URL 을 입력합니다. 이는 컨테이너 레지스트리 주소입니다.
  7. 컨테이너 레지스트리에 로그인하는 데 필요한 사용자 이름암호 또는 토큰 을 입력합니다.
  8. 필요한 경우 SSL 확인을 선택하여 SSL 확인을 활성화합니다.
  9. 저장을 클릭합니다.

6장. 컨테이너 리포지토리에서 이미지 가져오기

자동화 허브 컨테이너 레지스트리에서 이미지를 가져와 로컬 시스템에 복사합니다. 자동화 허브는 컨테이너 리포지토리의 각 최신 이미지에 대해 podman pull 명령을 제공합니다. 이 명령을 복사하여 터미널에 붙여넣거나 podman pull 을 사용하여 이미지 태그를 기반으로 이미지를 복사할 수 있습니다.

6.1. 사전 요구 사항

개인 컨테이너 리포지토리에서 보고 가져올 수 있는 권한이 있어야 합니다.

6.2. 이미지 가져오기

자동화 허브 컨테이너 레지스트리에서 이미지를 가져와 로컬 시스템에 복사할 수 있습니다. 자동화 허브는 컨테이너 리포지토리의 각 최신 이미지에 대해 podman pull 명령을 제공합니다.

참고

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

절차

  1. 실행 환경 으로 이동합니다.
  2. 컨테이너 리포지토리를 선택합니다.
  3. Pull this image 항목에서 Copy to 클립보드 를 클릭합니다.
  4. 터미널에서 명령을 붙여넣고 실행합니다.

검증

  • podman 이미지를 실행하여 로컬 시스템의 이미지를 봅니다.

6.3. 컨테이너 리포지토리에서 이미지 동기화

자동화 허브 컨테이너 레지스트리에서 이미지를 가져와서 이미지를 로컬 머신에 동기화할 수 있습니다.

사전 요구 사항

개인 컨테이너 리포지토리에서 보고 가져올 수 있는 권한이 있어야 합니다.

절차

원격 컨테이너 레지스트리에서 이미지를 동기화하려면 원격 레지스트리를 구성해야 합니다.

  1. 실행 환경으로 이동합니다. 원격레지스트리.
  2. 레지스트리에 https://registry.redhat.io 를 추가합니다.
  3. 인증에 필요한 인증 정보를 추가합니다.
참고

일부 컨테이너 레지스트리는 속도 제한으로 공격적입니다. Advanced Options 아래에서 유량 제한을 설정하는 것이 좋습니다.

  1. 실행 환경 으로 이동합니다.
  2. 페이지 헤더에서 실행 환경 추가 를 클릭합니다.
  3. 가져올 레지스트리를 선택합니다. "name" 필드에는 로컬 레지스트리에서 로 표시될 이미지의 이름이 표시됩니다.
참고

"업스트림 이름" 필드는 원격 서버의 이미지 이름입니다. 예를 들어 업스트림 이름이 "alpine"로 설정되고 "name" 필드를 "local/alpine"로 설정하면 alpine 이미지가 원격에서 다운로드되고 local/alpine으로 이름이 변경됩니다.

포함하거나 제외하도록 태그 목록을 설정하는 것이 좋습니다. 많은 수의 태그와 이미지를 동기화하는 것은 시간이 오래 걸리며 많은 디스크 공간을 사용합니다.

추가 리소스

6.4. 추가 리소스

  • 이미지를 가져올 때 사용할 옵션은 What is Podman? 설명서를 참조하십시오.

부록 A. 자동화 실행 환경 우선 순위

프로젝트 업데이트는 기본적으로 컨트롤 플레인 자동화 실행 환경을 사용하지만 작업은 다음과 같이 사용 가능한 첫 번째 자동화 실행 환경을 사용합니다.

  1. 작업을 생성한 템플릿에 정의된 execution_environment (작업 템플릿 또는 인벤토리 소스)입니다.
  2. 작업에서 사용하는 프로젝트에 정의된 default_environment 입니다.
  3. 작업 조직에 정의된 default_environment 입니다.
  4. 작업에서 사용하는 인벤토리 조직에 정의된 default_environment 입니다.
  5. 현재 DEFAULT_EXECUTION_ENVIRONMENT 설정( api/v2/settings/jobs/에서 설정 가능)
  6. GLOBAL_JOB_EXECUTION_ENVIRONMENTS 설정의 모든 이미지입니다.
  7. 기타 모든 글로벌 실행 환경
참고

둘 이상의 실행 환경이 기준에 맞는 경우(6 및 7에 적용) 가장 최근에 생성된 실행 환경이 사용됩니다.

법적 공지

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.