개인 자동화 허브에서 컨테이너 관리

Red Hat Ansible Automation Platform 2.4

자동화 허브 컨테이너 레지스트리를 사용하여 컨테이너 이미지 리포지토리 관리

Red Hat Customer Content Services

초록

이 가이드에서는 프라이빗 자동화 허브 컨테이너 레지스트리 및 리포지토리 구성을 위한 관리자 워크플로 및 프로세스를 제공합니다.

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

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

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

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

참고

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

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

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

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

1장. 프라이빗 자동화 허브 컨테이너 레지스트리 관리

자동화 허브 컨테이너 레지스트리를 사용하여 Ansible Automation Platform 인프라에서 컨테이너 이미지 리포지터리를 관리합니다. 자동화 허브는 개별 컨테이너 리포지토리에 액세스하거나, 이미지의 태그를 변경하고, 활동 및 이미지 계층을 보고, 각 컨테이너 리포지터리와 관련된 추가 정보를 제공할 수 있는 기능을 제공합니다.

1.1. 컨테이너 레지스트리

자동화 허브 컨테이너 레지스트리는 컨테이너 이미지를 저장하고 관리하는 데 사용됩니다. 컨테이너 이미지를 빌드하거나 소싱한 후에는 해당 컨테이너 이미지를 프라이빗 자동화 허브의 레지스트리 부분으로 내보내 컨테이너 리포지토리를 생성할 수 있습니다.

다음 단계

  • 컨테이너 이미지를 자동화 허브 컨테이너 레지스트리로 푸시합니다.
  • 레지스트리의 컨테이너 리포지토리에 액세스할 수 있는 그룹을 생성합니다.
  • 컨테이너 리포지토리에 새 그룹을 추가합니다.
  • 컨테이너 리포지토리에 README를 추가하여 사용자에게 정보 및 관련 링크를 제공합니다.

2장. 개인 자동화 허브에서 컨테이너 리포지토리에 대한 사용자 액세스 구성

개인 자동화 허브에서 컨테이너 리포지토리에 대한 사용자 액세스를 구성하여 Ansible Automation Platform의 이미지에 액세스하고 관리할 수 있는 권한을 제공합니다.

2.1. 사전 요구 사항

  • 개인 자동화 허브에서 그룹을 생성하고 권한을 할당할 수 있습니다.

2.2. 컨테이너 레지스트리 그룹 권한

사용자 액세스 권한을 통해 사용자는 개인 자동화 허브에서 관리되는 컨테이너와 상호 작용할 수 있는 세분화된 제어가 제공됩니다. 다음 권한 목록을 사용하여 컨테이너 레지스트리에 대한 올바른 권한이 있는 그룹을 생성합니다.

표 2.1. 개인 자동화 허브에서 컨테이너를 관리하는 데 사용되는 그룹 권한 목록

권한 이름설명

새 컨테이너 생성

사용자가 새 컨테이너를 만들 수 있습니다.

컨테이너 네임스페이스 권한 변경

사용자가 컨테이너 리포지터리에 대한 권한을 변경할 수 있습니다.

컨테이너 변경

사용자가 컨테이너에 대한 정보를 변경할 수 있습니다.

이미지 태그 변경

사용자가 이미지 태그를 수정할 수 있습니다.

개인 컨테이너 가져오기

사용자가 개인 컨테이너에서 이미지를 가져올 수 있습니다.

기존 컨테이너로 내보내기

사용자가 기존 컨테이너로 이미지를 푸시할 수 있습니다.

개인 컨테이너 보기

사용자는 개인용으로 표시된 컨테이너를 볼 수 있습니다.

2.3. 새 그룹 만들기

자동화 허브에서 그룹에 권한을 생성하고 할당하여 사용자가 시스템의 지정된 기능에 액세스할 수 있습니다. 기본적으로 자동화 허브에는 모든 권한이 할당되고 자동화 허브를 설치할 때 생성된 인증 정보를 사용하여 초기 로그인에서 사용할 수 있는 admins 그룹이 있습니다.

사전 요구 사항

  • 그룹 권한이 있으며 자동화 허브에서 그룹 구성 및 액세스를 생성 및 관리할 수 있습니다.

절차

  1. 로컬 자동화 허브에 로그인합니다.
  2. User AccessGroups 로 이동합니다.
  3. 생성을 클릭합니다.
  4. 이름을 입력하고 생성을 클릭합니다.

