Quay Operator를 사용하여 OpenShift에 Red Hat Quay 배포

Red Hat Quay 3.7

Quay Operator를 사용하여 OpenShift에 Red Hat Quay 배포

Red Hat OpenShift Documentation Team

초록

Red Hat Quay Operator를 사용하여 OpenShift 클러스터에 Red Hat Quay 배포

머리말

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

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

Red Hat Quay 3.4.0부터 Operator는 즉시 개선된 환경을 개선하고 더 많은 Day 2 작업을 지원하기 위해 완전히 다시 작성되었습니다. 결과적으로 새 Operator는 사용하기 쉬워지고 더 많은 의견을 받습니다. 이전 버전의 Operator와의 주요 차이점은 다음과 같습니다.

  • QuayEcosystem 사용자 정의 리소스가 QuayRegistry 사용자 정의 리소스로 교체됨
  • 기본 설치 옵션은 모든 관리 종속 항목(데이터베이스, 캐시, 오브젝트 스토리지 등)을 사용하여 완전히 지원되는 Quay 환경을 생성합니다(일부 구성 요소는 고가용성이 아닐 수 있음).
  • 일관성을 위해 Quay 애플리케이션 및 구성 툴에서 공유하는 Quay 구성에 대한 새로운 강력한 검증 라이브러리
  • ObjectBucketClaim Kubernetes API를 사용하여 Operator에서 오브젝트 스토리지를 관리할 수 있습니다(Red Hat OpenShift Data Foundation을 사용하여 OpenShift에서 이 API의 지원 구현을 제공할 수 있음)
  • 테스트 및 개발 시나리오에 배포된 Pod에서 사용하는 컨테이너 이미지의 사용자 지정

1장. Red Hat Quay Operator 소개

이 문서에서는 Red Hat Quay Operator를 사용하여 OpenShift에서 Red Hat Quay를 구성, 배포, 관리 및 업그레이드하는 단계를 간략하게 설명합니다.

다음을 수행하는 방법을 보여줍니다.

  • Red Hat Quay Operator 설치
  • 관리 또는 관리되지 않는 개체 스토리지 구성
  • 필요한 경우 데이터베이스, Redis, 경로, TLS 등을 포함하여 다른 관리되지 않는 구성 요소를 구성합니다.
  • Operator를 사용하여 OpenShift에 Red Hat Quay 레지스트리 배포
  • Operator에서 지원하는 고급 기능 사용
  • Operator를 업그레이드하여 레지스트리 업그레이드

1.1. QuayRegistry API

Quay Operator는 QuayRegistry 사용자 정의 리소스 API를 제공하여 클러스터에서 Quay 컨테이너 레지스트리를 선언적으로 관리합니다. OpenShift UI 또는 명령줄 툴을 사용하여 이 API와 상호 작용합니다.

  • QuayRegistry 를 생성하면 Operator가 클러스터에서 Quay를 실행하는 데 필요한 모든 리소스를 배포하고 구성합니다.
  • QuayRegistry 를 편집하면 Operator에서 변경 사항을 조정하고 원하는 구성에 맞게 오브젝트를 생성/작업/삭제합니다.
  • QuayRegistry 를 삭제하면 이전에 생성된 모든 리소스가 가비지 수집되고 Quay 컨테이너 레지스트리를 더 이상 사용할 수 없습니다.

QuayRegistry API는 매우 간단하며 필드는 다음 섹션에 설명되어 있습니다.

1.2. Quay Operator 구성 요소

Quay는 강력한 컨테이너 레지스트리 플랫폼이므로 많은 종속 항목이 있습니다. 여기에는 데이터베이스, 오브젝트 스토리지, Redis 등이 포함됩니다. Quay Operator는 Kubernetes에 대한 Quay 및 해당 종속 항목의 예상 배포를 관리합니다. 이러한 종속 항목은 구성 요소로 처리되며 QuayRegistry API를 통해 구성됩니다.

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

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.3. 관리형 구성 요소 사용

QuayRegistry 사용자 정의 리소스가 다른 리소스를 지정하지 않으면 Operator는 다음 관리 구성 요소에 기본값을 사용합니다.

  • Quay: Quay 배포에 대한 재정의(예: 환경 변수 및 복제본 수)를 유지합니다. 이 구성 요소는 Red Hat Quay 3.7의 새로운 기능이며 관리되지 않음으로 설정할 수 없습니다.
  • Postgres: 레지스트리 메타데이터를 저장하기 위해 소프트웨어 컬렉션에서 Postgres 10 버전을 사용합니다.
  • Clair: 이미지 취약점 스캔 제공
  • Redis: Quay 빌더 조정 및 일부 내부 로깅을 처리합니다.
  • HorizontalPodAutoscaler: 메모리/cpu 사용에 따라 Quay Pod 수 조정
  • Objectstorage: 이미지 계층 Blob 저장을 위해 Noobaa/RHOCS에서 제공하는 ObjectBucketClaim Kubernetes API를 활용합니다.
  • Route: OpenShift 외부에서 Quay 레지스트리에 외부 진입점을 제공
  • mirror: 저장소 미러 작업자 구성(선택 사항 저장소 미러링 지원)
  • Monitoring: 기능에는 Grafana 대시보드, 개별 메트릭 액세스, Quay Pod를 자주 다시 시작하도록 경고하기 위한 경고가 포함됩니다.
  • TLS: Red Hat Quay 또는 OpenShift에서 TLS를 처리할지 여부 구성
  • clairpostgres: 관리 Clair 데이터베이스 구성

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

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

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

참고

Quay 구성 편집기를 사용하여 기존 구성 번들을 생성하거나 수정하고 특히 여러 변경 사항에 대해 Kubernetes 보안을 업데이트하는 프로세스를 단순화할 수 있습니다. 구성 편집기를 통해 Quay 구성을 변경하고 Operator로 전송하면 새 구성을 반영하도록 Quay 배포가 업데이트됩니다.

1.5. 구성 번들 시크릿

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

1.6. OpenShift에서 Red Hat Quay의 사전 요구 사항

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

1.6.1. OpenShift 클러스터

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

1.6.2. 리소스 요구 사항

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

  • 메모리의 8GI
  • 2000 밀리코어 CPU.

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

1.6.3. 오브젝트 스토리지

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

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

2장. OperatorHub에서 Quay Operator 설치

  1. OpenShift 콘솔을 사용하여 Operator → OperatorHub를 선택한 다음 Red Hat Quay Operator를 선택합니다. 둘 이상의 경우 커뮤니티 버전이 아닌 Red Hat Certified Operator를 사용하십시오.

    operatorhub quay

  2. 설치 페이지에 기능 및 사전 요구 사항이 요약되어 있습니다.

    operator install page

  3. 설치를 선택합니다. Operator 설치 페이지가 표시됩니다.

    operator subscription

  4. 설치를 사용자 지정하는 데 다음과 같은 선택 사항을 선택할 수 있습니다.

    • 업데이트 채널: 최신 릴리스의 경우 업데이트 채널(예: stable- 3.7)을 선택합니다.
    • 설치 모드: 클러스터 전체에서 Operator를 사용할 수 있도록 하려면 클러스터의 모든 네임스페이스 를 선택합니다. 단일 네임스페이스 내에서만 배포하려면 클러스터의 특정 네임스페이스를 선택합니다. 클러스터 전체에 Operator를 설치하는 것이 좋습니다. 단일 네임스페이스를 선택하면 모니터링 구성 요소를 기본적으로 사용할 수 없습니다.
    • 승인 전략: 자동 또는 수동 업데이트를 승인하도록 선택합니다. 자동 업데이트 전략이 권장됩니다.
  5. 설치를 선택합니다.
  6. 잠시 후 Operator가 Installed Operators 페이지에 성공적으로 설치되었음을 확인할 수 있습니다.

3장. 배포 전에 Quay 구성

Operator는 OpenShift에 배포할 때 모든 Red Hat Quay 구성 요소를 관리할 수 있으며 이는 기본 구성입니다. 또는 하나 이상의 구성 요소를 외부에서 직접 관리할 수 있으며, 이를 통해 설정을 더 많은 제어할 수 있으며 Operator에서 나머지 구성 요소를 관리할 수 있습니다.

관리되지 않는 구성 요소를 구성하기 위한 표준 패턴은 다음과 같습니다.

  1. 적절한 설정으로 config.yaml 구성 파일을 생성
  2. 구성 파일을 사용하여 시크릿 생성

    $ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
  3. 관리되지 않는 구성 요소를 식별하고 생성된 보안을 참조하는 QuayRegistry YAML 파일 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. YAML 파일을 사용하여 레지스트리를 배포합니다.

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

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

Red Hat Quay에는 자동화를 지원하는 몇 가지 구성 옵션이 있습니다. 배포 전에 이러한 옵션을 설정하여 사용자 인터페이스와 상호 작용할 필요성을 최소화할 수 있습니다.

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

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

Red Hat Quay를 배포한 후에는 다른 사용자가 아직 생성되지 않은 경우 API를 사용하여 사용자를 생성할 수 있습니다(예: quayadmin ). 자세한 내용은 using the API to create the first user 를 참조하십시오.

3.1.2. 일반 API 액세스 활성화

Red Hat Quay 레지스트리 API에 대한 일반 액세스를 허용하도록 구성 옵션 BROWSER_API_CALLS_XHR_ONLYfalse 로 설정합니다.

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.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.6. 자동화에 권장되는 구성

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

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

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

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

Operator가 스토리지 관리를 담당하는 경우 NooBaa / RHOCS Operator 설치 및 구성에 대한 정보는 Managed 스토리지 의 섹션을 참조하십시오.

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

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

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

3.2.1.1. 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 스토리지

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. 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
Azure 스토리지의 endpoint_url 매개변수는 선택 사항이며 Microsoft Azure Government (MAG) 끝점에서 사용할 수 있습니다. 비워 두면 endpoint_url 이 일반 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 스토리지 / Hitachi HCP 스토리지

DISTRIBUTED_STORAGE_CONFIG:
  radosGWStorage:
    - RadosGWStorage
    - access_key: access_key_here
      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:
    - default

3.2.1.5. 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. 스토리지 → 오브젝트 버킷 클레임으로 이동하여 {product-title} 콘솔에 NooBaa 오브젝트 버킷 클레임 을 생성합니다.
  2. 액세스 키, 버킷 이름, 끝점(hostname) 및 시크릿 키를 포함하여 오브젝트 버킷 클레임 데이터 세부 정보를 검색합니다.
  3. 오브젝트 버킷 클레임에 대한 정보를 사용하여 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. 관리형 스토리지

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

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

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

    • 고가용성
    • ODF에 대한 별도의 서브스크립션이 필요합니다.

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

참고

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

3.2.2.1. 독립 실행형 오브젝트 게이트웨이 정보

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

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

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

3.2.2.1.1. 독립 실행형 오브젝트 게이트웨이 생성

ODF (이전 OpenShift Container Storage) Operator를 설치하고 단일 인스턴스 Multi-Cloud Gateway 서비스를 구성하려면 다음 단계를 따르십시오.

  1. OpenShift 콘솔을 열고 Operator → OperatorHub를 선택한 다음 OpenShift Data Foundation Operator를 선택합니다.
  2. 설치를 선택합니다. 모든 기본 옵션을 수락하고 다시 설치를 선택합니다.
  3. 1분 이내에 Operator는 네임스페이스 openshift-storage 를 설치하고 생성합니다. Status 열이 Succeeded 로 표시되면 완료되었는지 확인할 수 있습니다.

    When the installation of the ODF Operator is complete, you are prompted to create a storage system. Do not follow this instruction. Instead, create NooBaa object storage as outlined the following steps.
  4. NooBaa 오브젝트 스토리지를 생성합니다. 다음 YAML을 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 의 단일 인스턴스 배포가 생성됩니다.

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

    $ oc create -n openshift-storage -f noobaa.yaml
    noobaa.noobaa.io/noobaa created
  6. 몇 분 후 MCG 인스턴스가 프로비저닝을 완료했음을 확인할 수 있습니다(PHASE 열이 Ready로 설정됨).

    $ 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
  7. 다음으로 게이트웨이에 대한 백업 저장소를 구성합니다. 다음 YAML을 noobaa-pv-backing-store.yaml 파일에 저장합니다.

    noobaa-pv-backing-store.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
    요청된 PersistentVolumes 에 사용할 StorageClass, 클러스터 기본값을 사용하도록 이 속성을 삭제합니다.
  8. 다음 명령을 사용하여 구성을 적용합니다.

    $ oc create -f noobaa-pv-backing-store.yaml
    backingstore.noobaa.io/noobaa-pv-backing-store created

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

  9. 마지막으로 다음 명령을 실행하여 Operator에서 발행한 모든 ObjectBucketClaim의 PersistentVolume 백업 저장소를 기본으로 설정합니다.

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

이렇게 하면 Red Hat Quay에 대한 Multi-Cloud Object Gateway 인스턴스 설정이 완료됩니다. 이 구성은 Red Hat OpenShift Data Foundation이 설치된 클러스터에서 병렬로 실행할 수 없습니다.

3.3. 데이터베이스 구성

3.3.1. 기존 Postgres 데이터베이스 사용

  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 구성 요소를 Unmanaged로 표시하고 생성된 Secret을 참조하는 QuayRegistry YAML 파일 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. 다음 섹션에 설명된 대로 레지스트리를 배포합니다.

3.3.2. 데이터베이스 구성

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

3.3.2.1. 데이터베이스 URI

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

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

표 3.1. 데이터베이스 URI

필드유형설명

DB_URI
(필수)

문자열

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

DB_URI 필드 예:

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

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

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

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

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

필드유형설명

DB_CONNECTION_ARGS

개체

시간 제한 및 SSL과 같은 데이터베이스에 대한 선택적 연결 인수입니다.

.autorollback

부울

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

.threadlocals

부울

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

3.3.2.2.1. PostgreSQL SSL 연결 인수

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

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

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

표 3.3. SSL 옵션

mode설명

disable

구성에서는 SSL이 아닌 연결만 시도합니다.

allow

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


(기본값)

구성에서 먼저 SSL 연결을 시도합니다. 실패 시 SSL이 아닌 연결을 시도합니다.

require

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

verify-ca

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

verify-full

SSL 연결만 시도하고 서버 인증서가 신뢰할 수 있는 CA에서 발급하고 요청된 서버 호스트 이름이 인증서의 항목과 일치하는지 확인합니다.

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

3.3.2.2.2. MySQL SSL 연결 인수

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

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

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

3.3.3. 관리되는 PostgreSQL 사용

권장 사항:

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

3.4. TLS 및 경로 구성

OpenShift Container Platform Edge-Termination Routes에 대한 지원이 새로 관리되는 구성 요소 tls 를 통해 추가되었습니다. 이를 통해 TLS의 경로 구성 요소를 분리하고 사용자가 둘 다 별도로 구성할 수 있습니다. EXTERNAL_TLS_TERMINATION: true 는 의견 설정입니다. Managed tls 는 기본 클러스터 와일드카드 인증서가 사용됨을 나타냅니다. Unmanaged tls 는 사용자가 제공한 인증서/키 쌍이 경로에 삽입됨을 나타냅니다.

SSL .certssl.key 가 이제 별도의 영구 시크릿으로 이동되어 모든 조정 시 cert/key 쌍이 다시 생성되지 않습니다. 이제 에지 경로로 포맷되고 Quay 컨테이너의 동일한 디렉터리에 마운트됩니다.

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

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

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

표 3.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은 빌더를 지원하지 않습니다.

3.4.1. TLS 인증서, 키 쌍으로 구성 번들 시크릿 생성:

고유한 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

3.5. 기타 구성 요소 구성

3.5.1. 외부 Redis 사용

외부 Redis 데이터베이스를 사용하려면 QuayRegistry 인스턴스에서 구성 요소를 관리되지 않음으로 설정합니다.

  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 구성 요소를 관리되지 않음으로 표시하고 생성된 보안을 참조하는 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: redis
          managed: false
  4. 레지스트리 배포

3.5.1.1. Redis 구성 필드

이 섹션에서는 Redis 배포에 사용 가능한 구성 필드에 대해 자세히 설명합니다.

3.5.1.1.1. 빌드 로그

Redis 배포에 다음 빌드 로그 구성 필드를 사용할 수 있습니다.

표 3.5. 빌드 로그 구성

필드유형설명

BUILDLOGS_REDIS
(필수)

개체

빌드 로그 캐싱에 대한 Redis 연결 세부 정보입니다.

.host
(필수)

문자열

Redis에 액세스할 수 있는 호스트 이름
예:
quay-server.example.com

.port
(필수)

숫자

Redis에 액세스할 수 있는 포트입니다.
예:
6379

.password

문자열

Redis에 액세스할 수 있는 포트입니다.
예:
strongpassword

.port
(필수)

숫자

Redis에 액세스할 수 있는 포트입니다.
예:
6379

ssl

부울

Redis와 Quay 간 TLS 통신을 활성화할지 여부입니다. 기본값은 false입니다.

3.5.1.1.2. 사용자 이벤트

Redis 배포에 다음 사용자 이벤트 필드를 사용할 수 있습니다.

표 3.6. 사용자 이벤트 구성

필드유형설명

USER_SECRETENTS_REDIS
(필수)

개체

사용자 이벤트 처리에 대한 Redis 연결 세부 정보입니다.

.host
(필수)

문자열

Redis에 액세스할 수 있는 호스트 이름
예:
quay-server.example.com

.port
(필수)

숫자

Redis에 액세스할 수 있는 포트입니다.
예:
6379

.password

문자열

Redis에 액세스할 수 있는 포트입니다.
예:
strongpassword

ssl

부울

Redis와 Quay 간 TLS 통신을 활성화할지 여부입니다. 기본값은 false입니다.

