OpenShift Container Platform에 Red Hat Quay Operator 배포

Red Hat Quay 3.9

OpenShift Container Platform에 Red Hat Quay Operator 배포

Red Hat OpenShift Documentation Team

초록

OpenShift Container Platform 클러스터에 Red Hat Quay Operator 배포

머리말

Red Hat Quay는 엔터프라이즈급 컨테이너 레지스트리입니다. Red Hat Quay를 사용하여 컨테이너 이미지를 빌드 및 저장한 다음 엔터프라이즈 전반에 배포할 수 있도록 합니다.

Red Hat Quay Operator는 OpenShift 클러스터에서 Red Hat Quay를 배포하고 관리하는 간단한 방법을 제공합니다.

Red Hat Quay 3.4.0이 릴리스되면서 개선된 환경을 제공하고 Day 2 작업에 대한 지원을 추가하기 위해 Red Hat Quay Operator가 다시 작성되었습니다. 그 결과 Red Hat Quay Operator를 더 쉽게 사용할 수 있게 되었습니다. Red Hat Quay 3.4.0 이전 버전과의 주요 차이점은 다음과 같습니다.

  • QuayEcosystem 사용자 정의 리소스가 QuayRegistry 사용자 정의 리소스로 교체되었습니다.
  • 기본 설치 옵션은 프로덕션 환경에서 지원되는 모든 관리 종속 항목(데이터베이스, 캐시, 오브젝트 스토리지 등)이 포함된 완전히 지원되는 Red Hat Quay 환경을 생성합니다.

    참고

    일부 구성 요소는 가용성이 높지 않을 수 있습니다.

  • 일관성을 위해 Red Hat Quay 애플리케이션 및 구성 툴에서 공유하는 Red Hat Quay의 구성을 위한 새로운 검증 라이브러리입니다.
  • ObjectBucketClaim Kubernetes API를 사용하여 Red Hat Quay Operator에서 오브젝트 스토리지를 관리할 수 있습니다.

    참고

    Red Hat OpenShift Data Foundation은 OpenShift Container Platform에서 지원되는 API 구현을 제공하는 데 사용할 수 있습니다.

  • 테스트 및 개발 시나리오에 배포된 Pod에서 사용하는 컨테이너 이미지의 사용자 지정

1장. Red Hat Quay Operator 소개

이 장의 콘텐츠를 사용하여 다음을 실행합니다.

  • Red Hat Quay Operator 설치
  • 관리되거나 관리되지 않는 개체 스토리지 구성
  • 데이터베이스, Redis, 경로, TLS 등과 같은 관리되지 않는 구성 요소를 구성합니다.
  • Red Hat Quay Operator를 사용하여 OpenShift Container Platform에 Red Hat Quay 레지스트리 배포
  • Red Hat Quay Operator에서 지원하는 고급 기능 사용
  • Red Hat Quay Operator를 업그레이드하여 레지스트리 업그레이드

1.1. Red Hat Quay Operator 구성 요소

Red Hat Quay에는 상당한 수의 종속 항목이 있습니다. 여기에는 데이터베이스, 오브젝트 스토리지, Redis 등이 포함됩니다. Red Hat Quay Operator는 Red Hat Quay의 의견 배포와 Kubernetes에 대한 종속성을 관리합니다. 이러한 종속 항목은 구성 요소로 처리되며 QuayRegistry API를 통해 구성됩니다.

QuayRegistry 사용자 정의 리소스의 spec.components 필드는 구성 요소를 구성합니다. 각 구성 요소에는 kind (구성 요소의 이름) 및 관리 (구성 요소 라이프사이클이 Red Hat Quay Operator에서 처리되는지 여부를 처리하는 부울) 두 개의 필드가 포함되어 있습니다. 기본적으로 모든 구성 요소는 가시성을 위해 조정 시 관리되고 자동으로 채워집니다.

spec:
  components:
    - kind: quay
      managed: true
    - kind: postgres
      managed: true
    - kind: clair
      managed: true
    - kind: redis
      managed: true
    - kind: horizontalpodautoscaler
      managed: true
    - kind: objectstorage
      managed: true
    - kind: route
      managed: true
    - kind: mirror
      managed: true
    - kind: monitoring
      managed: true
    - kind: tls
      managed: true
    - kind: clairpostgres
      managed: true

1.2. 관리형 구성 요소 사용

QuayRegistry 사용자 정의 리소스가 다른 리소스를 지정하지 않는 한 Red Hat Quay Operator는 다음과 같은 관리 구성 요소에 기본값을 사용합니다.

  • Quay: Red Hat Quay 배포에 대한 재정의가 유지됩니다. 예를 들어 환경 변수 및 복제본 수입니다. 이 구성 요소는 Red Hat Quay 3.7부터 새로운 구성 요소이며 관리되지 않음으로 설정할 수 없습니다.
  • Postgres: 레지스트리 메타데이터를 저장하기 위해 Red Hat Quay 3.9로 Software Collections 의 PostgreSQL 13 버전을 사용합니다.

    참고

    Red Hat Quay 3.8 → 3.9에서 업그레이드할 때 Operator는 PostgreSQL 10 업그레이드를 자동으로 처리합니다. 이 업그레이드는 필수입니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다.

  • Clair: 이미지 취약점 스캔을 제공합니다.
  • Redis: 라이브 빌더 로그 및 Red Hat Quay 튜토리얼을 저장합니다. 가비지 컬렉션에 필요한 잠금 메커니즘도 포함되어 있습니다.
  • HorizontalPodAutoscaler: 메모리/cpu 소비에 따라 Quay Pod 수를 조정합니다.
  • ObjectStorage: 이미지 계층 Blob을 저장하기 위해 Noobaa 또는 RHOCS에서 제공하는 ObjectBucketClaim Kubernetes API를 활용합니다.
  • route: OpenShift Container Platform 외부에서 Red Hat Quay 레지스트리에 외부 진입점을 제공합니다.
  • mirror: 선택적 저장소 미러링을 지원하도록 저장소 미러 작업자를 구성합니다.
  • 모니터링: 기능에는 Grafana 대시보드, 개별 메트릭에 대한 액세스, Quay pod를 자주 다시 시작하라는 경고가 포함됩니다.
  • TLS: Red Hat Quay 또는 OpenShift Container Platform에서 SSL/TLS를 처리할지 여부를 구성합니다.
  • clairpostgres: 관리되는 Clair 데이터베이스를 구성합니다.

Red Hat Quay Operator는 Red Hat Quay가 관리되는 구성 요소를 사용하는 데 필요한 모든 구성 및 설치 작업을 처리합니다. Red Hat Quay Operator에서 수행하는 예상 배포가 사용자 환경에 적합하지 않은 경우 다음 섹션에 설명된 대로 Red Hat Quay Operator에 관리되지 않는 리소스(override)를 제공할 수 있습니다.

1.3. 종속 항목에 관리되지 않는 구성 요소 사용

Red Hat Quay와 함께 사용하려는 PostgreSQL, Redis 또는 오브젝트 스토리지와 같은 기존 구성 요소가 있는 경우 먼저 Red Hat Quay 구성 번들(config.yaml) 내에서 구성합니다. 그런 다음 관리되지 않는 구성 요소를 나타내는 동안 QuayRegistry 번들(Kubernetes 시크릿)에서 참조해야 합니다.

참고
  • Red Hat Quay 구성 편집기를 사용하여 기존 구성 번들을 생성하거나 수정하고 특히 여러 변경 사항에 대해 Kubernetes 보안을 업데이트하는 프로세스를 간소화할 수 있습니다. Red Hat Quay의 구성이 구성 편집기에서 변경되고 Red Hat Quay Operator로 전송되면 새 구성을 반영하도록 배포가 업데이트됩니다.
  • 관리되지 않는 PostgreSQL 데이터베이스를 사용하고 있고 버전이 PostgreSQL 10인 경우 PostgreSQL 13으로 업그레이드하는 것이 좋습니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다. 자세한 내용은 PostgreSQL 버전 관리 정책을 참조하십시오.

관리되지 않는 구성 요소를 구성하려면 다음 섹션을 참조하십시오.

1.4. 구성 번들 시크릿

spec.configBundleSecret 필드는 QuayRegistry 와 동일한 네임스페이스에 있는 Secretmetadata.name 에 대한 참조입니다. 이 시크릿에config.yaml 키/값 쌍이 포함되어야 합니다. 이 config.yaml 파일은 Red Hat Quay config.yaml 파일입니다. 이 필드는 선택 사항이며 제공되지 않는 경우 Red Hat Quay Operator에 의해 자동으로 채워집니다. 제공된 경우 나중에 관리형 구성 요소의 다른 필드와 병합되어 최종 출력 Secret 을 형성한 다음 Red Hat Quay 애플리케이션 pod에 마운트되는 기본 구성 필드 세트 역할을 합니다.

1.5. OpenShift Container Platform에서 Red Hat Quay 사전 요구 사항

OpenShift Container Platform에서 Red Hat Quay Operator 배포를 시작하기 전에 다음을 고려해야 합니다.

1.5.1. OpenShift 클러스터

Red Hat Quay Operator를 배포할 OpenShift Container Platform 4.5 이상 클러스터에 대한 권한 있는 계정이 필요합니다. 해당 계정에는 클러스터 범위에서 네임스페이스를 생성할 수 있어야 합니다.

1.5.2. 리소스 요구 사항

각 Red Hat Quay 애플리케이션 Pod에는 다음과 같은 리소스 요구 사항이 있습니다.

  • 8Gi 메모리
  • 2000 밀리코어 CPU.

Red Hat Quay Operator는 관리하는 Red Hat Quay 배포마다 하나 이상의 애플리케이션 Pod를 생성합니다. OpenShift Container Platform 클러스터에 이러한 요구 사항에 맞는 충분한 컴퓨팅 리소스가 있는지 확인합니다.

1.5.3. 오브젝트 스토리지

기본적으로 Red Hat Quay Operator는 ObjectBucketClaim Kubernetes API를 사용하여 오브젝트 스토리지를 프로비저닝합니다. 이 API를 사용하면 벤더별 구현에서 Red Hat Quay Operator가 분리됩니다. Red Hat OpenShift Data Foundation은 이 예제에서 사용되는 NooBaa 구성 요소를 통해 이 API를 제공합니다.

다음과 같은 지원되는 클라우드 스토리지 옵션을 사용하도록 Red Hat Quay를 수동으로 구성할 수 있습니다.

2장. OperatorHub에서 Red Hat Quay Operator 설치

