OpenShift Container Platform에 Red Hat Quay Operator 배포
OpenShift Container Platform에 Red Hat Quay Operator 배포
초록
머리말
Red Hat Quay는 엔터프라이즈급 컨테이너 레지스트리입니다. Red Hat Quay를 사용하여 컨테이너 이미지를 빌드 및 저장한 다음 엔터프라이즈 전반에 배포할 수 있도록 합니다.
Red Hat Quay Operator는 OpenShift 클러스터에서 Red Hat Quay를 배포하고 관리하는 간단한 방법을 제공합니다.
Red Hat Quay 3.4.0이 릴리스되면서 개선된 환경을 제공하고 Day 2 작업에 대한 지원을 추가하기 위해 Red Hat Quay Operator가 다시 작성되었습니다. 그 결과 Red Hat Quay Operator를 더 쉽게 사용할 수 있게 되었습니다. Red Hat Quay 3.4.0 이전 버전과의 주요 차이점은 다음과 같습니다.
-
QuayEcosystem사용자 정의 리소스가QuayRegistry사용자 정의 리소스로 교체되었습니다. 기본 설치 옵션은 프로덕션 환경에서 지원되는 모든 관리 종속 항목(데이터베이스, 캐시, 오브젝트 스토리지 등)이 포함된 완전히 지원되는 Red Hat Quay 환경을 생성합니다.
참고일부 구성 요소는 가용성이 높지 않을 수 있습니다.
- 일관성을 위해 Red Hat Quay 애플리케이션 및 구성 툴에서 공유하는 Red Hat Quay의 구성을 위한 새로운 검증 라이브러리입니다.
ObjectBucketClaimKubernetes API를 사용하여 Red Hat Quay Operator에서 오브젝트 스토리지를 관리할 수 있습니다.참고Red Hat OpenShift Data Foundation은 OpenShift Container Platform에서 지원되는 API 구현을 제공하는 데 사용할 수 있습니다.
- 테스트 및 개발 시나리오에 배포된 Pod에서 사용하는 컨테이너 이미지의 사용자 지정
1장. Red Hat Quay Operator 소개
이 장의 콘텐츠를 사용하여 다음을 실행합니다.
- Red Hat Quay Operator 설치
- 관리되거나 관리되지 않는 개체 스토리지 구성
- 데이터베이스, Redis, 경로, TLS 등과 같은 관리되지 않는 구성 요소를 구성합니다.
- Red Hat Quay Operator를 사용하여 OpenShift Container Platform에 Red Hat Quay 레지스트리 배포
- Red Hat Quay Operator에서 지원하는 고급 기능 사용
- Red Hat Quay Operator를 업그레이드하여 레지스트리 업그레이드
1.1. Red Hat Quay Operator 구성 요소
Red Hat Quay에는 상당한 수의 종속 항목이 있습니다. 여기에는 데이터베이스, 오브젝트 스토리지, Redis 등이 포함됩니다. Red Hat Quay Operator는 Red Hat Quay의 의견 배포와 Kubernetes에 대한 종속성을 관리합니다. 이러한 종속 항목은 구성 요소로 처리되며 QuayRegistry API를 통해 구성됩니다.
QuayRegistry 사용자 정의 리소스의 spec.components 필드는 구성 요소를 구성합니다. 각 구성 요소에는 kind (구성 요소의 이름) 및 관리 (구성 요소 라이프사이클이 Red Hat Quay Operator에서 처리되는지 여부를 처리하는 부울) 두 개의 필드가 포함되어 있습니다. 기본적으로 모든 구성 요소는 가시성을 위해 조정 시 관리되고 자동으로 채워집니다.
spec:
components:
- kind: quay
managed: true
- kind: postgres
managed: true
- kind: clair
managed: true
- kind: redis
managed: true
- kind: horizontalpodautoscaler
managed: true
- kind: objectstorage
managed: true
- kind: route
managed: true
- kind: mirror
managed: true
- kind: monitoring
managed: true
- kind: tls
managed: true
- kind: clairpostgres
managed: true1.2. 관리형 구성 요소 사용
QuayRegistry 사용자 정의 리소스가 다른 리소스를 지정하지 않는 한 Red Hat Quay Operator는 다음과 같은 관리 구성 요소에 기본값을 사용합니다.
- Quay: Red Hat Quay 배포에 대한 재정의가 유지됩니다. 예를 들어 환경 변수 및 복제본 수입니다. 이 구성 요소는 Red Hat Quay 3.7부터 새로운 구성 요소이며 관리되지 않음으로 설정할 수 없습니다.
Postgres: 레지스트리 메타데이터를 저장하기 위해 Red Hat Quay 3.9로 Software Collections 의 PostgreSQL 13 버전을 사용합니다.
참고Red Hat Quay 3.8 → 3.9에서 업그레이드할 때 Operator는 PostgreSQL 10 업그레이드를 자동으로 처리합니다. 이 업그레이드는 필수입니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다.
- Clair: 이미지 취약점 스캔을 제공합니다.
- Redis: 라이브 빌더 로그 및 Red Hat Quay 튜토리얼을 저장합니다. 가비지 컬렉션에 필요한 잠금 메커니즘도 포함되어 있습니다.
-
HorizontalPodAutoscaler: 메모리/cpu 소비에 따라
QuayPod 수를 조정합니다. -
ObjectStorage: 이미지 계층 Blob을 저장하기 위해 Noobaa 또는 RHOCS에서 제공하는
ObjectBucketClaimKubernetes API를 활용합니다. - route: OpenShift Container Platform 외부에서 Red Hat Quay 레지스트리에 외부 진입점을 제공합니다.
- mirror: 선택적 저장소 미러링을 지원하도록 저장소 미러 작업자를 구성합니다.
- 모니터링: 기능에는 Grafana 대시보드, 개별 메트릭에 대한 액세스, Quay pod를 자주 다시 시작하라는 경고가 포함됩니다.
- TLS: Red Hat Quay 또는 OpenShift Container Platform에서 SSL/TLS를 처리할지 여부를 구성합니다.
- clairpostgres: 관리되는 Clair 데이터베이스를 구성합니다.
Red Hat Quay Operator는 Red Hat Quay가 관리되는 구성 요소를 사용하는 데 필요한 모든 구성 및 설치 작업을 처리합니다. Red Hat Quay Operator에서 수행하는 예상 배포가 사용자 환경에 적합하지 않은 경우 다음 섹션에 설명된 대로 Red Hat Quay Operator에 관리되지 않는 리소스(override)를 제공할 수 있습니다.
1.3. 종속 항목에 관리되지 않는 구성 요소 사용
Red Hat Quay와 함께 사용하려는 PostgreSQL, Redis 또는 오브젝트 스토리지와 같은 기존 구성 요소가 있는 경우 먼저 Red Hat Quay 구성 번들(config.yaml) 내에서 구성합니다. 그런 다음 관리되지 않는 구성 요소를 나타내는 동안 QuayRegistry 번들(Kubernetes 시크릿)에서 참조해야 합니다.
-
Red Hat Quay 구성 편집기를 사용하여 기존 구성 번들을 생성하거나 수정하고 특히 여러 변경 사항에 대해 Kubernetes 보안을 업데이트하는 프로세스를 간소화할 수 있습니다.
Red Hat Quay의 구성이 구성 편집기에서 변경되고 Red Hat Quay Operator로 전송되면 새 구성을 반영하도록 배포가 업데이트됩니다. - 관리되지 않는 PostgreSQL 데이터베이스를 사용하고 있고 버전이 PostgreSQL 10인 경우 PostgreSQL 13으로 업그레이드하는 것이 좋습니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다. 자세한 내용은 PostgreSQL 버전 관리 정책을 참조하십시오.
관리되지 않는 구성 요소를 구성하려면 다음 섹션을 참조하십시오.
1.4. 구성 번들 시크릿
spec.configBundleSecret 필드는 QuayRegistry 와 동일한 네임스페이스에 있는 Secret 의 metadata.name 에 대한 참조입니다. 이 시크릿에 는 config.yaml 키/값 쌍이 포함되어야 합니다. 이 config.yaml 파일은 Red Hat Quay config.yaml 파일입니다. 이 필드는 선택 사항이며 제공되지 않는 경우 Red Hat Quay Operator에 의해 자동으로 채워집니다. 제공된 경우 나중에 관리형 구성 요소의 다른 필드와 병합되어 최종 출력 Secret 을 형성한 다음 Red Hat Quay 애플리케이션 pod에 마운트되는 기본 구성 필드 세트 역할을 합니다.
1.5. OpenShift Container Platform에서 Red Hat Quay 사전 요구 사항
OpenShift Container Platform에서 Red Hat Quay Operator 배포를 시작하기 전에 다음을 고려해야 합니다.
1.5.1. OpenShift 클러스터
Red Hat Quay Operator를 배포할 OpenShift Container Platform 4.5 이상 클러스터에 대한 권한 있는 계정이 필요합니다. 해당 계정에는 클러스터 범위에서 네임스페이스를 생성할 수 있어야 합니다.
1.5.2. 리소스 요구 사항
각 Red Hat Quay 애플리케이션 Pod에는 다음과 같은 리소스 요구 사항이 있습니다.
- 8Gi 메모리
- 2000 밀리코어 CPU.
Red Hat Quay Operator는 관리하는 Red Hat Quay 배포마다 하나 이상의 애플리케이션 Pod를 생성합니다. OpenShift Container Platform 클러스터에 이러한 요구 사항에 맞는 충분한 컴퓨팅 리소스가 있는지 확인합니다.
1.5.3. 오브젝트 스토리지
기본적으로 Red Hat Quay Operator는 ObjectBucketClaim Kubernetes API를 사용하여 오브젝트 스토리지를 프로비저닝합니다. 이 API를 사용하면 벤더별 구현에서 Red Hat Quay Operator가 분리됩니다. Red Hat OpenShift Data Foundation은 이 예제에서 사용되는 NooBaa 구성 요소를 통해 이 API를 제공합니다.
다음과 같은 지원되는 클라우드 스토리지 옵션을 사용하도록 Red Hat Quay를 수동으로 구성할 수 있습니다.
- Amazon S3 (Red Hat Quay에 대한 S3 버킷 정책 구성에 대한 자세한 내용은 S3 IAM 버킷 정책 참조)
- MicroShift Azure Blob Storage
- Google Cloud Storage
- Ceph Object Gateway(RADOS)
- OpenStack Swift
- CloudFront + S3
2장. OperatorHub에서 Red Hat Quay Operator 설치
다음 절차에 따라 OpenShift Container Platform OperatorHub에서 Red Hat Quay Operator를 설치합니다.
절차
- OpenShift Container Platform 콘솔을 사용하여 Operator → OperatorHub 를 선택합니다.
- 검색 상자에 Red Hat Quay 를 입력하고 Red Hat에서 제공하는 공식 Red Hat Quay Operator를 선택합니다. 그러면 기능, 사전 요구 사항 및 배포 정보를 간략하게 설명하는 설치 페이지로 이동합니다.
- 설치를 선택합니다. 그러면 Operator 설치 페이지로 이동합니다.
설치를 사용자 지정하는 데 다음과 같은 선택 사항을 선택할 수 있습니다.
-
업데이트 채널: 최신 릴리스의 경우 업데이트 채널(예:
stable-3.7)을 선택합니다. 설치 모드: Red Hat Quay Operator
를 클러스터 전체에서 사용하려면 클러스터의 모든 네임스페이스를 선택합니다. 단일네임스페이스 내에서만 배포하려면 클러스터의 특정네임스페이스를 선택합니다. 클러스터 전체에서 Red Hat Quay Operator를 설치하는 것이 좋습니다. 단일 네임스페이스를 선택하면 모니터링 구성 요소를 기본적으로 사용할 수 없습니다.- 승인 전략: 자동 또는 수동 업데이트를 승인하도록 선택합니다. 자동 업데이트 전략이 권장됩니다.
-
업데이트 채널: 최신 릴리스의 경우 업데이트 채널(예:
- 설치를 선택합니다.
3장. 배포 전에 Red Hat Quay 구성
Red Hat Quay Operator는 OpenShift Container Platform에 배포할 때 모든 Red Hat Quay 구성 요소를 관리할 수 있습니다. 그러나 이는 기본 구성이지만 설정을 더 많이 제어하려는 경우 외부에서 하나 이상의 구성 요소를 관리할 수 있습니다.
다음 패턴을 사용하여 관리되지 않는 Red Hat Quay 구성 요소를 구성합니다.
절차
-
적절한 설정으로
config.yaml구성 파일을 생성합니다. 다음 명령을 입력하여 구성 파일을 사용하여 보안을 생성합니다.
$ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
관리되지 않는 구성 요소를 식별하고 생성된
Secret을 참조하는quayregistry.yaml파일을 생성합니다. 예를 들면 다음과 같습니다.QuayRegistryYAML 파일의 예apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: objectstorage managed: falsequayregistry.yaml파일을 사용하여 레지스트리를 배포합니다.$ oc create -n quay-enterprise -f quayregistry.yaml
3.1. 자동화를 위한 Red Hat Quay 사전 구성
Red Hat Quay는 자동화를 활성화하는 여러 구성 옵션을 지원합니다. 사용자는 사용자 인터페이스와 상호 작용의 필요성을 줄이기 위해 배포 전에 이러한 옵션을 구성할 수 있습니다.
3.1.1. API가 첫 번째 사용자를 생성하도록 허용
첫 번째 사용자를 생성하려면 FEATURE_USER_INITIALIZE 매개변수를 true로 설정하고 /api/v1/user/initialize API를 호출해야 합니다. 기존 조직의 OAuth 애플리케이션에서 생성한 OAuth 토큰이 필요한 다른 모든 레지스트리 API 호출과 달리 API 끝점에는 인증이 필요하지 않습니다.
사용자는 다른 사용자가 생성되지 않은 경우 Red Hat Quay를 배포한 후 API를 사용하여 quayadmin 과 같은 사용자를 생성할 수 있습니다. 자세한 내용은 API를 사용하여 첫 번째 사용자 만들기를 참조하십시오.
3.1.2. 일반 API 액세스 활성화
Red Hat Quay 레지스트리 API에 대한 일반적인 액세스를 허용하려면 BROWSER_API_CALLS_XHR_ONLY config 옵션을 false로 설정해야 합니다.
3.1.3. 슈퍼 유저 추가
Red Hat Quay를 배포한 후 사용자는 사용자를 생성하고 전체 권한으로 첫 번째 사용자 관리자 권한을 부여할 수 있습니다. 사용자는 SUPER_USER 구성 오브젝트를 사용하여 사전에 전체 권한을 구성할 수 있습니다. 예를 들면 다음과 같습니다.
... SERVER_HOSTNAME: quay-server.example.com SETUP_COMPLETE: true SUPER_USERS: - quayadmin ...
3.1.4. 사용자 생성 제한
슈퍼유저를 구성한 후 FEATURE_USER_CREATION 을 false 로 설정하여 슈퍼유저 그룹에 새 사용자를 생성하는 기능을 제한할 수 있습니다. 예를 들면 다음과 같습니다.
... FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false ...
3.1.5. Red Hat Quay 3.8에서 새 기능 활성화
새로운 Red Hat Quay 3.8 기능을 사용하려면 다음 기능 중 일부 또는 모두를 활성화합니다.
...
FEATURE_UI_V2: true
FEATURE_LISTEN_IP_VERSION:
FEATURE_SUPERUSERS_FULL_ACCESS: true
GLOBAL_READONLY_SUPER_USERS:
-
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST:
-
...3.1.6. Red Hat Quay 3.7에서 새 기능 활성화
새로운 Red Hat Quay 3.7 기능을 사용하려면 다음 기능 중 일부 또는 모두를 활성화합니다.
... FEATURE_QUOTA_MANAGEMENT: true FEATURE_BUILD_SUPPORT: true FEATURE_PROXY_CACHE: true FEATURE_STORAGE_REPLICATION: true DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000 ...
3.1.7. 자동화에 권장되는 구성
다음 config.yaml 매개변수가 자동화를 위해 제안됩니다.
... FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false ...
3.2. 오브젝트 스토리지 구성
Red Hat Quay Operator가 스토리지를 관리하거나 직접 관리할 수 있는지 여부에 관계없이 Red Hat Quay를 설치하기 전에 오브젝트 스토리지를 구성해야 합니다.
Red Hat Quay Operator가 스토리지 관리를 담당하는 경우 NooBaa 및 Red Hat OpenShift Data Foundations Operator 설치 및 구성에 대한 정보는 관리형 스토리지 의 섹션을 참조하십시오.
별도의 스토리지 솔루션을 사용하는 경우 Operator를 구성할 때 objectstorage 를 관리되지 않음 으로 설정합니다. 다음 섹션을 참조하십시오. 기존 스토리지 구성에 대한 자세한 내용은 관리되지 않는 스토리지입니다.
3.2.1. 관리되지 않는 스토리지 사용
이 섹션에서는 편의를 위해 관리되지 않는 스토리지에 대한 구성 예제를 제공합니다. 오브젝트 스토리지 설정 방법에 대한 자세한 내용은 Red Hat Quay 구성 가이드를 참조하십시오.
3.2.1.1. AWS S3 스토리지
Red Hat Quay 배포를 위해 AWS S3 스토리지를 구성할 때 다음 예제를 사용합니다.
DISTRIBUTED_STORAGE_CONFIG:
s3Storage:
- S3Storage
- host: s3.us-east-2.amazonaws.com
s3_access_key: ABCDEFGHIJKLMN
s3_secret_key: OL3ABCDEFGHIJKLMN
s3_bucket: quay_bucket
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- s3Storage3.2.1.2. Google Cloud 스토리지
Red Hat Quay 배포를 위해 Google Cloud 스토리지를 구성할 때 다음 예제를 사용합니다.
DISTRIBUTED_STORAGE_CONFIG:
googleCloudStorage:
- GoogleCloudStorage
- access_key: GOOGQIMFB3ABCDEFGHIJKLMN
bucket_name: quay-bucket
secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- googleCloudStorage3.2.1.3. Microsoft Azure 스토리지
Red Hat Quay 배포를 위해 Microsoft Azure 스토리지를 구성할 때 다음 예제를 사용합니다.
DISTRIBUTED_STORAGE_CONFIG:
azureStorage:
- AzureStorage
- azure_account_name: azure_account_name_here
azure_container: azure_container_here
storage_path: /datastorage/registry
azure_account_key: azure_account_key_here
sas_token: some/path/
endpoint_url: https://[account-name].blob.core.usgovcloudapi.net 1
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- azureStorage- 1
- Microsoft Azure 스토리지의
endpoint_url매개변수는 선택 사항이며 Microsoft Azure Government (MAG) 끝점과 함께 사용할 수 있습니다. 비워 두면endpoint_url이 일반 Microsoft Azure 리전에 연결됩니다.Red Hat Quay 3.7부터 MAG Blob 서비스의 기본 끝점을 사용해야 합니다. MAG Blob 서비스의 보조 끝점을 사용하면 다음과 같은 오류가 발생합니다.
AuthenticationErrorDetail:Cannot find the claimed account when trying to GetProperties for the account whusc8-secondary.
3.2.1.4. Ceph/RadosGW Storage
Red Hat Quay 배포를 위해 Ceph/RadosGW 스토리지를 구성할 때 다음 예제를 사용합니다.
DISTRIBUTED_STORAGE_CONFIG:
radosGWStorage: #storage config name
- RadosGWStorage #actual driver
- access_key: access_key_here #parameters
secret_key: secret_key_here
bucket_name: bucket_name_here
hostname: hostname_here
is_secure: 'true'
port: '443'
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: #must contain name of the storage config
- radosGWStorage3.2.1.5. Swift 스토리지
Red Hat Quay 배포를 위해 Swift 스토리지를 구성할 때 다음 예제를 사용합니다.
DISTRIBUTED_STORAGE_CONFIG:
swiftStorage:
- SwiftStorage
- swift_user: swift_user_here
swift_password: swift_password_here
swift_container: swift_container_here
auth_url: https://example.org/swift/v1/quay
auth_version: 1
ca_cert_path: /conf/stack/swift.cert"
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- swiftStorage3.2.1.6. NooBaa 관리되지 않는 스토리지
다음 절차에 따라 NooBaa를 관리되지 않는 스토리지 구성으로 배포합니다.
절차
- 스토리지 → 오브젝트 버킷 클레임으로 이동하여 Red Hat Quay 콘솔에서 NooBaa Object Bucket Claims 를 생성합니다.
- 액세스 키, 버킷 이름, 끝점(hostname) 및 시크릿 키를 포함하여 오브젝트 버킷 클레임 데이터 세부 정보를 검색합니다.
Object Bucket Claim에 대한 정보를 사용하는
config.yaml구성 파일을 생성합니다.DISTRIBUTED_STORAGE_CONFIG: default: - RHOCSStorage - access_key: WmrXtSGk8B3nABCDEFGH bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef hostname: s3.openshift-storage.svc.cluster.local is_secure: true port: "443" secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
오브젝트 버킷 클레임 구성에 대한 자세한 내용은 오브젝트 버킷 클레임을 참조하십시오.
3.2.2. 관리되지 않는 NooBaa 인스턴스 사용
Red Hat Quay 배포에 관리되지 않는 NooBaa 인스턴스를 사용하려면 다음 절차를 사용하십시오.
절차
- 스토리지 → 오브젝트 버킷 클레임의 콘솔에 NooBaa Object Bucket Claims를 생성합니다.
-
액세스 키, 버킷이름,클레임 데이터 세부 정보를 검색합니다.엔드포인트(hostname)및시크릿키를 포함하여 오브젝트 버킷 Object Bucket Claim에 대한 정보를 사용하여
config.yaml구성 파일을 생성합니다. 예를 들면 다음과 같습니다.DISTRIBUTED_STORAGE_CONFIG: default: - RHOCSStorage - access_key: WmrXtSGk8B3nABCDEFGH bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef hostname: s3.openshift-storage.svc.cluster.local is_secure: true port: "443" secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
3.2.3. 관리형 스토리지
Red Hat Quay Operator에서 Red Hat Quay용 오브젝트 스토리지를 관리하려면 클러스터에서 ObjectBucketClaim API를 통해 오브젝트 스토리지를 제공할 수 있어야 합니다. Red Hat OpenShift Data Foundation Operator를 사용하면 다음과 같은 두 가지 옵션을 사용할 수 있습니다.
로컬 Kubernetes
PersistentVolume스토리지에서 지원하는 Multi-Cloud Object Gateway의 독립 실행형 인스턴스- 고가용성이 아님
- Red Hat Quay 서브스크립션에 포함
- Red Hat OpenShift Data Foundation에 대한 별도의 서브스크립션이 필요하지 않음
스케일 아웃 오브젝트 서비스 및 Ceph를 사용하는 Red Hat OpenShift Data Foundation의 프로덕션 배포
- 고가용성
- Red Hat OpenShift Data Foundation에 대해 별도의 서브스크립션이 필요
독립 실행형 인스턴스 옵션을 사용하려면 아래에서 계속 읽습니다. Red Hat OpenShift Data Foundation의 프로덕션 배포는 공식 문서를 참조하십시오.
오브젝트 스토리지 디스크 공간은 50GiB의 Red Hat Quay Operator에 의해 자동으로 할당됩니다. 이 수는 대부분의 소규모에서 중간 규모의 Red Hat Quay 설치에 사용 가능한 스토리지 양을 나타내지만 사용 사례에는 충분하지 않을 수 있습니다. Red Hat OpenShift Data Foundation 볼륨 크기 조정은 현재 Red Hat Quay Operator에 의해 처리되지 않습니다. 자세한 내용은 관리 스토리지 크기 조정 섹션을 참조하십시오.
3.2.3.1. Red Hat OpenShift Data Foundation Operator for Red Hat Quay에서 Multicloud Object Gateway 구성 요소 활용
Red Hat Quay 서브스크립션의 일부로 사용자는 Red Hat OpenShift Data Foundation Operator(이전의 OpenShift Container Storage Operator라고도 함)의 Multicloud Object Gateway 구성 요소를 사용할 수 있습니다. 이 게이트웨이 구성 요소를 사용하면 Kubernetes PersistentVolume- 기반 블록 스토리지에서 지원하는 Red Hat Quay에 S3 호환 오브젝트 스토리지 인터페이스를 제공할 수 있습니다. 사용량은 Operator에서 관리하는 Red Hat Quay 배포와 아래에 설명된 대로 multicloud Object Gateway 인스턴스의 정확한 사양으로 제한됩니다.
Red Hat Quay는 로컬 파일 시스템 스토리지를 지원하지 않으므로 사용자는 Kubernetes PersistentVolume 스토리지와 함께 게이트웨이를 활용하여 지원되는 배포를 제공할 수 있습니다. PersistentVolume 은 오브젝트 스토리지의 백업 저장소로 게이트웨이 인스턴스에 직접 마운트되며 모든 블록 기반 StorageClass 가 지원됩니다.
PersistentVolume 의 특성에 따라 이는 확장 가능한 고가용성 솔루션이 아니며 Red Hat OpenShift Data Foundation과 같은 스케일 아웃 스토리지 시스템을 대체하지 않습니다. 게이트웨이의 단일 인스턴스만 실행되고 있습니다. 일정 변경, 업데이트 또는 계획되지 않은 다운타임으로 인해 게이트웨이를 실행하는 Pod를 사용할 수 없게 되면 연결된 Red Hat Quay 인스턴스가 일시적으로 저하됩니다.
다음 절차를 사용하여 Local Storage Operator, Red Hat OpenShift Data Foundation을 설치하고 독립 실행형 Multicloud Object Gateway를 생성하여 OpenShift Container Platform에 Red Hat Quay를 배포합니다.
다음 문서는 공식 Red Hat OpenShift Data Foundation 설명서 와 공통성을 공유합니다.
3.2.3.1.1. OpenShift Container Platform에 Local Storage Operator 설치
로컬 스토리지 장치에서 Red Hat OpenShift Data Foundation 클러스터를 생성하기 전에 Operator Hub 에서 Local Storage Operator를 설치하려면 다음 절차를 사용하십시오.
- OpenShift 웹 콘솔에 로그인합니다.
- Operators → OperatorHub를 클릭합니다.
- 검색 상자에 로컬 스토리지를 입력하여 Operator 목록에서 Local Storage Operator를 찾습니다. 로컬 스토리지를 클릭합니다.
- 설치를 클릭합니다.
Operator 설치 페이지에서 다음 옵션을 설정합니다.
- Update channel의 경우 stable 을 선택합니다.
- 설치 모드의 경우 클러스터에서 특정 네임스페이스를 선택합니다.
- 설치된 네임스페이스의 경우 Operator 권장 네임스페이스 openshift-local-storage 를 선택합니다.
- 업데이트 승인의 경우 자동 을 선택합니다.
- 설치를 클릭합니다.
3.2.3.1.2. OpenShift Container Platform에 Red Hat OpenShift Data Foundation 설치
OpenShift Container Platform에 Red Hat OpenShift Data Foundation을 설치하려면 다음 절차를 사용하십시오.
사전 요구 사항
-
cluster-admin및 Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 클러스터에 3개 이상의 작업자 노드가 있어야 합니다.
- 추가 리소스 요구 사항은 배포 계획 가이드를 참조하십시오.
절차
- OpenShift 웹 콘솔에 로그인합니다.
- Operators → OperatorHub를 클릭합니다.
- 검색 상자에 OpenShift Data Foundation 을 입력합니다. OpenShift Data Foundation 을 클릭합니다.
- 설치를 클릭합니다.
Operator 설치 페이지에서 다음 옵션을 설정합니다.
- Update channel의 경우 최신 stable 버전을 선택합니다.
- 설치 모드의 경우 클러스터에서 특정 네임스페이스를 선택합니다.
- 설치된 네임스페이스의 경우 Operator 권장 네임스페이스: openshift-storage 를 선택합니다.
업데이트 승인의 경우 자동 또는 수동 을 선택합니다.
자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)은 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다.
수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 최신 버전으로 업데이트하기 위해 해당 업데이트 요청을 수동으로 승인해야 합니다.
- 콘솔 플러그인의 경우 Enable 을 선택합니다.
설치를 클릭합니다.
Operator가 설치되면 메시지가 포함된 팝업이 사용자 인터페이스에
웹 콘솔 업데이트를 사용할 수 있습니다. 콘솔 변경 사항을 반영하려면 이 팝업 창에서 웹 콘솔 새로 고침을 클릭합니다.- Red Hat Quay의 Multicloud Object Gateway 구성 요소를 활용하기 위해 "독립 실행형 Multicloud Object Gateway" 섹션을 계속 진행합니다.
3.2.3.1.3. OpenShift Container Platform UI를 사용하여 독립 실행형 Multicloud Object Gateway 생성
다음 절차에 따라 독립 실행형 Multicloud Object Gateway를 생성합니다.
사전 요구 사항
- Local Storage Operator가 설치되어 있습니다.
- Red Hat OpenShift Data Foundation Operator를 설치했습니다.
절차
OpenShift 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하여 설치된 모든 Operator를 확인합니다.
네임스페이스가
openshift-storage인지 확인합니다.- 스토리지 시스템 생성을 클릭합니다.
백업 스토리지 페이지에서 다음을 선택합니다.
- 배포 유형 용으로 Multicloud Object Gateway를 선택합니다.
- 로컬 스토리지 장치 옵션을 사용하여 새 StorageClass 만들기 옵션을 선택합니다.
다음을 클릭합니다.
참고아직 설치되지 않은 경우 Local Storage Operator를 설치하라는 메시지가 표시됩니다. 설치를 클릭하고 "OpenShift Container Platform에 Local Storage Operator 설치"에 설명된 절차를 따르십시오.
로컬 볼륨 세트 생성 페이지에서 다음 정보를 제공합니다.
- 로컬 볼륨 세트의 이름과 스토리지 클래스를 입력합니다. 기본적으로 스토리지 클래스 이름에 로컬 볼륨 세트 이름이 표시됩니다. 이름을 변경할 수 있습니다.
다음 중 하나를 선택합니다.
모든 노드의 디스크
모든 노드에서 선택한 필터와 일치하는 사용 가능한 디스크를 사용합니다.
선택한 노드의 디스크
선택한 노드에서만 선택한 필터와 일치하는 사용 가능한 디스크를 사용합니다.
- 사용 가능한 디스크 유형 목록에서 SSD/NVMe을 선택합니다.
고급 섹션을 확장하고 다음 옵션을 설정합니다.
볼륨 모드
파일 시스템은 기본적으로 선택됩니다. 항상 볼륨 모드에 대해 파일 시스템이 선택되어 있는지 확인합니다.
장치 유형
드롭다운 목록에서 하나 이상의 장치 유형을 선택합니다.
디스크 크기
장치에 대해 최소 크기 100GB와 포함되어야 하는 장치의 사용 가능한 최대 크기를 설정합니다.
최대 디스크 제한
이는 노드에서 생성할 수 있는 최대 PV 수를 나타냅니다. 이 필드가 비어 있으면 일치하는 노드에서 사용 가능한 모든 디스크에 PV가 생성됩니다.
다음을클릭합니다.
LocalVolumeSet생성이 표시되는지 확인하는 팝업이 표시됩니다.- 계속하려면 예를 클릭합니다.
용량 및 노드 페이지에서 다음을 구성합니다.
- 사용 가능한 원시 용량 은 스토리지 클래스와 연결된 모든 디스크에 따라 용량 값으로 채워집니다. 이 작업을 수행하는 데 시간이 다소 걸립니다. 선택한 노드 목록에는 스토리지 클래스를 기반으로 하는 노드가 표시됩니다.
- 다음을 클릭하여 계속합니다.
선택 사항: 외부 키 관리 서비스에 연결 확인란을 선택합니다. 이는 클러스터 전체 암호화의 경우 선택 사항입니다.
- 키 관리 서비스 공급자 드롭다운 목록에서 Vault 또는 Thales CipherTrust Manager(KMIP 사용) 를 선택합니다. Vault 를 선택한 경우 다음 단계로 이동합니다. Thales CipherTrust Manager(KMIP를 사용하여) 를 선택한 경우 iii 단계로 이동합니다.
인증 방법을 선택합니다.
토큰 인증 방법 사용
- 고유한 연결 이름, Vault 서버의 호스트 주소 ('https://<hostname or ip>'), 포트 번호 및 토큰 을 입력합니다.
고급 설정을 확장하여
Vault구성에 따라 추가 설정 및 인증서 세부 정보를 입력합니다.- OpenShift Data Foundation 전용 및 고유한 백엔드 경로에 키 값 시크릿 경로를 입력합니다.
- 선택 사항: TLS 서버 이름 및 Vault Enterprise 네임스페이스 를 입력합니다.
- 각 PEM 인코딩 인증서 파일을 업로드하여 CA 인증서,클라이언트 인증서 및 클라이언트 개인 키를 제공합니다.
저장을 클릭하고 단계 활성화로 건너뜁니다.
Kubernetes 인증 방법 사용
- 고유한 Vault 연결 이름, Vault 서버의 호스트 주소 ('https://<hostname or ip>'), 포트 번호 및 역할 이름을 입력합니다.
고급 설정을 확장하여 Vault 구성에 따라 추가 설정 및 인증서 세부 정보를 입력합니다.
- Red Hat OpenShift Data Foundation 전용 및 고유한 백엔드 경로에 키 값 시크릿 경로를 입력합니다.
- 선택 사항: 해당하는 경우 TLS 서버 이름 및 인증 경로를 입력합니다.
- 각 PEM 인코딩 인증서 파일을 업로드하여 CA 인증서,클라이언트 인증서 및 클라이언트 개인 키를 제공합니다.
- 저장을 클릭하고 단계 활성화로 건너뜁니다.
Thales CipherTrust Manager (KMIP 사용) 를 KMS 공급자로 사용하려면 다음 단계를 따르십시오.
- 프로젝트 내에서 키 관리 서비스에 대한 고유한 연결 이름을 입력합니다.
주소 및 포트 섹션에서 Thales CipherTrust Manager의 IP와 KMIP 인터페이스가 활성화된 포트를 입력합니다. 예를 들면 다음과 같습니다.
- 주소: 123.34.3.2
- 포트: 5696
- 클라이언트 인증서,CA 인증서 및 클라이언트 개인 키를 업로드합니다.
- StorageClass 암호화가 활성화된 경우 위에서 생성된 암호화 및 암호 해독에 사용할 고유 ID를 입력합니다.
-
TLS Server 필드는 선택 사항이며 KMIP 엔드포인트에 대한 DNS 항목이 없을 때 사용됩니다. 예를 들어
kmip_all_<port>.ciphertrustmanager.local.
- 네트워크를 선택합니다.
- 다음을 클릭합니다.
- 검토 및 생성 페이지에서 구성 세부 정보를 검토합니다. 구성 설정을 수정하려면 뒤로를 클릭합니다.
- 스토리지 시스템 생성을 클릭합니다.
3.2.3.1.4. CLI를 사용하여 독립 실행형 Multicloud Object Gateway 생성
다음 절차에 따라 Red Hat OpenShift Data Foundation(이전의 OpenShift Container Storage) Operator를 설치하고 단일 인스턴스 Multi-Cloud Gateway 서비스를 구성합니다.
Red Hat OpenShift Data Foundation이 설치된 클러스터에서는 다음 구성을 병렬로 실행할 수 없습니다.
절차
- OpenShift 웹 콘솔에서 Operator → OperatorHub 를 선택합니다.
- Red Hat OpenShift Data Foundation 을 검색한 다음 설치를 선택합니다.
- 모든 기본 옵션을 수락한 다음 설치를 선택합니다.
Succeeded 로 표시되어야 하는 Status 열을 확인하여 Operator가 설치되었는지 확인합니다.
주의Red Hat OpenShift Data Foundation Operator 설치가 완료되면 스토리지 시스템을 생성하라는 메시지가 표시됩니다. 이 지침을 따르지 마십시오. 대신 다음 단계에 설명된 대로 NooBaa 오브젝트 스토리지를 생성합니다.
시스템에서 다음 정보를 사용하여
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 의 단일 인스턴스 배포가 생성됩니다.
다음 명령을 사용하여 구성을 적용합니다.
$ oc create -n openshift-storage -f noobaa.yaml
출력 예
noobaa.noobaa.io/noobaa created
몇 분 후에 Multi-cloud Object Gateway 가 프로비저닝을 완료해야 합니다. 다음 명령을 입력하여 상태를 확인할 수 있습니다.
$ oc get -n openshift-storage noobaas noobaa -w
출력 예
NAME MGMT-ENDPOINTS S3-ENDPOINTS IMAGE PHASE AGE noobaa [https://10.0.32.3:30318] [https://10.0.32.3:31958] registry.redhat.io/ocs4/mcg-core-rhel8@sha256:56624aa7dd4ca178c1887343c7445a9425a841600b1309f6deace37ce6b8678d Ready 3d18h
noobaa-pv-backing-store.yaml이라는 YAML 파일을 생성하여 게이트웨이에 대한 백업 저장소를 구성합니다.apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: noobaa-pv-backing-store namespace: openshift-storage spec: pvPool: numVolumes: 1 resources: requests: storage: 50Gi 1 storageClass: STORAGE-CLASS-NAME 2 type: pv-pool다음 명령을 입력하여 구성을 적용합니다.
$ oc create -f noobaa-pv-backing-store.yaml
출력 예
backingstore.noobaa.io/noobaa-pv-backing-store created
이렇게 하면 게이트웨이에 대한 백업 저장소 구성이 생성됩니다. Red Hat Quay의 모든 이미지는 위의 구성으로 생성된
PersistentVolume의 게이트웨이를 통해 오브젝트로 저장됩니다.다음 명령을 실행하여 Red Hat Quay Operator에서 발행한 모든
ObjectBucketClaims의 기본값을PersistentVolume백업 저장소로 설정합니다.$ oc patch bucketclass noobaa-default-bucket-class --patch '{"spec":{"placementPolicy":{"tiers":[{"backingStores":["noobaa-pv-backing-store"]}]}}}' --type merge -n openshift-storage
4장. 데이터베이스 구성
4.1. 기존 PostgreSQL 데이터베이스 사용
외부 관리형 PostgreSQL 데이터베이스를 사용하는 경우 성공적인 배포를 위해 pg_trgm 확장을 수동으로 활성화해야 합니다.
기존 PostgreSQL 데이터베이스를 배포하려면 다음 절차를 사용하십시오.
절차
필요한 데이터베이스 필드를 사용하여
config.yaml파일을 생성합니다. 예를 들면 다음과 같습니다.config.yaml파일의 예:DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database
구성 파일을
사용하여보안을 생성합니다.$ kubectl create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
postgres구성 요소를관리되지 않음으로 표시하고 생성된Secret을 참조하는QuayRegistryYAML 파일을 만듭니다. 예를 들면 다음과 같습니다.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.1.1. 데이터베이스 구성
이 섹션에서는 Red Hat Quay 배포에 사용할 수 있는 데이터베이스 구성 필드에 대해 설명합니다.
4.1.1.1. 데이터베이스 URI
Red Hat Quay를 사용하면 필수 DB_URI 필드를 사용하여 데이터베이스에 대한 연결이 구성됩니다.
다음 표에서는 DB_URI 구성 필드에 대해 설명합니다.
표 4.1. 데이터베이스 URI
| 필드 | 유형 | 설명 |
|---|---|---|
|
DB_URI | 문자열 | 자격 증명을 포함하여 데이터베이스에 액세스하기 위한 URI입니다.
postgresql://quayuser:quaypass@quay-server.example.com:5432/quay |
4.1.1.2. 데이터베이스 연결 인수
선택적 연결 인수는 DB_CONNECTION_ARGS 매개변수에 의해 구성됩니다. DB_CONNECTION_ARGS 에 정의된 일부 키-값 쌍은 일반적이지만 다른 값은 데이터베이스에 따라 다릅니다.
다음 표에서는 데이터베이스 연결 인수를 설명합니다.
표 4.2. 데이터베이스 연결 인수
| 필드 | 유형 | 설명 |
|---|---|---|
| DB_CONNECTION_ARGS | 개체 | 데이터베이스의 선택적 연결 인수(예: 시간 초과 및 SSL/TLS)입니다. |
| .autorollback | 부울 |
스레드 로컬 연결 사용 여부입니다. |
| .threadlocals | 부울 |
자동 롤백 연결을 사용할지 여부입니다. |
4.1.1.2.1. PostgreSQL SSL/TLS 연결 인수
SSL/TLS를 사용하면 배포 중인 데이터베이스에 따라 구성이 달라집니다. 다음 예제에서는 PostgreSQL SSL/TLS 구성을 보여줍니다.
DB_CONNECTION_ARGS: sslmode: verify-ca sslrootcert: /path/to/cacert
sslmode 옵션은 보안 SSL/TLS TCP/IP 연결이 서버와 협상될 우선순위를 결정합니다. 여섯 가지 모드가 있습니다.
표 4.3. SSL/TLS 옵션
| mode | 설명 |
|---|---|
| disable | 구성은 SSL/TLS 연결만 시도합니다. |
| allow | 구성은 먼저 비 SSL/TLS 연결을 시도합니다. 실패하면 SSL/TLS 연결을 시도합니다. |
|
| 구성은 먼저 SSL/TLS 연결을 시도합니다. 실패하면 SSL/TLS 연결을 시도합니다. |
| require | 구성은 SSL/TLS 연결만 시도합니다. 루트 CA 파일이 있는 경우 verify-ca가 지정된 것과 동일한 방식으로 인증서를 확인합니다. |
| verify-ca | 구성은 SSL/TLS 연결만 시도하며 신뢰할 수 있는 CA(인증 기관)에서 서버 인증서를 발급하는지 확인합니다. |
| verify-full | SSL/TLS 연결만 시도한 후 서버 인증서가 신뢰할 수 있는 CA에서 발행되고 요청된 서버 호스트 이름이 인증서에서 해당 이름과 일치하는지 확인합니다. |
PostgreSQL에 대한 유효한 인수에 대한 자세한 내용은 데이터베이스 연결 제어 기능을 참조하십시오.
4.1.1.2.2. MySQL SSL/TLS 연결 인수
다음 예제에서는 샘플 MySQL SSL/TLS 구성을 보여줍니다.
DB_CONNECTION_ARGS:
ssl:
ca: /path/to/cacertMySQL의 유효한 연결 인수에 대한 정보는 URI-Like Strings 또는 Key-Value pairs를 사용하여 서버에 연결할 때 사용할 수 있습니다.
4.1.2. 관리형 PostgreSQL 데이터베이스 사용
Red Hat Quay 3.9를 사용하면 Red Hat Quay Operator에서 데이터베이스를 관리하는 경우 Red Hat Quay 3.8 → 3.9에서 업데이트하면 PostgreSQL 10에서 PostgreSQL 13으로의 업그레이드를 자동으로 처리합니다.
- 관리형 데이터베이스가 있는 사용자는 PostgreSQL 데이터베이스를 10 → 13에서 업그레이드해야 합니다.
- Operator에서 Red Hat Quay 및 Clair 데이터베이스를 관리하는 경우 3.9.0 업그레이드가 성공하려면 각 구성 요소의 데이터베이스 업그레이드가 성공해야 합니다. 데이터베이스 업그레이드 중 하나가 실패하면 전체 Red Hat Quay 버전 업그레이드가 실패합니다. 이 동작이 예상됩니다.
Red Hat Quay Operator가 PostgreSQL 배포를 PostgreSQL 10 → 13에서 업그레이드하지 않으려면 quayregistry.yaml 파일에서 PostgreSQL 매개변수를 managed: false 로 설정해야 합니다. 데이터베이스를 Unmanaged로 설정하는 방법에 대한 자세한 내용은 기존 Postgres 데이터베이스 사용을 참조하십시오.
- PostgreSQL 13으로 업그레이드하는 것이 좋습니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다. 자세한 내용은 PostgreSQL 버전 관리 정책을 참조하십시오.
PostgreSQL 데이터베이스가 RHEL(Red Hat Enterprise Linux) 시스템과 동일한 버전을 일치시키려면 RHEL 8용 RHEL 8 버전으로 마이그레이션 하거나 RHEL 9용 RHEL 9 버전의 PostgreSQL으로 마이그레이션 을 참조하십시오.
Red Hat Quay 3.8 → 3.9 절차에 대한 자세한 내용은 "OpenShift Container Platform에서 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스 업그레이드"를 참조하십시오.
4.1.2.1. PostgreSQL 데이터베이스 권장 사항
Red Hat Quay 팀은 PostgreSQL 데이터베이스를 관리하기 위해 다음을 권장합니다.
- 데이터베이스 백업은 PostgreSQL 이미지 또는 자체 백업 인프라에서 제공된 툴을 사용하여 정기적으로 수행해야 합니다. Red Hat Quay Operator는 현재 PostgreSQL 데이터베이스가 백업되었는지 확인하지 않습니다.
-
백업에서 PostgreSQL 데이터베이스 복원은 PostgreSQL 툴 및 절차를 사용하여 수행해야 합니다. 데이터베이스 복원이 진행 중인 동안
Quaypod가 실행되지 않아야 합니다. - 데이터베이스 디스크 공간은 50GiB의 Red Hat Quay Operator에 의해 자동으로 할당됩니다. 이 수는 대부분의 소규모에서 중간 규모의 Red Hat Quay 설치에 사용 가능한 스토리지 양을 나타내지만 사용 사례에는 충분하지 않을 수 있습니다. 데이터베이스 볼륨 크기 조정은 현재 Red Hat Quay Operator에 의해 처리되지 않습니다.
4.2. SSL/TLS 및 경로 구성
OpenShift Container Platform Edge-Termination Routes에 대한 지원이 새로 관리되는 구성 요소 tls 를 통해 추가되었습니다. 이를 통해 SSL/TLS의 경로 구성 요소를 분리하고 사용자가 둘 다 별도로 구성할 수 있습니다.
EXTERNAL_TLS_TERMINATION: true 는 의견 설정입니다.
-
Managed
tls는 기본 클러스터 와일드카드 인증서가 사용됨을 의미합니다. -
Unmanaged
tls는 사용자가 제공한 키 및 인증서 쌍을 경로에 삽입함을나타냅니다.
이제 ssl.cert 및 ssl.key 가 별도의 영구 보안으로 이동되어 키 및 인증서 쌍이 모든 조정 시 다시 생성되지 않습니다. 키 및 인증서 쌍은 이제 에지 경로로 포맷되고 Quay 컨테이너의 동일한 디렉터리에 마운트됩니다.
SSL/TLS 및 경로를 구성할 때 여러 순으로 변경할 수 있지만 다음 규칙이 적용됩니다.
-
SSL/TLS가
관리되는경우 경로도 관리해야 합니다. -
SSL/TLS가
관리되지 않는경우 구성 툴을 사용하거나 구성 번들에서 직접 인증서를 제공해야 합니다.
다음 표에서는 유효한 옵션을 설명합니다.
표 4.4. TLS 및 경로에 유효한 구성 옵션
| 옵션 | 경로 | TLS | 인증서 제공 | 결과 |
|---|---|---|---|---|
| 자체 로드 밸런서에서 TLS를 처리합니다. | Managed | Managed | 없음 | 기본 와일드카드 인증서가 있는 엣지 경로 |
| Red Hat Quay handles TLS | Managed | Unmanaged | 제공됨 | Pod 내부에 마운트된 인증서가 있는 패스스루 경로 |
| Red Hat Quay handles TLS | Unmanaged | Unmanaged | 제공됨 | 인증서는 quay pod 내부에 설정되지만 경로를 수동으로 생성해야 합니다. |
Operator에서 TLS를 관리할 때 Red Hat Quay 3.7은 빌더를 지원하지 않습니다.
4.2.1. SSL/TLS 인증서 및 키 쌍을 사용하여 구성 번들 보안 생성
다음 절차에 따라 고유한 SSL/TLS 인증서 및 키 쌍이 포함된 구성 번들 시크릿을 생성합니다.
절차
다음 명령을 입력하여 고유한 SSL/TLS 인증서 및 키 쌍을 포함하는 구성 번들 시크릿을 생성합니다.
$ oc create secret generic --from-file config.yaml=./config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret
4.3. 외부 Redis 구성
이 섹션의 콘텐츠를 사용하여 외부 Redis 배포를 설정합니다.
4.3.1. 관리되지 않는 Redis 데이터베이스 사용
다음 절차에 따라 외부 Redis 데이터베이스를 설정합니다.
절차
다음 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다음 명령을 입력하여 구성 파일을 사용하여 시크릿을 생성합니다.
$ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
Redis 구성 요소를
Unmanaged로 설정하고 생성된 보안을 참조하는quayregistry.yaml파일을 생성합니다.apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: redis managed: false- Red Hat Quay 레지스트리를 배포합니다.
추가 리소스
4.3.2. 관리되지 않는 Horizontal Pod Autoscaler 사용
이제 HPA(Horizontal Pod Autoscalers)가 Clair,Quay, Mirror Pod에 포함되어 로드 급증 중에 자동으로 확장됩니다.
HPA는 기본적으로 관리되도록 구성되므로 Clair,Quay 및 미러 Pod의 수는 2로 설정됩니다. 이를 통해 Operator 또는 이벤트 예약 중에 Red Hat Quay를 업데이트하거나 재구성할 때 다운타임이 방지됩니다.
4.3.2.1. Horizontal Pod Autoscaler 비활성화
자동 스케일링을 비활성화하거나 자체 HorizontalPodAutoscaler 를 생성하려면 QuayRegistry 인스턴스에서 구성 요소를 관리되지 않음 으로 지정합니다. 예를 들면 다음과 같습니다.
apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
name: example-registry
namespace: quay-enterprise
spec:
components:
- kind: horizontalpodautoscaler
managed: false4.3.3. Route 구성 요소 비활성화
Red Hat Quay Operator가 경로를 생성하지 못하도록 하려면 다음 절차를 사용하십시오.
절차
quayregistry.yaml파일에서 구성 요소를managed: false로 설정합니다.apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: components: - kind: route managed: falseconfig.yaml파일을 편집하여 Red Hat Quay가 SSL/TLS를 처리하도록 지정합니다. 예를 들면 다음과 같습니다.... EXTERNAL_TLS_TERMINATION: false ... SERVER_HOSTNAME: example-registry-quay-quay-enterprise.apps.user1.example.com ... PREFERRED_URL_SCHEME: https ...
관리되지 않는 경로를 올바르게 구성하지 않으면 다음 오류가 반환됩니다.
{ { "kind":"QuayRegistry", "namespace":"quay-enterprise", "name":"example-registry", "uid":"d5879ba5-cc92-406c-ba62-8b19cf56d4aa", "apiVersion":"quay.redhat.com/v1", "resourceVersion":"2418527" }, "reason":"ConfigInvalid", "message":"required component `route` marked as unmanaged, but `configBundleSecret` is missing necessary fields" }
기본 경로를 비활성화하면 Red Hat Quay 인스턴스에 액세스하기 위해 경로,서비스 또는 Ingress 를 생성해야 합니다. 또한 사용하는 DNS는 Red Hat Quay 구성의 SERVER_HOSTNAME 과 일치해야 합니다.
4.3.4. 모니터링 구성 요소 비활성화
단일 네임스페이스에 Red Hat Quay Operator를 설치하는 경우 모니터링 구성 요소가 자동으로 managed: false 로 설정됩니다. 모니터링을 명시적으로 비활성화하려면 다음 참조를 사용합니다.
관리되지 않는 모니터링
apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
name: example-registry
namespace: quay-enterprise
spec:
components:
- kind: monitoring
managed: false
이 시나리오에서 모니터링을 활성화하려면 Red Hat Quay Operator가 단일 네임스페이스에 설치될 때 모니터링 활성화를 참조하십시오.
4.3.5. 미러링 구성 요소 비활성화
미러링을 명시적으로 비활성화하려면 다음 YAML 구성을 사용합니다.
관리되지 않는 미러링 예제 YAML 구성
apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
name: example-registry
namespace: quay-enterprise
spec:
components:
- kind: mirroring
managed: false
5장. Red Hat Quay Operator 배포
Red Hat Quay Operator는 명령줄 또는 OpenShift Container Platform 콘솔에서 배포할 수 있지만 단계는 근본적으로 동일합니다.
5.1. 명령줄에서 Red Hat Quay 배포
다음 절차에 따라 CLI(명령줄 인터페이스)를 사용하여 에서 Red Hat Quay를 배포합니다.
사전 요구 사항
- CLI를 사용하여 OpenShift Container Platform에 로그인했습니다.
절차
다음 명령을 입력하여 네임스페이스(예:
quay-enterprise)를 만듭니다.$ oc new-project quay-enterprise
선택 사항: Red Hat Quay 배포의 모든 측면을 사전 구성하려면 구성 번들에
대한보안을 생성합니다.$ oc create secret generic quay-enterprise-config-bundle --from-file=config-bundle.tar.gz=/path/to/config-bundle.tar.gz
quayregistry.yaml이라는 파일에QuayRegistry사용자 정의 리소스를 만듭니다.최소 배포의 경우 모든 기본값을 사용합니다.
quayregistry.yaml:
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise
선택 사항: 관리되지 않는 일부 구성 요소를 사용하려면
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선택 사항: 구성 번들(예:
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
선택 사항: 프록시가 구성된 경우 Red Hat Quay, Clair, 미러링에 대한 재정의를 사용하여 정보를 추가할 수 있습니다.
프록시가 구성된 quayregistry.yaml 예
kind: QuayRegistry metadata: name: quay37 spec: configBundleSecret: config-bundle-secret components: - kind: objectstorage managed: false - kind: route managed: true - kind: mirror managed: true overrides: env: - name: DEBUGLOG value: "true" - name: HTTP_PROXY value: quayproxy.qe.devcluster.openshift.com:3128 - name: HTTPS_PROXY value: quayproxy.qe.devcluster.openshift.com:3128 - name: NO_PROXY value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com - kind: tls managed: false - kind: clair managed: true overrides: env: - name: HTTP_PROXY value: quayproxy.qe.devcluster.openshift.com:3128 - name: HTTPS_PROXY value: quayproxy.qe.devcluster.openshift.com:3128 - name: NO_PROXY value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com - kind: quay managed: true overrides: env: - name: DEBUGLOG value: "true" - name: NO_PROXY value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com - name: HTTP_PROXY value: quayproxy.qe.devcluster.openshift.com:3128 - name: HTTPS_PROXY value: quayproxy.qe.devcluster.openshift.com:3128
지정된 네임스페이스에서
QuayRegistry를 생성합니다.$ oc create -n quay-enterprise -f quayregistry.yaml
status.registryEndpoint가 채워지는 시기를 확인하려면 다음 명령을 입력합니다.$ oc get quayregistry -n quay-enterprise example-registry -o jsonpath="{.status.registryEndpoint}" -w
추가 리소스
- Red Hat Quay 배포의 진행 상황을 추적하는 방법에 대한 자세한 내용은 배포 프로세스 모니터링 및 디버깅을 참조하십시오.
5.1.1. 명령줄을 사용하여 생성된 구성 요소 보기
배포된 Red Hat Quay 구성 요소를 보려면 다음 절차를 사용하십시오.
사전 요구 사항
- {ocp.}에 Red Hat Quay Operator를 배포했습니다.
절차
배포된 구성 요소를 보려면 다음 명령을 입력합니다.
$ oc get pods -n quay-enterprise
출력 예
NAME READY STATUS RESTARTS AGE example-registry-clair-app-5ffc9f77d6-jwr9s 1/1 Running 0 3m42s example-registry-clair-app-5ffc9f77d6-wgp7d 1/1 Running 0 3m41s example-registry-clair-postgres-54956d6d9c-rgs8l 1/1 Running 0 3m5s example-registry-quay-app-79c6b86c7b-8qnr2 1/1 Running 4 3m42s example-registry-quay-app-79c6b86c7b-xk85f 1/1 Running 4 3m41s example-registry-quay-app-upgrade-5kl5r 0/1 Completed 4 3m50s example-registry-quay-config-editor-597b47c995-svqrl 1/1 Running 0 3m42s example-registry-quay-database-b466fc4d7-tfrnx 1/1 Running 2 3m42s example-registry-quay-mirror-6d9bd78756-6lj6p 1/1 Running 0 2m58s example-registry-quay-mirror-6d9bd78756-bv6gq 1/1 Running 0 2m58s example-registry-quay-postgres-init-dzbmx 0/1 Completed 0 3m43s example-registry-quay-redis-8bd67b647-skgqx 1/1 Running 0 3m42s
5.1.2. 수평 Pod 자동 확장
기본 배포에는 다음과 같은 실행 중인 Pod가 표시됩니다.
-
Red Hat Quay 애플리케이션 자체를 위한 두 개의 Pod(
예:-registry-quay-app-*') -
Red Hat Quay 로깅을 위한 하나의 Redis Pod (
예:-registry-quay-redis-*) -
메타데이터 스토리지에 Red Hat Quay에서 사용하는 PostgreSQL용 데이터베이스 포드 1개(
예:-registry-quay-database-*) -
Red Hat Quay 구성 편집기용 하나의 Pod(
예:-registry-quay-config-editor-*) -
두 개의
Quay미러링 Pod(example-registry-quay-mirror-*) -
Clair 애플리케이션에 대한 두 개의 포드(
example-registry-clair-app-*) -
Clair용 PostgreSQL Pod 1개(
예-registry-clair-postgres-*)
수평 PPod 자동 확장은 기본적으로 관리 되도록 구성되며 Quay, Clair 및 리포지토리 미러링의 Pod 수는 2로 설정됩니다. 이를 통해 Red Hat Quay Operator 또는 일정 조정 이벤트를 통해 Red Hat Quay를 업데이트하거나 재구성할 때 다운타임을 방지할 수 있습니다. 다음 명령을 입력하여 HPA 오브젝트에 대한 정보를 볼 수 있습니다.
$ oc get hpa -n quay-enterprise
출력 예
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE example-registry-clair-app Deployment/example-registry-clair-app 16%/90%, 0%/90% 2 10 2 13d example-registry-quay-app Deployment/example-registry-quay-app 31%/90%, 1%/90% 2 20 2 13d example-registry-quay-mirror Deployment/example-registry-quay-mirror 27%/90%, 0%/90% 2 20 2 13d
5.1.2.1. API를 사용하여 첫 번째 사용자 생성
다음 절차에 따라 Red Hat Quay 조직에 첫 번째 사용자를 생성합니다.
사전 요구 사항
-
설정 옵션
FEATURE_USER_INITIALIZE를true로 설정해야 합니다. - 데이터베이스에 이미 사용자가 있을 수 없습니다.
이 절차에서는 "access_token": true 를 지정하여 OAuth 토큰을 요청합니다.
root 사용자로 다음 명령을 입력하여
python39를 설치합니다.$ sudo yum install python39
Python 3.9용
pip패키지 관리자를 업그레이드합니다.$ python3.9 -m pip install --upgrade pip
pip패키지 관리자를 사용하여bcrypt패키지를 설치합니다.$ pip install bcrypt
다음 명령을 입력하여 Python 3.9에서
bcrypt패키지를 사용하여 보안 해시 암호를 생성합니다.$ python3.9 -c 'import bcrypt; print(bcrypt.hashpw(b"subquay12345", bcrypt.gensalt(12)).decode("utf-8"))'Red Hat Quay 구성 파일을 열고 다음 구성 필드를 업데이트합니다.
FEATURE_USER_INITIALIZE: true SUPER_USERS: - quayadmin다음 명령을 입력하여 Red Hat Quay 서비스를 중지합니다.
$ sudo podman stop quay
다음 명령을 입력하여 Red Hat Quay 서비스를 시작합니다.
$ sudo podman run -d -p 80:8080 -p 443:8443 --name=quay -v $QUAY/config:/conf/stack:Z -v $QUAY/storage:/datastorage:Z {productrepo}/{quayimage}:{productminv}다음
CURL명령을 실행하여 사용자 이름, 암호, 이메일 및 액세스 토큰을 사용하여 새 사용자를 생성합니다.$ curl -X POST -k http://quay-server.example.com/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass12345", "email": "quayadmin@example.com", "access_token": true}'성공하면 명령은 사용자 이름, 이메일 및 암호화된 암호를 사용하여 오브젝트를 반환합니다. 예를 들면 다음과 같습니다.
{"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"quayadmin@example.com","encrypted_password":"1nZMLH57RIE5UGdL/yYpDOHLqiNCgimb6W9kfF8MjZ1xrfDpRyRs9NUnUuNuAitW","username":"quayadmin"} # gitleaks:allow사용자가 이미 데이터베이스에 있으면 오류가 반환됩니다.
{"message":"Cannot initialize user in a non-empty database"}암호가 8자를 넘지 않거나 공백을 포함하는 경우 오류가 반환됩니다.
{"message":"Failed to initialize user: Invalid password, password must be at least 8 characters and contain no whitespace."}다음 명령을 입력하여 Red Hat Quay 배포에 로그인합니다.
$ sudo podman login -u quayadmin -p quaypass12345 http://quay-server.example.com --tls-verify=false
출력 예
Login Succeeded!
추가 리소스
Red Hat Quay 배포 사전 구성에 대한 자세한 내용은 자동화를 위한 Red Hat Quay 사전 구성 섹션을참조하십시오.
5.1.3. 배포 프로세스 모니터링 및 디버깅
사용자는 배포 단계 중 문제를 해결할 수 있습니다. QuayRegistry 오브젝트의 상태는 배포 중에 구성 요소의 상태를 모니터링하는 데 도움이 될 수 있으며 발생할 수 있는 문제를 디버깅하는 데 도움이 될 수 있습니다.
절차
다음 명령을 입력하여 배포 상태를 확인합니다.
$ 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: {}
5.2. OpenShift Container Platform 콘솔에서 Red Hat Quay 배포
-
네임스페이스(예:
quay-enterprise)를 생성합니다. - Operators → 설치된 Operator 를 선택한 다음 Quay Operator를 선택하여 Operator 세부 정보 보기로 이동합니다.
- 'Provided APIs' 아래의 'Quay Registry' 타일에서 '인스턴스 생성'을 클릭합니다.
-
선택적으로
QuayRegistry의 'Name'을 변경합니다. 이는 레지스트리의 호스트 이름에 영향을 미칩니다. 다른 모든 필드는 기본값으로 채워집니다. -
'Create'를 클릭하여 Quay Operator가 배포할
QuayRegistry를 제출합니다. -
QuayRegistry목록 보기로 리디렉션되어야 합니다. 방금 만든QuayRegistry를 클릭하여 세부 정보 보기를 확인합니다. - 'Registry Endpoint'에 값이 있으면 클릭하여 UI를 통해 새 Quay 레지스트리에 액세스합니다. 이제 'Create Account'를 선택하여 사용자를 생성하고 로그인할 수 있습니다.
5.2.1. Red Hat Quay UI를 사용하여 첫 번째 사용자 생성
다음 절차에 따라 Red Hat Quay UI에서 첫 번째 사용자를 생성합니다.
이 절차에서는 FEATURE_USER_CREATION config 옵션이 false로 설정되지 않은 것으로 가정합니다. false 인 경우 UI의 계정 만들기 기능이 비활성화되고 API를 사용하여 첫 번째 사용자를 만들어야 합니다.
절차
- OpenShift Container Platform 콘솔에서 적절한 네임스페이스/프로젝트를 사용하여 Operator → 설치된 Operator 로 이동합니다.
새로 설치된
QuayRegistry오브젝트를 클릭하여 세부 정보를 확인합니다. 예를 들면 다음과 같습니다.
-
Registry Endpoint에 값이 있으면 브라우저에서 이 URL로 이동합니다. Red Hat Quay 레지스트리 UI에서 계정 만들기 를 선택하여 사용자를 생성합니다. 예를 들면 다음과 같습니다.
사용자 이름 , 암호,이메일에 대한 세부 정보를 입력한 다음 Create Account 를 클릭합니다. 예를 들면 다음과 같습니다.
첫 번째 사용자를 생성한 후 Red Hat Quay 레지스트리에 자동으로 로그인됩니다. 예를 들면 다음과 같습니다.
6장. QuayRegistry 오브젝트의 상태 보기
지정된 Red Hat Quay 배포의 라이프사이클 관찰 기능은 해당 QuayRegistry 오브젝트의 status 섹션에서 보고됩니다. Red Hat Quay Operator는 이 섹션을 지속적으로 업데이트하므로 Red Hat Quay 또는 관리형 종속성에서 문제 또는 상태 변경 사항을 찾을 수 있는 첫 번째 위치에 있어야 합니다.
6.1. 레지스트리 끝점 보기
Red Hat Quay를 사용할 준비가 되면 status.registryEndpoint 필드가 레지스트리의 공개적으로 사용 가능한 호스트 이름으로 채워집니다.
6.2. 구성 편집기 끝점 보기
status.configEditorEndpoint 를 사용하여 Red Hat Quay의 UI 기반 구성 편집기에 액세스합니다.
6.3. 구성 편집기 인증 정보 시크릿 보기
구성 편집기 UI의 사용자 이름과 암호는 status.configEditorCredentials 에서 참조하는 Secret QuayRegistry 와 동일한 네임스페이스에 있는 Secret에 저장됩니다.
6.4. 사용 중인 Red Hat Quay 버전 보기
실행 중인 Red Hat Quay의 현재 버전은 status.currentVersion 으로 보고됩니다.
6.5. Red Hat Quay 배포의 조건 보기
특정 조건이 status.conditions 에 보고됩니다.
7장. OpenShift Container Platform에서 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스 업데이트
Red Hat Quay 배포가 하나의 y-stream에서 다음 단계로 업그레이드하는 경우 예를 들어 3.8.10 → 3.8.11에서 업그레이드 채널을 stable-3.8 에서 stable-3.9 로 전환해서는 안 됩니다. y-stream 업그레이드 중 업그레이드 채널을 변경하면 Red Hat Quay가 3.9로 업그레이드할 수 없습니다. 이는 알려진 문제이며 Red Hat Quay의 향후 버전에서 수정될 예정입니다.
Red Hat Quay 3.8 → 3.9를 업데이트할 때 Operator는 Clair 및 Red Hat Quay의 기존 PostgreSQL 데이터베이스를 버전 10에서 버전 13으로 자동으로 업그레이드합니다.
- 관리형 데이터베이스가 있는 사용자는 PostgreSQL 데이터베이스를 10 → 13에서 업그레이드해야 합니다.
- Operator에서 Red Hat Quay 및 Clair 데이터베이스를 관리하는 경우 3.9.0 업그레이드가 성공하려면 각 구성 요소의 데이터베이스 업그레이드가 성공해야 합니다. 데이터베이스 업그레이드 중 하나가 실패하면 전체 Red Hat Quay 버전 업그레이드가 실패합니다. 이 동작이 예상됩니다.
웹 콘솔 UI를 사용하거나 CLI를 사용하여 OpenShift Container Platform에서 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스를 업데이트할 수 있습니다.
7.1. OpenShift Container Platform 웹 콘솔을 사용하여 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스 업데이트
다음 절차에 따라 OpenShift Container Platform 웹 콘솔을 사용하여 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스를 업데이트합니다.
- 이 업그레이드는 되돌릴 수 없습니다. PostgreSQL 13으로 업그레이드하는 것이 좋습니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다. 자세한 내용은 PostgreSQL 버전 관리 정책을 참조하십시오.
- Operator에서 Red Hat Quay 및 Clair 데이터베이스를 관리하는 경우 3.9.0 업그레이드가 성공하려면 각 구성 요소의 데이터베이스 업그레이드가 성공해야 합니다. 데이터베이스 업그레이드 중 하나가 실패하면 전체 Red Hat Quay 버전 업그레이드가 실패합니다. 이 동작이 예상됩니다.
-
기본적으로 Red Hat Quay는 PostgreSQL 10에서 이전 PVC(영구 볼륨 클레임)를 제거하도록 구성됩니다. 이 설정 및 이전 PVC를 비활성화하려면
quay-operatorSubscription오브젝트에서POSTGRES_UPGRADE_RETAIN_BACKUP을True로 설정해야 합니다.
사전 요구 사항
- OpenShift Container Platform에 Red Hat Quay 3.6, 3.7 또는 3.8을 설치했습니다.
100GB의 무료 추가 스토리지.
업그레이드 프로세스 중에 마이그레이션된 데이터를 저장하기 위해 추가 PVC(영구 볼륨 클레임)가 프로비저닝됩니다. 이는 사용자 데이터에 대한 파괴적인 작업을 방지하는 데 도움이 됩니다. 업그레이드 프로세스에서는 Red Hat Quay 데이터베이스 업그레이드 및 Clair 데이터베이스 업그레이드 모두에 대해 50GB의 PVC를 롤아웃합니다.
절차
선택 사항:
POSTGRES_UPGRADE_RETAIN_BACKUP을quay-operatorSubscription오브젝트로 설정하여 PostgreSQL 10에서 이전 PVC를 백업합니다.예를 들면 다음과 같습니다.apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: quay-operator namespace: quay-enterprise spec: channel: stable-3.8 name: quay-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: POSTGRES_UPGRADE_RETAIN_BACKUP value: "true"- OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
- Red Hat Quay Operator를 클릭합니다.
- 서브스크립션 탭으로 이동합니다.
- 서브스크립션 세부 정보 에서 채널 업데이트를 클릭합니다.
- stable-3.9 를 선택하고 변경 사항을 저장합니다.
- Upgrade(업그레이드) 상태에서 새 설치 진행 상황을 확인합니다. 계속하기 전에 업그레이드 상태가 1 로 변경될 때까지 기다립니다.
- OpenShift Container Platform 클러스터에서 워크로드 → Pod 로 이동합니다. 기존 Pod는 종료되거나 종료되어야 합니다.
-
clair-postgres-upgrade,quay-postgres-upgrade,quay-app-upgrade. -
clair-postgres-upgrade,quay-postgres-upgrade및quay-app-upgradePod가 Completed 로 표시된 후 Red Hat Quay 배포의 나머지 Pod가 실행됩니다. 이 작업은 약 10분 정도 걸립니다. -
quay-database및clair-postgresPod에서postgresql-13이미지를 사용하는지 확인합니다. -
quay-app포드가 Running 으로 표시되면 Red Hat Quay 레지스트리에 도달할 수 있습니다.
7.2. CLI를 사용하여 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스 업데이트
CLI(명령줄 인터페이스)를 사용하여 Red Hat Quay 및 Red Hat Quay 및 Clair PostgreSQL 데이터베이스를 업데이트하려면 다음 절차를 사용하십시오.
- 이 업그레이드는 되돌릴 수 없습니다. PostgreSQL 13으로 업그레이드하는 것이 좋습니다. PostgreSQL 10은 2022년 11월 10일에 최종 릴리스되었으며 더 이상 지원되지 않습니다. 자세한 내용은 PostgreSQL 버전 관리 정책을 참조하십시오.
-
기본적으로 Red Hat Quay는 PostgreSQL 10에서 이전 PVC(영구 볼륨 클레임)를 제거하도록 구성됩니다. 이 설정 및 이전 PVC를 비활성화하려면
quay-operatorSubscription오브젝트에서POSTGRES_UPGRADE_RETAIN_BACKUP을True로 설정해야 합니다.
사전 요구 사항
- OpenShift Container Platform에 Red Hat Quay 3.6, 3.7 또는 3.8을 설치했습니다.
100GB의 무료 추가 스토리지.
업그레이드 프로세스 중에 마이그레이션된 데이터를 저장하기 위해 추가 PVC(영구 볼륨 클레임)가 프로비저닝됩니다. 이는 사용자 데이터에 대한 파괴적인 작업을 방지하는 데 도움이 됩니다. 업그레이드 프로세스에서는 Red Hat Quay 데이터베이스 업그레이드 및 Clair 데이터베이스 업그레이드 모두에 대해 50GB의 PVC를 롤아웃합니다.
절차
다음
oc get명령을 입력하여quay-operator구성 파일을 검색합니다.$ oc get subscription quay-operator -n quay-enterprise -o yaml > quay-operator.yaml
다음 명령을 입력하여 Red Hat Quay Operator의 최신 버전과 해당 채널을 검색합니다.
oc get packagemanifests quay-operator \ -o jsonpath='{range .status.channels[*]}{@.currentCSV} {@.name}{"\n"}{end}' \ | awk '{print "STARTING_CSV=" $1 " CHANNEL=" $2 }' \ | sort -nr \ | head -1출력 예
STARTING_CSV=quay-operator.v3.9.0 CHANNEL=stable-3.9
이전 명령의 출력을 사용하여 Red Hat Quay Operator에 대한
Subscription사용자 정의 리소스를 업데이트하여quay-operator.yaml로 저장합니다. 예를 들면 다음과 같습니다.apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: quay-operator namespace: quay-enterprise spec: channel: stable-3.9 1 name: quay-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: POSTGRES_UPGRADE_RETAIN_BACKUP 2 value: "true"
다음 명령을 입력하여 구성을 적용합니다.
$ oc apply -f quay-operator.yaml
출력 예
subscription.operators.coreos.com/quay-operator created
다음 단계