3.5.1.1.3. Redis 구성 예

다음 YAML은 Redis를 사용하는 샘플 구성을 보여줍니다.

BUILDLOGS_REDIS:
    host: quay-server.example.com
    password: strongpassword
    port: 6379
    ssl: true

USER_EVENTS_REDIS:
    host: quay-server.example.com
    password: strongpassword
    port: 6379
    ssl: true
참고

배포에서 Redis에 Azure Cache를 사용하고 ssltrue 로 설정된 경우 포트는 6380 입니다.

3.5.2. Horizontal Pod Autoscaler 비활성화

HorizontalPodAutoscalers 가 Clair, Quay 및 Mirror 포드에 추가되어 이제 로드 급증 중에 자동으로 확장됩니다.

HPA는 기본적으로 관리 되도록 구성되므로 Quay, Clair 및 저장소 미러링의 Pod 수는 2로 설정됩니다. 이를 통해 Operator 또는 일정 기간 동안 Quay를 업데이트/구성할 때 다운타임을 방지할 수 있습니다.

자동 스케일링을 비활성화하거나 HorizontalPodAutoscaler 자체 생성하려는 경우 QuayRegistry 인스턴스에서 구성 요소를 관리되지 않는 것으로만 지정하면 됩니다.

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

3.5.3. 경로 구성 요소 비활성화

Operator가 경로 를 생성하지 못하도록 하려면 다음을 수행합니다.

  1. QuayRegistry 에서 구성 요소를 Unmanaged로 표시합니다.

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: example-registry
      namespace: quay-enterprise
    spec:
      components:
        - kind: route
          managed: false
  2. config.yaml 파일을 편집하여 Quay가 구성에서 TLS를 처리하도록 지정합니다.

    config.yaml

    ...
    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"
    }
참고

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

3.5.4. 관리되지 않는 모니터링

Quay Operator를 단일 네임스페이스에 설치하면 모니터링 구성 요소가 자동으로 '관리되지 않음'으로 설정됩니다. 이 시나리오에서 모니터링을 활성화하려면 8.2절. “단일 네임스페이스에 Operator가 설치될 때 모니터링 활성화” 섹션을 참조하십시오.

모니터링을 명시적으로 비활성화하려면 다음을 수행합니다.

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

3.5.5. 관리되지 않는 미러링

미러링을 명시적으로 비활성화하려면 다음을 수행합니다.

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

4장. Quay Operator를 사용하여 Quay 배포

Operator는 명령줄 또는 OpenShift 콘솔에서 배포할 수 있지만 기본 단계는 동일합니다.

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

  1. 네임스페이스(예: quay-enterprise )를 생성합니다.
  2. 배포의 모든 측면을 사전 구성하려면 구성 번들에 대한 시크릿을 생성합니다.
  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. 프록시가 구성된 경우 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. 배포 진행 상황을 추적하는 방법에 대한 자세한 내용은 배포 프로세스 모니터링 및 디버깅 섹션을 참조하십시오.
  6. status.registryEndpoint 가 채워질 때까지 기다립니다.

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

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

oc get pods 명령을 사용하여 배포된 구성 요소를 확인합니다.

$ 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

4.1.2. HPA(Horizontal Pod Autoscaling)

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

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

HPA는 기본적으로 관리 되도록 구성되므로 Quay, Clair 및 저장소 미러링의 Pod 수는 2로 설정됩니다. 이를 통해 Operator 또는 일정 기간 동안 Quay를 업데이트/구성할 때 다운타임을 방지할 수 있습니다.

$ 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

4.1.3. API를 사용하여 Red Hat Quay 배포

이 섹션에서는 API를 사용하여 Red Hat Quay를 배포하는 방법을 설명합니다.

사전 요구 사항

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

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

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

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

참고

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

  • status.registryEndpoint URL을 사용하여 /api/v1/user/initialize API를 호출하고 다음 명령을 입력하여 사용자 이름, 암호 및 이메일 주소를 전달합니다.

    $  curl -X POST -k  https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass123", "email": "quayadmin@example.com", "access_token": true}'

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

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

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

    {"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."}

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

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

$ 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: ""

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

배포가 진행되는 동안 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

배포 프로세스가 성공적으로 완료되면 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: {}

4.2. OpenShift 콘솔에서 Red Hat Quay 배포

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

4.2.1. Quay UI를 사용하여 첫 번째 사용자 생성

참고

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

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

    QuayRegistry details

  3. Registry Endpoint 에 값이 있으면 브라우저에서 이 URL로 이동합니다.
  4. Quay 레지스트리 UI에서 'Create Account'를 선택하여 사용자를 생성합니다.

    Create Account

  5. 사용자 이름, 암호, 이메일에 대한 세부 정보를 입력하고 Create Account를 클릭합니다.

    Enter account details

  6. Quay 레지스트리에 자동으로 로그인되어 있습니다.

    Initial log in

5장. OpenShift에서 Quay 구성

배포한 후 Quay 구성 번들 시크릿 spec.configBundleSecret 을 편집하여 Quay 애플리케이션을 구성할 수 있으며 QuayRegistry 리소스의 spec.components 오브젝트에서 구성 요소의 관리 상태를 변경할 수도 있습니다.

또는 6장. 구성 툴을 사용하여 OpenShift에서 Quay 재구성 섹션에 설명된 대로 구성 편집기 UI를 사용하여 Quay 애플리케이션을 구성할 수 있습니다.

5.1. OpenShift 콘솔에서 구성 번들 시크릿 편집

절차

  1. Quay Registry 개요 화면에서 Config Bundle Secret에 대한 링크를 클릭합니다.

    Quay Registry overview

  2. 시크릿을 편집하려면 작업시크릿 편집을 클릭합니다.

    Edit secret

  3. 설정을 수정하고 변경 사항을 저장

    Save changes

  4. 배포를 모니터링하여 성공적으로 완료되고 구성 변경 사항이 적용되었는지 확인합니다.

5.2. QuayRegistry 끝점 및 시크릿 확인

oc describe quayregistry 또는 oc get quayregistry -o yaml yaml을 사용하여 QuayRegistry 리소스를 검사하여 현재 끝점 및 시크릿을 확인할 수 있습니다.

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

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  ...
  name: example-registry
  namespace: quay-enterprise
  ...
spec:
  components:
  - kind: quay
    managed: true
  ...
  - kind: clairpostgres
    managed: true
  configBundleSecret: init-config-bundle-secret
status:
  configEditorCredentialsSecret: example-registry-quay-config-editor-credentials-fg2gdgtm24
  configEditorEndpoint: https://example-registry-quay-config-editor-quay-enterprise.apps.docs.gcp.quaydev.org
  currentVersion: 3.7.0
  lastUpdated: 2022-05-11 13:28:38.199476938 +0000 UTC
  registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org

관련 필드는 다음과 같습니다.

  • registryEndpoint: 레지스트리의 URL, 레지스트리 UI에 대한 브라우저 액세스, 레지스트리 API 끝점
  • configBundleSecret: config.yaml 파일 및 모든 SSL 인증서가 포함된 구성 번들 보안
  • configEditorEndpoint: 구성 편집기 툴의 URL, 구성 툴에 대한 브라우저 액세스용
  • configEditorCredentialsSecret: 사용자 이름(일반적으로 quayconfig) 및 config 편집기 툴의 암호가 포함된 시크릿

구성 편집기 도구의 사용자 이름과 암호를 확인하려면 다음을 수행합니다.

  1. 시크릿을 검색합니다.

    $ oc get secret -n quay-enterprise example-registry-quay-config-editor-credentials-fg2gdgtm24 -o yaml
    
    apiVersion: v1
    data:
      password: SkZwQkVKTUN0a1BUZmp4dA==
      username: cXVheWNvbmZpZw==
    kind: Secret
  2. 사용자 이름을 디코딩합니다.

    $ echo 'cXVheWNvbmZpZw==' | base64 --decode
    
    quayconfig
  3. 암호를 디코딩합니다.

    $ echo 'SkZwQkVKTUN0a1BUZmp4dA==' | base64 --decode
    
    JFpBEJMCtkPTfjxt

5.3. 기존 구성 다운로드

현재 구성에 액세스하는 방법은 여러 가지가 있습니다.

  1. 구성 편집기 끝점을 사용하여 구성 편집기의 사용자 이름과 암호를 지정합니다.

    $ curl -k -u quayconfig:JFpBEJMCtkPTfjxt https://example-registry-quay-config-editor-quay-enterprise.apps.docs.quayteam.org/api/v1/config
    {
        "config.yaml": {
            "ALLOW_PULLS_WITHOUT_STRICT_LOGGING": false,
            "AUTHENTICATION_TYPE": "Database",
            ...
            "USER_RECOVERY_TOKEN_LIFETIME": "30m"
        },
        "certs": {
            "extra_ca_certs/service-ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURVVENDQWptZ0F3SUJBZ0lJRE9kWFhuUXFjMUF3RFFZSktvWklodmNOQVFFTEJRQXdOakUwTURJR0ExVUUKQXd3cmIzQmxibk5vYVdaMExYTmxjblpwWTJVdGMyVnlkbWx1WnkxemFXZHVaWEpBTVRZek1UYzNPREV3TXpBZQpGdzB5TVRBNU1UWXdOelF4TkRKYUZ..."
        }
    }
  2. 구성 번들 시크릿 사용

    1. 시크릿 데이터를 가져옵니다.

      $ oc get secret -n quay-enterprise init-config-bundle-secret -o jsonpath='{.data}'

      샘플 출력

      {
          "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo="
      }

    2. 데이터를 디코딩합니다.

      $ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode
      FEATURE_USER_INITIALIZE: true
      BROWSER_API_CALLS_XHR_ONLY: false
      SUPER_USERS:
      - quayadmin
      FEATURE_USER_CREATION: false
      FEATURE_QUOTA_MANAGEMENT: true
      FEATURE_PROXY_CACHE: true
      FEATURE_BUILD_SUPPORT: true
      DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000

5.4. 구성 번들을 사용하여 사용자 정의 SSL 인증서 구성

구성 번들 시크릿을 생성하거나 업데이트하여 초기 배포 전 또는 Red Hat Quay가 OpenShift에 배포된 후 사용자 정의 SSL 인증서를 구성할 수 있습니다. 기존 배포에 인증서를 추가하는 경우 구성을 변경하지 않더라도 새 구성 번들 시크릿에 기존 config.yaml 을 포함해야 합니다.

5.4.1. TLS를 Unmanaged로 설정

Quay Registry yaml에서 kind: tlsmanaged: false 로 설정합니다.

  - kind: tls
    managed: false

이벤트에서는 적절한 구성을 설정할 때까지 변경 사항이 차단됩니다.

    - lastTransitionTime: '2022-03-28T12:56:49Z'
      lastUpdateTime: '2022-03-28T12:56:49Z'
      message: >-
        required component `tls` marked as unmanaged, but `configBundleSecret`
        is missing necessary fields
      reason: ConfigInvalid
      status: 'True'

5.4.2. 구성 번들에 인증서 추가

절차

  1. 포함된 데이터를 사용하거나 파일을 사용하여 시크릿을 생성합니다.

    1. 다음과 같이 구성 세부 정보를 Secret 리소스 YAML 파일에 직접 포함합니다.

      custom-ssl-config-bundle.yaml

      apiVersion: v1
      kind: Secret
      metadata:
        name: custom-ssl-config-bundle-secret
        namespace: quay-enterprise
      data:
        config.yaml: |
          FEATURE_USER_INITIALIZE: true
          BROWSER_API_CALLS_XHR_ONLY: false
          SUPER_USERS:
          - quayadmin
          FEATURE_USER_CREATION: false
          FEATURE_QUOTA_MANAGEMENT: true
          FEATURE_PROXY_CACHE: true
          FEATURE_BUILD_SUPPORT: true
          DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000
        extra_ca_cert_my-custom-ssl.crt: |
          -----BEGIN CERTIFICATE-----
          MIIDsDCCApigAwIBAgIUCqlzkHjF5i5TXLFy+sepFrZr/UswDQYJKoZIhvcNAQEL
          BQAwbzELMAkGA1UEBhMCSUUxDzANBgNVBAgMBkdBTFdBWTEPMA0GA1UEBwwGR0FM
          ....
          -----END CERTIFICATE-----

      다음으로 YAML 파일에서 보안을 생성합니다.

      $ oc create  -f custom-ssl-config-bundle.yaml
    2. 또는 원하는 정보가 포함된 파일을 생성한 다음 해당 파일에서 보안을 생성할 수 있습니다.

      $ oc create secret generic custom-ssl-config-bundle-secret \
        --from-file=config.yaml \
        --from-file=extra_ca_cert_my-custom-ssl.crt=my-custom-ssl.crt
  2. 생성된 보안을 참조하여 QuayRegistry YAML 파일 quayregistry.yaml 을 생성하거나 업데이트합니다.

    quayregistry.yaml

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

  3. YAML 파일을 사용하여 레지스트리를 배포하거나 업데이트합니다.

    oc apply -f quayregistry.yaml

6장. 구성 툴을 사용하여 OpenShift에서 Quay 재구성

6.1. config 편집기에 액세스

QuayRegistry 화면의 세부 정보 섹션에서 구성 편집기의 끝점과 구성 편집기에 로그인할 수 있는 인증 정보가 포함된 보안에 대한 링크도 사용할 수 있습니다.

Config editor details

6.1.1. 구성 편집기 인증 정보 검색

  1. 구성 편집기 보안 링크를 클릭합니다.

    Config editor secret

  2. Secret details 화면의 Data 섹션에서 Reveal 값을 클릭하여 구성 편집기에 로그인할 수 있는 인증 정보를 확인합니다.

    Config editor secret reveal

6.1.2. 구성 편집기에 로그인

구성 편집기 끝점으로 이동한 다음 사용자 이름, 일반적으로 quayconfig 및 해당 암호를 입력하여 구성 툴에 액세스합니다.

Config editor user interface

6.1.3. 구성 변경

구성을 업데이트하는 이 예에서는 config 편집기 툴을 통해 슈퍼 유저가 추가됩니다.

  1. 시간 머신 기능에 대한 만료 기간(예: 4w )을 추가합니다.

    Add expiration period

  2. 구성 변경 사항 검증을 선택하여 변경 사항이 유효한지 확인합니다.
  3. Reconfigure Quay 버튼을 눌러 변경 사항을 적용합니다.

    Reconfigure

  4. 구성 툴에서 변경 사항이 Quay에 제출되었음을 알립니다.

    Reconfigured

참고

구성 도구 UI를 사용하여 Red Hat Quay를 재구성하면 업데이트된 구성이 적용되는 동안 레지스트리를 단기간에 사용할 수 없게 될 수 있습니다.

6.2. UI의 재구성 모니터링

6.2.1. QuayRegistry 리소스

Operator를 재구성한 후 QuayRegistry의 특정 인스턴스에 대해 YAML 탭에서 재배포 진행 상황을 추적할 수 있습니다(이 경우 example-registry ):

ui monitor deploy update

상태가 변경될 때마다 데이터를 다시 로드하여 업데이트된 버전을 확인하라는 메시지가 표시됩니다. 결국 Operator는 변경 사항을 조정하고 비정상적인 구성 요소가 보고되지 않습니다.

ui monitor deploy done

6.2.2. 이벤트

QuayRegistry의 Events 탭에는 재배포와 관련된 일부 이벤트가 표시됩니다.

ui monitor deploy streaming events

재구성의 영향을 받는 네임스페이스의 모든 리소스에 대한 스트리밍 이벤트는 홈 → 이벤트 아래의 OpenShift 콘솔에서 사용할 수 있습니다.

ui monitor deploy streaming events

6.3. 재구성 후 업데이트된 정보에 액세스

6.3.1. UI에서 업데이트된 구성 툴 인증 정보에 액세스

Red Hat Quay 3.7을 사용하면 UI를 통해 Quay를 재구성해도 더 이상 새 로그인 암호가 생성되지 않습니다. 이제 암호는 한 번만 생성되며 QuayRegistry 오브젝트를 조정한 후 동일하게 유지됩니다.

6.3.2. UI에서 업데이트된 config.yaml에 액세스

config 번들을 사용하여 업데이트된 config.yaml 파일에 액세스합니다.

  1. QuayRegistry 세부 정보 화면에서 Config Bundle Secret을 클릭합니다.
  2. Secret details 화면의 Data 섹션에서 Reveal 값을 클릭하여 config.yaml 파일을 확인합니다.
  3. 변경 사항이 적용되었는지 확인합니다. 이 경우 4wTAG_EXPIRATION_OPTIONS 목록에 있어야 합니다.

    ...
    SERVER_HOSTNAME: example-quay-openshift-operators.apps.docs.quayteam.org
    SETUP_COMPLETE: true
    SUPER_USERS:
    - quayadmin
    TAG_EXPIRATION_OPTIONS:
    - 2w
    - 4w
    ...

6.4. 사용자 정의 SSL 인증서 UI

구성 툴을 사용하여 외부 데이터베이스와 같은 리소스에 쉽게 액세스할 수 있도록 사용자 정의 인증서를 로드할 수 있습니다. 업로드할 사용자 정의 인증서를 선택하여 .crt .crt 확장자를 사용하여 PEM 형식인지 확인합니다.

Custom SSL certificates

구성 툴에는 업로드된 인증서 목록도 표시됩니다. 사용자 정의 SSL 인증서를 업로드하면 목록에 표시됩니다.

Custom SSL certificates

6.5. 레지스트리에 대한 외부 액세스

OpenShift에서 실행하는 경우 Routes API를 사용할 수 있으며 자동으로 관리되는 구성 요소로 사용됩니다. QuayRegistry 를 생성한 후 외부 액세스 포인트는 QuayRegistry 의 상태 블록에서 확인할 수 있습니다.