다음 절차에 따라 OpenShift Container Platform OperatorHub에서 Red Hat Quay Operator를 설치합니다.

절차

  1. OpenShift Container Platform 콘솔을 사용하여 OperatorOperatorHub 를 선택합니다.
  2. 검색 상자에 Red Hat Quay 를 입력하고 Red Hat에서 제공하는 공식 Red Hat Quay Operator를 선택합니다. 그러면 기능, 사전 요구 사항 및 배포 정보를 간략하게 설명하는 설치 페이지로 이동합니다.
  3. 설치를 선택합니다. 그러면 Operator 설치 페이지로 이동합니다.
  4. 설치를 사용자 지정하는 데 다음과 같은 선택 사항을 선택할 수 있습니다.

    1. 업데이트 채널: 최신 릴리스의 경우 업데이트 채널(예: stable- 3.7)을 선택합니다.
    2. 설치 모드: Red Hat Quay Operator 를 클러스터 전체에서 사용하려면 클러스터의 모든 네임스페이스 를 선택합니다. 단일 네임스페이스 내에서만 배포하려면 클러스터의 특정 네임스페이스를 선택합니다. 클러스터 전체에서 Red Hat Quay Operator를 설치하는 것이 좋습니다. 단일 네임스페이스를 선택하면 모니터링 구성 요소를 기본적으로 사용할 수 없습니다.

      • 승인 전략: 자동 또는 수동 업데이트를 승인하도록 선택합니다. 자동 업데이트 전략이 권장됩니다.
  5. 설치를 선택합니다.

3장. 배포 전에 Red Hat Quay 구성

Red Hat Quay Operator는 OpenShift Container Platform에 배포할 때 모든 Red Hat Quay 구성 요소를 관리할 수 있습니다. 그러나 이는 기본 구성이지만 설정을 더 많이 제어하려는 경우 외부에서 하나 이상의 구성 요소를 관리할 수 있습니다.

다음 패턴을 사용하여 관리되지 않는 Red Hat Quay 구성 요소를 구성합니다.

절차

  1. 적절한 설정으로 config.yaml 구성 파일을 생성합니다.
  2. 다음 명령을 입력하여 구성 파일을 사용하여 보안을 생성합니다.

    $ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
  3. 관리되지 않는 구성 요소를 식별하고 생성된 Secret 을 참조하는 quayregistry.yaml 파일을 생성합니다. 예를 들면 다음과 같습니다.

    QuayRegistry YAML 파일의 예

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: example-registry
      namespace: quay-enterprise
    spec:
      configBundleSecret: config-bundle-secret
      components:
        - kind: objectstorage
          managed: false

  4. quayregistry.yaml 파일을 사용하여 레지스트리를 배포합니다.

    $ oc create -n quay-enterprise -f quayregistry.yaml

3.1. 자동화를 위한 Red Hat Quay 사전 구성

Red Hat Quay는 자동화를 활성화하는 여러 구성 옵션을 지원합니다. 사용자는 사용자 인터페이스와 상호 작용의 필요성을 줄이기 위해 배포 전에 이러한 옵션을 구성할 수 있습니다.

3.1.1. API가 첫 번째 사용자를 생성하도록 허용

첫 번째 사용자를 생성하려면 FEATURE_USER_INITIALIZE 매개변수를 true로 설정하고 /api/v1/user/initialize API를 호출해야 합니다. 기존 조직의 OAuth 애플리케이션에서 생성한 OAuth 토큰이 필요한 다른 모든 레지스트리 API 호출과 달리 API 끝점에는 인증이 필요하지 않습니다.

사용자는 다른 사용자가 생성되지 않은 경우 Red Hat Quay를 배포한 후 API를 사용하여 quayadmin 과 같은 사용자를 생성할 수 있습니다. 자세한 내용은 API를 사용하여 첫 번째 사용자 만들기를 참조하십시오.

3.1.2. 일반 API 액세스 활성화

Red Hat Quay 레지스트리 API에 대한 일반적인 액세스를 허용하려면 BROWSER_API_CALLS_XHR_ONLY config 옵션을 false로 설정해야 합니다.

3.1.3. 슈퍼 유저 추가

Red Hat Quay를 배포한 후 사용자는 사용자를 생성하고 전체 권한으로 첫 번째 사용자 관리자 권한을 부여할 수 있습니다. 사용자는 SUPER_USER 구성 오브젝트를 사용하여 사전에 전체 권한을 구성할 수 있습니다. 예를 들면 다음과 같습니다.

...
SERVER_HOSTNAME: quay-server.example.com
SETUP_COMPLETE: true
SUPER_USERS:
  - quayadmin
...

3.1.4. 사용자 생성 제한

슈퍼유저를 구성한 후 FEATURE_USER_CREATIONfalse 로 설정하여 슈퍼유저 그룹에 새 사용자를 생성하는 기능을 제한할 수 있습니다. 예를 들면 다음과 같습니다.

...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
...

3.1.5. Red Hat Quay 3.8에서 새 기능 활성화

새로운 Red Hat Quay 3.8 기능을 사용하려면 다음 기능 중 일부 또는 모두를 활성화합니다.

...
FEATURE_UI_V2: true
FEATURE_LISTEN_IP_VERSION:
FEATURE_SUPERUSERS_FULL_ACCESS: true
GLOBAL_READONLY_SUPER_USERS:
      -
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST:
      -
...

3.1.6. Red Hat Quay 3.7에서 새 기능 활성화

새로운 Red Hat Quay 3.7 기능을 사용하려면 다음 기능 중 일부 또는 모두를 활성화합니다.

...
FEATURE_QUOTA_MANAGEMENT: true
FEATURE_BUILD_SUPPORT: true
FEATURE_PROXY_CACHE: true
FEATURE_STORAGE_REPLICATION: true
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000
...

3.1.7. 자동화에 권장되는 구성

다음 config.yaml 매개변수가 자동화를 위해 제안됩니다.

...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
...

3.2. 오브젝트 스토리지 구성

Red Hat Quay Operator가 스토리지를 관리하거나 직접 관리할 수 있는지 여부에 관계없이 Red Hat Quay를 설치하기 전에 오브젝트 스토리지를 구성해야 합니다.

Red Hat Quay Operator가 스토리지 관리를 담당하는 경우 NooBaa 및 Red Hat OpenShift Data Foundations Operator 설치 및 구성에 대한 정보는 관리형 스토리지 의 섹션을 참조하십시오.

별도의 스토리지 솔루션을 사용하는 경우 Operator를 구성할 때 objectstorage관리되지 않음 으로 설정합니다. 다음 섹션을 참조하십시오. 기존 스토리지 구성에 대한 자세한 내용은 관리되지 않는 스토리지입니다.

3.2.1. 관리되지 않는 스토리지 사용

이 섹션에서는 편의를 위해 관리되지 않는 스토리지에 대한 구성 예제를 제공합니다. 오브젝트 스토리지 설정 방법에 대한 자세한 내용은 Red Hat Quay 구성 가이드를 참조하십시오.

3.2.1.1. AWS S3 스토리지

Red Hat Quay 배포를 위해 AWS S3 스토리지를 구성할 때 다음 예제를 사용합니다.

DISTRIBUTED_STORAGE_CONFIG:
  s3Storage:
    - S3Storage
    - host: s3.us-east-2.amazonaws.com
      s3_access_key: ABCDEFGHIJKLMN
      s3_secret_key: OL3ABCDEFGHIJKLMN
      s3_bucket: quay_bucket
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - s3Storage

3.2.1.2. Google Cloud 스토리지

Red Hat Quay 배포를 위해 Google Cloud 스토리지를 구성할 때 다음 예제를 사용합니다.

DISTRIBUTED_STORAGE_CONFIG:
    googleCloudStorage:
        - GoogleCloudStorage
        - access_key: GOOGQIMFB3ABCDEFGHIJKLMN
          bucket_name: quay-bucket
          secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
          storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - googleCloudStorage

3.2.1.3. Microsoft Azure 스토리지

Red Hat Quay 배포를 위해 Microsoft Azure 스토리지를 구성할 때 다음 예제를 사용합니다.

DISTRIBUTED_STORAGE_CONFIG:
  azureStorage:
    - AzureStorage
    - azure_account_name: azure_account_name_here
      azure_container: azure_container_here
      storage_path: /datastorage/registry
      azure_account_key: azure_account_key_here
      sas_token: some/path/
      endpoint_url: https://[account-name].blob.core.usgovcloudapi.net 1
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - azureStorage
1
Microsoft Azure 스토리지의 endpoint_url 매개변수는 선택 사항이며 Microsoft Azure Government (MAG) 끝점과 함께 사용할 수 있습니다. 비워 두면 endpoint_url 이 일반 Microsoft Azure 리전에 연결됩니다.

Red Hat Quay 3.7부터 MAG Blob 서비스의 기본 끝점을 사용해야 합니다. MAG Blob 서비스의 보조 끝점을 사용하면 다음과 같은 오류가 발생합니다. AuthenticationErrorDetail:Cannot find the claimed account when trying to GetProperties for the account whusc8-secondary.

3.2.1.4. Ceph/RadosGW Storage

Red Hat Quay 배포를 위해 Ceph/RadosGW 스토리지를 구성할 때 다음 예제를 사용합니다.

DISTRIBUTED_STORAGE_CONFIG:
  radosGWStorage: #storage config name
    - RadosGWStorage #actual driver
    - access_key: access_key_here #parameters
      secret_key: secret_key_here
      bucket_name: bucket_name_here
      hostname: hostname_here
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: #must contain name of the storage config
    - radosGWStorage

3.2.1.5. Swift 스토리지

Red Hat Quay 배포를 위해 Swift 스토리지를 구성할 때 다음 예제를 사용합니다.

DISTRIBUTED_STORAGE_CONFIG:
  swiftStorage:
    - SwiftStorage
    - swift_user: swift_user_here
      swift_password: swift_password_here
      swift_container: swift_container_here
      auth_url: https://example.org/swift/v1/quay
      auth_version: 1
      ca_cert_path: /conf/stack/swift.cert"
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - swiftStorage

3.2.1.6. NooBaa 관리되지 않는 스토리지

다음 절차에 따라 NooBaa를 관리되지 않는 스토리지 구성으로 배포합니다.