이제 권한을 할당하고 그룹 편집 페이지에서 사용자를 추가할 수 있습니다.

2.4. 그룹에 권한 할당

사용자가 시스템의 특정 기능에 액세스할 수 있도록 하는 자동화 허브의 그룹에 권한을 할당할 수 있습니다. 기본적으로 새 그룹에는 할당된 권한이 없습니다. 초기 그룹 생성 시 권한을 추가하거나 기존 그룹을 편집하여 권한을 추가하거나 삭제할 수 있습니다.

사전 요구 사항

  • 그룹 권한 변경 및 자동화 허브에서 그룹 권한을 편집할 수 있습니다.

절차

  1. 로컬 자동화 허브에 로그인합니다.
  2. User AccessRoles 로 이동합니다.
  3. 역할 추가를 클릭합니다.
  4. 이름 필드를 클릭하고 역할 이름을 작성합니다.
  5. 설명 필드를 클릭하고 설명을 작성합니다.
  6. Permissions 섹션을 완료합니다.
  7. 각 권한 유형에 대한 필드를 클릭하고 목록에 표시되는 권한을 선택합니다.
  8. 권한 할당이 완료되면 저장 을 클릭합니다.
  9. User AccessGroups 로 이동합니다.
  10. 그룹 이름을 클릭합니다.
  11. 액세스 탭을 클릭합니다.
  12. 역할 추가를 클릭합니다.
  13. 8단계에서 생성된 역할을 선택합니다.
  14. 다음을 클릭하여 선택한 역할을 확인합니다.
  15. 추가 를 클릭하여 역할 추가를 완료합니다.

그룹은 할당된 권한과 연결된 자동화 허브의 기능에 액세스할 수 있습니다.

추가 리소스

2.5. 그룹에 사용자 추가

그룹을 생성할 때 그룹에 사용자를 추가하거나 기존 그룹에 사용자를 수동으로 추가할 수 있습니다. 이 섹션에서는 기존 그룹에 사용자를 추가하는 방법을 설명합니다.

사전 요구 사항

  • 그룹 권한이 있으며 자동화 허브에서 그룹 구성 및 액세스를 생성 및 관리할 수 있습니다.

절차

  1. 자동화 허브에 로그인합니다.
  2. User AccessGroups 로 이동합니다.
  3. 그룹 이름을 클릭합니다.
  4. Users (사용자) 탭으로 이동한 다음 Add 를 클릭합니다.
  5. 목록에서 추가할 사용자를 선택하고 추가 를 클릭합니다.

선택한 사용자를 그룹에 추가했습니다. 이러한 사용자에게는 이제 그룹에 할당된 자동화 허브를 사용할 수 있는 권한이 있습니다.

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

기본적으로 프라이빗 자동화 허브에는 컨테이너 이미지가 포함되어 있지 않습니다. 컨테이너 레지스트리를 채우려면 컨테이너 이미지를 푸시해야 합니다. 이 섹션의 절차에서는 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 레지스트리와 직접 상호 작용해야 합니다.

3.1. 사전 요구 사항

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

3.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. 태그가 올바른지 확인합니다.

추가 리소스

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

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

사전 요구 사항

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

절차

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

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

검증

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

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

3.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. 컨테이너 리포지토리 목록에서 컨테이너를 찾습니다.

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

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

4.1. 사전 요구 사항

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

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

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

사전 요구 사항

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

절차

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

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

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

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

사전 요구 사항

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

절차

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

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

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

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

사전 요구 사항

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

절차

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

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

검증

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

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

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

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

절차

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

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

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

5.1. 사전 요구 사항

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

5.2. 이미지 가져오기

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

참고

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

절차

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

검증

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

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

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

사전 요구 사항

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

절차

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

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

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

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

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

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

추가 리소스

5.4. 추가 리소스

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

6장. 서명된 컨테이너 작업

6.1. 컨테이너 서명을 위해 시스템 배포

실행 환경은 Ansible 자동화 컨트롤러에서 작업을 실행하는 데 사용하는 컨테이너 이미지입니다. 이 콘텐츠는 프라이빗 자동화 허브로 다운로드하여 조직 내에 게시할 수 있습니다.