status:
  registryEndpoint: some-quay.my-namespace.apps.mycluster.com

7장. Quay Operator 기능

7.1. 콘솔 모니터링 및 경고

Red Hat Quay는 OpenShift 콘솔 내부에서 Operator를 사용하여 배포된 Quay 인스턴스 모니터링을 지원합니다. 새로운 모니터링 기능에는 Grafana 대시보드, 개별 메트릭 액세스, Quay Pod를 자주 다시 시작하도록 경고하는 경고가 포함됩니다.

참고

모니터링 기능을 활성화하려면 Operator를 "모든 네임스페이스" 모드에 설치해야 합니다.

7.1.1. 대시보드

OpenShift 콘솔에서 모니터링 → 대시보드로 이동하여 원하는 Quay 레지스트리 인스턴스의 대시보드를 검색합니다.

Choose Quay dashboard

대시보드에는 다음을 포함한 다양한 통계가 표시됩니다.

  • 조직, 리포지토리, 사용자 및 iPXE 계정 수
  • CPU 사용량 및 최대 메모리 사용량
  • 이미지 가져오기 및 푸시 속도 및 인증 요청
  • API 요청 속도
  • 대기 시간

Console dashboard

7.1.2. 메트릭

UI에서 모니터링 → 메트릭에 액세스하여 Quay 대시보드 뒤의 기본 메트릭을 확인할 수 있습니다. 표현식 필드에 텍스트 quay_ 를 입력하여 사용 가능한 지표 목록을 확인합니다.

Quay metrics

샘플 메트릭을 선택합니다(예: quay_org_rows ).

Number of Quay organizations

이 메트릭은 레지스트리의 조직 수를 나타내며 대시보드에도 직접 표시됩니다.

7.1.3. 경고

Quay 포드가 너무 자주 다시 시작되면 경고가 발생합니다. consol UI의 Monitoring → Alerting에서 경고 규칙 탭에 액세스하고 Quay별 경고를 검색하여 경고를 구성할 수 있습니다.

Alerting rules

QuayPod frequentlyRestarting 규칙 세부 정보를 선택하여 경고를 구성합니다.

Alerting rule details

7.2. Air-gapped OpenShift 클러스터에서 Clair의 취약점 데이터베이스를 수동으로 업데이트

Clair는 다양한 취약점 데이터베이스를 가져오고 구문 분석하는 논리를 캡슐화하는 update r라는 패키지를 활용합니다. Clair는 다른 환경에서 업데이트 프로그램을 실행하고 결과를 가져올 수 있습니다. 이는 Clair 클러스터가 인터넷에 직접 대화하지 못하도록 하는 설치를 지원하기 위한 것입니다.

Air-gapped OpenShift 클러스터에서 Clair의 취약점 데이터베이스를 수동으로 업데이트하려면 다음 단계를 사용합니다.

  • clairctl 프로그램 가져오기
  • Clair 구성 검색
  • clairctl 을 사용하여 인터넷에 액세스할 수 있는 Clair 인스턴스에서 업데이트됨 번들을 내보냅니다.
  • Clair 데이터베이스에 액세스할 수 있도록 air-gapped OpenShift 클러스터에서 Clair 구성을 업데이트합니다.
  • 인터넷 액세스가 가능한 시스템에서 업데이트 번들을 전송하여 에어-Gapped 환경에서 사용할 수 있도록 합니다.
  • clairctl 을 사용하여 Air-gapped OpenShift 클러스터의 Clair 인스턴스로 업데이트 번들을 가져옵니다.

7.2.1. clairctl 가져오기

OpenShift 클러스터의 Clair 배포에서 clairctl 프로그램을 가져오려면 oc cp 명령을 사용합니다. 예를 들면 다음과 같습니다.

$ oc -n quay-enterprise cp example-registry-clair-app-64dd48f866-6ptgw:/usr/bin/clairctl ./clairctl
$ chmod u+x ./clairctl

독립 실행형 Clair 배포의 경우 podman cp 명령을 사용합니다. 예를 들면 다음과 같습니다.

$ sudo podman cp clairv4:/usr/bin/clairctl ./clairctl
$ chmod u+x ./clairctl

7.2.2. Clair 구성 검색

7.2.2.1. OpenShift 구성의 Clair

OpenShift Operator를 사용하여 배포된 Clair 인스턴스의 구성 파일을 검색하려면 적절한 네임스페이스를 사용하여 config 시크릿을 검색하고 디코딩하고 파일에 저장합니다. 예를 들면 다음과 같습니다.

$ kubectl get secret -n quay-enterprise example-registry-clair-config-secret  -o "jsonpath={$.data['config\.yaml']}" | base64 -d > clair-config.yaml

Clair 구성 파일에서 발췌한 내용은 다음과 같습니다.

clair-config.yaml

http_listen_addr: :8080
introspection_addr: ""
log_level: info
indexer:
    connstring: host=example-registry-clair-postgres port=5432 dbname=postgres user=postgres password=postgres sslmode=disable
    scanlock_retry: 10
    layer_scan_concurrency: 5
    migrations: true
    scanner:
        package: {}
        dist: {}
        repo: {}
    airgap: false
matcher:
    connstring: host=example-registry-clair-postgres port=5432 dbname=postgres user=postgres password=postgres sslmode=disable
    max_conn_pool: 100
    indexer_addr: ""
    migrations: true
    period: null
    disable_updaters: false
notifier:
    connstring: host=example-registry-clair-postgres port=5432 dbname=postgres user=postgres password=postgres sslmode=disable
    migrations: true
    indexer_addr: ""
    matcher_addr: ""
    poll_interval: 5m
    delivery_interval: 1m
    ...

7.2.2.2. 독립 실행형 Clair 구성

독립 실행형 Clair 배포의 경우 구성 파일은 podman run 명령의 CLAIR_CONF 환경 변수에 지정된 파일입니다. 예를 들면 다음과 같습니다.

sudo podman run -d --rm --name clairv4 \
  -p 8081:8081 -p 8089:8089 \
  -e CLAIR_CONF=/clair/config.yaml -e CLAIR_MODE=combo \
  -v /etc/clairv4/config:/clair:Z \
  registry.redhat.io/quay/clair-rhel8:v3.7.10

7.2.3. 업데이트 번들 내보내기

인터넷에 액세스할 수 있는 Clair 인스턴스에서 적절한 구성 파일과 함께 clairctl 을 사용하여 업데이트 번들을 내보냅니다.

$ ./clairctl --config ./config.yaml export-updaters updates.gz

7.2.4. air-gapped OpenShift 클러스터에서 Clair 데이터베이스에 대한 액세스 구성

  • kubectl 을 사용하여 Clair 데이터베이스 서비스를 확인합니다.

    $ kubectl get svc -n quay-enterprise
    
    NAME                                  TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                             AGE
    example-registry-clair-app            ClusterIP      172.30.224.93    <none>        80/TCP,8089/TCP                     4d21h
    example-registry-clair-postgres       ClusterIP      172.30.246.88    <none>        5432/TCP                            4d21h
    ...
  • 로컬 시스템에서 액세스할 수 있도록 Clair 데이터베이스 포트를 전달합니다. 예를 들면 다음과 같습니다.

    $ kubectl port-forward -n quay-enterprise service/example-registry-clair-postgres 5432:5432
  • 여러 connstring 필드의 호스트 값을 localhost 로 교체하여 Clair 구성 파일을 업데이트합니다. 예를 들면 다음과 같습니다.

    clair-config.yaml

        ...
        connstring: host=localhost port=5432 dbname=postgres user=postgres password=postgres sslmode=disable
        ...

참고

kubectl port-forward 를 사용하는 대신 kubefwd 를 사용할 수 있습니다. 이 방법을 사용하면 localhost 를 사용하도록 Clair 구성 파일에서 connstring 필드를 수정할 필요가 없습니다.

7.2.5. Air-gapped 환경으로 업데이트 번들 가져오기

업데이트기 번들을 Air-gapped 환경으로 변환한 후 clairctl 을 사용하여 OpenShift Operator가 배포한 Clair 데이터베이스로 번들을 가져옵니다.

$ ./clairctl --config ./clair-config.yaml import-updaters updates.gz

7.3. FIPS 준비 및 컴플라이언스

FIPS (National About of Standards and Technology에서 개발한 연방 정보 처리 표준)는 특히 금융, 의료 및 대중과 같은 많이 규제되는 영역에서 민감한 데이터를 보호하고 암호화하기위한 금 표준으로 분류되고 있습니다. Red Hat Enterprise Linux 및 Red Hat OpenShift Container Platform은 시스템에서 openssl 과 같은 특정 FIPS 검증 암호화 모듈만 사용할 수 있는 FIPS 모드를 제공하여 이 표준을 지원합니다. 이렇게 하면 FIPS 규정 준수가 보장됩니다.

Red Hat Quay는 버전 3.5의 FIPS 지원 RHEL 및 Red Hat OpenShift Container Platform에서 실행을 지원합니다.

8장. 고급 개념

8.1. 인프라 노드에 Quay 배포