절차

  1. 스토리지 → 오브젝트 버킷 클레임으로 이동하여 Red Hat Quay 콘솔에서 NooBaa Object Bucket Claims 를 생성합니다.
  2. 액세스 키, 버킷 이름, 끝점(hostname) 및 시크릿 키를 포함하여 오브젝트 버킷 클레임 데이터 세부 정보를 검색합니다.
  3. Object Bucket Claim에 대한 정보를 사용하는 config.yaml 구성 파일을 생성합니다.

    DISTRIBUTED_STORAGE_CONFIG:
      default:
        - RHOCSStorage
        - access_key: WmrXtSGk8B3nABCDEFGH
          bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef
          hostname: s3.openshift-storage.svc.cluster.local
          is_secure: true
          port: "443"
          secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD
          storage_path: /datastorage/registry
    DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
    DISTRIBUTED_STORAGE_PREFERENCE:
      - default

오브젝트 버킷 클레임 구성에 대한 자세한 내용은 오브젝트 버킷 클레임을 참조하십시오.

3.2.2. 관리되지 않는 NooBaa 인스턴스 사용

Red Hat Quay 배포에 관리되지 않는 NooBaa 인스턴스를 사용하려면 다음 절차를 사용하십시오.

절차

  1. 스토리지 → 오브젝트 버킷 클레임의 콘솔에 NooBaa Object Bucket Claims를 생성합니다.
  2. 액세스 키, 버킷이름,엔드포인트(hostname)시크릿 키를 포함하여 오브젝트 버킷 클레임 데이터 세부 정보를 검색합니다.
  3. Object Bucket Claim에 대한 정보를 사용하여 config.yaml 구성 파일을 생성합니다. 예를 들면 다음과 같습니다.

    DISTRIBUTED_STORAGE_CONFIG:
      default:
        - RHOCSStorage
        - access_key: WmrXtSGk8B3nABCDEFGH
          bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef
          hostname: s3.openshift-storage.svc.cluster.local
          is_secure: true
          port: "443"
          secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD
          storage_path: /datastorage/registry
    DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
    DISTRIBUTED_STORAGE_PREFERENCE:
      - default

3.2.3. 관리형 스토리지

Red Hat Quay Operator에서 Red Hat Quay용 오브젝트 스토리지를 관리하려면 클러스터에서 ObjectBucketClaim API를 통해 오브젝트 스토리지를 제공할 수 있어야 합니다. Red Hat OpenShift Data Foundation Operator를 사용하면 다음과 같은 두 가지 옵션을 사용할 수 있습니다.

  • 로컬 Kubernetes PersistentVolume 스토리지에서 지원하는 Multi-Cloud Object Gateway의 독립 실행형 인스턴스

    • 고가용성이 아님
    • Red Hat Quay 서브스크립션에 포함
    • Red Hat OpenShift Data Foundation에 대한 별도의 서브스크립션이 필요하지 않음
  • 스케일 아웃 오브젝트 서비스 및 Ceph를 사용하는 Red Hat OpenShift Data Foundation의 프로덕션 배포

    • 고가용성
    • Red Hat OpenShift Data Foundation에 대해 별도의 서브스크립션이 필요

독립 실행형 인스턴스 옵션을 사용하려면 아래에서 계속 읽습니다. Red Hat OpenShift Data Foundation의 프로덕션 배포는 공식 문서를 참조하십시오.

참고

오브젝트 스토리지 디스크 공간은 50GiB의 Red Hat Quay Operator에 의해 자동으로 할당됩니다. 이 수는 대부분의 소규모에서 중간 규모의 Red Hat Quay 설치에 사용 가능한 스토리지 양을 나타내지만 사용 사례에는 충분하지 않을 수 있습니다. Red Hat OpenShift Data Foundation 볼륨 크기 조정은 현재 Red Hat Quay Operator에 의해 처리되지 않습니다. 자세한 내용은 관리 스토리지 크기 조정 섹션을 참조하십시오.

3.2.3.1. Red Hat OpenShift Data Foundation Operator for Red Hat Quay에서 Multicloud Object Gateway 구성 요소 활용

Red Hat Quay 서브스크립션의 일부로 사용자는 Red Hat OpenShift Data Foundation Operator(이전의 OpenShift Container Storage Operator라고도 함)의 Multicloud Object Gateway 구성 요소를 사용할 수 있습니다. 이 게이트웨이 구성 요소를 사용하면 Kubernetes PersistentVolume- 기반 블록 스토리지에서 지원하는 Red Hat Quay에 S3 호환 오브젝트 스토리지 인터페이스를 제공할 수 있습니다. 사용량은 Operator에서 관리하는 Red Hat Quay 배포와 아래에 설명된 대로 multicloud Object Gateway 인스턴스의 정확한 사양으로 제한됩니다.

Red Hat Quay는 로컬 파일 시스템 스토리지를 지원하지 않으므로 사용자는 Kubernetes PersistentVolume 스토리지와 함께 게이트웨이를 활용하여 지원되는 배포를 제공할 수 있습니다. PersistentVolume 은 오브젝트 스토리지의 백업 저장소로 게이트웨이 인스턴스에 직접 마운트되며 모든 블록 기반 StorageClass 가 지원됩니다.

PersistentVolume 의 특성에 따라 이는 확장 가능한 고가용성 솔루션이 아니며 Red Hat OpenShift Data Foundation과 같은 스케일 아웃 스토리지 시스템을 대체하지 않습니다. 게이트웨이의 단일 인스턴스만 실행되고 있습니다. 일정 변경, 업데이트 또는 계획되지 않은 다운타임으로 인해 게이트웨이를 실행하는 Pod를 사용할 수 없게 되면 연결된 Red Hat Quay 인스턴스가 일시적으로 저하됩니다.

다음 절차를 사용하여 Local Storage Operator, Red Hat OpenShift Data Foundation을 설치하고 독립 실행형 Multicloud Object Gateway를 생성하여 OpenShift Container Platform에 Red Hat Quay를 배포합니다.

참고

다음 문서는 공식 Red Hat OpenShift Data Foundation 설명서 와 공통성을 공유합니다.

3.2.3.1.1. OpenShift Container Platform에 Local Storage Operator 설치

로컬 스토리지 장치에서 Red Hat OpenShift Data Foundation 클러스터를 생성하기 전에 Operator Hub 에서 Local Storage Operator를 설치하려면 다음 절차를 사용하십시오.

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. OperatorsOperatorHub를 클릭합니다.
  3. 검색 상자에 로컬 스토리지를 입력하여 Operator 목록에서 Local Storage Operator를 찾습니다. 로컬 스토리지를 클릭합니다.
  4. 설치를 클릭합니다.
  5. Operator 설치 페이지에서 다음 옵션을 설정합니다.

    • Update channel의 경우 stable 을 선택합니다.
    • 설치 모드의 경우 클러스터에서 특정 네임스페이스를 선택합니다.
    • 설치된 네임스페이스의 경우 Operator 권장 네임스페이스 openshift-local-storage 를 선택합니다.
    • 업데이트 승인의 경우 자동 을 선택합니다.
  6. 설치를 클릭합니다.
3.2.3.1.2. OpenShift Container Platform에 Red Hat OpenShift Data Foundation 설치

OpenShift Container Platform에 Red Hat OpenShift Data Foundation을 설치하려면 다음 절차를 사용하십시오.

사전 요구 사항

  • cluster-admin 및 Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 클러스터에 3개 이상의 작업자 노드가 있어야 합니다.
  • 추가 리소스 요구 사항은 배포 계획 가이드를 참조하십시오.

절차

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. OperatorsOperatorHub를 클릭합니다.
  3. 검색 상자에 OpenShift Data Foundation 을 입력합니다. OpenShift Data Foundation 을 클릭합니다.
  4. 설치를 클릭합니다.
  5. Operator 설치 페이지에서 다음 옵션을 설정합니다.

    • Update channel의 경우 최신 stable 버전을 선택합니다.
    • 설치 모드의 경우 클러스터에서 특정 네임스페이스를 선택합니다.
    • 설치된 네임스페이스의 경우 Operator 권장 네임스페이스: openshift-storage 를 선택합니다.
    • 업데이트 승인의 경우 자동 또는 수동 을 선택합니다.

      자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)은 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다.

      수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 최신 버전으로 업데이트하기 위해 해당 업데이트 요청을 수동으로 승인해야 합니다.

    • 콘솔 플러그인의 경우 Enable 을 선택합니다.
  6. 설치를 클릭합니다.

    Operator가 설치되면 메시지가 포함된 팝업이 사용자 인터페이스에 웹 콘솔 업데이트를 사용할 수 있습니다. 콘솔 변경 사항을 반영하려면 이 팝업 창에서 웹 콘솔 새로 고침을 클릭합니다.

  7. Red Hat Quay의 Multicloud Object Gateway 구성 요소를 활용하기 위해 "독립 실행형 Multicloud Object Gateway" 섹션을 계속 진행합니다.
3.2.3.1.3. OpenShift Container Platform UI를 사용하여 독립 실행형 Multicloud Object Gateway 생성

다음 절차에 따라 독립 실행형 Multicloud Object Gateway를 생성합니다.

사전 요구 사항

  • Local Storage Operator가 설치되어 있습니다.
  • Red Hat OpenShift Data Foundation Operator를 설치했습니다.