이제 자동화 허브에서 이미지 서명을 구현하고 있어 사용자는 EE 컨테이너 이미지에 대한 보안을 보다 효과적으로 사용할 수 있습니다.

Ansible Automation Platform 사용자는 이제 EE/Container가 이미 서명되었는지 또는 적절한 도구를 사용하여 서명을 직접 서명하고 확인하는 방법을 확인할 수 있습니다. 이 섹션에서는 컨테이너 서명 준비를 위해 시스템을 배포하는 방법을 자세히 설명합니다.

절차

  1. 컨테이너 서명이 활성화된 시스템을 배포합니다.

    _automation_hub:
        automationhub_create_default_container_signing_service: true
        automationhub_container_signing_service_key: _path/to/gpg.key_
        automationhub_container_signing_service_script: _path/to/executable_
  2. 자동화 허브로 이동합니다.
  3. 탐색 창에서 서명 키 를 선택합니다.
  4. container-default, container-anyname 이라는 키가 있는지 확인합니다.
참고

'container-default' 서비스는 Ansible Automation Platform 설치 프로그램에서 생성합니다.

6.2. 자동화 허브에 컨테이너를 원격으로 추가

자동화 허브에 컨테이너를 추가하는 방법은 다음 두 가지가 있습니다.

  • 원격 생성
  • 실행 환경

절차

원격 레지스트리를 추가하려면 다음을 수행합니다.

  1. 자동화 허브의 기본 메뉴 창에서 실행 환경을 클릭합니다.In automation hub, click Execution Environments in the main menu pane. 두 가지 선택 항목인 실행 환경원격 레지스트리가 제공됩니다.
  2. Remote Registries 를 클릭합니다.
  3. 기본 창에서 원격 레지스트리 추가 를 클릭합니다.

    • 이름 필드에 컨테이너가 있는 레지스트리의 이름을 입력합니다.
    • URL 필드에 컨테이너가 있는 레지스트리의 URL을 입력합니다.
    • Username 필드에 필요한 경우 사용자 이름을 입력합니다.
    • 필요한 경우 암호 필드에 암호를 입력합니다.
    • 저장을 클릭합니다.

6.3. 실행 환경 추가

절차

  1. 실행 환경 으로 이동합니다.
  2. 실행 환경의 이름을 입력합니다.
  3. 선택 사항: 업스트림 이름을 입력합니다.
  4. 레지스트리 의 드롭다운 메뉴에서 레지스트리 이름을 선택합니다.
  5. Add tags to include (포함할 태그 추가) 필드에 태그를 입력합니다. 필드를 비워 두면 모든 태그가 전달됩니다. 따라서 리포지토리별 태그를 전달하는 것이 중요합니다.
  6. 나머지 필드는 선택 사항입니다.

    • 현재 포함된 태그
    • 제외에 tag를 추가합니다.
    • 현재 제외된 태그
    • 설명
    • 액세스 권한이 있는 그룹
  7. 저장을 클릭합니다.
  8. 이미지를 동기화합니다.

6.4. 로컬에서 컨테이너 이미지 푸시

절차

  1. 터미널에서 podman에 로그인하거나 현재 사용 중인 컨테이너 클라이언트에 로그인합니다.

    > podman pull <__container-name__>
  2. 이미지를 가져온 후 태그를 추가합니다.

    > podman tag <container-name> _<server-address>_/<container-name>:<tag name>
  3. 변경한 후 이미지에 서명하고 다시 푸시합니다.

    > podman push _<server-address>_/<container-name>:<tag name>
    --tls-verify=false --sign-by<reference to the gpg key on your local>

    이미지에 서명하지 않은 경우 현재 서명이 포함된 경우에만 푸시할 수 있습니다.

  4. 서명하지 않고 이미지를 푸시합니다.

    > podman push _<server-address>_/<container-name>:<tag name>
    --tls-verify=false
  5. 자동화 허브로 이동하고 해당 창이 열려 있지 않은 경우 실행 환경을 클릭합니다.
  6. 새로 고침 아이콘을 클릭하여 새 실행 환경을 표시하도록 페이지를 새로 고칩니다.
  7. 이미지 이름을 클릭합니다.

세부 정보 페이지에 이미지 이름 아래에 이미지가 서명되었는지의 여부가 표시됩니다. 이 경우 "Unsigned."이 표시됩니다.