기본적으로 Quay 관련 포드는 Operator를 사용하여 레지스트리를 배포할 때 임의의 작업자 노드에 배치됩니다. OpenShift Container Platform 설명서에서는 머신 세트를 사용하여 호스트 인프라 구성 요소에만 노드를 구성하는 방법을 보여줍니다( https://docs.openshift.com/container-platform/4.7/machine_management/creating-infrastructure-machinesets.html참조).

OCP MachineSet 리소스를 사용하여 인프라 노드를 배포하지 않는 경우 이 섹션에서는 인프라 목적으로 노드를 수동으로 레이블을 지정하고 테인트하는 방법을 보여줍니다.

인프라 노드를 수동 또는 머신 세트를 사용하여 구성한 후에는 노드 선택기 및 허용 오차를 사용하여 이러한 노드에 Quay Pod 배치를 제어할 수 있습니다.

8.1.1. 인프라가 사용할 라벨 및 테인트 노드

이 예제에서 사용되는 클러스터에는 3개의 마스터 노드와 6개의 작업자 노드가 있습니다.

$ oc get nodes
NAME                                               STATUS   ROLES    AGE     VERSION
user1-jcnp6-master-0.c.quay-devel.internal         Ready    master   3h30m   v1.20.0+ba45583
user1-jcnp6-master-1.c.quay-devel.internal         Ready    master   3h30m   v1.20.0+ba45583
user1-jcnp6-master-2.c.quay-devel.internal         Ready    master   3h30m   v1.20.0+ba45583
user1-jcnp6-worker-b-65plj.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
user1-jcnp6-worker-b-jr7hc.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
user1-jcnp6-worker-c-jrq4v.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal   Ready    worker   3h22m   v1.20.0+ba45583
user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583

인프라 사용을 위해 마지막 세 개의 작업자 노드에 레이블을 지정합니다.

$ oc label node --overwrite user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal node-role.kubernetes.io/infra=
$ oc label node --overwrite user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal node-role.kubernetes.io/infra=
$ oc label node --overwrite user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal node-role.kubernetes.io/infra=

이제 클러스터의 노드를 나열하면 마지막 3개의 작업자 노드가 infra 의 추가 역할을 갖습니다.

$ oc get nodes
NAME                                               STATUS   ROLES          AGE     VERSION
user1-jcnp6-master-0.c.quay-devel.internal         Ready    master         4h14m   v1.20.0+ba45583
user1-jcnp6-master-1.c.quay-devel.internal         Ready    master         4h15m   v1.20.0+ba45583
user1-jcnp6-master-2.c.quay-devel.internal         Ready    master         4h14m   v1.20.0+ba45583
user1-jcnp6-worker-b-65plj.c.quay-devel.internal   Ready    worker         4h6m    v1.20.0+ba45583
user1-jcnp6-worker-b-jr7hc.c.quay-devel.internal   Ready    worker         4h5m    v1.20.0+ba45583
user1-jcnp6-worker-c-jrq4v.c.quay-devel.internal   Ready    worker         4h5m    v1.20.0+ba45583
user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal   Ready    infra,worker   4h6m    v1.20.0+ba45583
user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal   Ready    infra,worker   4h6m    v1.20.0+ba45583
user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal   Ready    infra,worker   4h6m    v1.20.0+ba45583

인프라 노드가 작업자로 할당되면 사용자 워크로드가 의도치 않게 인프라 노드에 할당될 수 있습니다. 이를 방지하려면 인프라 노드에 테인트를 적용한 다음 제어하려는 Pod에 대한 허용 오차를 추가할 수 있습니다.

$ oc adm taint nodes user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule
$ oc adm taint nodes user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule
$ oc adm taint nodes user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule

8.1.2. 노드 선택기 및 허용 오차를 사용하여 프로젝트를 생성

Quay Operator를 사용하여 Quay를 이미 배포한 경우, 설치된 Operator 및 배포에 대해 생성한 특정 네임스페이스를 제거합니다.

다음 예와 같이 노드 선택기 및 허용 오차를 지정하여 프로젝트 리소스를 생성합니다.

quay-registry.yaml

kind: Project
apiVersion: project.openshift.io/v1
metadata:
  name: quay-registry
  annotations:
    openshift.io/node-selector: 'node-role.kubernetes.io/infra='
    scheduler.alpha.kubernetes.io/defaultTolerations: >-
      [{"operator": "Exists", "effect": "NoSchedule", "key":
      "node-role.kubernetes.io/infra"}
      ]

oc apply 명령을 사용하여 프로젝트를 생성합니다.

$ oc apply -f quay-registry.yaml
project.project.openshift.io/quay-registry created

quay-registry 네임스페이스에서 생성된 후속 리소스는 이제 전용 인프라 노드에 예약해야 합니다.

8.1.3. 네임스페이스에 Quay Operator 설치

Quay Operator를 설치할 때 적절한 프로젝트 네임스페이스를 명시적으로 지정합니다(이 경우 quay-registry ). 이렇게 하면 Operator Pod가 세 가지 인프라 노드 중 하나에서 중단됩니다.

$ oc get pods -n quay-registry -o wide
NAME                                    READY   STATUS    RESTARTS   AGE   IP            NODE                                              
quay-operator.v3.4.1-6f6597d8d8-bd4dp   1/1     Running   0          30s   10.131.0.16   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal

8.1.4. 레지스트리를 생성

앞에서 설명한 대로 레지스트리를 생성한 다음 배포가 준비될 때까지 기다립니다. Quay 포드를 나열하면 인프라 목적으로 레이블이 지정된 세 개의 노드에서만 예약되었음을 확인할 수 있습니다.

$ oc get pods -n quay-registry -o wide
NAME                                                   READY   STATUS      RESTARTS   AGE     IP            NODE                                                
example-registry-clair-app-789d6d984d-gpbwd            1/1     Running     1          5m57s   10.130.2.80   user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal
example-registry-clair-postgres-7c8697f5-zkzht         1/1     Running     0          4m53s   10.129.2.19   user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal
example-registry-quay-app-56dd755b6d-glbf7             1/1     Running     1          5m57s   10.129.2.17   user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal
example-registry-quay-config-editor-7bf9bccc7b-dpc6d   1/1     Running     0          5m57s   10.131.0.23   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal
example-registry-quay-database-8dc7cfd69-dr2cc         1/1     Running     0          5m43s   10.129.2.18   user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal
example-registry-quay-mirror-78df886bcc-v75p9          1/1     Running     0          5m16s   10.131.0.24   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal
example-registry-quay-postgres-init-8s8g9              0/1     Completed   0          5m54s   10.130.2.79   user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal
example-registry-quay-redis-5688ddcdb6-ndp4t           1/1     Running     0          5m56s   10.130.2.78   user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal
quay-operator.v3.4.1-6f6597d8d8-bd4dp                  1/1     Running     0          22m     10.131.0.16   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal

8.2. 단일 네임스페이스에 Operator가 설치될 때 모니터링 활성화

Red Hat Quay Operator가 단일 네임스페이스에 설치되면 모니터링 구성 요소가 관리되지 않습니다. 모니터링을 구성하려면 OpenShift Container Platform에서 사용자 정의 네임스페이스에 대해 활성화해야 합니다. 자세한 내용은 모니터링 스택 구성사용자 정의 프로젝트에 대한 모니터링 활성화에 대한 OCP 문서를 참조하십시오.

다음 단계에서는 OCP 설명서를 기반으로 Quay에 대한 모니터링을 구성하는 방법을 보여줍니다.

8.2.1. 클러스터 모니터링 구성 맵 생성

  1. cluster-monitoring-config ConfigMap 오브젝트가 있는지 확인합니다.

    $ oc -n openshift-monitoring get configmap cluster-monitoring-config
    
    Error from server (NotFound): configmaps "cluster-monitoring-config" not found
  2. ConfigMap 오브젝트가 없는 경우: 

    1. 다음 YAML 매니페스트를 생성합니다. 이 예제에서는 파일을 cluster-monitoring-config.yaml 이라고 합니다.

      $ cat cluster-monitoring-config.yaml
      
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
    2. ConfigMap 오브젝트를 생성합니다.

      $ oc apply -f cluster-monitoring-config.yaml configmap/cluster-monitoring-config created
      $ oc -n openshift-monitoring get configmap cluster-monitoring-config
      
      NAME                        DATA   AGE
      cluster-monitoring-config   1      12s

8.2.2. 사용자 정의 워크로드 모니터링 구성 맵 생성

  1. user-workload-monitoring-config ConfigMap 오브젝트가 있는지 확인합니다.

    $ oc -n openshift-user-workload-monitoring get configmap user-workload-monitoring-config
    
    Error from server (NotFound): configmaps "user-workload-monitoring-config" not found
  2. ConfigMap 오브젝트가 없는 경우:

    1. 다음 YAML 매니페스트를 생성합니다. 이 예제에서는 파일을 user-workload-monitoring-config.yaml 이라고 합니다.

      $ cat user-workload-monitoring-config.yaml
      
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
    2. ConfigMap 오브젝트를 생성합니다.

      $ oc apply -f user-workload-monitoring-config.yaml
      
      configmap/user-workload-monitoring-config created

8.2.3. 사용자 정의 프로젝트에 대한 모니터링 활성화

  1. 사용자 정의 프로젝트에 대한 모니터링이 실행 중인지 확인합니다.

    $ oc get pods -n openshift-user-workload-monitoring
    
    No resources found in openshift-user-workload-monitoring namespace.
  2. cluster-monitoring-config ConfigMap을 편집합니다.

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     

  3. 클러스터에서 사용자 정의 프로젝트에 대한 모니터링을 활성화하려면 enableUserWorkload: true 를 설정합니다.

    apiVersion: v1
    data:
      config.yaml: |
        enableUserWorkload: true
    kind: ConfigMap
    metadata:
      annotations:
  4. 파일을 저장하여 변경 사항을 적용한 다음 적절한 Pod가 실행 중인지 확인합니다.

    $ oc get pods -n openshift-user-workload-monitoring
    
    NAME                                   READY   STATUS    RESTARTS   AGE
    prometheus-operator-6f96b4b8f8-gq6rl   2/2     Running   0          15s
    prometheus-user-workload-0             5/5     Running   1          12s
    prometheus-user-workload-1             5/5     Running   1          12s
    thanos-ruler-user-workload-0           3/3     Running   0          8s
    thanos-ruler-user-workload-1           3/3     Running   0          8s

     

8.2.4. Quay 지표를 노출하는 Service 오브젝트 생성

  1. Service 오브젝트에 대한 YAML 파일을 생성합니다.

    $ cat quay-service.yaml
    
    apiVersion: v1
    kind: Service
    metadata:
      annotations:
      labels:
        quay-component: monitoring
        quay-operator/quayregistry: example-registry
      name: example-registry-quay-metrics
      namespace: quay-enterprise
    spec:
      ports:
      - name: quay-metrics
        port: 9091
        protocol: TCP
        targetPort: 9091
      selector:
        quay-component: quay-app
        quay-operator/quayregistry: example-registry
      type: ClusterIP

       

  2. Service 오브젝트를 생성합니다.

    $  oc apply -f quay-service.yaml
    
    service/example-registry-quay-metrics created

8.2.5. ServiceMonitor 오브젝트 생성

ServiceMonitor 리소스를 생성하여 지표를 스크랩하도록 OpenShift 모니터링을 구성합니다.

  1. ServiceMonitor 리소스에 대한 YAML 파일을 생성합니다.

    $ cat quay-service-monitor.yaml
    
    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      labels:
        quay-operator/quayregistry: example-registry
      name: example-registry-quay-metrics-monitor
      namespace: quay-enterprise
    spec:
      endpoints:
      - port: quay-metrics
      namespaceSelector:
        any: true
      selector:
        matchLabels:
          quay-component: monitoring
  2. ServiceMonitor를 생성합니다.

    $  oc apply -f quay-service-monitor.yaml
    
    servicemonitor.monitoring.coreos.com/example-registry-quay-metrics-monitor created

8.2.6. OpenShift에서 메트릭 보기

모니터링 → 메트릭에서 OpenShift 콘솔의 메트릭에 액세스할 수 있습니다. 표현식 필드에 텍스트 quay_ 를 입력하여 사용 가능한 지표 목록을 확인합니다.

Quay metrics

예를 들어 레지스트리에 사용자를 추가한 경우 quay-users_rows 지표를 선택합니다.

Quay metrics

8.3. 관리 스토리지 크기 조정

Quay Operator는 NooBaa 오브젝트(50 Gib)를 생성할 때 RHOCS에서 제공하는 기본값을 사용하여 기본 오브젝트 스토리지를 생성합니다. 이 스토리지를 확장하는 방법에는 두 가지가 있습니다. 기존 PVC의 크기를 조정하거나 새 스토리지 풀에 PVC를 더 추가할 수 있습니다.

8.3.1. Noobaa PVC 크기 조정

  1. OpenShift 콘솔에 로그인하고 스토리지영구 볼륨 클레임 을 선택합니다.
  2. noobaa-default-backing-store-noobaa-pvc-* 와 같은 PersistentVolumeClaim 을 선택합니다.
  3. Action 메뉴에서 Expand PVC 를 선택합니다.
  4. 영구 볼륨 클레임의 새 크기를 입력하고 Expand 를 선택합니다.

몇 분 후에 PVC 크기에 따라 확장된 크기는 PVC의 용량 필드에 반영되어야 합니다.

참고

CSI 볼륨 확장은 기술 프리뷰 기능 전용입니다. 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html/storage/expanding-persistent-volumes 에서 참조하십시오.

8.3.2. 다른 스토리지 풀 추가

  1. OpenShift 콘솔에 로그인하고 네트워킹경로 를 선택합니다. openshift-storage 프로젝트가 선택되었는지 확인합니다.
  2. noobaa-mgmt 경로의 위치 필드를 클릭합니다.
  3. Noobaa 관리 콘솔에 로그인합니다.
  4. 기본 대시보드의 스토리지 리소스에서 스토리지 리소스 추가를 선택합니다.
  5. Deploy Kubernetes Pool선택
  6. 새 풀 이름을 입력합니다. 다음을 클릭합니다.
  7. 풀을 관리하고 노드당 크기를 설정할 Pod 수를 선택합니다. 다음을 클릭합니다.
  8. 배포를 클릭합니다.

몇 분 후에 Noobaa 리소스에 추가 스토리지 풀이 추가되고 Red Hat Quay에서 사용할 수 있습니다.

8.4. 기본 Operator 이미지 사용자 정의

참고

이 메커니즘 사용은 프로덕션 Quay 환경에서 지원되지 않으며 개발/테스트 목적으로만 권장됩니다. Quay Operator와 함께 기본이 아닌 이미지를 사용할 때 배포가 제대로 작동하는지 보장할 수 없습니다.

특정 상황에서는 Operator에서 사용하는 기본 이미지를 재정의하는 것이 유용할 수 있습니다. Quay Operator ClusterServiceVersion 에서 하나 이상의 환경 변수를 설정하여 이 작업을 수행할 수 있습니다.

8.4.1. 환경 변수

Operator에서 다음 환경 변수는 구성 요소 이미지를 재정의하는 데 사용됩니다.

환경 변수

구성 요소

RELATED_IMAGE_COMPONENT_QUAY

base

RELATED_IMAGE_COMPONENT_CLAIR

Clair

RELATED_IMAGE_COMPONENT_POSTGRES

Postgres 및 clair 데이터베이스

RELATED_IMAGE_COMPONENT_REDIS

Redis

참고

덮어쓰기 이미지는 태그(:latest)가 아닌 매니페스트(@sha256:)에서 참조해야 합니다.

8.4.2. 실행 중인 Operator에 덮어쓰기 적용

OLM(Operator Lifecycle Manager)을 통해 Quay Operator가 클러스터에 설치되면 클러스터에서 실행 중인 Operator에 대한 OLM 의 표현인 ClusterServiceVersion 오브젝트를 수정하여 관리 구성 요소 컨테이너 이미지를 쉽게 덮어쓸 수 있습니다. Kubernetes UI 또는 kubectl/oc 를 사용하여 Quay Operator의 ClusterServiceVersion 을 찾습니다.

$ oc get clusterserviceversions -n <your-namespace>

UI, oc edit 또는 기타 방법을 사용하여 덮어쓰기 이미지를 가리키도록 위에서 설명한 환경 변수를 포함하도록 Quay ClusterServiceVersion 을 수정합니다.

JSONPath: spec.install.spec.deployments[0].spec.template.spec.containers[0].env

- name: RELATED_IMAGE_COMPONENT_QUAY
  value: quay.io/projectquay/quay@sha256:c35f5af964431673f4ff5c9e90bdf45f19e38b8742b5903d41c10cc7f6339a6d
- name: RELATED_IMAGE_COMPONENT_CLAIR
  value: quay.io/projectquay/clair@sha256:70c99feceb4c0973540d22e740659cd8d616775d3ad1c1698ddf71d0221f3ce6
- name: RELATED_IMAGE_COMPONENT_POSTGRES
  value: centos/postgresql-10-centos7@sha256:de1560cb35e5ec643e7b3a772ebaac8e3a7a2a8e8271d9e91ff023539b4dfb33
- name: RELATED_IMAGE_COMPONENT_REDIS
  value: centos/redis-32-centos7@sha256:06dbb609484330ec6be6090109f1fa16e936afcf975d1cbc5fff3e6c7cae7542

이 작업은 Operator 수준에서 수행되므로 모든 QuayRegistry는 동일한 덮어쓰기를 사용하여 배포됩니다.

8.5. AWS S3 CloudFront

백엔드 레지스트리 스토리지에 AWS S3 CloudFront를 사용하는 경우 다음 예와 같이 개인 키를 지정합니다.

$ oc create secret generic --from-file config.yaml=./config_awss3cloudfront.yaml --from-file default-cloudfront-signing-key.pem=./default-cloudfront-signing-key.pem test-config-bundle

8.5.1. 고급 Clair 구성

8.5.1.1. 관리되지 않는 Clair 구성

Red Hat Quay 3.7을 사용하면 Red Hat Quay OpenShift Container Platform Operator에서 관리되지 않는 Clair 구성을 실행할 수 있습니다. 이 기능을 사용하면 관리되지 않는 Clair 데이터베이스를 생성하거나 관리되지 않는 데이터베이스 없이 사용자 지정 Clair 구성을 실행할 수 있습니다.

8.5.1.1.1. Clair 데이터베이스 관리 해제

관리되지 않는 Clair 데이터베이스를 사용하면 Red Hat Quay Operator가 지역 복제 환경에서 작업할 수 있습니다. 여기서 Operator의 여러 인스턴스가 동일한 데이터베이스와 통신해야 합니다. 관리되지 않는 Clair 데이터베이스는 사용자에게 클러스터 외부에 존재하는 HA(고가용성) Clair 데이터베이스가 필요한 경우에도 사용할 수 있습니다.

절차

  • Quay Operator에서 QuayRegistry 사용자 정의 리소스의 clairpostgres 구성 요소를 Unmanaged로 설정합니다.

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: quay370
    spec:
      configBundleSecret: config-bundle-secret
      components:
        - kind: objectstorage
          managed: false
        - kind: route
          managed: true
        - kind: tls
          managed: false
        - kind: clairpostgres
          managed: false
8.5.1.1.2. 사용자 정의 Clair 데이터베이스 구성

OpenShift Container Platform용 Red Hat Quay Operator를 사용하면 configBundleSecret 매개변수를 편집하여 자체 Clair 구성을 제공할 수 있습니다.

절차

  1. clair-config.yaml 을 포함하는 Quay 구성 번들 시크릿을 생성합니다.

    $ oc create secret generic --from-file config.yaml=./config.yaml --from-file extra_ca_cert_rds-ca-2019-root.pem=./rds-ca-2019-root.pem --from-file clair-config.yaml=./clair-config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret

    clair-config.yaml 설정 예:

    indexer:
        connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslrootcert=/run/certs/rds-ca-2019-root.pem sslmode=verify-ca
        layer_scan_concurrency: 6
        migrations: true
        scanlock_retry: 11
    log_level: debug
    matcher:
        connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslrootcert=/run/certs/rds-ca-2019-root.pem sslmode=verify-ca
        migrations: true
    metrics:
        name: prometheus
    notifier:
        connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslrootcert=/run/certs/rds-ca-2019-root.pem sslmode=verify-ca
        migrations: true
    참고
    • 데이터베이스 인증서는 clair-config.yaml 의 Clair 애플리케이션 Pod의 /run/certs/rds-ca-2019-root.pem 에 마운트됩니다. clair-config.yaml 을 구성할 때 지정해야 합니다.
    • clair-config.yaml 의 예는 OpenShift 구성의 Clair에서 확인할 수 있습니다.
  2. configBundleSecret 이라는 번들 보안에 clair-config.yaml 을 추가합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: config-bundle-secret
      namespace: quay-enterprise
    data:
      config.yaml: <base64 encoded Quay config>
      clair-config.yaml: <base64 encoded Clair config>
      extra_ca_cert_<name>: <base64 encoded ca cert>
      clair-ssl.crt: >-
      clair-ssl.key: >-
    참고

    업데이트되면 제공된 clair-config.yaml 이 Clair 포드에 마운트됩니다. 제공되지 않는 모든 필드는 Clair 구성 모듈을 사용하여 기본값으로 자동으로 채워집니다.

올바르게 구성된 후 Clair 애플리케이션 Pod는 Ready 상태로 돌아갑니다.

8.5.1.2. 관리 데이터베이스를 사용하여 사용자 정의 Clair 구성 실행

경우에 따라 사용자가 관리 데이터베이스를 사용하여 사용자 지정 Clair 구성을 실행하려고 할 수 있습니다. 이는 다음 시나리오에서 유용합니다.

  • 사용자가 업데이트를 비활성화하려는 경우
  • 사용자가 Air-gapped 환경에서 실행되는 경우

    참고
    • Air-gapped 환경에서 Quay를 실행하는 경우 clair-config.yamlairgap 매개변수를 true 로 설정해야 합니다.
    • Air-gapped 환경에서 Quay를 실행하는 경우 모든 업데이트자를 비활성화해야 합니다.

clairpostgres 가 관리로 설정된 경우 "사용자 지정 Clair 데이터베이스 구성"의 단계를 사용하여 데이터베이스를 구성합니다.

Air-gapped 환경에서 Clair를 실행하는 방법에 대한 자세한 내용은 Air-gapped OpenShift 클러스터의 Clair 데이터베이스에 대한 액세스 구성을 참조하십시오.

9장. Red Hat Quay 빌드 개선 사항

Red Hat Quay 3.7 이전에는 Pod에서 시작한 가상 머신에서 podman 명령을 실행했습니다. 가상 플랫폼에서 빌드를 실행하려면 중첩된 가상화를 활성화해야 하며, 이는 Red Hat Enterprise Linux 또는 OpenShift Container Platform에 포함되지 않습니다. 그 결과 리소스를 비효율적으로 사용하는 것이 베어 메탈 클러스터에서 빌드를 실행해야 했습니다.

Red Hat Quay 3.7.에서는 가상 머신 계층이 포함되지 않은 빌드 옵션을 추가하여 빌드를 실행하는 데 필요한 베어 메탈 제약 조건이 제거되었습니다. 결과적으로 가상화된 플랫폼에서 빌드를 실행할 수 있습니다. 이전 빌드 구성을 실행하기 위한 이전 버전과의 호환성도 사용할 수 있습니다.

9.1. Red Hat Quay의 향상된 빌드 아키텍처

위 이미지는 향상된 빌드 기능의 예상 설계 흐름 및 아키텍처를 보여줍니다.

Enhanced Quay builds architecture

이번 개선된 기능을 통해 빌드 관리자는 먼저 Job Object 를 생성합니다. 그런 다음 Job Object 에서 quay-builder-image 를 사용하여 포드를 생성합니다. quay-builder-image 에는 quay-builder 바이너리Podman 서비스가 포함됩니다. 생성된 Pod는 권한이 없는 Pod로 실행됩니다. quay-builder 바이너리 는 상태를 통신하고 빌드 관리자에서 빌드 정보를 검색하는 동안 이미지를 빌드합니다.

9.2. Red Hat Quay 빌드 제한 사항

권한이 없는 컨텍스트에서 Red Hat Quay에서 빌드를 실행하면 이전 빌드 전략에서 작업하는 일부 명령이 실패할 수 있습니다. 빌드 전략을 변경하려고 하면 빌드와 관련된 성능 문제 및 안정성이 발생할 수 있습니다.

컨테이너에서 직접 빌드를 실행하는 경우 가상 머신 사용과 동일한 격리가 없습니다. 빌드 환경을 변경하면 이전에 작업했던 빌드가 실패할 수 있었습니다.

9.3. OpenShift를 사용하여 Red Hat Quay 빌더 환경 생성

9.3.1. OpenShift TLS 구성 요소

tls 구성 요소를 사용하면 TLS 구성을 제어할 수 있습니다.

참고

Operator에서 TLS 구성 요소를 관리하는 경우 Red Hat Quay 3.7은 빌더를 지원하지 않습니다.

tls관리되지 않는 ssl.certssl.key 파일을 제공합니다. 이 경우 클러스터가 빌더를 지원하도록 하려면 인증서의 SAN 목록에 Quay 경로와 빌더 경로 이름을 모두 추가하거나 와일드카드를 사용해야 합니다. 빌더 경로를 추가하려면 다음 형식을 사용합니다.

[quayregistry-cr-name]-quay-builder-[ocp-namespace].[ocp-domain-name]:443

9.3.2. Red Hat Quay 빌더에 OpenShift Container Platform 사용

다음 절차에서는 Red Hat Quay에서 빌더 기능을 구현하는 방법을 설명합니다.

사전 요구 사항

  • 빌더에는 SSL 인증서가 필요합니다. 자세한 내용은 Red Hat Quay 컨테이너에 TLS 인증서 추가를 참조하십시오.
  • AWS S3 스토리지를 사용하는 경우 빌더를 실행하기 전에 AWS 콘솔에서 스토리지 버킷을 수정해야 합니다. 필수 매개변수는 다음 섹션의 "AWS S3 스토리지 버킷 수정"을 참조하십시오.
절차
  • 이 절차에서는 클러스터가 이미 프로비저닝되어 Quay Operator가 실행되고 있다고 가정합니다.
  • 다음 절차에서는 OpenShift Container Platform에서 가상 네임스페이스를 설정하는 데 사용됩니다.

9.3.2.1. 가상 빌더를 위한 OpenShift Container Platform 준비

  1. 클러스터 관리자 계정을 사용하여 Red Hat Quay 클러스터에 로그인합니다.
  2. 가상 빌더가 실행될 새 프로젝트를 생성합니다(예: virtual-builders).

    $ oc new-project virtual-builders
  3. 이 프로젝트에서 빌드를 실행하는 데 사용할 ServiceAccount 를 생성합니다.

    $ oc create sa -n virtual-builders quay-builder
  4. 빌드를 실행할 수 있도록 편집 권한이 생성된 서비스 계정을 제공합니다.

    $ oc adm policy -n virtual-builders add-role-to-user edit system:serviceaccount:virtual-builders:quay-builder
  5. Quay 빌더 anyuid scc 권한을 부여합니다.

    $ oc adm policy -n virtual-builders add-scc-to-user anyuid -z quay-builder
    참고

    이 작업을 수행하려면 클러스터 관리자 권한이 필요합니다. 이는 권한이 없거나 rootless 빌드가 작동하려면 빌더를 Podman 사용자로 실행해야 하므로 필요합니다.

  6. Quay 빌더 서비스 계정의 토큰을 가져옵니다.

    1. OpenShift Container Platform 4.10 또는 이전 버전을 사용하는 경우 다음 명령을 입력합니다.

      oc sa get-token -n virtual-builders quay-builder
    2. OpenShift Container Platform 4.11 이상을 사용하는 경우 다음 명령을 입력합니다.

      $ oc create token quay-builder -n virtual-builders

      샘플 출력

      eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ...

  7. 빌더 경로를 확인합니다.

    $ oc get route -n quay-enterprise

    샘플 출력

    NAME                                  HOST/PORT                                                                    PATH   SERVICES                              PORT   TERMINATION     WILDCARD
    ...
    example-registry-quay-builder         example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org                example-registry-quay-app             grpc   edge/Redirect   None
    ...

  8. .crt 확장자를 사용하여 자체 서명된 SSL 인증서를 생성합니다.

    $ oc extract cm/kube-root-ca.crt -n openshift-apiserver ca.crt
    $ mv ca.crt extra_ca_cert_build_cluster.crt
  9. 콘솔에서 구성 번들의 시크릿을 찾고 작업 → 시크릿 편집을 선택하고 적절한 빌더 구성을 추가합니다.

    FEATURE_USER_INITIALIZE: true
    BROWSER_API_CALLS_XHR_ONLY: false
    SUPER_USERS:
    - <superusername>
    FEATURE_USER_CREATION: false
    FEATURE_QUOTA_MANAGEMENT: true
    FEATURE_BUILD_SUPPORT: True
    BUILDMAN_HOSTNAME: <sample_build_route> 1
    BUILD_MANAGER:
      - ephemeral
      - ALLOWED_WORKER_COUNT: 1
        ORCHESTRATOR_PREFIX: buildman/production/
        JOB_REGISTRATION_TIMEOUT: 3600 2
        ORCHESTRATOR:
          REDIS_HOST: <sample_redis_hostname> 3
          REDIS_PASSWORD: ""
          REDIS_SSL: false
          REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
        EXECUTORS:
          - EXECUTOR: kubernetesPodman
            NAME: openshift
            BUILDER_NAMESPACE: <sample_builder_namespace> 4
            SETUP_TIME: 180
            MINIMUM_RETRY_THRESHOLD:
            BUILDER_CONTAINER_IMAGE: <sample_builder_container_image> 5
            # Kubernetes resource options
            K8S_API_SERVER: <sample_k8s_api_server> 6
            K8S_API_TLS_CA: <sample_crt_file> 7
            VOLUME_SIZE: 8G
            KUBERNETES_DISTRIBUTION: openshift
            CONTAINER_MEMORY_LIMITS: 300m 8
            CONTAINER_CPU_LIMITS: 1G 9
            CONTAINER_MEMORY_REQUEST: 300m 10
            CONTAINER_CPU_REQUEST: 1G 11
            NODE_SELECTOR_LABEL_KEY: ""
            NODE_SELECTOR_LABEL_VALUE: ""
            SERVICE_ACCOUNT_NAME: <sample_service_account_name>
            SERVICE_ACCOUNT_TOKEN: <sample_account_token> 12
    1
    빌드 경로는 OpenShift Operators 네임스페이스의 이름으로 oc get route -n 을 실행하여 가져옵니다. 예를 들어, 포트는 경로 끝에 제공되어야 하며 [quayregistry-cr-name]-quay-builder-[ocp-namespace].[ocp-domain-name]:443 형식을 따라야 합니다.
    2
    JOB_REGISTRATION_TIMEOUT 매개변수가 너무 낮으면 다음과 같은 오류가 발생할 수 있습니다: failed to register job to build manager:ECDHE error: code = Unauthenticated desc = Invalid build token: signature has expired. 이 매개 변수는 최소 CloudEvent로 설정되는 것이 좋습니다.
    3
    Redis 호스트에 암호 또는 SSL 인증서가 있는 경우 적절하게 업데이트해야 합니다.
    4
    가상 빌더 네임스페이스의 이름과 일치하도록 설정합니다(예: virtual-builders ).
    5
    초기 액세스의 경우 BUILDER_CONTAINER_IMAGE 는 현재 quay.io/projectquay/quay-builder:3.7.0-rc.2 입니다. 초기 액세스 기간 동안 변경될 수 있습니다. 이러한 상황이 발생하면 고객에게 경고를 받을 수 있습니다.
    6
    oc cluster-info 를 실행하여 가져옵니다.
    7
    사용자 정의 CA 인증서를 수동으로 생성하고 추가해야 합니다(예: K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build_cluster.crt ).
    8
    지정되지 않은 경우 기본값은 5120Mi입니다.
    9
    가상 빌드의 경우 클러스터에 리소스가 충분한지 확인해야 합니다. 지정되지 않은 경우 기본값은 1000m입니다.
    10
    지정되지 않은 경우 기본값은 3968Mi입니다.
    11
    지정되지 않은 경우 기본값은 500m입니다.
    12
    oc create sa 를 실행할 때 가져옵니다.

    샘플 구성

    FEATURE_USER_INITIALIZE: true
    BROWSER_API_CALLS_XHR_ONLY: false
    SUPER_USERS:
    - quayadmin
    FEATURE_USER_CREATION: false
    FEATURE_QUOTA_MANAGEMENT: true
    FEATURE_BUILD_SUPPORT: True
    BUILDMAN_HOSTNAME: example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org:443
    BUILD_MANAGER:
      - ephemeral
      - ALLOWED_WORKER_COUNT: 1
        ORCHESTRATOR_PREFIX: buildman/production/
        JOB_REGISTRATION_TIMEOUT: 3600
        ORCHESTRATOR:
          REDIS_HOST: example-registry-quay-redis
          REDIS_PASSWORD: ""
          REDIS_SSL: false
          REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
        EXECUTORS:
          - EXECUTOR: kubernetesPodman
            NAME: openshift
            BUILDER_NAMESPACE: virtual-builders
            SETUP_TIME: 180
            MINIMUM_RETRY_THRESHOLD:
            BUILDER_CONTAINER_IMAGE: quay.io/projectquay/quay-builder:3.7.0-rc.2
            # Kubernetes resource options
            K8S_API_SERVER: api.docs.quayteam.org:6443
            K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build_cluster.crt
            VOLUME_SIZE: 8G
            KUBERNETES_DISTRIBUTION: openshift
            CONTAINER_MEMORY_LIMITS: 1G
            CONTAINER_CPU_LIMITS: 1080m
            CONTAINER_MEMORY_REQUEST: 1G
            CONTAINER_CPU_REQUEST: 580m
            NODE_SELECTOR_LABEL_KEY: ""
            NODE_SELECTOR_LABEL_VALUE: ""
            SERVICE_ACCOUNT_NAME: quay-builder
            SERVICE_ACCOUNT_TOKEN: "eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ"

9.3.2.2. SSL 인증서를 수동으로 추가합니다.

중요
  • 구성 도구의 알려진 문제로 인해 빌더를 올바르게 실행하려면 사용자 정의 SSL 인증서를 수동으로 추가해야 합니다. 사용자 정의 SSL 인증서를 수동으로 추가하려면 다음 절차를 사용하십시오. SSL 인증서를 생성하는 방법에 대한 자세한 내용은 Red Hat Quay 컨테이너에 TLS 인증서 추가를 참조하십시오.
9.3.2.2.1. 인증서 생성 및 서명
  1. 인증 기관을 생성하고 인증서에 서명합니다. 자세한 내용은 인증 기관 생성 및 인증서에 서명을 참조하십시오.

    참고
    • Quay 레지스트리의 URL에 alt_name 을 추가합니다.
    • config.yaml에 지정된 BUILDMAN_HOSTNAMEalt_name 을 추가합니다.

    openssl.cnf

    [req]
    req_extensions = v3_req
    distinguished_name = req_distinguished_name
    [req_distinguished_name]
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    subjectAltName = @alt_names
    [alt_names]
    DNS.1 = example-registry-quay-quay-enterprise.apps.docs.quayteam.org
    DNS.2 = example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org

    샘플 명령

    $ openssl genrsa -out rootCA.key 2048
    $ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem
    $ openssl genrsa -out ssl.key 2048
    $ openssl req -new -key ssl.key -out ssl.csr
    $ openssl x509 -req -in ssl.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out ssl.cert -days 356 -extensions v3_req -extfile openssl.cnf

9.3.2.2.2. TLS를 Unmanaged로 설정

Quay Registry yaml에서 kind: tlsmanaged: false 로 설정합니다.

  - kind: tls
    managed: false

이벤트에서는 적절한 구성을 설정할 때까지 변경 사항이 차단됩니다.

    - lastTransitionTime: '2022-03-28T12:56:49Z'
      lastUpdateTime: '2022-03-28T12:56:49Z'
      message: >-
        required component `tls` marked as unmanaged, but `configBundleSecret`
        is missing necessary fields
      reason: ConfigInvalid
      status: 'True'
9.3.2.2.3. 임시 보안 생성
  1. CA 인증서의 기본 네임스페이스에 보안을 생성합니다.

    $ oc create secret generic -n quay-enterprise temp-crt --from-file extra_ca_cert_build_cluster.crt
  2. ssl.key 및 ssl.cert 파일의 기본 네임스페이스에 보안을 생성합니다.

    $ oc create secret generic -n quay-enterprise quay-config-ssl --from-file ssl.cert --from-file ssl.key
9.3.2.2.4. 시크릿 데이터를 config.yaml에 복사
  1. 워크로드 → 시크릿의 콘솔 UI에서 새 보안을 찾습니다.
  2. 각 시크릿에 대해 YAML 보기를 찾습니다.

    kind: Secret
    apiVersion: v1
    metadata:
      name: temp-crt
      namespace: quay-enterprise
      uid: a4818adb-8e21-443a-a8db-f334ace9f6d0
      resourceVersion: '9087855'
      creationTimestamp: '2022-03-28T13:05:30Z'
    ...
    data:
      extra_ca_cert_build_cluster.crt: >-
        LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURNakNDQWhxZ0F3SUJBZ0l....
    type: Opaque
    kind: Secret
    apiVersion: v1
    metadata:
      name: quay-config-ssl
      namespace: quay-enterprise
      uid: 4f5ae352-17d8-4e2d-89a2-143a3280783c
      resourceVersion: '9090567'
      creationTimestamp: '2022-03-28T13:10:34Z'
    ...
    data:
      ssl.cert: >-
        LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVaakNDQTA2Z0F3SUJBZ0lVT...
      ssl.key: >-
        LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBc...
    type: Opaque
  3. 다음과 같은 명령을 실행하여 UI에서 Quay 레지스트리 구성 번들의 시크릿을 검색하거나 명령줄을 통해 찾습니다.

    $ oc get quayregistries.quay.redhat.com -o jsonpath="{.items[0].spec.configBundleSecret}{'\n'}"  -n quay-enterprise
  4. OpenShift 콘솔에서 구성 번들 시크릿의 YAML 탭을 선택하고 생성한 두 보안의 데이터를 추가합니다.

    kind: Secret
    apiVersion: v1
    metadata:
      name: init-config-bundle-secret
      namespace: quay-enterprise
      uid: 4724aca5-bff0-406a-9162-ccb1972a27c1
      resourceVersion: '4383160'
      creationTimestamp: '2022-03-22T12:35:59Z'
    ...
    data:
      config.yaml: >-
        RkVBVFVSRV9VU0VSX0lOSVRJQUxJWkU6IHRydWUKQlJ...
      extra_ca_cert_build_cluster.crt: >-
        LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURNakNDQWhxZ0F3SUJBZ0ldw....
      ssl.cert: >-
        LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVaakNDQTA2Z0F3SUJBZ0lVT...
      ssl.key: >-
        LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBc...
    type: Opaque
  5. 저장을 클릭합니다. Pod가 다시 시작되어야 합니다.

    $ oc get pods -n quay-enterprise

    샘플 출력

    NAME                                                   READY   STATUS              RESTARTS   AGE
    ...
    example-registry-quay-app-6786987b99-vgg2v             0/1     ContainerCreating   0          2s
    example-registry-quay-app-7975d4889f-q7tvl             1/1     Running             0          5d21h
    example-registry-quay-app-7975d4889f-zn8bb             1/1     Running             0          5d21h
    example-registry-quay-app-upgrade-lswsn                0/1     Completed           0          6d1h
    example-registry-quay-config-editor-77847fc4f5-nsbbv   0/1     ContainerCreating   0          2s
    example-registry-quay-config-editor-c6c4d9ccd-2mwg2    1/1     Running             0          5d21h
    example-registry-quay-database-66969cd859-n2ssm        1/1     Running             0          6d1h
    example-registry-quay-mirror-764d7b68d9-jmlkk          1/1     Terminating         0          5d21h
    example-registry-quay-mirror-764d7b68d9-jqzwg          1/1     Terminating         0          5d21h
    example-registry-quay-redis-7cc5f6c977-956g8           1/1     Running             0          5d21h

  6. Quay 레지스트리가 재구성된 후 Quay 앱 포드가 실행 중인지 확인합니다.

    $ oc get pods -n quay-enterprise

    샘플 출력

    example-registry-quay-app-6786987b99-sz6kb             1/1     Running            0          7m45s
    example-registry-quay-app-6786987b99-vgg2v             1/1     Running            0          9m1s
    example-registry-quay-app-upgrade-lswsn                0/1     Completed          0          6d1h
    example-registry-quay-config-editor-77847fc4f5-nsbbv   1/1     Running            0          9m1s
    example-registry-quay-database-66969cd859-n2ssm        1/1     Running            0          6d1h
    example-registry-quay-mirror-758fc68ff7-5wxlp          1/1     Running            0          8m29s
    example-registry-quay-mirror-758fc68ff7-lbl82          1/1     Running            0          8m29s
    example-registry-quay-redis-7cc5f6c977-956g8           1/1     Running            0          5d21h

  7. 브라우저에서 레지스트리 끝점에 액세스하여 인증서가 적절하게 업데이트되었는지 확인합니다.

    Common Name (CN)	example-registry-quay-quay-enterprise.apps.docs.quayteam.org
    Organisation (O)	DOCS
    Organisational Unit (OU)	QUAY

9.3.2.3. UI를 사용하여 빌드 트리거 생성

  1. Quay 리포지토리에 로그인합니다.
  2. Create New Repository 를 클릭하고 새 레지스트리(예: testrepo )를 생성합니다.
  3. Repositories (리포지토리) 페이지의 왼쪽 창에서 Builds 탭을 클릭합니다. 또는 해당 URL을 직접 사용합니다. 예를 들면 다음과 같습니다.

    https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/repository/quayadmin/testrepo?tab=builds
    중요

    경우에 따라 빌더에 호스트 이름을 확인하는 데 문제가 있을 수 있습니다. 이 문제는 작업 오브젝트에 대해 dnsPolicydefault 로 설정되는 것과 관련이 있을 수 있습니다. 현재 이 문제에 대한 해결방법이 없습니다. 이 문제는 향후 Red Hat Quay 버전에서 해결될 예정입니다.

  4. 빌드 트리거 생성사용자 지정 Git 리포지토리 내보내기를 클릭합니다.
  5. Git 리포지토리를 복제하는 데 사용되는 HTTPS 또는 SSH 스타일 URL을 입력한 다음 Continue 를 클릭합니다. 예를 들면 다음과 같습니다.

    https://github.com/gabriel-rh/actions_test.git
  6. 분기 또는 태그 이름으로 태그 매니페스트를 확인한 다음 Continue 를 클릭합니다.
  7. 트리거를 호출할 때 빌드할 Dockerfile의 위치를 입력하고(예: /Dockerfile ) 계속 을 클릭합니다.
  8. Docker 빌드에 대한 컨텍스트 위치(예: / )를 입력하고 Continue 를 클릭합니다.
  9. 필요한 경우 WebSocket 계정을 만듭니다. 그렇지 않으면 Continue 를 클릭합니다.
  10. Continue 를 클릭하여 매개 변수를 확인합니다.
  11. 빌드 페이지에서 트리거 이름의 옵션 아이콘을 클릭한 다음 지금 트리거 실행을 클릭합니다.
  12. Git 리포지토리에서 커밋 SHA를 입력하고 Start Build 를 클릭합니다.
  13. 빌드 기록 페이지에서 커밋을 클릭하거나 oc get pods -n virtual-builders 를 실행하여 빌드 상태를 확인할 수 있습니다.

     $ oc get pods -n virtual-builders
    NAME                                               READY   STATUS    RESTARTS   AGE
    f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2   1/1     Running   0          7s
    $ oc get pods -n virtual-builders
    NAME                                               READY   STATUS        RESTARTS   AGE
    f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2   1/1     Terminating   0          9s
    $ oc get pods -n virtual-builders
    No resources found in virtual-builders namespace.
  14. 빌드가 완료되면 왼쪽 창에서 태그 아래에 있는 태그의 상태를 확인할 수 있습니다.

    참고

    초기 액세스 권한을 사용하면 현재 전체 빌드 로그 및 빌드 타임 스탬프를 사용할 수 없습니다.

9.3.2.4. AWS S3 스토리지 버킷 수정

AWS S3 스토리지를 사용하는 경우 빌더를 실행하기 전에 AWS 콘솔에서 스토리지 버킷을 수정해야 합니다.

  1. s3.console.aws.com 에서 AWS 콘솔에 로그인합니다.
  2. 검색 창에서 S3 을 검색한 다음 S3 을 클릭합니다.
  3. 버킷 이름을 클릭합니다(예: myawsbucket ).
  4. 권한 탭을 클릭합니다.
  5. CORS(Cross-origin resource sharing) 아래에서 다음 매개변수를 포함합니다.

      [
          {
              "AllowedHeaders": [
                  "Authorization"
              ],
              "AllowedMethods": [
                  "GET"
              ],
              "AllowedOrigins": [
                  "*"
              ],
              "ExposeHeaders": [],
              "MaxAgeSeconds": 3000
          },
          {
              "AllowedHeaders": [
                  "Content-Type",
                  "x-amz-acl",
                  "origin"
              ],
              "AllowedMethods": [
                  "PUT"
              ],
              "AllowedOrigins": [
                  "*"
              ],
              "ExposeHeaders": [],
              "MaxAgeSeconds": 3000
          }
      ]

10장. geo-replication

Geo-replication을 사용하면 지역적으로 분산된 여러 Red Hat Quay 배포가 클라이언트 또는 사용자의 관점에서 단일 레지스트리로 작동하도록 허용합니다. 전역적으로 분산된 Red Hat Quay 설정에서 푸시 및 풀 성능을 크게 향상시킵니다. 클라이언트의 투명한 장애 조치 / 리디렉션을 사용하여 백그라운드에서 이미지 데이터가 비동기적으로 복제됩니다.

Red Hat Quay 3.7을 사용하면 지역간 복제를 사용하는 Red Hat Quay 배포는 독립 실행형 및 Operator 배포에서 지원됩니다.

10.1. Geo-replication 기능

  • Geo-replication이 구성되면 컨테이너 이미지 푸시가 해당 Red Hat Quay 인스턴스(일반적으로 리전 내 가장 가까운 스토리지 백엔드)의 기본 스토리지 엔진에 작성됩니다.
  • 초기 푸시 후 이미지 데이터는 백그라운드에서 다른 스토리지 엔진에 복제됩니다.
  • 복제 위치 목록은 구성 가능하며 다른 스토리지 백엔드일 수 있습니다.
  • 이미지 풀은 항상 사용 가능한 가장 가까운 스토리지 엔진을 사용하여 가져오기 성능을 극대화합니다.
  • 복제가 아직 완료되지 않은 경우 pull은 대신 소스 스토리지 백엔드를 사용합니다.

10.2. 지역 복제 요구 사항 및 제약 조건

  • Geo-replicated 설정에서 Red Hat Quay는 다른 모든 리전의 개체 스토리지를 읽고 쓸 수 있어야 합니다. 오브젝트 스토리지는 다른 모든 리전에서 지리적으로 액세스할 수 있어야 합니다.
  • 하나의 geo-replicating 사이트의 오브젝트 스토리지 시스템에 오류가 발생하는 경우 해당 사이트의 Red Hat Quay 배포를 종료해야 합니다. 클라이언트가 글로벌 로드 밸런서에 의해 손상되지 않은 스토리지 시스템을 사용하여 나머지 사이트로 리디렉션되도록 해당 사이트의 Red Hat Quay 배포를 종료해야 합니다. 그렇지 않으면 클라이언트가 풀 및 푸시 오류를 경험하게 됩니다.
  • Red Hat Quay는 연결된 오브젝트 스토리지 시스템의 상태 또는 가용성에 대한 내부적인 인식이 없습니다. 한 사이트의 오브젝트 스토리지 시스템을 사용할 수 없게 되면 나머지 사이트 또는 사이트 중 나머지 스토리지 시스템 또는 시스템으로 자동 리디렉션되지 않습니다.
  • Geo-replication은 비동기식입니다. 사이트를 영구적으로 손실하면 해당 사이트의 개체 스토리지 시스템에 저장된 데이터가 손실되지만 실패 시 아직 남아 있는 사이트로 복제되지 않았습니다.
  • 단일 데이터베이스이므로 모든 메타데이터 및 Quay 구성은 모든 리전에서 공유됩니다.

    Geo-replication은 데이터베이스를 복제하지 않습니다. 중단이 발생하면 geo-replication이 활성화된 Red Hat Quay는 다른 데이터베이스로 장애 조치되지 않습니다.

  • 단일 Redis 캐시는 전체 Quay 설정에서 공유되며 모든 Quay 포드에서 액세스할 수 있어야 합니다.
  • QUAY_DISTRIBUTED_STORAGE_PREFERENCE 환경 변수를 사용하여 명시적으로 구성할 수 있는 스토리지 백엔드를 제외하고 모든 리전에서 정확히 동일한 구성을 사용해야 합니다.
  • geo-Replication에는 각 리전의 오브젝트 스토리지가 필요합니다. 로컬 스토리지 또는 NFS에서는 작동하지 않습니다.
  • 각 리전은 각 리전의 모든 스토리지 엔진에 액세스할 수 있어야 합니다(네트워크 경로가 필요함).
  • 또는 스토리지 프록시 옵션을 사용할 수 있습니다.
  • 전체 스토리지 백엔드(모든 Blob)가 복제됩니다. 이는 조직 또는 리포지토리 또는 이미지로 제한할 수 있는 저장소 미러링과는 다릅니다.
  • 모든 Quay 인스턴스는 일반적으로 로드 밸런서를 통해 동일한 진입점을 공유해야 합니다.
  • 모든 Quay 인스턴스에는 공통 구성 파일 내에 정의되어 있으므로 동일한 슈퍼유저 세트가 있어야 합니다.
  • Geo-replication을 사용하려면 Clair 구성을 관리되지 않음 으로 설정해야 합니다. 관리되지 않는 Clair 데이터베이스를 사용하면 Red Hat Quay Operator가 지역 복제 환경에서 작업할 수 있습니다. 여기서 Operator의 여러 인스턴스가 동일한 데이터베이스와 통신해야 합니다. 자세한 내용은 Advanced Clair 구성을 참조하십시오.
  • Geo-Replication에는 SSL/TSL 인증서와 키가 필요합니다. 자세한 내용은 Using SSL to Red Hat Quay 를 참조하십시오.

위의 요구 사항을 충족할 수 없는 경우 대신 두 개 이상의 개별 Quay 배포를 사용하고 저장소 미러링 기능을 사용해야 합니다.

10.3. Red Hat Quay Operator를 사용하여 geo-replication

Georeplication architecture

위에 표시된 예제에서 Red Hat Quay Operator는 공통 데이터베이스 및 공통 Redis 인스턴스와 함께 두 개의 별도의 지역에 배포됩니다. 로컬화된 이미지 스토리지는 각 리전에 제공되며, 사용 가능한 가장 가까운 스토리지 엔진에서 이미지 풀이 제공됩니다. 컨테이너 이미지 푸시는 Quay 인스턴스의 기본 스토리지 엔진에 기록되며 백그라운드에서 다른 스토리지 엔진에 복제됩니다.

Operator에서 Clair 보안 스캐너와 해당 데이터베이스를 별도로 관리하므로 Clair 데이터베이스를 관리하지 않도록 geo-replication 설정을 활용할 수 있습니다. 대신 외부 공유 데이터베이스가 사용됩니다. Red Hat Quay와 Clair는 Red Hat Quay 3.x 테스트 매트릭스 에서 찾을 수 있는 PostgreSQL의 여러 공급업체와 공급업체를 지원합니다. 또한 Operator는 배포에 삽입할 수 있는 사용자 지정 Clair 구성을 지원하므로 사용자가 외부 데이터베이스의 연결 자격 증명을 사용하여 Clair를 구성할 수 있습니다.

10.3.1. Openshift에서 지역 복제 설정

절차

  1. Quay postgres 인스턴스를 배포합니다.

    1. 데이터베이스에 로그인
    2. Quay의 데이터베이스 생성

      CREATE DATABASE quay;
    3. 데이터베이스 내에서 pg_trm 확장을 활성화합니다.

      \c quay;
      CREATE EXTENSION IF NOT EXISTS pg_trgm;
  2. Redis 인스턴스를 배포합니다.

    참고
    • 클라우드 공급자에 자체 서비스가 있는 경우 Redis 인스턴스를 배포할 필요가 없습니다.
    • 빌더를 활용하는 경우 Redis 인스턴스를 배포해야 합니다.
    1. Redis의 VM 배포
    2. Quay가 실행 중인 클러스터에서 액세스할 수 있는지 확인합니다.
    3. 6379/TCP 포트가 열려 있어야 합니다.
    4. 인스턴스 내에서 Redis 실행

      sudo dnf install -y podman
      podman run -d --name redis -p 6379:6379 redis
  3. 각 클러스터에 하나씩 두 개의 오브젝트 스토리지 백엔드 생성

    이상적으로 하나의 오브젝트 스토리지 버킷은 1차 클러스터(기본)에 근접하고 다른 오브젝트 스토리지 버킷은 2차 클러스터(초)에 더 가깝게 실행됩니다.

  4. 환경 변수 덮어쓰기를 사용하여 동일한 구성 번들이 있는 클러스터를 배포하여 개별 클러스터에 적합한 스토리지 백엔드를 선택합니다.
  5. 클러스터에 단일 진입점을 제공하도록 로드 밸런서 구성

10.3.1.1. 설정

config.yaml 파일은 클러스터 간에 공유되며 일반 PostgreSQL, Redis 및 스토리지 백엔드에 대한 세부 정보를 포함합니다.

config.yaml

SERVER_HOSTNAME: <georep.quayteam.org or any other name> 1
DB_CONNECTION_ARGS:
  autorollback: true
  threadlocals: true
DB_URI: postgresql://postgres:password@10.19.0.1:5432/quay 2
BUILDLOGS_REDIS:
  host: 10.19.0.2
  port: 6379
USER_EVENTS_REDIS:
  host: 10.19.0.2
  port: 6379
DISTRIBUTED_STORAGE_CONFIG:
  usstorage:
    - GoogleCloudStorage
    - access_key: GOOGQGPGVMASAAMQABCDEFG
      bucket_name: georep-test-bucket-0
      secret_key: AYWfEaxX/u84XRA2vUX5C987654321
      storage_path: /quaygcp
  eustorage:
    - GoogleCloudStorage
    - access_key: GOOGQGPGVMASAAMQWERTYUIOP
      bucket_name: georep-test-bucket-1
      secret_key: AYWfEaxX/u84XRA2vUX5Cuj12345678
      storage_path: /quaygcp
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
  - usstorage
  - eustorage
DISTRIBUTED_STORAGE_PREFERENCE:
  - usstorage
  - eustorage
FEATURE_STORAGE_REPLICATION: true

1
경로에 적절한 SERVER_HOSTNAME 을 사용해야 하며 글로벌 로드 밸런서의 호스트 이름과 일치해야 합니다.
2
OpenShift Operator를 사용하여 배포된 Clair 인스턴스의 구성 파일을 검색하려면 Clair 구성 검색에서 참조하십시오.

configBundleSecret 을 만듭니다.

$ oc create secret generic --from-file config.yaml=./config.yaml georep-config-bundle

각 클러스터에서 configBundleSecret 을 설정하고 QUAY_DISTRIBUTED_STORAGE_PREFERENCE 환경 변수 덮어쓰기를 사용하여 해당 클러스터에 적절한 스토리지를 구성합니다.

참고

두 배포 간의 config.yaml 파일이 일치해야 합니다. 하나의 클러스터를 변경하는 경우 다른 클러스터에서도 변경해야 합니다.

미국 클러스터

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: georep-config-bundle
  components:
    - kind: objectstorage
      managed: false
    - kind: route
      managed: true
    - kind: tls
      managed: false
    - kind: postgres
      managed: false
    - kind: clairpostgres
      managed: false
    - kind: redis
      managed: false
    - kind: quay
      managed: true
      overrides:
        env:
        - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
          value: usstorage
    - kind: mirror
      managed: true
      overrides:
        env:
        - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
          value: usstorage

+

참고

TLS는 관리되지 않으며 경로가 관리되므로 인증서를 config 툴을 사용하거나 구성 번들에 직접 제공해야 합니다. 자세한 내용은 TLS 및 경로 구성을 참조하십시오.

유럽 클러스터

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: georep-config-bundle
  components:
    - kind: objectstorage
      managed: false
    - kind: route
      managed: true
    - kind: tls
      managed: false
    - kind: postgres
      managed: false
    - kind: clairpostgres
      managed: false
    - kind: redis
      managed: false
    - kind: quay
      managed: true
      overrides:
        env:
        - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
          value: eustorage
    - kind: mirror
      managed: true
      overrides:
        env:
        - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
          value: eustorage

+

참고

TLS는 관리되지 않으며 경로가 관리되므로 인증서를 config 툴을 사용하거나 구성 번들에 직접 제공해야 합니다. 자세한 내용은 TLS 및 경로 구성을 참조하십시오.

10.3.2. Geo-replication을 위한 혼합 스토리지

Red Hat Quay geo-replication은 서로 다른 여러 복제 대상의 사용을 지원합니다(예: 퍼블릭 클라우드에서 AWS S3 스토리지 사용 및 사용). 이를 통해 모든 Red Hat Quay 포드 및 클러스터 노드의 모든 스토리지 백엔드에 대한 액세스 권한을 부여하는 주요 요구 사항이 복잡해집니다. 따라서 다음을 수행하는 것이 좋습니다.

  • VPN을 사용하여 내부 스토리지 또는스토리지의 가시성을 방지
  • Quay에서 사용하는 지정된 버킷에 대한 액세스만 허용하는 토큰 쌍을 사용합니다.

그러면 Red Hat Quay의 퍼블릭 클라우드 인스턴스가 온-프레미스 스토리지에 액세스할 수 있지만 네트워크는 암호화되고 보호되며 ACL을 사용하여 보안 요구 사항을 충족합니다.

이러한 보안 조치를 구현할 수 없는 경우 두 개의 별도의 Red Hat Quay 레지스트리를 배포하고 지역 복제 대신 저장소 미러링을 사용하는 것이 좋습니다.

11장. Red Hat Quay Operator에서 관리하는 Red Hat Quay 백업 및 복원

이 섹션의 콘텐츠를 사용하여 OpenShift Container Platform의 Red Hat Quay Operator에서 관리할 때 Red Hat Quay를 백업 및 복원합니다.

11.1. Red Hat Quay 백업

다음 절차에서는 Red Hat Quay Operator를 사용하여 OpenShift Container Platform에 배포된 Red Hat Quay의 백업을 생성하는 방법을 설명합니다.

사전 요구 사항

  • Red Hat Quay Operator를 사용하여 OpenShift Container Platform에 정상적인 Red Hat Quay 배포 (상태 조건 Available is set to true)
  • 구성 요소 quay,postgresobjectstoragemanaged: true로 설정됩니다.
  • 구성 요소 clairmanaged: true 로 설정된 경우 구성 요소 clairpostgresmanaged: true 로 설정됩니다(Red Hat Quay Operator v3.7 이상으로 시작)
참고

배포에 부분적으로 관리되지 않는 데이터베이스 또는 스토리지 구성 요소가 포함되어 있고 Postgres 또는 S3 호환 오브젝트 스토리지에 외부 서비스를 사용하여 Red Hat Quay 배포를 실행하는 경우, 데이터 백업을 생성하려면 서비스 공급자 또는 벤더 설명서를 참조해야 합니다. 이 가이드에 설명된 툴을 외부 Postgres 데이터베이스 또는 오브젝트 스토리지를 백업하는 방법에 대한 시작점으로 참조할 수 있습니다.

11.1.1. Red Hat Quay 구성 백업

  1. QuayRegistry 사용자 정의 리소스를 내보내십시오.

    $ oc get quayregistry <quay-registry-name> -n <quay-namespace> -o yaml > quay-registry.yaml
  2. 결과 quayregistry.yaml 을 편집하고 status 섹션 및 다음 메타데이터 필드를 제거합니다.

      metadata.creationTimestamp
      metadata.finalizers
      metadata.generation
      metadata.resourceVersion
      metadata.uid
  3. 관리형 키 시크릿을 백업합니다.

    참고

    Red Hat Quay 3.7.0 이전 버전을 실행하는 경우 이 단계를 건너뜁니다. 일부 시크릿은 Quay를 처음 배포하는 동안 자동으로 생성됩니다. 이는 QuayRegistry 리소스의 네임스페이스에서 < quay-registry-name>-quay-registry-managed-secret-keys 라는 시크릿에 저장됩니다.

    $ oc get secret -n <quay-namespace> <quay-registry-name>-quay-registry-managed-secret-keys -o yaml > managed-secret-keys.yaml
  4. 결과 managed-secret-keys.yaml 파일을 편집하고 metadata.ownerReferences 항목을 제거합니다. managed-secret-keys.yaml 파일은 다음과 유사해야 합니다.

    apiVersion: v1
    kind: Secret
    type: Opaque
    metadata:
      name: <quayname>-quay-registry-managed-secret-keys
      namespace: <quay-namespace>
    data:
      CONFIG_EDITOR_PW: <redacted>
      DATABASE_SECRET_KEY: <redacted>
      DB_ROOT_PW: <redacted>
      DB_URI: <redacted>
      SECRET_KEY: <redacted>
      SECURITY_SCANNER_V4_PSK: <redacted>

    데이터 속성의 모든 정보는 동일하게 유지되어야 합니다.

  5. 현재 Quay 구성을 백업합니다.

    $ oc get secret -n <quay-namespace>  $(oc get quayregistry <quay-registry-name> -n <quay-namespace>  -o jsonpath='{.spec.configBundleSecret}') -o yaml > config-bundle.yaml
  6. Quay 포드 내부에 마운트된 /conf/stack/config.yaml 파일을 백업합니다.

    $ oc exec -it quay-pod-name -- cat /conf/stack/config.yaml > quay-config.yaml

11.1.2. Red Hat Quay 배포 축소

중요

이 단계는 Red Hat Quay 배포 상태의 일관된 백업을 생성하는 데 필요합니다. Postgres 데이터베이스 및/또는 S3 호환 오브젝트 스토리지를 외부 서비스(Operator에서 관리하지 않음)에서 제공하는 설정을 포함하여 이 단계를 생략하지 마십시오.

  1. Operator 버전 3.7 이상: 자동 확장을 비활성화하고 Red Hat Quay, 미러 작업자 및 Clair(관리된 경우)의 복제본 수를 재정의하여 Red Hat Quay 배포를 축소합니다. QuayRegistry 리소스는 다음과 유사해야 합니다.

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: registry
      namespace: ns
    spec:
      components:
        …
        - kind: horizontalpodautoscaler
          managed: false 1
        - kind: quay
          managed: true
          overrides: 2
            replicas: 0
        - kind: clair
          managed: true
          overrides:
            replicas: 0
        - kind: mirror
          managed: true
          overrides:
            replicas: 0
        …
    1
    Quay, Clair 및 미러링 작업자의 자동 스케일링 비활성화
    2
    데이터베이스 및 objectstorage에 액세스하는 구성 요소의 경우 복제본 수를 0으로 설정합니다.
  2. Operator 버전 3.6 및 이전 버전의 경우: Red Hat Quay Operator를 먼저 축소한 다음 관리되는 Red Hat Quay 리소스를 확장하여 Red Hat Quay 배포를 축소합니다.

    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-operator-namespace>|awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/quay-app/ {print $1}') -n <quay-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/quay-mirror/ {print $1}') -n <quay-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/clair-app/ {print $1}') -n <quay-namespace>
  3. registry-quay-app,registry-quay-mirrorregistry-clair-app 포드(Red Hat Quay Operator에서 관리하도록 설정한 구성 요소에 따라)가 사라질 때까지 기다립니다. 다음 명령을 실행하여 상태를 확인할 수 있습니다.

    $ oc get pods -n <quay-namespace>

    출력 예:

    $ oc get pod
    
    quay-operator.v3.7.1-6f9d859bd-p5ftc               1/1     Running     0             12m
    quayregistry-clair-postgres-7487f5bd86-xnxpr       1/1     Running     1 (12m ago)   12m
    quayregistry-quay-app-upgrade-xq2v6                0/1     Completed   0             12m
    quayregistry-quay-config-editor-6dfdcfc44f-hlvwm   1/1     Running     0             73s
    quayregistry-quay-database-859d5445ff-cqthr        1/1     Running     0             12m
    quayregistry-quay-redis-84f888776f-hhgms           1/1     Running     0             12m