절차

  1. OpenShift 웹 콘솔에서 Operator설치된 Operator 를 클릭하여 설치된 모든 Operator를 확인합니다.

    네임스페이스가 openshift-storage 인지 확인합니다.

  2. 스토리지 시스템 생성을 클릭합니다.
  3. 백업 스토리지 페이지에서 다음을 선택합니다.

    1. 배포 유형 용으로 Multicloud Object Gateway를 선택합니다.
    2. 로컬 스토리지 장치 옵션을 사용하여 새 StorageClass 만들기 옵션을 선택합니다.
    3. 다음을 클릭합니다.

      참고

      아직 설치되지 않은 경우 Local Storage Operator를 설치하라는 메시지가 표시됩니다. 설치를 클릭하고 "OpenShift Container Platform에 Local Storage Operator 설치"에 설명된 절차를 따르십시오.

  4. 로컬 볼륨 세트 생성 페이지에서 다음 정보를 제공합니다.

    1. 로컬 볼륨 세트의 이름과 스토리지 클래스를 입력합니다. 기본적으로 스토리지 클래스 이름에 로컬 볼륨 세트 이름이 표시됩니다. 이름을 변경할 수 있습니다.
    2. 다음 중 하나를 선택합니다.

      • 모든 노드의 디스크

        모든 노드에서 선택한 필터와 일치하는 사용 가능한 디스크를 사용합니다.

      • 선택한 노드의 디스크

        선택한 노드에서만 선택한 필터와 일치하는 사용 가능한 디스크를 사용합니다.

    3. 사용 가능한 디스크 유형 목록에서 SSD/NVMe을 선택합니다.
    4. 고급 섹션을 확장하고 다음 옵션을 설정합니다.

      볼륨 모드

      파일 시스템은 기본적으로 선택됩니다. 항상 볼륨 모드에 대해 파일 시스템이 선택되어 있는지 확인합니다.

      장치 유형

      드롭다운 목록에서 하나 이상의 장치 유형을 선택합니다.

      디스크 크기

      장치에 대해 최소 크기 100GB와 포함되어야 하는 장치의 사용 가능한 최대 크기를 설정합니다.

      최대 디스크 제한

      이는 노드에서 생성할 수 있는 최대 PV 수를 나타냅니다. 이 필드가 비어 있으면 일치하는 노드에서 사용 가능한 모든 디스크에 PV가 생성됩니다.

    5. 다음을클릭합니다.

      LocalVolumeSet 생성이 표시되는지 확인하는 팝업이 표시됩니다.

    6. 계속하려면 를 클릭합니다.
  5. 용량 및 노드 페이지에서 다음을 구성합니다.

    1. 사용 가능한 원시 용량 은 스토리지 클래스와 연결된 모든 디스크에 따라 용량 값으로 채워집니다. 이 작업을 수행하는 데 시간이 다소 걸립니다. 선택한 노드 목록에는 스토리지 클래스를 기반으로 하는 노드가 표시됩니다.
    2. 다음을 클릭하여 계속합니다.
  6. 선택 사항: 외부 키 관리 서비스에 연결 확인란을 선택합니다. 이는 클러스터 전체 암호화의 경우 선택 사항입니다.

    1. 키 관리 서비스 공급자 드롭다운 목록에서 Vault 또는 Thales CipherTrust Manager(KMIP 사용) 를 선택합니다. Vault 를 선택한 경우 다음 단계로 이동합니다. Thales CipherTrust Manager(KMIP를 사용하여) 를 선택한 경우 iii 단계로 이동합니다.
    2. 인증 방법을 선택합니다.

      토큰 인증 방법 사용

      • 고유한 연결 이름, Vault 서버의 호스트 주소 ('https://<hostname or ip>'), 포트 번호 및 토큰 을 입력합니다.
      • 고급 설정을 확장하여 Vault 구성에 따라 추가 설정 및 인증서 세부 정보를 입력합니다.

        • OpenShift Data Foundation 전용 및 고유한 백엔드 경로에 키 값 시크릿 경로를 입력합니다.
        • 선택 사항: TLS 서버 이름Vault Enterprise 네임스페이스 를 입력합니다.
        • 각 PEM 인코딩 인증서 파일을 업로드하여 CA 인증서,클라이언트 인증서클라이언트 개인 키를 제공합니다.
        • 저장을 클릭하고 단계 활성화로 건너뜁니다.

          Kubernetes 인증 방법 사용

      • 고유한 Vault 연결 이름, Vault 서버의 호스트 주소 ('https://<hostname or ip>'), 포트 번호 및 역할 이름을 입력합니다.
      • 고급 설정을 확장하여 Vault 구성에 따라 추가 설정 및 인증서 세부 정보를 입력합니다.

        • Red Hat OpenShift Data Foundation 전용 및 고유한 백엔드 경로에 키 값 시크릿 경로를 입력합니다.
        • 선택 사항: 해당하는 경우 TLS 서버 이름인증 경로를 입력합니다.
        • 각 PEM 인코딩 인증서 파일을 업로드하여 CA 인증서,클라이언트 인증서클라이언트 개인 키를 제공합니다.
        • 저장을 클릭하고 단계 활성화로 건너뜁니다.
    3. Thales CipherTrust Manager (KMIP 사용) 를 KMS 공급자로 사용하려면 다음 단계를 따르십시오.

      1. 프로젝트 내에서 키 관리 서비스에 대한 고유한 연결 이름을 입력합니다.
      2. 주소포트 섹션에서 Thales CipherTrust Manager의 IP와 KMIP 인터페이스가 활성화된 포트를 입력합니다. 예를 들면 다음과 같습니다.

        • 주소: 123.34.3.2
        • 포트: 5696
      3. 클라이언트 인증서,CA 인증서클라이언트 개인 키를 업로드합니다.
      4. StorageClass 암호화가 활성화된 경우 위에서 생성된 암호화 및 암호 해독에 사용할 고유 ID를 입력합니다.
      5. TLS Server 필드는 선택 사항이며 KMIP 엔드포인트에 대한 DNS 항목이 없을 때 사용됩니다. 예를 들어kmip_all_<port>.ciphertrustmanager.local.
    4. 네트워크를 선택합니다.
    5. 다음을 클릭합니다.
  7. 검토 및 생성 페이지에서 구성 세부 정보를 검토합니다. 구성 설정을 수정하려면 뒤로를 클릭합니다.
  8. 스토리지 시스템 생성을 클릭합니다.
3.2.3.1.4. CLI를 사용하여 독립 실행형 Multicloud Object Gateway 생성

다음 절차에 따라 Red Hat OpenShift Data Foundation(이전의 OpenShift Container Storage) Operator를 설치하고 단일 인스턴스 Multi-Cloud Gateway 서비스를 구성합니다.

참고

Red Hat OpenShift Data Foundation이 설치된 클러스터에서는 다음 구성을 병렬로 실행할 수 없습니다.

