실행 환경 생성 및 사용
Red Hat Ansible Automation Platform을 위한 일관되고 재현 가능한 자동화 실행 환경을 생성합니다.
초록
머리말 링크 복사링크가 클립보드에 복사되었습니다!
Ansible Builder를 사용하여 Red Hat Ansible Automation Platform 요구 사항에 맞게 일관되고 재현 가능한 자동화 실행 환경을 구축할 수 있습니다.
보다 포괄적 수용을 위한 오픈 소스 용어 교체 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
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 Builder 사용 링크 복사링크가 클립보드에 복사되었습니다!
Ansible Builder는 다양한 Ansible Collections에 정의된 메타데이터 또는 사용자가 생성한 메타데이터를 사용하여 자동화 실행 환경을 빌드하는 프로세스를 자동화하는 명령줄 툴입니다.
2.1. Ansible Builder를 사용하는 이유는 무엇입니까? 링크 복사링크가 클립보드에 복사되었습니다!
Ansible Builder를 개발하기 전에 Red Hat Ansible Automation Platform 사용자는 설치된 모든 필수 종속 항목이 포함된 사용자 지정 가상 환경 또는 컨테이너를 생성할 때 종속성 문제와 오류로 실행될 수 있었습니다.
이제 Ansible Builder를 사용하면 자동화 실행 환경에 포함된 콘텐츠(예: 컬렉션, 요구 사항, 시스템 수준 패키지)를 지정하는 사용자 정의 자동화 실행 환경 정의 파일을 쉽게 생성할 수 있습니다. 이를 통해 작업을 실행하는 데 필요한 모든 요구 사항과 종속 항목을 충족할 수 있습니다.
2.2. Ansible Builder 설치 링크 복사링크가 클립보드에 복사되었습니다!
RHSM(Red Hat Subscription Management)을 사용하여 Ansible Builder를 설치하여 Red Hat Ansible Automation Platform 서브스크립션을 연결할 수 있습니다. Red Hat Ansible Automation Platform 서브스크립션을 연결하면 ansible-builder 를 설치하는 데 필요한 서브스크립션 전용 리소스에 액세스할 수 있습니다. 서브스크립션을 연결하면 ansible-builder 에 필요한 리포지토리가 자동으로 활성화됩니다.
ansible-builder 를 설치하기 전에 호스트에 유효한 서브스크립션이 연결되어 있어야 합니다.
절차
터미널에서 다음 명령을 실행하여 Ansible Automation Platform 리포지토리를 활성화합니다.
dnf config-manager --enable ansible-automation-platform-2.2-for-rhel-8-x86_64-rpms
# dnf config-manager --enable ansible-automation-platform-2.2-for-rhel-8-x86_64-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 그런 다음 다음 명령을 입력하여 Ansible Builder를 설치합니다.
dnf install ansible-builder
# dnf install ansible-builderCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. 정의 파일 빌드 링크 복사링크가 클립보드에 복사되었습니다!
Ansible 빌더가 설치되면 Ansible Builder에서 자동화 실행 환경 이미지를 생성하는 데 사용하는 정의 파일을 생성할 수 있습니다. 자동화 실행 환경 이미지를 빌드하는 상위 수준 프로세스는 Ansible Builder가 정의 파일을 읽고 검증한 다음 을 생성하고 마지막으로 컨테이너 파일을 생성한 다음 패키징하고 자동화 실행 환경 이미지를 생성하는 Podman에 전달하는 것입니다. 생성된 정의 파일은 Containerfile yaml 형식으로 되어 있으며 다양한 섹션이 포함되어 있습니다. 정의 파일 콘텐츠에 대한 자세한 내용은 정의 파일 콘텐츠 의 Breakdown 을 참조하십시오.
다음은 정의 파일의 예입니다.
예 2.1. 정의 파일
이러한 정의 파일 매개변수에 대한 자세한 내용은 Breakdown of definition file content 를 참조하십시오.
2.4. 빌드 및 명령 생성 링크 복사링크가 클립보드에 복사되었습니다!
사전 요구 사항
- 정의 파일을 생성했습니다.
절차
자동화 실행 환경 이미지를 빌드하려면 다음을 실행합니다.
ansible-builder build
$ ansible-builder build
기본적으로 Ansible Builder는 execution-environment.yml 이라는 정의 파일을 찾지만 -f 플래그를 통해 다른 파일 경로를 인수로 지정할 수 있습니다.
ansible-builder build -f definition-file-name.yml
$ ansible-builder build -f definition-file-name.yml
여기서 definition-file-name 은 정의 파일의 이름을 지정합니다.
2.5. 정의 파일 콘텐츠 분석 링크 복사링크가 클립보드에 복사되었습니다!
자동화 실행 환경 컨테이너 이미지에 포함된 콘텐츠를 지정하므로 정의 파일은 Ansible Builder를 사용하여 자동화 실행 환경을 빌드하는 데 필요합니다.
다음 섹션에서는 정의 파일의 여러 부분을 나눕니다.
2.5.1. 빌드 args 및 기본 이미지 링크 복사링크가 클립보드에 복사되었습니다!
정의 파일의 build_arg_defaults 섹션은 키가 Ansible Builder에 대한 인수의 기본값을 제공할 수 있는 사전입니다. build_arg_defaults 에서 사용할 수 있는 값 목록은 다음 표를 참조하십시오.
| 현재의 | 설명 |
|---|---|
|
| 사용자가 컬렉션 설치 단계에서 ansible-galaxy CLI에 임의의 인수를 전달할 수 있습니다. 예를 들어 -pre 플래그는 사전 릴리스 컬렉션 설치를 활성화하거나 -c를 사용하여 서버의 SSL 인증서 확인을 비활성화합니다. |
|
| 자동화 실행 환경의 상위 이미지를 지정하여 기존 이미지를 기반으로 하는 새 이미지를 빌드할 수 있도록 합니다. 일반적으로 ee-minimal 또는 ee-supported와 같이 지원되는 실행 환경 기본 이미지이지만 이전에 생성한 후 추가로 사용자 정의하려는 실행 환경 이미지일 수도 있습니다.
기본 이미지는 |
|
|
Python 종속성 수집 및 컴파일에 사용되는 중간 빌더 이미지를 지정합니다.
기본 이미지는 |
build_arg_defaults 내부에 지정된 값은 컨테이너 파일에 하드 코딩되므로 podman 빌드 를 수동으로 호출하면 이러한 값이 유지됩니다.
CLI --build-arg 플래그에 동일한 변수가 지정된 경우 CLI 값이 우선 순위가 높습니다.
2.5.2. Ansible 구성 파일 경로 링크 복사링크가 클립보드에 복사되었습니다!
ansible_config 지시문을 사용하면 빌드의 Collection 설치 단계에서 개인 계정의 토큰 및 기타 설정을 자동화 허브 서버에 전달할 ansible.cfg 파일의 경로를 지정할 수 있습니다. 구성 파일 경로는 정의 파일 위치와 상대적이어야 하며 생성된 컨테이너 빌드 컨텍스트로 복사됩니다.
ansible.cfg 파일은 다음 예제와 같이 포맷해야 합니다.
예 2.2. ansible.cfg 파일
자동화 허브에서 컬렉션을 다운로드하는 방법에 대한 자세한 내용은 관련 Ansible 설명서 페이지를 참조하십시오.
2.5.3. 종속 항목 링크 복사링크가 클립보드에 복사되었습니다!
자동화 실행 환경 이미지 문제를 방지하려면 Galaxy, Python 및 system 항목이 유효한 요구 사항 파일을 가리키는지 확인하십시오.
2.5.3.1. Galaxy 링크 복사링크가 클립보드에 복사되었습니다!
이 항목은 ansible- 명령에 대한 유효한 요구 사항 파일을 가리킵니다.
galaxy collection install -r …
항목 requirements.yml 은 자동화 실행 환경 정의 폴더의 디렉터리 또는 절대 경로의 상대 경로일 수 있습니다.
requirements.yml 파일의 내용은 다음과 같을 수 있습니다.
예 2.3. Galaxy에 대한 requirements.yml 파일
collections: - community.aws - kubernetes.core
collections:
- community.aws
- kubernetes.core
2.5.3.2. Python 링크 복사링크가 클립보드에 복사되었습니다!
정의 파일의 python 항목은 pip install -r … 명령에 대한 유효한 요구 사항 파일을 가리킵니다.
항목 requirements.txt 는 Collections가 이미 Python 종속 항목으로 나열된 추가 Python 요구 사항을 설치하는 파일입니다. 자동화 실행 환경 정의 폴더 또는 절대 경로의 디렉터리에서 상대 경로로 나열될 수 있습니다. pip 동결 명령의 표준 출력과 유사하게 requirements.txt 파일의 내용은 다음 예제와 같이 포맷해야 합니다.
예 2.4. Python용 requirements.txt 파일
2.5.3.3. 시스템 링크 복사링크가 클립보드에 복사되었습니다!
정의의 시스템 항목은 바인딩 요구 사항 파일을 가리킵니다. 이 파일은 컬렉션 외부에 이미 포함된 시스템 수준 종속 항목을 종속 항목으로 설치합니다. 자동화 실행 환경 정의 폴더 또는 절대 경로의 디렉터리에서 상대 경로로 나열할 수 있습니다. 최소한의 기대치는 컬렉션이 [platform:rpm] 에 필요한 요구 사항을 지정한다는 것입니다.
이를 설명하기 위해 다음은 libxml2 및 subversion 패키지를 컨테이너에 추가하는 bindep.txt 파일 예제입니다.
예 2.5. bindep.txt 파일
libxml2-devel [platform:rpm] subversion [platform:rpm]
libxml2-devel [platform:rpm]
subversion [platform:rpm]
여러 컬렉션의 항목이 단일 파일로 결합됩니다. 바인딩에 의해 처리되고 로 전달됩니다. 프로필이 없거나 런타임 요구 사항이 없는 요구 사항만 이미지에 설치됩니다.
dnf
2.5.4. 추가적인 사용자 지정 빌드 단계 링크 복사링크가 클립보드에 복사되었습니다!
prepend 및 append 명령은 additional_build_steps 섹션에 지정할 수 있습니다. 이러한 명령은 기본 빌드 단계가 실행되기 전이나 후에 실행되는 Containerfile 에 명령을 추가합니다.
additional_build_steps 의 구문은 다음 중 하나여야 합니다.
여러 줄 문자열
예 2.6. 다중 줄 문자열 항목
prepend: | RUN whoami RUN cat /etc/os-release
prepend: | RUN whoami RUN cat /etc/os-releaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 목록
예 2.7. 목록 항목
append: - RUN echo This is a post-install command! - RUN ls -la /etc
append: - RUN echo This is a post-install command! - RUN ls -la /etcCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. 선택적 빌드 명령 인수 링크 복사링크가 클립보드에 복사되었습니다!
-t 플래그는 자동화 실행 환경 이미지에 특정 이름을 태그합니다. 예를 들어 다음 명령은 my_first_ee_image 라는 이미지를 빌드합니다.
ansible-builder build -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 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에서 이를 읽고 검증한 다음, 컨테이너 파일을 생성하고, 마지막으로 Podman에 컨테이너 파일을 전달하고 다음 지침을 사용하여 자동화 실행 환경 이미지를 생성합니다.
- 기본 이미지 가져오기
- 기본 이미지의 임시 사본에서 컬렉션이 다운로드되고 선언된 Python 및 시스템 종속 항목 목록이 나중에 대해 수집됩니다.
- 임시 빌더 이미지에서 정의 파일에 나열된 모든 Python 종속 항목에 대한 Python이 다운로드되고 빌드됩니다(필요한 경우) 정의 파일에 나열된 컬렉션으로 선언된 모든 Python 종속성을 포함합니다.
-
정의 파일의 additional_build_steps
앞에는 실행됩니다. - 최종 자동화 실행 환경 이미지에서는 정의 파일에 나열된 컬렉션으로 선언된 모든 시스템 종속 항목을 포함하여 정의 파일에 나열된 시스템 종속 항목이 설치됩니다.
- 최종 자동화 실행 환경 이미지에서 다운로드한 컬렉션이 복사되고 이전에 가져온 Python 종속 항목이 설치됩니다.
-
정의 파일에서 additional_build_steps에 대한 추가 기능이 실행됩니다.
2.8. 이미지를 빌드하지 않고 컨테이너 파일 생성 링크 복사링크가 클립보드에 복사되었습니다!
공유 가능한 Containerfile 을 이미지를 빌드하지 않고 생성하려면 다음을 실행합니다.
ansible-builder create
$ ansible-builder create
3장. 자동화 실행 환경 게시 링크 복사링크가 클립보드에 복사되었습니다!
3.1. 기존 자동화 실행 환경 이미지 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
Ansible Controller에는 다음 세 가지 기본 실행 환경이 제공됩니다.
-
Ansible 2.9- Controller 모듈 이외의 컬렉션이 설치되지 않음 -
minimal- Ansible Runner와 함께 최신 Ansible 2.13 릴리스가 포함되어 있지만 컬렉션이나 기타 추가 콘텐츠가 포함되어 있지 않습니다. -
EE 지원- 최소 및 모든 Red Hat 지원 컬렉션 및 종속 항목
이러한 환경은 많은 자동화 사용 사례를 다루지만 추가 항목을 추가하여 특정 요구 사항에 맞게 이러한 컨테이너를 사용자 지정할 수 있습니다. 다음 절차에서는 kubernetes.core 컬렉션을 ee-minimal 기본 이미지에 추가합니다.
절차
Podman을 통해
registry.redhat.io에 로그인합니다.podman login -u="[username]" -p="[token/hash]" registry.redhat.io
$ podman login -u="[username]" -p="[token/hash]" registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 원하는 자동화 실행 환경 기본 이미지를 가져올 수 있는지 확인합니다.
podman pull registry.redhat.io/ansible-automation-platform-22/ee-minimal-rhel8:latest
podman pull registry.redhat.io/ansible-automation-platform-22/ee-minimal-rhel8:latestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 원하는 기본 이미지와 새로운 실행 환경 이미지에 추가할 추가 콘텐츠를 지정하도록 Ansible Builder 파일을 구성합니다.
예를 들어, Galaxy의 Kubernetes Core Collection 을 이미지에 추가하려면 다음과 같이
requirements.yml파일을 작성합니다.collections: - kubernetes.core
collections: - kubernetes.coreCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 정의 파일 및 해당 콘텐츠에 대한 자세한 내용은 정의 파일 분석 섹션을 참조하십시오.
실행 환경 정의 파일에서
EE_BASE_IMAGE필드에 원래ee-minimal컨테이너의 URL 및 태그를 지정합니다. 이렇게 하면 최종execution-environment.yml파일은 다음과 같이 표시됩니다.예 3.1. 사용자 지정
execution-environment.yml파일Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 예에서는 자동화 허브에서 인증된 컬렉션이 아닌
kubernetes.core커뮤니티 버전을 사용하므로 정의 파일에서ansible.cfg파일 또는 참조를 생성할 필요가 없습니다.다음 명령을 사용하여 새 실행 환경 이미지를 빌드합니다.
ansible-builder build -t registry.redhat.io/[username]/new-ee
$ ansible-builder build -t registry.redhat.io/[username]/new-eeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 여기서
[username]은 사용자 이름을 지정하고new-ee는 새 컨테이너 이미지의 이름을 지정합니다.
빌드에 -t 를 사용하지 않는 경우 ansible-execution-env 라는 이미지가 생성되고 로컬 컨테이너 레지스트리에 로드됩니다.
podman images명령을 사용하여 새 컨테이너 이미지가 해당 목록에 있는지 확인합니다.예 3.2.
new-ee이미지가 포함된podman images명령의 출력REPOSITORY TAG IMAGE ID CREATED SIZE localhost/new-ee latest f5509587efbb 3 minutes ago 769 MB
REPOSITORY TAG IMAGE ID CREATED SIZE localhost/new-ee latest f5509587efbb 3 minutes ago 769 MBCopy to Clipboard Copied! Toggle word wrap Toggle overflow 컬렉션이 설치되었는지 확인합니다.
podman run registry.redhat.io/[username]/new-ee ansible-doc -l kubernetes.core
$ podman run registry.redhat.io/[username]/new-ee ansible-doc -l kubernetes.coreCopy to Clipboard Copied! Toggle word wrap Toggle overflow 자동화 허브에서 사용할 이미지를 태그합니다.
podman tag registry.redhat.io/[username]/new-ee [automation-hub-IP-address]/[username]/new-ee
$ podman tag registry.redhat.io/[username]/new-ee [automation-hub-IP-address]/[username]/new-eeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Podman을 사용하여 자동화 허브에 로그인합니다.
참고컨테이너를 푸시하려면 자동화 허브에 대한
관리자또는 적절한 컨테이너 리포지토리 권한이 있어야 합니다. 자세한 내용은 Red Hat Ansible Automation Platform 설명서 의 프라이빗 자동화 허브로 컨테이너 관리를 참조하십시오.podman login -u="[username]" -p="[token/hash]" [automation-hub-IP-address]
$ podman login -u="[username]" -p="[token/hash]" [automation-hub-IP-address]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 자동화 허브에서 컨테이너 레지스트리로 이미지를 푸시합니다.
podman push [automation-hub-IP-address]/[username]/new-ee
$ podman push [automation-hub-IP-address]/[username]/new-eeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 자동화 컨트롤러 인스턴스로 새 이미지를 가져옵니다.
- 자동화 컨트롤러로 이동합니다.
- side-navigational 표시줄에서 → 를 클릭합니다.
- 클릭합니다.
적절한 정보를 입력하고 클릭하여 새 이미지를 가져옵니다.
참고자동화 허브 인스턴스가 암호 또는 토큰 보호인 경우 적절한 컨테이너 레지스트리 인증 정보를 설정해야 합니다.
4장. 프라이빗 자동화 허브 컨테이너 레지스트리 채우기 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 개인 자동화 허브에는 컨테이너 이미지가 포함되지 않습니다. 컨테이너 레지스트리를 채우려면 컨테이너 이미지를 푸시해야 합니다. 이 섹션의 절차에서는 Red Hat Ecosystem Catalog(registry.redhat.io)에서 이미지를 가져와서 태그를 지정한 후 프라이빗 자동화 허브 컨테이너 레지스트리로 푸시하는 방법을 설명합니다.
4.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 새 컨테이너를 생성하고 컨테이너를 프라이빗 자동화 허브로 푸시할 수 있는 권한이 있습니다.
4.2. 자동화 허브에서 사용할 이미지 가져오기 링크 복사링크가 클립보드에 복사되었습니다!
컨테이너 이미지를 프라이빗 자동화 허브로 푸시하려면 먼저 기존 레지스트리에서 이미지를 가져와서 사용할 태그를 지정해야 합니다. 이 예에서는 Red Hat Ecosystem Catalog(registry.redhat.io)에서 이미지를 가져오는 방법을 자세히 설명합니다.
사전 요구 사항
registry.redhat.io에서 이미지를 가져올 수 있는 권한이 있습니다.
절차
registry.redhat.io 인증 정보를 사용하여 Podman에 로그인합니다.
podman login registry.redhat.io
$ podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 프롬프트에 사용자 이름과 암호를 입력합니다.
컨테이너 이미지를 가져옵니다.
podman pull registry.redhat.io/<container_image_name>:<tag>
$ podman pull registry.redhat.io/<container_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
로컬 스토리지의 이미지를 나열합니다.
podman images
$ podman imagesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 최근 가져온 이미지가 목록에 포함되어 있는지 확인합니다.
- 태그가 올바른지 확인합니다.
4.3. 자동화 허브에서 사용할 이미지 태그 지정 링크 복사링크가 클립보드에 복사되었습니다!
레지스트리에서 이미지를 가져온 후 개인 자동화 허브 컨테이너 레지스트리에 사용하도록 태그를 지정합니다.
사전 요구 사항
- 외부 레지스트리에서 컨테이너 이미지를 가져왔습니다.
- 자동화 허브 인스턴스의 FQDN 또는 IP 주소가 있습니다.
절차
자동화 허브 컨테이너 리포지터리로 로컬 이미지에 태그 지정
podman tag registry.redhat.io/<container_image_name>:<tag> <automation_hub_URL>/<container_image_name>
$ podman tag registry.redhat.io/<container_image_name>:<tag> <automation_hub_URL>/<container_image_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
로컬 스토리지의 이미지를 나열합니다.
podman images
$ podman imagesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 최근 자동화 허브 정보로 태그를 지정한 이미지가 목록에 포함되어 있는지 확인합니다.
4.4. 개인 자동화 허브로 컨테이너 이미지 푸시 링크 복사링크가 클립보드에 복사되었습니다!
태그된 컨테이너 이미지를 프라이빗 자동화 허브로 푸시하여 새 컨테이너를 생성하고 컨테이너 레지스트리를 채울 수 있습니다.
사전 요구 사항
- 새 컨테이너를 생성할 수 있는 권한이 있습니다.
- 자동화 허브 인스턴스의 FQDN 또는 IP 주소가 있습니다.
절차
자동화 허브 위치 및 인증 정보를 사용하여 Podman에 로그인합니다.
podman login -u=<username> -p=<password> <automation_hub_url>
$ podman login -u=<username> -p=<password> <automation_hub_url>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 컨테이너 이미지를 자동화 허브 컨테이너 레지스트리로 푸시합니다.
podman push <automation_hub_url>/<container_image_name>
$ podman push <automation_hub_url>/<container_image_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고registry.redhat.io의 서명된 이미지가 자동화 허브 컨테이너 레지스트리로 푸시되는 경우
--remove-signatures플래그가 필요합니다.푸시작업에서는 업로드 중에 이미지 계층을 다시 압축하므로 재현할 수 없으며 클라이언트 구현에 따라 달라집니다. 이로 인해 이미지 계층 다이제스트 변경 및 오류 발생으로 인해Error: 이 이미지를 복사하려면 계층 표현을 변경해야 합니다(이미지 서명 또는 대상이 다이제스트를 지정함).
검증
- 자동화 허브에 로그인합니다.
- 컨테이너 .
- 컨테이너 리포지토리 목록에서 컨테이너를 찾습니다.
5장. 컨테이너 리포지터리 설정 링크 복사링크가 클립보드에 복사되었습니다!
컨테이너 리포지토리를 설정하여 설명을 추가하고 README를 포함하고, 리포지토리에 액세스할 수 있는 그룹을 추가하고, 이미지를 태그할 수 있습니다.
5.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 리포지토리를 변경할 수 있는 권한이 있는 프라이빗 Automation Hub에 로그인되어 있습니다.
5.2. 컨테이너 리포지토리에 README 추가 링크 복사링크가 클립보드에 복사되었습니다!
컨테이너 리포지토리에 README를 추가하여 컨테이너 작업 방법에 대한 지침을 사용자에게 제공합니다. Automation hub 컨테이너 리포지토리는 README를 생성하기 위해 Markdown을 지원합니다. 기본적으로 README는 비어 있습니다.
사전 요구 사항
- 컨테이너를 변경할 수 있는 권한이 있습니다.
절차
- 으로 이동합니다.
- 컨테이너 리포지토리를 선택합니다.
- 세부 정보 탭에서 클릭합니다.
- Raw Markdown 텍스트 필드에 README 텍스트를 Markdown에 입력합니다.
- 완료되면 클릭합니다.
README를 추가하면 및 단계 4와 5 반복을 클릭하여 언제든지 편집할 수 있습니다.
5.3. 컨테이너 리포지토리에 대한 액세스 제공 링크 복사링크가 클립보드에 복사되었습니다!
이미지를 작동해야 하는 사용자에게 컨테이너 리포지토리에 대한 액세스 권한을 제공합니다. 그룹을 추가하면 그룹이 컨테이너 리포지토리에 대해 가질 수 있는 권한을 수정할 수 있습니다. 이 옵션을 사용하여 그룹에 할당된 내용에 따라 권한을 확장하거나 제한할 수 있습니다.
사전 요구 사항
- 컨테이너 네임스페이스 권한이 변경됩니다.
절차
- 으로 이동합니다.
- 컨테이너 리포지토리를 선택합니다.
- 창의 오른쪽 상단에 있는 을 클릭합니다.
액세스 권한이 있는 Groups에서 액세스 권한을 부여할 그룹 또는 그룹을 선택합니다.
- 선택 사항: 해당 그룹 이름 아래의 드롭다운을 사용하여 특정 그룹에 대한 권한을 추가하거나 제거합니다.
- 을 클릭합니다.
5.4. 컨테이너 이미지 태그 지정 링크 복사링크가 클립보드에 복사되었습니다!
이미지를 태그하여 자동화 허브 컨테이너 리포지토리에 저장된 이미지에 추가 이름을 추가합니다. 이미지에 태그가 추가되지 않은 경우 자동화 허브는 기본적으로 이름에 대해 latest 로 설정됩니다.
사전 요구 사항
- 이미지 태그 권한이 변경되어 있어야 합니다.
절차
- 으로 이동합니다.
- 컨테이너 리포지토리를 선택합니다.
- 이미지 탭을 클릭합니다.
-
을 클릭한 다음 클릭합니다.
텍스트 필드에 새 태그를 클릭합니다.
- 선택 사항: 해당 이미지의 태그에서 를 클릭하여 현재 태그를 제거합니다.
- 을 클릭합니다.
검증
- Activity 탭을 클릭하고 최신 변경 사항을 검토합니다.
6장. 컨테이너 리포지토리에서 이미지 가져오기 링크 복사링크가 클립보드에 복사되었습니다!
자동화 허브 컨테이너 레지스트리에서 이미지를 가져와 로컬 시스템에 복사합니다. Automation hub는 컨테이너 리포지토리의 각 최신 이미지에 대해 podman pull 명령을 제공합니다. 이 명령을 터미널에 복사하여 붙여넣거나 podman pull 을 사용하여 이미지 태그를 기반으로 이미지를 복사할 수 있습니다.
6.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 개인 컨테이너 리포지토리에서 보고 가져올 수 있는 권한이 있습니다.
6.2. 이미지 가져오기 링크 복사링크가 클립보드에 복사되었습니다!
자동화 허브 컨테이너 레지스트리에서 이미지를 가져와서 로컬 머신에 복사할 수 있습니다. Automation hub는 컨테이너 리포지토리의 각 최신 이미지에 대해 podman pull 명령을 제공합니다.
절차
- 으로 이동합니다.
- 컨테이너 리포지토리를 선택합니다.
- Pull 이 이미지 항목에서 를 클릭합니다.
- 터미널에 명령을 붙여넣고 실행합니다.
검증
-
podman 이미지를실행하여 로컬 시스템의 이미지를 확인합니다.
부록 A. 자동화 실행 환경 우선 순위 링크 복사링크가 클립보드에 복사되었습니다!
프로젝트 업데이트는 기본적으로 항상 컨트롤 플레인 자동화 실행 환경을 사용하지만 작업에서 다음과 같이 사용 가능한 첫 번째 자동화 실행 환경을 사용합니다.
-
작업을 생성한 템플릿에 정의된
execution_environment(작업 템플릿 또는 인벤토리 소스)입니다. -
작업에서 사용하는 프로젝트에 정의된
default_environment입니다. -
작업 조직에 정의된
default_environment입니다. -
작업에서 사용하는 인벤토리의 조직에 정의된
default_environment입니다. -
현재
DEFAULT_EXECUTION_ENVIRONMENT설정(api/v2/settings/jobs/)에서 구성 가능 -
GLOBAL_JOB_EXECUTION_ENVIRONMENTS설정의 모든 이미지입니다. - 기타 글로벌 실행 환경
둘 이상의 실행 환경이 기준(6 및 7에 적용)에 맞는 경우 가장 최근에 생성된 실행 환경이 사용됩니다.