11.1.3. Red Hat Quay 관리 데이터베이스 백업

참고

Red Hat Quay 배포가 외부(비밀리) Postgres 데이터베이스로 구성된 경우 공급업체의 문서를 참조하여 이러한 데이터베이스의 일관된 백업을 생성합니다.

  1. Quay PostgreSQL 포드 이름을 식별합니다.

    $ oc get pod -l quay-component=postgres -n <quay-namespace> -o jsonpath='{.items[0].metadata.name}'

    출력 예:

    quayregistry-quay-database-59f54bb7-58xs7
  2. Quay 데이터베이스 이름을 가져옵니다.

    $ oc -n <quay-namespace> rsh $(oc get pod -l app=quay -o NAME -n <quay-namespace> |head -n 1) cat /conf/stack/config.yaml|awk -F"/" '/^DB_URI/ {print $4}'
    quayregistry-quay-database
  3. 백업 데이터베이스를 다운로드합니다.

    $ oc exec quayregistry-quay-database-59f54bb7-58xs7 -- /usr/bin/pg_dump -C quayregistry-quay-database  > backup.sql

11.1.3.1. Red Hat Quay 관리 개체 스토리지 백업

이 섹션의 지침은 다음 구성에 적용됩니다.

  • 독립형 다중 클라우드 오브젝트 게이트웨이 구성
  • OpenShift Data Foundations 스토리지에서는 Red Hat Quay Operator가 ObjectStorageBucketClaim API를 통해 S3 오브젝트 스토리지 버킷을 프로비저닝해야 합니다.