절차

  1. OpenShift 웹 콘솔에서 OperatorOperatorHub 를 선택합니다.
  2. Red Hat OpenShift Data Foundation 을 검색한 다음 설치를 선택합니다.
  3. 모든 기본 옵션을 수락한 다음 설치를 선택합니다.
  4. Succeeded 로 표시되어야 하는 Status 열을 확인하여 Operator가 설치되었는지 확인합니다.

    주의

    Red Hat OpenShift Data Foundation Operator 설치가 완료되면 스토리지 시스템을 생성하라는 메시지가 표시됩니다. 이 지침을 따르지 마십시오. 대신 다음 단계에 설명된 대로 NooBaa 오브젝트 스토리지를 생성합니다.

  5. 시스템에서 다음 정보를 사용하여 noobaa.yaml 이라는 파일을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: noobaa
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: '0.1'
         memory: 1Gi
     dbType: postgres
     coreResources:
       requests:
         cpu: '0.1'
         memory: 1Gi

    이렇게 하면 Multi-cloud Object Gateway 의 단일 인스턴스 배포가 생성됩니다.

  6. 다음 명령을 사용하여 구성을 적용합니다.

    $ oc create -n openshift-storage -f noobaa.yaml

    출력 예

    noobaa.noobaa.io/noobaa created

  7. 몇 분 후에 Multi-cloud Object Gateway 가 프로비저닝을 완료해야 합니다. 다음 명령을 입력하여 상태를 확인할 수 있습니다.

    $ oc get -n openshift-storage noobaas noobaa -w

    출력 예

    NAME     MGMT-ENDPOINTS              S3-ENDPOINTS                IMAGE                                                                                                            PHASE   AGE
    noobaa   [https://10.0.32.3:30318]   [https://10.0.32.3:31958]   registry.redhat.io/ocs4/mcg-core-rhel8@sha256:56624aa7dd4ca178c1887343c7445a9425a841600b1309f6deace37ce6b8678d   Ready   3d18h

  8. noobaa-pv-backing-store.yaml 이라는 YAML 파일을 생성하여 게이트웨이에 대한 백업 저장소를 구성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: noobaa-pv-backing-store
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 1
        resources:
          requests:
            storage: 50Gi 1
        storageClass: STORAGE-CLASS-NAME 2
      type: pv-pool
    1
    오브젝트 스토리지 서비스의 전체 용량입니다. 필요에 따라 조정합니다.
    2
    요청된 PersistentVolume에 사용할 StorageClass 입니다. 클러스터 기본값을 사용하려면 이 속성을 삭제합니다.
  9. 다음 명령을 입력하여 구성을 적용합니다.

    $ oc create -f noobaa-pv-backing-store.yaml

    출력 예

    backingstore.noobaa.io/noobaa-pv-backing-store created

    이렇게 하면 게이트웨이에 대한 백업 저장소 구성이 생성됩니다. Red Hat Quay의 모든 이미지는 위의 구성으로 생성된 PersistentVolume 의 게이트웨이를 통해 오브젝트로 저장됩니다.

  10. 다음 명령을 실행하여 Red Hat Quay Operator에서 발행한 모든 ObjectBucketClaims 의 기본값을 PersistentVolume 백업 저장소로 설정합니다.

    $ oc patch bucketclass noobaa-default-bucket-class --patch '{"spec":{"placementPolicy":{"tiers":[{"backingStores":["noobaa-pv-backing-store"]}]}}}' --type merge -n openshift-storage

4장. 데이터베이스 구성

4.1. 기존 PostgreSQL 데이터베이스 사용

외부 관리형 PostgreSQL 데이터베이스를 사용하는 경우 성공적인 배포를 위해 pg_trgm 확장을 수동으로 활성화해야 합니다.

기존 PostgreSQL 데이터베이스를 배포하려면 다음 절차를 사용하십시오.

절차

  1. 필요한 데이터베이스 필드를 사용하여 config.yaml 파일을 생성합니다. 예를 들면 다음과 같습니다.

    config.yaml 파일의 예:

    DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database

  2. 구성 파일을 사용하여 보안을 생성합니다.

    $ kubectl create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
  3. postgres 구성 요소를 관리되지 않음 으로 표시하고 생성된 Secret 을 참조하는 QuayRegistry YAML 파일을 만듭니다. 예를 들면 다음과 같습니다.

    quayregistry.yaml 파일 예

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: example-registry
      namespace: quay-enterprise
    spec:
      configBundleSecret: config-bundle-secret
      components:
        - kind: postgres
          managed: false

  4. 다음 섹션에 설명된 대로 레지스트리를 배포합니다.

4.1.1. 데이터베이스 구성

이 섹션에서는 Red Hat Quay 배포에 사용할 수 있는 데이터베이스 구성 필드에 대해 설명합니다.

4.1.1.1. 데이터베이스 URI

Red Hat Quay를 사용하면 필수 DB_URI 필드를 사용하여 데이터베이스에 대한 연결이 구성됩니다.

다음 표에서는 DB_URI 구성 필드에 대해 설명합니다.

표 4.1. 데이터베이스 URI

필드유형설명

DB_URI
(필수)

문자열

자격 증명을 포함하여 데이터베이스에 액세스하기 위한 URI입니다.

DB_URI 필드 예:

postgresql://quayuser:quaypass@quay-server.example.com:5432/quay

4.1.1.2. 데이터베이스 연결 인수

선택적 연결 인수는 DB_CONNECTION_ARGS 매개변수에 의해 구성됩니다. DB_CONNECTION_ARGS 에 정의된 일부 키-값 쌍은 일반적이지만 다른 값은 데이터베이스에 따라 다릅니다.

다음 표에서는 데이터베이스 연결 인수를 설명합니다.

표 4.2. 데이터베이스 연결 인수

필드유형설명

DB_CONNECTION_ARGS

개체

데이터베이스의 선택적 연결 인수(예: 시간 초과 및 SSL/TLS)입니다.

.autorollback

부울

스레드 로컬 연결 사용 여부입니다.
항상 true여야 합니다.

.threadlocals

부울

자동 롤백 연결을 사용할지 여부입니다.
항상 true여야 합니다.

4.1.1.2.1. PostgreSQL SSL/TLS 연결 인수

SSL/TLS를 사용하면 배포 중인 데이터베이스에 따라 구성이 달라집니다. 다음 예제에서는 PostgreSQL SSL/TLS 구성을 보여줍니다.

DB_CONNECTION_ARGS:
  sslmode: verify-ca
  sslrootcert: /path/to/cacert

sslmode 옵션은 보안 SSL/TLS TCP/IP 연결이 서버와 협상될 우선순위를 결정합니다. 여섯 가지 모드가 있습니다.

표 4.3. SSL/TLS 옵션

mode설명

disable

구성은 SSL/TLS 연결만 시도합니다.

allow

구성은 먼저 비 SSL/TLS 연결을 시도합니다. 실패하면 SSL/TLS 연결을 시도합니다.


(기본값)

구성은 먼저 SSL/TLS 연결을 시도합니다. 실패하면 SSL/TLS 연결을 시도합니다.

require

구성은 SSL/TLS 연결만 시도합니다. 루트 CA 파일이 있는 경우 verify-ca가 지정된 것과 동일한 방식으로 인증서를 확인합니다.

verify-ca

구성은 SSL/TLS 연결만 시도하며 신뢰할 수 있는 CA(인증 기관)에서 서버 인증서를 발급하는지 확인합니다.

verify-full

SSL/TLS 연결만 시도한 후 서버 인증서가 신뢰할 수 있는 CA에서 발행되고 요청된 서버 호스트 이름이 인증서에서 해당 이름과 일치하는지 확인합니다.

PostgreSQL에 대한 유효한 인수에 대한 자세한 내용은 데이터베이스 연결 제어 기능을 참조하십시오.

4.1.1.2.2. MySQL SSL/TLS 연결 인수

다음 예제에서는 샘플 MySQL SSL/TLS 구성을 보여줍니다.

DB_CONNECTION_ARGS:
  ssl:
    ca: /path/to/cacert

MySQL의 유효한 연결 인수에 대한 정보는 URI-Like Strings 또는 Key-Value pairs를 사용하여 서버에 연결할 때 사용할 수 있습니다.

4.1.2. 관리형 PostgreSQL 데이터베이스 사용

Red Hat Quay 3.9를 사용하면 Red Hat Quay Operator에서 데이터베이스를 관리하는 경우 Red Hat Quay 3.8 → 3.9에서 업데이트하면 PostgreSQL 10에서 PostgreSQL 13으로의 업그레이드를 자동으로 처리합니다.

중요
  • 관리형 데이터베이스가 있는 사용자는 PostgreSQL 데이터베이스를 10 → 13에서 업그레이드해야 합니다.
  • Operator에서 Red Hat Quay 및 Clair 데이터베이스를 관리하는 경우 3.9.0 업그레이드가 성공하려면 각 구성 요소의 데이터베이스 업그레이드가 성공해야 합니다. 데이터베이스 업그레이드 중 하나가 실패하면 전체 Red Hat Quay 버전 업그레이드가 실패합니다. 이 동작이 예상됩니다.

Red Hat Quay Operator가 PostgreSQL 배포를 PostgreSQL 10 → 13에서 업그레이드하지 않으려면 quayregistry.yaml 파일에서 PostgreSQL 매개변수를 managed: false 로 설정해야 합니다. 데이터베이스를 Unmanaged로 설정하는 방법에 대한 자세한 내용은 기존 Postgres 데이터베이스 사용을 참조하십시오.

중요
  • PostgreSQL 13으로 업그레이드하는 것이 좋습니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다. 자세한 내용은 PostgreSQL 버전 관리 정책을 참조하십시오.

PostgreSQL 데이터베이스가 RHEL(Red Hat Enterprise Linux) 시스템과 동일한 버전을 일치시키려면 RHEL 8용 RHEL 8 버전으로 마이그레이션 하거나 RHEL 9용 RHEL 9 버전의 PostgreSQL으로 마이그레이션 을 참조하십시오.

Red Hat Quay 3.8 → 3.9 절차에 대한 자세한 내용은 "OpenShift Container Platform에서 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스 업그레이드"를 참조하십시오.

4.1.2.1. PostgreSQL 데이터베이스 권장 사항

Red Hat Quay 팀은 PostgreSQL 데이터베이스를 관리하기 위해 다음을 권장합니다.

  • 데이터베이스 백업은 PostgreSQL 이미지 또는 자체 백업 인프라에서 제공된 툴을 사용하여 정기적으로 수행해야 합니다. Red Hat Quay Operator는 현재 PostgreSQL 데이터베이스가 백업되었는지 확인하지 않습니다.
  • 백업에서 PostgreSQL 데이터베이스 복원은 PostgreSQL 툴 및 절차를 사용하여 수행해야 합니다. 데이터베이스 복원이 진행 중인 동안 Quay pod가 실행되지 않아야 합니다.
  • 데이터베이스 디스크 공간은 50GiB의 Red Hat Quay Operator에 의해 자동으로 할당됩니다. 이 수는 대부분의 소규모에서 중간 규모의 Red Hat Quay 설치에 사용 가능한 스토리지 양을 나타내지만 사용 사례에는 충분하지 않을 수 있습니다. 데이터베이스 볼륨 크기 조정은 현재 Red Hat Quay Operator에 의해 처리되지 않습니다.

4.2. SSL/TLS 및 경로 구성

OpenShift Container Platform Edge-Termination Routes에 대한 지원이 새로 관리되는 구성 요소 tls 를 통해 추가되었습니다. 이를 통해 SSL/TLS의 경로 구성 요소를 분리하고 사용자가 둘 다 별도로 구성할 수 있습니다.

EXTERNAL_TLS_TERMINATION: true 는 의견 설정입니다.

  • Managed tls 는 기본 클러스터 와일드카드 인증서가 사용됨을 의미합니다.
  • Unmanaged tls 는 사용자가 제공한 키 및 인증서 쌍을 경로에 삽입함을 나타냅니다.

이제 ssl.certssl.key 가 별도의 영구 보안으로 이동되어 키 및 인증서 쌍이 모든 조정 시 다시 생성되지 않습니다. 키 및 인증서 쌍은 이제 에지 경로로 포맷되고 Quay 컨테이너의 동일한 디렉터리에 마운트됩니다.

SSL/TLS 및 경로를 구성할 때 여러 순으로 변경할 수 있지만 다음 규칙이 적용됩니다.

  • SSL/TLS가 관리되는 경우 경로도 관리해야 합니다.
  • SSL/TLS가 관리되지 않는 경우 구성 툴을 사용하거나 구성 번들에서 직접 인증서를 제공해야 합니다.

다음 표에서는 유효한 옵션을 설명합니다.

표 4.4. TLS 및 경로에 유효한 구성 옵션

옵션경로TLS인증서 제공결과

자체 로드 밸런서에서 TLS를 처리합니다.

Managed

Managed

없음

기본 와일드카드 인증서가 있는 엣지 경로

Red Hat Quay handles TLS

Managed

Unmanaged

제공됨

Pod 내부에 마운트된 인증서가 있는 패스스루 경로

Red Hat Quay handles TLS

Unmanaged

Unmanaged

제공됨

인증서는 quay pod 내부에 설정되지만 경로를 수동으로 생성해야 합니다.

참고

Operator에서 TLS를 관리할 때 Red Hat Quay 3.7은 빌더를 지원하지 않습니다.

4.2.1. SSL/TLS 인증서 및 키 쌍을 사용하여 구성 번들 보안 생성

다음 절차에 따라 고유한 SSL/TLS 인증서 및 키 쌍이 포함된 구성 번들 시크릿을 생성합니다.

절차

  • 다음 명령을 입력하여 고유한 SSL/TLS 인증서 및 키 쌍을 포함하는 구성 번들 시크릿을 생성합니다.

    $ oc create secret generic --from-file config.yaml=./config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret

4.3. 외부 Redis 구성

이 섹션의 콘텐츠를 사용하여 외부 Redis 배포를 설정합니다.

4.3.1. 관리되지 않는 Redis 데이터베이스 사용

다음 절차에 따라 외부 Redis 데이터베이스를 설정합니다.

절차

  1. 다음 Redis 필드를 사용하여 config.yaml 파일을 생성합니다.

    BUILDLOGS_REDIS:
        host: quay-server.example.com
        port: 6379
        ssl: false
    
    USER_EVENTS_REDIS:
        host: quay-server.example.com
        port: 6379
        ssl: false
  2. 다음 명령을 입력하여 구성 파일을 사용하여 시크릿을 생성합니다.

    $ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
  3. Redis 구성 요소를 Unmanaged 로 설정하고 생성된 보안을 참조하는 quayregistry.yaml 파일을 생성합니다.

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: example-registry
      namespace: quay-enterprise
    spec:
      configBundleSecret: config-bundle-secret
      components:
        - kind: redis
          managed: false
  4. Red Hat Quay 레지스트리를 배포합니다.

추가 리소스

Redis 구성 필드

4.3.2. 관리되지 않는 Horizontal Pod Autoscaler 사용

이제 HPA(Horizontal Pod Autoscalers)가 Clair,Quay, Mirror Pod에 포함되어 로드 급증 중에 자동으로 확장됩니다.

HPA는 기본적으로 관리되도록 구성되므로 Clair,Quay미러 Pod의 수는 2로 설정됩니다. 이를 통해 Operator 또는 이벤트 예약 중에 Red Hat Quay를 업데이트하거나 재구성할 때 다운타임이 방지됩니다.

4.3.2.1. Horizontal Pod Autoscaler 비활성화

자동 스케일링을 비활성화하거나 자체 HorizontalPodAutoscaler 를 생성하려면 QuayRegistry 인스턴스에서 구성 요소를 관리되지 않음 으로 지정합니다. 예를 들면 다음과 같습니다.

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: horizontalpodautoscaler
      managed: false

4.3.3. Route 구성 요소 비활성화

Red Hat Quay Operator가 경로를 생성하지 못하도록 하려면 다음 절차를 사용하십시오.

절차

  1. quayregistry.yaml 파일에서 구성 요소를 managed: false 로 설정합니다.

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: example-registry
      namespace: quay-enterprise
    spec:
      components:
        - kind: route
          managed: false
  2. config.yaml 파일을 편집하여 Red Hat Quay가 SSL/TLS를 처리하도록 지정합니다. 예를 들면 다음과 같습니다.

    ...
    EXTERNAL_TLS_TERMINATION: false
    ...
    SERVER_HOSTNAME: example-registry-quay-quay-enterprise.apps.user1.example.com
    ...
    PREFERRED_URL_SCHEME: https
    ...

    관리되지 않는 경로를 올바르게 구성하지 않으면 다음 오류가 반환됩니다.

    {
      {
        "kind":"QuayRegistry",
        "namespace":"quay-enterprise",
        "name":"example-registry",
        "uid":"d5879ba5-cc92-406c-ba62-8b19cf56d4aa",
        "apiVersion":"quay.redhat.com/v1",
        "resourceVersion":"2418527"
      },
      "reason":"ConfigInvalid",
      "message":"required component `route` marked as unmanaged, but `configBundleSecret` is missing necessary fields"
    }
참고

기본 경로를 비활성화하면 Red Hat Quay 인스턴스에 액세스하기 위해 경로,서비스 또는 Ingress 를 생성해야 합니다. 또한 사용하는 DNS는 Red Hat Quay 구성의 SERVER_HOSTNAME 과 일치해야 합니다.

4.3.4. 모니터링 구성 요소 비활성화

단일 네임스페이스에 Red Hat Quay Operator를 설치하는 경우 모니터링 구성 요소가 자동으로 managed: false 로 설정됩니다. 모니터링을 명시적으로 비활성화하려면 다음 참조를 사용합니다.

관리되지 않는 모니터링

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: monitoring
      managed: false

이 시나리오에서 모니터링을 활성화하려면 Red Hat Quay Operator가 단일 네임스페이스에 설치될 때 모니터링 활성화를 참조하십시오.

4.3.5. 미러링 구성 요소 비활성화

미러링을 명시적으로 비활성화하려면 다음 YAML 구성을 사용합니다.

관리되지 않는 미러링 예제 YAML 구성

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: mirroring
      managed: false

5장. Red Hat Quay Operator 배포

Red Hat Quay Operator는 명령줄 또는 OpenShift Container Platform 콘솔에서 배포할 수 있지만 단계는 근본적으로 동일합니다.

5.1. 명령줄에서 Red Hat Quay 배포

다음 절차에 따라 CLI(명령줄 인터페이스)를 사용하여 에서 Red Hat Quay를 배포합니다.

사전 요구 사항

  • CLI를 사용하여 OpenShift Container Platform에 로그인했습니다.

절차

  1. 다음 명령을 입력하여 네임스페이스(예: quay-enterprise )를 만듭니다.

    $ oc new-project quay-enterprise
  2. 선택 사항: Red Hat Quay 배포의 모든 측면을 사전 구성하려면 구성 번들에 대한 보안을 생성합니다.

    $ oc create secret generic quay-enterprise-config-bundle --from-file=config-bundle.tar.gz=/path/to/config-bundle.tar.gz
  3. quayregistry.yaml이라는 파일에 QuayRegistry 사용자 정의 리소스를 만듭니다.

    1. 최소 배포의 경우 모든 기본값을 사용합니다.

      quayregistry.yaml:

      apiVersion: quay.redhat.com/v1
      kind: QuayRegistry
      metadata:
        name: example-registry
        namespace: quay-enterprise

    2. 선택 사항: 관리되지 않는 일부 구성 요소를 사용하려면 spec 필드에 이 정보를 추가합니다. 최소 배포는 다음 예와 같을 수 있습니다.

      관리되지 않는 구성 요소가 있는 quayregistry.yaml의 예

      apiVersion: quay.redhat.com/v1
      kind: QuayRegistry
      metadata:
        name: example-registry
        namespace: quay-enterprise
      spec:
        components:
          - kind: clair
            managed: false
          - kind: horizontalpodautoscaler
            managed: false
          - kind: mirror
            managed: false
          - kind: monitoring
            managed: false

    3. 선택 사항: 구성 번들(예: init-config-bundle-secret )을 생성한 경우 quayregistry.yaml 파일에서 참조합니다.

      구성 번들이 포함된 quayregistry.yaml 예

      apiVersion: quay.redhat.com/v1
      kind: QuayRegistry
      metadata:
        name: example-registry
        namespace: quay-enterprise
      spec:
        configBundleSecret: init-config-bundle-secret

    4. 선택 사항: 프록시가 구성된 경우 Red Hat Quay, Clair, 미러링에 대한 재정의를 사용하여 정보를 추가할 수 있습니다.

      프록시가 구성된 quayregistry.yaml 예

        kind: QuayRegistry
        metadata:
          name: quay37
        spec:
          configBundleSecret: config-bundle-secret
          components:
            - kind: objectstorage
              managed: false
            - kind: route
              managed: true
            - kind: mirror
              managed: true
              overrides:
                env:
                  - name: DEBUGLOG
                    value: "true"
                  - name: HTTP_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: HTTPS_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: NO_PROXY
                    value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com
            - kind: tls
              managed: false
            - kind: clair
              managed: true
              overrides:
                env:
                  - name: HTTP_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: HTTPS_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: NO_PROXY
                    value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com
            - kind: quay
              managed: true
              overrides:
                env:
                  - name: DEBUGLOG
                    value: "true"
                  - name: NO_PROXY
                    value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com
                  - name: HTTP_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: HTTPS_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128

  4. 지정된 네임스페이스에서 QuayRegistry 를 생성합니다.

    $ oc create -n quay-enterprise -f quayregistry.yaml
  5. status.registryEndpoint 가 채워지는 시기를 확인하려면 다음 명령을 입력합니다.

    $ oc get quayregistry -n quay-enterprise example-registry -o jsonpath="{.status.registryEndpoint}" -w

추가 리소스

5.1.1. 명령줄을 사용하여 생성된 구성 요소 보기

배포된 Red Hat Quay 구성 요소를 보려면 다음 절차를 사용하십시오.

사전 요구 사항

  • {ocp.}에 Red Hat Quay Operator를 배포했습니다.

절차

  1. 배포된 구성 요소를 보려면 다음 명령을 입력합니다.

    $ oc get pods -n quay-enterprise

    출력 예

    NAME                                                   READY   STATUS      RESTARTS   AGE
    example-registry-clair-app-5ffc9f77d6-jwr9s            1/1     Running     0          3m42s
    example-registry-clair-app-5ffc9f77d6-wgp7d            1/1     Running     0          3m41s
    example-registry-clair-postgres-54956d6d9c-rgs8l       1/1     Running     0          3m5s
    example-registry-quay-app-79c6b86c7b-8qnr2             1/1     Running     4          3m42s
    example-registry-quay-app-79c6b86c7b-xk85f             1/1     Running     4          3m41s
    example-registry-quay-app-upgrade-5kl5r                0/1     Completed   4          3m50s
    example-registry-quay-config-editor-597b47c995-svqrl   1/1     Running     0          3m42s
    example-registry-quay-database-b466fc4d7-tfrnx         1/1     Running     2          3m42s
    example-registry-quay-mirror-6d9bd78756-6lj6p          1/1     Running     0          2m58s
    example-registry-quay-mirror-6d9bd78756-bv6gq          1/1     Running     0          2m58s
    example-registry-quay-postgres-init-dzbmx              0/1     Completed   0          3m43s
    example-registry-quay-redis-8bd67b647-skgqx            1/1     Running     0          3m42s

5.1.2. 수평 Pod 자동 확장

기본 배포에는 다음과 같은 실행 중인 Pod가 표시됩니다.

  • Red Hat Quay 애플리케이션 자체를 위한 두 개의 Pod(예:-registry-quay-app-*')
  • Red Hat Quay 로깅을 위한 하나의 Redis Pod (예:-registry-quay-redis-*)
  • 메타데이터 스토리지에 Red Hat Quay에서 사용하는 PostgreSQL용 데이터베이스 포드 1개(예:-registry-quay-database-*)
  • Red Hat Quay 구성 편집기용 하나의 Pod(예:-registry-quay-config-editor-*)
  • 두 개의 Quay 미러링 Pod(example-registry-quay-mirror-*)
  • Clair 애플리케이션에 대한 두 개의 포드(example-registry-clair-app-*)
  • Clair용 PostgreSQL Pod 1개(예-registry-clair-postgres-*)

수평 PPod 자동 확장은 기본적으로 관리 되도록 구성되며 Quay, Clair 및 리포지토리 미러링의 Pod 수는 2로 설정됩니다. 이를 통해 Red Hat Quay Operator 또는 일정 조정 이벤트를 통해 Red Hat Quay를 업데이트하거나 재구성할 때 다운타임을 방지할 수 있습니다. 다음 명령을 입력하여 HPA 오브젝트에 대한 정보를 볼 수 있습니다.

$ oc get hpa -n quay-enterprise

출력 예

NAME                           REFERENCE                                 TARGETS           MINPODS   MAXPODS   REPLICAS   AGE
example-registry-clair-app     Deployment/example-registry-clair-app     16%/90%, 0%/90%   2         10        2          13d
example-registry-quay-app      Deployment/example-registry-quay-app      31%/90%, 1%/90%   2         20        2          13d
example-registry-quay-mirror   Deployment/example-registry-quay-mirror   27%/90%, 0%/90%   2         20        2          13d

5.1.2.1. API를 사용하여 첫 번째 사용자 생성

다음 절차에 따라 Red Hat Quay 조직에 첫 번째 사용자를 생성합니다.

사전 요구 사항

  • 설정 옵션 FEATURE_USER_INITIALIZEtrue 로 설정해야 합니다.
  • 데이터베이스에 이미 사용자가 있을 수 없습니다.
절차

이 절차에서는 "access_token": true 를 지정하여 OAuth 토큰을 요청합니다.

  1. root 사용자로 다음 명령을 입력하여 python39 를 설치합니다.

    $ sudo yum install python39
  2. Python 3.9용 pip 패키지 관리자를 업그레이드합니다.

    $ python3.9 -m pip install --upgrade pip
  3. pip 패키지 관리자를 사용하여 bcrypt 패키지를 설치합니다.

    $ pip install bcrypt
  4. 다음 명령을 입력하여 Python 3.9에서 bcrypt 패키지를 사용하여 보안 해시 암호를 생성합니다.

    $ python3.9 -c 'import bcrypt; print(bcrypt.hashpw(b"subquay12345", bcrypt.gensalt(12)).decode("utf-8"))'
  5. Red Hat Quay 구성 파일을 열고 다음 구성 필드를 업데이트합니다.

    FEATURE_USER_INITIALIZE: true
    SUPER_USERS:
         -  quayadmin
  6. 다음 명령을 입력하여 Red Hat Quay 서비스를 중지합니다.

    $ sudo podman stop quay
  7. 다음 명령을 입력하여 Red Hat Quay 서비스를 시작합니다.

    $ sudo podman run -d -p 80:8080 -p 443:8443 --name=quay -v $QUAY/config:/conf/stack:Z  -v $QUAY/storage:/datastorage:Z {productrepo}/{quayimage}:{productminv}
  8. 다음 CURL 명령을 실행하여 사용자 이름, 암호, 이메일 및 액세스 토큰을 사용하여 새 사용자를 생성합니다.

    $ curl -X POST -k  http://quay-server.example.com/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass12345", "email": "quayadmin@example.com", "access_token": true}'

    성공하면 명령은 사용자 이름, 이메일 및 암호화된 암호를 사용하여 오브젝트를 반환합니다. 예를 들면 다음과 같습니다.

    {"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"quayadmin@example.com","encrypted_password":"1nZMLH57RIE5UGdL/yYpDOHLqiNCgimb6W9kfF8MjZ1xrfDpRyRs9NUnUuNuAitW","username":"quayadmin"} # gitleaks:allow

    사용자가 이미 데이터베이스에 있으면 오류가 반환됩니다.

    {"message":"Cannot initialize user in a non-empty database"}

    암호가 8자를 넘지 않거나 공백을 포함하는 경우 오류가 반환됩니다.

    {"message":"Failed to initialize user: Invalid password, password must be at least 8 characters and contain no whitespace."}
  9. 다음 명령을 입력하여 Red Hat Quay 배포에 로그인합니다.

    $ sudo podman login -u quayadmin -p quaypass12345 http://quay-server.example.com --tls-verify=false

    출력 예

    Login Succeeded!

추가 리소스

Red Hat Quay 배포 사전 구성에 대한 자세한 내용은 자동화를 위한 Red Hat Quay 사전 구성 섹션을참조하십시오.

5.1.3. 배포 프로세스 모니터링 및 디버깅

사용자는 배포 단계 중 문제를 해결할 수 있습니다. QuayRegistry 오브젝트의 상태는 배포 중에 구성 요소의 상태를 모니터링하는 데 도움이 될 수 있으며 발생할 수 있는 문제를 디버깅하는 데 도움이 될 수 있습니다.

절차

  1. 다음 명령을 입력하여 배포 상태를 확인합니다.

    $ oc get quayregistry -n quay-enterprise -o yaml

    출력 예

    배포 직후 QuayRegistry 오브젝트에는 기본 설정이 표시됩니다.

    apiVersion: v1
    items:
    - apiVersion: quay.redhat.com/v1
      kind: QuayRegistry
      metadata:
        creationTimestamp: "2021-09-14T10:51:22Z"
        generation: 3
        name: example-registry
        namespace: quay-enterprise
        resourceVersion: "50147"
        selfLink: /apis/quay.redhat.com/v1/namespaces/quay-enterprise/quayregistries/example-registry
        uid: e3fc82ba-e716-4646-bb0f-63c26d05e00e
      spec:
        components:
        - kind: postgres
          managed: true
        - kind: clair
          managed: true
        - kind: redis
          managed: true
        - kind: horizontalpodautoscaler
          managed: true
        - kind: objectstorage
          managed: true
        - kind: route
          managed: true
        - kind: mirror
          managed: true
        - kind: monitoring
          managed: true
        - kind: tls
          managed: true
        configBundleSecret: example-registry-config-bundle-kt55s
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
  2. oc get pods 명령을 사용하여 배포된 구성 요소의 현재 상태를 확인합니다.

    $ oc get pods -n quay-enterprise

    출력 예

    NAME                                                   READY   STATUS              RESTARTS   AGE
    example-registry-clair-app-86554c6b49-ds7bl            0/1     ContainerCreating   0          2s
    example-registry-clair-app-86554c6b49-hxp5s            0/1     Running             1          17s
    example-registry-clair-postgres-68d8857899-lbc5n       0/1     ContainerCreating   0          17s
    example-registry-quay-app-upgrade-h2v7h                0/1     ContainerCreating   0          9s
    example-registry-quay-config-editor-5f646cbcb7-lbnc2   0/1     ContainerCreating   0          17s
    example-registry-quay-database-66f495c9bc-wqsjf        0/1     ContainerCreating   0          17s
    example-registry-quay-mirror-854c88457b-d845g          0/1     Init:0/1            0          2s
    example-registry-quay-mirror-854c88457b-fghxv          0/1     Init:0/1            0          17s
    example-registry-quay-postgres-init-bktdt              0/1     Terminating         0          17s
    example-registry-quay-redis-f9b9d44bf-4htpz            0/1     ContainerCreating   0          17s

  3. 배포가 진행 중인 동안 QuayRegistry 오브젝트에 현재 상태가 표시됩니다. 이 경우 데이터베이스 마이그레이션이 수행되고 기타 구성 요소가 완료될 때까지 대기 중입니다.

      status:
        conditions:
        - lastTransitionTime: "2021-09-14T10:52:04Z"
          lastUpdateTime: "2021-09-14T10:52:04Z"
          message: all objects created/updated successfully
          reason: ComponentsCreationSuccess
          status: "False"
          type: RolloutBlocked
        - lastTransitionTime: "2021-09-14T10:52:05Z"
          lastUpdateTime: "2021-09-14T10:52:05Z"
          message: running database migrations
          reason: MigrationsInProgress
          status: "False"
          type: Available
        configEditorCredentialsSecret: example-registry-quay-config-editor-credentials-btbkcg8dc9
        configEditorEndpoint: https://example-registry-quay-config-editor-quay-enterprise.apps.docs.quayteam.org
        lastUpdated: 2021-09-14 10:52:05.371425635 +0000 UTC
        unhealthyComponents:
          clair:
          - lastTransitionTime: "2021-09-14T10:51:32Z"
            lastUpdateTime: "2021-09-14T10:51:32Z"
            message: 'Deployment example-registry-clair-postgres: Deployment does not have minimum availability.'
            reason: MinimumReplicasUnavailable
            status: "False"
            type: Available
          - lastTransitionTime: "2021-09-14T10:51:32Z"
            lastUpdateTime: "2021-09-14T10:51:32Z"
            message: 'Deployment example-registry-clair-app: Deployment does not have minimum availability.'
            reason: MinimumReplicasUnavailable
            status: "False"
            type: Available
          mirror:
          - lastTransitionTime: "2021-09-14T10:51:32Z"
            lastUpdateTime: "2021-09-14T10:51:32Z"
            message: 'Deployment example-registry-quay-mirror: Deployment does not have minimum availability.'
            reason: MinimumReplicasUnavailable
            status: "False"
            type: Available
  4. 배포 프로세스가 완료되면 QuayRegistry 오브젝트의 상태가 비정상 구성 요소를 표시하지 않습니다.

      status:
        conditions:
        - lastTransitionTime: "2021-09-14T10:52:36Z"
          lastUpdateTime: "2021-09-14T10:52:36Z"
          message: all registry component healthchecks passing
          reason: HealthChecksPassing
          status: "True"
          type: Available
        - lastTransitionTime: "2021-09-14T10:52:46Z"
          lastUpdateTime: "2021-09-14T10:52:46Z"
          message: all objects created/updated successfully
          reason: ComponentsCreationSuccess
          status: "False"
          type: RolloutBlocked
        configEditorCredentialsSecret: example-registry-quay-config-editor-credentials-hg7gg7h57m
        configEditorEndpoint: https://example-registry-quay-config-editor-quay-enterprise.apps.docs.quayteam.org
        currentVersion: {producty}
        lastUpdated: 2021-09-14 10:52:46.104181633 +0000 UTC
        registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org
        unhealthyComponents: {}

5.2. OpenShift Container Platform 콘솔에서 Red Hat Quay 배포

  1. 네임스페이스(예: quay-enterprise )를 생성합니다.
  2. Operators설치된 Operator 를 선택한 다음 Quay Operator를 선택하여 Operator 세부 정보 보기로 이동합니다.
  3. 'Provided APIs' 아래의 'Quay Registry' 타일에서 '인스턴스 생성'을 클릭합니다.
  4. 선택적으로 QuayRegistry 의 'Name'을 변경합니다. 이는 레지스트리의 호스트 이름에 영향을 미칩니다. 다른 모든 필드는 기본값으로 채워집니다.
  5. 'Create'를 클릭하여 Quay Operator가 배포할 QuayRegistry 를 제출합니다.
  6. QuayRegistry 목록 보기로 리디렉션되어야 합니다. 방금 만든 QuayRegistry 를 클릭하여 세부 정보 보기를 확인합니다.
  7. 'Registry Endpoint'에 값이 있으면 클릭하여 UI를 통해 새 Quay 레지스트리에 액세스합니다. 이제 'Create Account'를 선택하여 사용자를 생성하고 로그인할 수 있습니다.

5.2.1. Red Hat Quay UI를 사용하여 첫 번째 사용자 생성

다음 절차에 따라 Red Hat Quay UI에서 첫 번째 사용자를 생성합니다.

참고

이 절차에서는 FEATURE_USER_CREATION config 옵션이 false로 설정되지 않은 것으로 가정합니다. false 인 경우 UI의 계정 만들기 기능이 비활성화되고 API를 사용하여 첫 번째 사용자를 만들어야 합니다.

절차

  1. OpenShift Container Platform 콘솔에서 적절한 네임스페이스/프로젝트를 사용하여 Operator → 설치된 Operator 로 이동합니다.
  2. 새로 설치된 QuayRegistry 오브젝트를 클릭하여 세부 정보를 확인합니다. 예를 들면 다음과 같습니다.

    QuayRegistry details

  3. Registry Endpoint 에 값이 있으면 브라우저에서 이 URL로 이동합니다.
  4. Red Hat Quay 레지스트리 UI에서 계정 만들기 를 선택하여 사용자를 생성합니다. 예를 들면 다음과 같습니다.

    Create Account

  5. 사용자 이름 , 암호,이메일에 대한 세부 정보를 입력한 다음 Create Account 를 클릭합니다. 예를 들면 다음과 같습니다.

    Enter account details

첫 번째 사용자를 생성한 후 Red Hat Quay 레지스트리에 자동으로 로그인됩니다. 예를 들면 다음과 같습니다.

Initial log in

6장. QuayRegistry 오브젝트의 상태 보기

지정된 Red Hat Quay 배포의 라이프사이클 관찰 기능은 해당 QuayRegistry 오브젝트의 status 섹션에서 보고됩니다. Red Hat Quay Operator는 이 섹션을 지속적으로 업데이트하므로 Red Hat Quay 또는 관리형 종속성에서 문제 또는 상태 변경 사항을 찾을 수 있는 첫 번째 위치에 있어야 합니다.

6.1. 레지스트리 끝점 보기

Red Hat Quay를 사용할 준비가 되면 status.registryEndpoint 필드가 레지스트리의 공개적으로 사용 가능한 호스트 이름으로 채워집니다.

6.2. 구성 편집기 끝점 보기

status.configEditorEndpoint 를 사용하여 Red Hat Quay의 UI 기반 구성 편집기에 액세스합니다.

6.3. 구성 편집기 인증 정보 시크릿 보기

구성 편집기 UI의 사용자 이름과 암호는 status.configEditorCredentials Secret 에서 참조하는 QuayRegistry 와 동일한 네임스페이스에 있는 Secret에 저장됩니다.

6.4. 사용 중인 Red Hat Quay 버전 보기

실행 중인 Red Hat Quay의 현재 버전은 status.currentVersion 으로 보고됩니다.

6.5. Red Hat Quay 배포의 조건 보기

특정 조건이 status.conditions 에 보고됩니다.

7장. OpenShift Container Platform에서 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스 업데이트

중요

Red Hat Quay 배포가 하나의 y-stream에서 다음 단계로 업그레이드하는 경우 예를 들어 3.8.10 → 3.8.11에서 업그레이드 채널을 stable-3.8 에서 stable-3.9 로 전환해서는 안 됩니다. y-stream 업그레이드 중 업그레이드 채널을 변경하면 Red Hat Quay가 3.9로 업그레이드할 수 없습니다. 이는 알려진 문제이며 Red Hat Quay의 향후 버전에서 수정될 예정입니다.

Red Hat Quay 3.8 → 3.9를 업데이트할 때 Operator는 Clair 및 Red Hat Quay의 기존 PostgreSQL 데이터베이스를 버전 10에서 버전 13으로 자동으로 업그레이드합니다.

중요
  • 관리형 데이터베이스가 있는 사용자는 PostgreSQL 데이터베이스를 10 → 13에서 업그레이드해야 합니다.
  • Operator에서 Red Hat Quay 및 Clair 데이터베이스를 관리하는 경우 3.9.0 업그레이드가 성공하려면 각 구성 요소의 데이터베이스 업그레이드가 성공해야 합니다. 데이터베이스 업그레이드 중 하나가 실패하면 전체 Red Hat Quay 버전 업그레이드가 실패합니다. 이 동작이 예상됩니다.

웹 콘솔 UI를 사용하거나 CLI를 사용하여 OpenShift Container Platform에서 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스를 업데이트할 수 있습니다.

7.1. OpenShift Container Platform 웹 콘솔을 사용하여 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스 업데이트

다음 절차에 따라 OpenShift Container Platform 웹 콘솔을 사용하여 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스를 업데이트합니다.

중요
  • 이 업그레이드는 되돌릴 수 없습니다. PostgreSQL 13으로 업그레이드하는 것이 좋습니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다. 자세한 내용은 PostgreSQL 버전 관리 정책을 참조하십시오.
  • Operator에서 Red Hat Quay 및 Clair 데이터베이스를 관리하는 경우 3.9.0 업그레이드가 성공하려면 각 구성 요소의 데이터베이스 업그레이드가 성공해야 합니다. 데이터베이스 업그레이드 중 하나가 실패하면 전체 Red Hat Quay 버전 업그레이드가 실패합니다. 이 동작이 예상됩니다.
  • 기본적으로 Red Hat Quay는 PostgreSQL 10에서 이전 PVC(영구 볼륨 클레임)를 제거하도록 구성됩니다. 이 설정 및 이전 PVC를 비활성화하려면 quay-operator Subscription 오브젝트에서 POSTGRES_UPGRADE_RETAIN_BACKUPTrue 로 설정해야 합니다.

사전 요구 사항

  • OpenShift Container Platform에 Red Hat Quay 3.6, 3.7 또는 3.8을 설치했습니다.
  • 100GB의 무료 추가 스토리지.

    업그레이드 프로세스 중에 마이그레이션된 데이터를 저장하기 위해 추가 PVC(영구 볼륨 클레임)가 프로비저닝됩니다. 이는 사용자 데이터에 대한 파괴적인 작업을 방지하는 데 도움이 됩니다. 업그레이드 프로세스에서는 Red Hat Quay 데이터베이스 업그레이드 및 Clair 데이터베이스 업그레이드 모두에 대해 50GB의 PVC를 롤아웃합니다.

절차

  1. 선택 사항: POSTGRES_UPGRADE_RETAIN_BACKUPquay-operator Subscription 오브젝트로 설정하여 PostgreSQL 10에서 이전 PVC를 백업합니다. 예를 들면 다음과 같습니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: quay-operator
      namespace: quay-enterprise
    spec:
      channel: stable-3.8
      name: quay-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      config:
        env:
        - name: POSTGRES_UPGRADE_RETAIN_BACKUP
          value: "true"
  2. OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
  3. Red Hat Quay Operator를 클릭합니다.
  4. 서브스크립션 탭으로 이동합니다.
  5. 서브스크립션 세부 정보 에서 채널 업데이트를 클릭합니다.
  6. stable-3.9 를 선택하고 변경 사항을 저장합니다.
  7. Upgrade(업그레이드) 상태에서 새 설치 진행 상황을 확인합니다. 계속하기 전에 업그레이드 상태가 1 로 변경될 때까지 기다립니다.
  8. OpenShift Container Platform 클러스터에서 워크로드Pod 로 이동합니다. 기존 Pod는 종료되거나 종료되어야 합니다.
  9. clair-postgres-upgrade,quay-postgres-upgrade, quay-app-upgrade.
  10. clair-postgres-upgrade,quay-postgres-upgradequay-app-upgrade Pod가 Completed 로 표시된 후 Red Hat Quay 배포의 나머지 Pod가 실행됩니다. 이 작업은 약 10분 정도 걸립니다.
  11. quay-databaseclair-postgres Pod에서 postgresql-13 이미지를 사용하는지 확인합니다.
  12. quay-app 포드가 Running 으로 표시되면 Red Hat Quay 레지스트리에 도달할 수 있습니다.

7.2. CLI를 사용하여 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스 업데이트

CLI(명령줄 인터페이스)를 사용하여 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스를 업데이트하려면 다음 절차를 사용하십시오.

중요
  • 이 업그레이드는 되돌릴 수 없습니다. PostgreSQL 13으로 업그레이드하는 것이 좋습니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다. 자세한 내용은 PostgreSQL 버전 관리 정책을 참조하십시오.
  • 기본적으로 Red Hat Quay는 PostgreSQL 10에서 이전 PVC(영구 볼륨 클레임)를 제거하도록 구성됩니다. 이 설정 및 이전 PVC를 비활성화하려면 quay-operator Subscription 오브젝트에서 POSTGRES_UPGRADE_RETAIN_BACKUPTrue 로 설정해야 합니다.

사전 요구 사항

  • OpenShift Container Platform에 Red Hat Quay 3.6, 3.7 또는 3.8을 설치했습니다.
  • 100GB의 무료 추가 스토리지.

    업그레이드 프로세스 중에 마이그레이션된 데이터를 저장하기 위해 추가 PVC(영구 볼륨 클레임)가 프로비저닝됩니다. 이는 사용자 데이터에 대한 파괴적인 작업을 방지하는 데 도움이 됩니다. 업그레이드 프로세스에서는 Red Hat Quay 데이터베이스 업그레이드 및 Clair 데이터베이스 업그레이드 모두에 대해 50GB의 PVC를 롤아웃합니다.

절차

  1. 다음 oc get 명령을 입력하여 quay-operator 구성 파일을 검색합니다.

    $ oc get subscription quay-operator -n quay-enterprise -o yaml > quay-operator.yaml
  2. 다음 명령을 입력하여 Red Hat Quay Operator의 최신 버전과 해당 채널을 검색합니다.

    oc get packagemanifests quay-operator \
      -o jsonpath='{range .status.channels[*]}{@.currentCSV} {@.name}{"\n"}{end}' \
      | awk '{print "STARTING_CSV=" $1 " CHANNEL=" $2 }' \
      | sort -nr \
      | head -1

    출력 예

    STARTING_CSV=quay-operator.v3.9.0 CHANNEL=stable-3.9

  3. 이전 명령의 출력을 사용하여 Red Hat Quay Operator에 대한 Subscription 사용자 정의 리소스를 업데이트하여 quay-operator.yaml 로 저장합니다. 예를 들면 다음과 같습니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: quay-operator
      namespace: quay-enterprise
    spec:
      channel: stable-3.9 1
      name: quay-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      config:
        env:
        - name: POSTGRES_UPGRADE_RETAIN_BACKUP 2
          value: "true"
    1
    spec.channel 매개변수에 대해 이전 단계에서 얻은 값을 지정합니다.
    2
    선택 사항: POSTGRES_UPGRADE_RETAIN_BACKUPquay-operator Subscription 오브젝트로 설정하여 PostgreSQL 10에서 이전 PVC를 백업합니다.
  4. 다음 명령을 입력하여 구성을 적용합니다.

    $ oc apply -f quay-operator.yaml

    출력 예

    subscription.operators.coreos.com/quay-operator created

다음 단계

법적 공지

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.