자동화 허브에서 이미지에 서명하려면 다음을 수행합니다.

  1. 이미지 이름을 클릭하여 세부 정보 페이지를 엽니다.
  2. 세부 정보 페이지의 오른쪽 상단에 있는 세 개의 점을 클릭합니다. 세 가지 옵션을 사용할 수 있습니다.

    • 컨트롤러에서 사용
    • delete
    • 서명
  3. 드롭다운 메뉴에서 기호 를 클릭합니다.

서명 서비스는 이미지에 서명합니다. 이미지에 서명하면 상태가 "signed"로 변경됩니다.

6.5. 서명된 이미지에서 정책 사용

podman 또는 기타 이미지 클라이언트에서 정책을 사용하여 해당 서명에 특정 정책을 할당하여 이미지의 유효성을 확인할 수 있습니다.

6.5.1. podman을 사용하여 특정 서명에 의해 이미지가 서명되었는지 확인

특정 서명에 의해 서명이 서명되었는지 확인할 때 서명은 로컬에 있어야 합니다.

절차

  1. 탐색 창에서 서명 키 를 선택합니다.
  2. 사용 중인 서명의 오른쪽에 있는 세 점을 클릭합니다.
  3. 드롭다운 메뉴에서 Download key 를 선택합니다. 새 창이 열립니다.
  4. 이름 필드에 키 이름을 입력합니다.
  5. 저장을 클릭합니다.

6.6. 서명을 확인하도록 클라이언트 구성

Prerequsites

  • 클라이언트에는 서명을 확인하도록 구성된 sudo 권한이 있어야 합니다.

절차

  1. 터미널에서 다음을 입력합니다.

    > sudo <name of editor> __/etc/containers/policy.json__

이 파일은 다음과 유사할 수 있습니다.

    {
        "default": [{"type": "reject"}],
        "transports": {
            "docker": {
              "quay.io": [{"type": "insecureAcceptAnything}],
              "docker.io": [{"type": "insecureAcceptAnything}],
              "_<server-address>_": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/tmp/containersig.txt"
    }

이 명령은 quay.io 또는 docker.io 에서 기본 유형의 거부 를 재정의하는 insecureAcceptAnything 이기 때문에 검증이 없음을 보여줍니다. 그러나 매개변수 유형이 "signedBy"' 로 설정되었으므로 < server-address >에서 확인됩니다.

참고

현재 지원되는 유일한 keyType 은 GPG 키입니다.

  1. &lt ;server-address > 항목에서 키 파일의 이름을 반영하도록 keyPath <1>를 수정합니다.

        {
            "default": [{"type": "reject"}],
            "transports": {
                "docker": {
                  "quay.io": [{"type": "insecureAcceptAnything}],
                  "docker.io": [{"type": "insecureAcceptAnything}],
                  "_<server-address>_1": [
                    {
                        "type": "signedBy",
                        "keyType": "GPGKeys",
                        "keyPath": "/tmp/<key file name", 1
                        "signedIdentity": {
                          "type": "remapIdentity",
                          "prefix": "_<server-address>_",
                          "signedPrefix": "0.0.0.0:8002"
        }
  2. 파일을 저장한 후 닫습니다.
  3. podman 또는 선택한 클라이언트를 사용하여 파일을 가져옵니다.
> podman pull _<server-address>_/<container-name>:<tag name>
--tls-verify=false

이렇게 하면 오류 없이 서명을 확인합니다.

7장. 컨테이너 리포지터리 삭제

로컬 자동화 허브에서 컨테이너 리포지토리를 삭제하여 디스크 공간을 관리합니다. 컨테이너 리포지토리 목록 보기의 Red Hat Ansible Automation Platform 인터페이스에서 리포지토리를 삭제할 수 있습니다.

7.1. 컨테이너 리포지터리 삭제

사전 요구 사항

  • 리포지토리를 관리할 수 있는 권한이 있습니다.

절차

  1. 실행 환경 으로 이동합니다.
  2. 삭제하려는 컨테이너 리포지토리에서 More Actions 아이콘을 클릭한 다음 Delete 를 클릭합니다.
  3. 확인 메시지가 표시되면 확인란을 클릭한 다음 삭제 를 클릭합니다.

검증

  • 실행 환경 목록 보기로 돌아갑니다. 컨테이너 리포지토리는 목록에서 제거해야 합니다.

법적 공지

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.