참고

Red Hat Quay 배포가 외부(비밀리) 오브젝트 스토리지로 구성된 경우, Quay 스토리지 버킷의 콘텐츠 사본을 생성하는 방법에 대한 공급 업체의 설명서를 참조하십시오.

  1. AWS_ACCESS_KEY_ID 를 디코딩하고 내보냅니다.

    $ export AWS_ACCESS_KEY_ID=$(oc get secret -l app=noobaa -n <quay-namespace>  -o jsonpath='{.items[0].data.AWS_ACCESS_KEY_ID}' |base64 -d)
  2. AWS_SECRET_ACCESS_KEY_ID 를 디코딩하고 내보냅니다.

    $ export AWS_SECRET_ACCESS_KEY=$(oc get secret -l app=noobaa -n <quay-namespace> -o jsonpath='{.items[0].data.AWS_SECRET_ACCESS_KEY}' |base64 -d)
  3. 새 디렉터리를 만들고 모든 Blob을 복사합니다.

    $ mkdir blobs
    
    $ aws s3 sync --no-verify-ssl --endpoint https://$(oc get route s3 -n openshift-storage  -o jsonpath='{.spec.host}')  s3://$(oc get cm -l app=noobaa -n <quay-namespace> -o jsonpath='{.items[0].data.BUCKET_NAME}') ./blobs
참고

AWS 명령줄 유틸리티 대신 rclone 또는 sc3md 를 사용할 수도 있습니다.

11.1.4. Red Hat Quay 배포 백업 확장

  1. Operator 버전 3.7 이상: 필요에 따라 자동 스케일링을 재활성화하고 Quay, 미러 작업자 및 Clair에 대한 복제본 덮어쓰기를 제거하여 Red Hat Quay 배포를 확장합니다. QuayRegistry 리소스는 다음과 유사해야 합니다.

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: registry
      namespace: ns
    spec:
      components:
        …
        - kind: horizontalpodautoscaler
          managed: true 1
        - kind: quay 2
          managed: true
        - kind: clair
          managed: true
        - kind: mirror
          managed: true
        …
    1
    Quay의 자동 스케일링, Clair 및 작업자를 다시 활성화(원하는 경우)
    2
    Quay 구성 요소를 백업하기 위해 복제본 덮어쓰기가 다시 제거됨
  2. Operator 버전 3.6 이하의 경우: Red Hat Quay Operator를 다시 확장하여 Red Hat Quay 배포를 확장합니다.

    $ oc scale --replicas=1 deployment $(oc get deployment -n <quay-operator-namespace> | awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
  3. Red Hat Quay 배포 상태를 확인합니다.

    $ oc wait quayregistry registry --for=condition=Available=true -n <quay-namespace>

    출력 예:

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      ...
      name: registry
      namespace: <quay-namespace>
      ...
    spec:
      ...
    status:
      - lastTransitionTime: '2022-06-20T05:31:17Z'
        lastUpdateTime: '2022-06-20T17:31:13Z'
        message: All components reporting as healthy
        reason: HealthChecksPassing
        status: 'True'
        type: Available

11.2. Red Hat Quay 복원

이 절차는 Red Hat Quay Operator가 데이터베이스를 관리할 때 Red Hat Quay를 복원하는 데 사용됩니다. Red Hat Quay 레지스트리의 백업 후 수행해야 합니다. 자세한 내용은 Red Hat Quay 백업을 참조하십시오.

사전 요구 사항

  • Red Hat Quay는 Red Hat Quay Operator를 사용하여 OpenShift Container Platform에 배포됩니다.
  • Red Hat Quay Operator에서 관리하는 Red Hat Quay 구성의 백업은 Red Hat Quay 섹션의 지침에 따라 생성되었습니다.
  • Red Hat Quay 데이터베이스가 백업되었습니다.
  • Red Hat Quay에서 사용하는 오브젝트 스토리지 버킷이 백업되었습니다.
  • 구성 요소 quay,postgresobjectstoragemanaged: true로 설정됩니다.
  • 구성 요소 clairmanaged: true 로 설정된 경우 구성 요소 clairpostgresmanaged: true 로 설정됩니다(Red Hat Quay Operator v3.7 이상으로 시작)
  • OpenShift Container Platform 클러스터의 대상 네임스페이스에서 Red Hat Quay Operator에서 관리하는 실행 중인 Red Hat Quay 배포가 없습니다.
참고

배포에 부분적으로 관리되지 않는 데이터베이스 또는 스토리지 구성 요소가 포함되어 있고 Postgres 또는 S3 호환 오브젝트 스토리지에 외부 서비스를 사용하여 Red Hat Quay 배포를 실행하는 경우, Red Hat Quay를 복원하기 전에 백업에서 데이터를 복원하려면 서비스 공급자 또는 공급 업체 설명서를 참조해야 합니다.

11.2.1. Red Hat Quay 및 백업에서 구성 복원

참고

이 지침에서는 Red Hat Quay 백업 가이드의 프로세스를 따라 동일한 이름으로 백업 파일을 생성한다고 가정합니다.

  1. 백업된 Red Hat Quay 구성 및 백업에서 생성된 키를 복원합니다.

    $ oc create -f ./config-bundle.yaml
    
    $ oc create -f ./managed-secret-keys.yaml
    중요

    "./config-bundle.yaml": secrets "config-bundle-secret"을 생성할 때 오류 발생 (AlreadyExists): 오류가 발생하면 $ oc delete Secret config-bundle-secret -n <quay-namespace>를 사용하여 기존 리소스를 삭제하고 $ oc create -f./config-bundle.yaml.yaml로 다시 생성해야 합니다.

  2. QuayRegistry 사용자 정의 리소스를 복원합니다.

    $ oc create -f ./quay-registry.yaml
  3. Red Hat Quay 배포 상태를 확인하고 사용 가능할 때까지 기다립니다.

    $ oc wait quayregistry registry --for=condition=Available=true -n <quay-namespace>

11.2.2. Red Hat Quay 배포 축소

  1. Operator 버전 3.7 이상: 자동 스케일링을 비활성화하고 Quay, 미러 작업자 및 Clair(관리된 경우)의 복제본 수를 재정의하여 Red Hat Quay 배포를 축소합니다. QuayRegistry 리소스는 다음과 유사해야 합니다.

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: registry
      namespace: ns
    spec:
      components:
        …
        - kind: horizontalpodautoscaler
          managed: false 1
        - kind: quay
          managed: true
          overrides: 2
            replicas: 0
        - kind: clair
          managed: true
          overrides:
            replicas: 0
        - kind: mirror
          managed: true
          overrides:
            replicas: 0
        …
    1
    Quay, Clair 및 미러링 작업자의 자동 스케일링 비활성화
    2
    데이터베이스 및 objectstorage에 액세스하는 구성 요소의 경우 복제본 수를 0으로 설정합니다.
  2. Operator 버전 3.6 이하의 경우: Red Hat Quay Operator를 먼저 축소한 다음 관리되는 Red Hat Quay 리소스를 확장하여 Red Hat Quay 배포를 축소합니다.

    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-operator-namespace>|awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
    
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/quay-app/ {print $1}') -n <quay-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/quay-mirror/ {print $1}') -n <quay-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/clair-app/ {print $1}') -n <quay-namespace>
  3. registry-quay-app,registry-quay-mirrorregistry-clair-app Pod(Operator에서 관리하도록 설정한 구성 요소에 따라)가 사라질 때까지 기다립니다. 다음 명령을 실행하여 상태를 확인할 수 있습니다.

    $ oc get pods -n <quay-namespace>

    출력 예:

    registry-quay-config-editor-77847fc4f5-nsbbv   1/1     Running            0          9m1s
    registry-quay-database-66969cd859-n2ssm        1/1     Running            0          6d1h
    registry-quay-redis-7cc5f6c977-956g8           1/1     Running            0          5d21h

11.2.3. Red Hat Quay 데이터베이스 복원

  1. Quay 데이터베이스 포드를 식별합니다.

    $ oc get pod -l quay-component=postgres -n  <quay-namespace> -o jsonpath='{.items[0].metadata.name}'

    출력 예:

    quayregistry-quay-database-59f54bb7-58xs7
  2. 로컬 환경 및 Pod에 백업을 복사하여 백업을 업로드합니다.

    $ oc cp ./backup.sql -n <quay-namespace> registry-quay-database-66969cd859-n2ssm:/tmp/backup.sql
  3. 데이터베이스에 대한 원격 터미널을 엽니다.

    $ oc rsh -n <quay-namespace> registry-quay-database-66969cd859-n2ssm
  4. psql을 입력합니다.

    bash-4.4$ psql
  5. 다음 명령을 실행하여 데이터베이스를 나열할 수 있습니다.

    postgres=# \l

    출력 예:

                                                      List of databases
               Name            |           Owner            | Encoding |  Collate   |   Ctype    |   Access privileges
    ----------------------------+----------------------------+----------+------------+------------+-----------------------
    postgres                   | postgres                   | UTF8     | en_US.utf8 | en_US.utf8 |
    quayregistry-quay-database | quayregistry-quay-database | UTF8     | en_US.utf8 | en_US.utf8 |
  6. 데이터베이스를 삭제합니다.

    postgres=# DROP DATABASE "quayregistry-quay-database";

    출력 예:

    DROP DATABASE
  7. postgres CLI를 종료하여 bash-4.4를 다시 입력합니다.

    \q
  8. PostgreSQL 데이터베이스를 백업 데이터베이스로 리디렉션합니다.

    sh-4.4$ psql < /tmp/backup.sql
  9. bash를 종료합니다.

    sh-4.4$ exit

11.2.4. Red Hat Quay 오브젝트 스토리지 데이터 복원

  1. AWS_ACCESS_KEY_ID 를 내보냅니다.

    $ export AWS_ACCESS_KEY_ID=$(oc get secret -l app=noobaa -n <quay-namespace>  -o jsonpath='{.items[0].data.AWS_ACCESS_KEY_ID}' |base64 -d)
  2. AWS_SECRET_ACCESS_KEY 내보내기:

    $ export AWS_SECRET_ACCESS_KEY=$(oc get secret -l app=noobaa -n <quay-namespace> -o jsonpath='{.items[0].data.AWS_SECRET_ACCESS_KEY}' |base64 -d)
  3. 다음 명령을 실행하여 모든 Blob을 버킷에 업로드합니다.

    $ aws s3 sync --no-verify-ssl --endpoint https://$(oc get route s3 -n openshift-storage  -o jsonpath='{.spec.host}') ./blobs  s3://$(oc get cm -l app=noobaa -n <quay-namespace> -o jsonpath='{.items[0].data.BUCKET_NAME}')
참고

AWS 명령줄 유틸리티 대신 rclone 또는 sc3md 를 사용할 수도 있습니다.

11.2.5. Red Hat Quay 배포 확장

  1. Operator 버전 3.7 이상: 필요에 따라 자동 스케일링을 재활성화하고 Quay, 미러 작업자 및 Clair에 대한 복제본 덮어쓰기를 제거하여 Red Hat Quay 배포를 확장합니다. QuayRegistry 리소스는 다음과 유사해야 합니다.

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: registry
      namespace: ns
    spec:
      components:
        …
        - kind: horizontalpodautoscaler
          managed: true 1
        - kind: quay 2
          managed: true
        - kind: clair
          managed: true
        - kind: mirror
          managed: true
        …
    1
    Red Hat Quay, Clair 및 미러링 작업자의 자동 스케일링을 다시 활성화(원하는 경우)
    2
    Red Hat Quay 구성 요소를 백업하기 위해 복제본 덮어쓰기가 다시 제거됨
  2. Operator 버전 3.6 이하의 경우: Red Hat Quay Operator를 다시 확장하여 Red Hat Quay 배포를 확장합니다.

    $ oc scale --replicas=1 deployment $(oc get deployment -n <quay-operator-namespace> | awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
  3. Red Hat Quay 배포 상태를 확인합니다.

    $ oc wait quayregistry registry --for=condition=Available=true -n <quay-namespace>

    출력 예:

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      ...
      name: registry
      namespace: <quay-namespace>
      ...
    spec:
      ...
    status:
      - lastTransitionTime: '2022-06-20T05:31:17Z'
        lastUpdateTime: '2022-06-20T17:31:13Z'
        message: All components reporting as healthy
        reason: HealthChecksPassing
        status: 'True'
        type: Available

12장. Quay Operator 업그레이드 개요

Quay Operator는 동기화된 버전 관리 체계를 따릅니다. 즉, Operator의 각 버전이 Quay 버전 및 관리하는 구성 요소와 연결되어 있습니다. QuayRegistry 사용자 정의 리소스에는 배포할 Quay 버전을 설정하는 필드가 없습니다. Operator는 모든 구성 요소의 단일 버전을 배포하는 방법만 알고 있습니다. 이 스키마는 모든 구성 요소가 서로 잘 작동하도록 하고 Operator에서 Kubernetes에서 다양한 Quay 버전의 라이프사이클을 관리하는 방법을 알아야 하는 복잡성을 줄이기 위해 선택되었습니다.

12.1. Operator Lifecycle Manager

OLM(Operator Lifecycle Manager)을 사용하여 Quay Operator 를 설치하고 업그레이드해야 합니다. 기본 approvalStrategy: 자동으로 서브스크립션을 생성할 때 OLM은 새 버전을 사용할 수 있을 때마다 Quay Operator를 자동으로 업그레이드합니다.

주의

Operator Lifecycle Manager를 통해 Quay Operator를 설치하면 자동 또는 수동 업그레이드를 지원하도록 구성할 수 있습니다. 이 옵션은 설치 중에 Quay Operator의 Operator Hub 페이지에 표시됩니다. approvalStrategy 필드를 통해 Quay Operator Subscription 오브젝트에서도 확인할 수 있습니다. Automatic 을 선택하면 새 Operator 버전이 릴리스될 때마다 Quay Operator가 자동으로 업그레이드됩니다. 이를 원하지 않는 경우 수동 승인 전략을 선택해야 합니다.

12.2. Quay Operator 업그레이드

OpenShift에서 설치된 Operator를 업그레이드하는 표준 방법은 설치된 Operator 업그레이드에 설명되어 있습니다.

일반적으로 Red Hat Quay는 이전 (N-1) 마이너 버전의 업그레이드만 지원합니다. 예를 들어 Red Hat Quay 3.0.5에서 최신 3.5 버전으로 직접 업그레이드할 수 없습니다. 대신 사용자는 다음과 같이 업그레이드해야 합니다.

  1. 3.0.5 → 3.1.3
  2. 3.1.3 → 3.2.2
  3. 3.2.2 → 3.3.4
  4. 3.3.4 → 3.4.z
  5. 3.4.z → 3.5.z

이는 업그레이드 중에 필요한 모든 데이터베이스 마이그레이션을 올바르게 수행하고 올바른 순서로 수행해야 합니다.

경우에 따라 Red Hat Quay는 이전 (N-2, N-3) 마이너 버전에서 직접 단일 단계 업그레이드를 지원합니다. 이 예외는 이전 마이너 버전 전용의 일반 버전만 제외하고 업그레이드하면 이전 릴리스 고객의 업그레이드 절차를 단순화합니다. 다음과 같은 업그레이드 경로가 지원됩니다.

  1. 3.3.z → 3.6.z
  2. 3.4.z → 3.6.z
  3. 3.4.z → 3.7.z
  4. 3.5.z → 3.7.z

3.7로 업그레이드하려는 Quay의 독립 실행형 배포에 있는 사용자는 독립 실행형 업그레이드 가이드를 참조하십시오.

12.2.1. Quay 업그레이드

Quay를 하나의 마이너 버전에서 다음 버전으로 업데이트하려면 (예: 3.4 → 3.5) Quay Operator의 업데이트 채널을 변경해야 합니다.

z 스트림 업그레이드(예: 3.4.2 → 3.4.3)의 경우 사용자가 처음 설치하는 동안 사용자가 선택한 메이저 마이너 채널로 업데이트가 릴리스됩니다. z 스트림 업그레이드를 수행하는 절차는 위에 설명된 approvalStrategy 에 따라 다릅니다. 승인 전략이 자동으로 설정된 경우 Quay Operator는 최신 z 스트림으로 자동 업그레이드됩니다. 이로 인해 Quay가 다운타임 없이 최신 z 스트림으로 자동으로 업데이트됩니다. 그렇지 않으면 설치를 시작하기 전에 업데이트를 수동으로 승인해야 합니다.

12.2.2. 3.3.z 또는 3.4.z에서 3.6으로 직접 업그레이드하는 방법에 대한 참고 사항

12.2.2.1. 엣지 라우팅 활성화로 업그레이드

  • 이전에는 엣지 라우팅이 활성화된 Red Hat Quay의 3.3.z 버전을 실행할 때 사용자는 Red Hat Quay의 3.4.z 버전으로 업그레이드할 수 없었습니다. 이 문제는 Red Hat Quay 3.6 릴리스와 함께 해결되었습니다.
  • 3.3.z에서 3.6으로 업그레이드할 때 Red Hat Quay 3.3.z 배포에서 tls.terminationnone 으로 설정되어 TLS 엣지 종료를 통해 HTTPS로 변경되고 기본 클러스터 와일드카드 인증서를 사용합니다. 예를 들면 다음과 같습니다.

    apiVersion: redhatcop.redhat.io/v1alpha1
    kind: QuayEcosystem
    metadata:
      name: quay33
    spec:
      quay:
        imagePullSecretName: redhat-pull-secret
        enableRepoMirroring: true
        image: quay.io/quay/quay:v3.3.4-2
        ...
        externalAccess:
          hostname: quayv33.apps.devcluster.openshift.com
          tls:
            termination: none
        database:
    ...

12.2.2.2. 주체 대체 이름 없이 사용자 정의 TLS 인증서/키 쌍으로 업그레이드

Red Hat Quay 3.3.4에서 Red Hat Quay 3.6으로 직접 업그레이드할 때 SAN(Subject Alternative Names) 없이 자체 TLS 인증서/키 쌍을 사용하는 고객은 문제가 있습니다. Red Hat Quay 3.6으로 업그레이드하는 동안 배포가 차단되며 Quay TLS 인증서에 SAN이 있어야 함을 나타내는 Quay Operator pod 로그의 오류 메시지가 표시됩니다.

가능하면 SAN에서 올바른 호스트 이름을 사용하여 TLS 인증서를 다시 생성해야 합니다. 가능한 해결 방법은 CommonName 일치를 사용하도록 업그레이드한 후 quay-app,quay-upgradequay-config-editor Pod에서 환경 변수를 정의하는 것입니다.

 GODEBUG=x509ignoreCN=0

GODEBUG=x509ignoreCN=0 플래그를 사용하면 SAN이 없을 때 X.509 인증서의 CommonName 필드를 호스트 이름으로 처리하는 기존 동작을 활성화합니다. 그러나 재배포 시 유지되지 않으므로 이 해결방법은 권장되지 않습니다.

12.2.2.3. Quay Operator를 사용하여 3.3.z 또는 3.4.z에서 3.6으로 업그레이드할 때 Clair v4 구성

OpenShift에 새로운 Red Hat Quay 배포에 Clair v4를 설정하려면 Quay Operator를 사용하는 것이 좋습니다. 기본적으로 Quay Operator는 Red Hat Quay 배포와 함께 Clair 배포를 설치 또는 업그레이드하고 Clair 보안 검사를 자동으로 구성합니다.

OpenShift에서 Clair v4를 설정하는 방법에 대한 자세한 내용은 Red Hat Quay OpenShift 배포에서 Clair 설정을 참조하십시오.

12.2.3. 3.3.z에서 3.6으로 업그레이드할 때 Swift 구성

Red Hat Quay 3.3.z에서 3.6.z로 업그레이드하는 경우 일부 사용자에게 다음 오류가 발생할 수 있습니다. Switch auth v3 requires tenant_id (string) in os_options. 이 문제를 해결하려면 DISTRIBUTED_STORAGE_CONFIG 를 수동으로 업데이트하여 os_optionstenant_id 매개변수를 추가할 수 있습니다.

  DISTRIBUTED_STORAGE_CONFIG:
    brscale:
    - SwiftStorage
    - auth_url: http://****/v3
      auth_version: "3"
      os_options:
        tenant_id: ****
        project_name: ocp-base
        user_domain_name: Default
      storage_path: /datastorage/registry
      swift_container: ocp-svc-quay-ha
      swift_password: *****
      swift_user: *****

12.2.4. Operator의 업데이트 채널 변경

설치된 Operator의 서브스크립션은 Operator의 업데이트를 추적하고 수신하는 데 사용되는 업데이트 채널을 지정합니다. Quay Operator를 업그레이드하여 최신 채널에서 업데이트를 추적하고 받으려면 설치된 Quay Operator의 서브스크립션 탭에서 업데이트 채널을 변경합니다. 자동 승인 전략이 있는 서브스크립션의 경우 업그레이드가 자동으로 시작되고 설치된 Operator가 나열된 페이지에서 모니터링할 수 있습니다.

12.2.5. 보류 중인 Operator 업그레이드 수동 승인

설치된 Operator의 서브스크립션에 있는 승인 전략이 Manual 로 설정된 경우 새 업데이트가 현재 업데이트 채널에 릴리스되면 업데이트를 수동으로 승인해야 설치가 시작됩니다. Quay Operator에 업그레이드가 보류 중인 경우 이 상태가 Installed Operator 목록에 표시됩니다. Quay Operator의 서브스크립션 탭에서 설치 계획을 미리 보고 업그레이드할 수 있는 것으로 나열된 리소스를 검토할 수 있습니다. 문제가 발생할 경우 승인을 클릭하고 Installed Operators를 나열하는 페이지로 돌아가 업그레이드 진행 상황을 모니터링합니다.

다음 이미지는 업데이트 채널, 승인 전략, 업그레이드 상태InstallPlan 을 포함하여 UI의 Subscription 탭을 보여줍니다.

Subscription tab including upgrade Channel and Approval strategy

설치된 Operator 목록은 현재 Quay 설치에 대한 상위 수준 요약을 제공합니다.

Installed Operators

12.3. QuayRegistry 업그레이드

Quay Operator가 시작되면 조사하도록 구성된 네임스페이스에서 찾을 수 있는 모든 QuayRegistries 를 즉시 찾습니다. 이 논리를 찾으면 다음과 같은 논리가 사용됩니다.

  • status.currentVersion 이 설정되지 않은 경우 정상으로 조정합니다.
  • status.currentVersion 이 Operator 버전과 같은 경우 정상으로 조정합니다.
  • status.currentVersion 이 Operator 버전과 동일하지 않은 경우 업그레이드할 수 있는지 확인합니다. 가능하면 업그레이드 작업을 수행하고 완료되면 status.currentVersion 을 Operator의 버전으로 설정합니다. 업그레이드할 수 없는 경우 오류를 반환하고 QuayRegistry 및 배포된 Kubernetes 오브젝트만 그대로 둡니다.

12.4. Quay 3.7에서 기능 활성화

12.4.1. 할당량 관리 구성

할당량 관리는 이제 FEATURE_QUOTA_MANAGEMENT 속성에서 지원되며 기본적으로 해제됩니다. 할당량 관리를 활성화하려면 config.yaml 의 기능 플래그를 true 로 설정합니다.

FEATURE_QUOTA_MANAGEMENT: true

12.4.2. Red Hat Quay를 사용하여 원격 조직 구성 프록시

Red Hat Quay를 사용하여 원격 조직을 프록시하는 것은 이제 FEATURE_PROXY_CACHE 속성에서 지원됩니다. 프록시 캐시를 활성화하려면 confg.yaml 의 기능 플래그를 true 로 설정합니다.

FEATURE_PROXY_CACHE: true

12.4.3. Red Hat Quay 빌드 개선 사항

가상화된 플랫폼에서 빌드를 실행할 수 있습니다. 이전 빌드 구성을 실행하기 위한 이전 버전과의 호환성도 사용할 수 있습니다. 가상 빌드를 활성화하려면 config.yaml 의 기능 플래그를 true 로 설정합니다.

FEATURE_BUILD_SUPPORT: true

12.4.4. Red Hat Quay Operator를 사용하여 geo-replication

Operator 배포에서 geo-replication을 사용한 Red Hat Quay 배포를 지원합니다. Geo-replication을 활성화하려면 config.yaml 의 기능 플래그를 true 로 설정합니다.

FEATURE_STORAGE_REPLICATION: true

12.5. Quay 3.6에서 기능 활성화

12.5.1. 콘솔 모니터링 및 경고

OpenShift 콘솔에서 Quay 3.6 모니터링을 지원하려면 Operator가 모든 네임스페이스에 설치해야 합니다. 이전에 특정 네임스페이스에 Operator를 설치한 경우 업그레이드 후 Operator 자체를 삭제하고 모든 네임스페이스에 대해 다시 설치합니다.

12.5.2. OCI 및 Helm 지원

Red Hat Quay 3.6에서 Helm 및 일부 OCI 아티팩트에 대한 지원은 기본적으로 활성화됩니다. 기능을 명시적으로 활성화하려면 (예: 기본적으로 활성화되어 있지 않은 버전에서 업그레이드하는 경우 다음 속성을 사용하여 OCI 아티팩트 사용을 활성화하도록 Quay 배포를 재구성해야 합니다.

FEATURE_GENERAL_OCI_SUPPORT: true

12.6. QuayEcosystem 업그레이드

제한된 구성 집합에 QuayEcosystem API를 사용하는 이전 버전의 Operator에서 업그레이드가 지원됩니다. 마이그레이션이 예기치 않게 발생하지 않도록 하려면 이를 마이그레이션하려면 QuayEcosystem 에 특수 레이블을 적용해야 합니다. Operator가 관리할 수 있도록 새 QuayRegistry 가 생성되지만, 문제가 발생하는 경우에도 QuayEcosystem 을 롤백하고 Quay에 계속 액세스할 수 있도록 이전 QuayEcosystem이 수동으로 삭제될 때까지 유지됩니다. 기존 QuayEcosystem 을 새 QuayRegistry 로 마이그레이션하려면 다음 단계를 따르십시오.

  1. QuayEcosystemmetadata.labels"quay-operator/migrate": "true" 를 추가합니다.

    $ oc edit quayecosystem <quayecosystemname>
    metadata:
      labels:
        quay-operator/migrate: "true"
  2. QuayEcosystem 과 동일한 metadata.name 을 사용하여 QuayRegistry 가 생성될 때까지 기다립니다. QuayEcosystem"quay-operator/migration-complete": "true" 라벨이 표시됩니다.
  3. QuayRegistrystatus.registryEndpoint 가 설정되면 Quay에 액세스하여 모든 데이터 및 설정이 성공적으로 마이그레이션되었는지 확인합니다.
  4. 모든 항목이 올바르게 작동했다고 확신하면 QuayEcosystem 을 삭제할 수 있으며 Kubernetes 가비지 컬렉션은 이전 리소스를 모두 정리합니다.

12.6.1. QuayEcosystem 업그레이드 되돌리기

QuayEcosystem 에서 QuayRegistry 로 자동 업그레이드하는 동안 문제가 발생하면 다음 단계에 따라 QuayEcosystem 을 사용하여 되돌아갑니다.

  1. UI 또는 kubectl 을 사용하여 QuayRegistry 를 삭제합니다.

    $ kubectl delete -n <namespace> quayregistry <quayecosystem-name>
  2. 경로 를 사용하여 외부 액세스가 제공된 경우 UI 또는 kubectl 을 사용하여 원래 서비스를 가리키도록 경로 를 변경합니다.
참고

QuayEcosystem 에서 Postgres 데이터베이스를 관리하는 경우 업그레이드 프로세스에서 업그레이드된 Operator가 관리하는 새 Postgres 데이터베이스로 데이터를 마이그레이션합니다. 이전 데이터베이스는 변경 또는 제거되지 않지만 마이그레이션이 완료되면 더 이상 Quay를 사용하지 않습니다. 데이터 마이그레이션 중에 문제가 발생하면 업그레이드 프로세스가 종료되고 관리되지 않는 구성 요소로 데이터베이스를 계속 사용하는 것이 좋습니다.

12.6.2. 업그레이드를 위해 지원되는 QuayEcosystem 구성

Quay Operator는 QuayEcosystem 구성 요소를 마이그레이션하는 데 실패하거나 지원되지 않는 경우 로그 및 status.conditions 에서 오류를 보고합니다. Kubernetes 리소스를 채택할 필요가 없으며 필요한 모든 값은 Quay의 config.yaml 에서 이미 제공되므로 관리되지 않는 모든 구성 요소를 성공적으로 마이그레이션해야 합니다.

데이터베이스

임시 데이터베이스가 지원되지 않습니다(volumeSize 필드를 설정해야 함).

Redis

특별한 필요 없습니다.

외부 액세스

자동 마이그레이션에는 패스스루 경로 액세스만 지원됩니다. 다른 방법에 필요한 수동 마이그레이션

  • 사용자 지정 호스트 이름이 없는 LoadBalancer: QuayEcosystem"quay-operator/migration-complete": "true" 레이블로 표시된 후 QuayEcosystem 에서 metadata.ownerReferences 필드를 기존 서비스에서 삭제 하여 Kubernetes가 서비스를 가비지 수집하지 못하도록 하고 로드 밸런서를 제거합니다. metadata.name 형식 < QuayEcosystem-name>-quay-app 으로 새 서비스가 생성됩니다. 기존 서비스의 spec.selector 를 새 서비스의 spec.selector 와 일치하도록 편집하여 이전 로드 밸런서 끝점에 대한 트래픽이 이제 새 Pod로 이동합니다. 이제 이전 서비스를 담당합니다. Quay Operator는 이를 관리하지 않습니다.
  • 사용자 지정 호스트 이름이 있는 LoadBalancer/NodePort/Ingress: LoadBalancer 유형의 새로운 서비스는 metadata.name 형식 < QuayEcosystem-name>-quay-app 으로 생성됩니다. 새 서비스에서 제공하는 status.loadBalancer 엔드포인트를 가리키도록 DNS 설정을 변경합니다.

Clair

특별한 필요 없습니다.

오브젝트 스토리지

QuayEcosystem 에는 관리형 개체 스토리지 구성 요소가 없으므로 오브젝트 스토리지는 항상 관리되지 않는 것으로 표시됩니다. 로컬 스토리지는 지원되지 않습니다.

저장소 미러링

특별한 필요 없습니다.

추가 리소스

  • Red Hat Quay Operator에 대한 자세한 내용은 업스트림 quay-operator 프로젝트를 참조하십시오.

법적 공지

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.