Quay Operator를 사용하여 OpenShift에 Red Hat Quay 배포
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 구성에 대한 새로운 강력한 검증 라이브러리
-
ObjectBucketClaimKubernetes 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: true1.3. 관리형 구성 요소 사용
QuayRegistry 사용자 정의 리소스가 다른 리소스를 지정하지 않는 한 Red Hat Quay Operator는 다음과 같은 관리 구성 요소에 기본값을 사용합니다.
- Quay: Red Hat Quay 배포에 대한 재정의가 유지됩니다. 예를 들어 환경 변수 및 복제본 수입니다. 이 구성 요소는 Red Hat Quay 3.7의 새로운 기능이며 관리되지 않음으로 설정할 수 없습니다.
- Postgres: 레지스트리 메타데이터를 저장하기 위해 소프트웨어 컬렉션에서 Postgres 10 버전을 사용합니다.
- Clair: 이미지 취약점 스캔 제공
- Redis: 라이브 빌더 로그 및 Red Hat Quay 튜토리얼을 저장합니다. 가비지 컬렉션에 필요한 잠금 메커니즘도 포함되어 있습니다.
-
HorizontalPodAutoscaler: 메모리/cpu 사용에 따라
QuayPod 수 조정 -
Objectstorage: 이미지 계층 Blob 저장을 위해 Noobaa/RHOCS에서 제공하는
ObjectBucketClaimKubernetes API를 활용합니다. - Route: OpenShift Container Platform 외부에서 Red Hat Quay 레지스트리에 외부 진입점을 제공
- mirror: 선택적 저장소 미러링을 지원하도록 저장소 미러 작업자 구성
- Monitoring: 기능에는 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.4. 종속 항목에 관리되지 않는 구성 요소 사용
Quay와 함께 사용하려는 Postgres, Redis 또는 오브젝트 스토리지와 같은 기존 구성 요소가 있는 경우 먼저 Quay 구성 번들(config.yaml) 내에서 구성한 다음 관리되지 않는 구성 요소를 나타내는 동안 QuayRegistry (Kubernetes Secret)의 번들을 참조합니다.
Quay 구성 편집기를 사용하여 기존 구성 번들을 생성하거나 수정하고 특히 여러 변경 사항에 대해 Kubernetes 보안을 업데이트하는 프로세스를 단순화할 수 있습니다. 구성 편집기를 통해 Quay 구성을 변경하고 Operator로 전송하면 새 구성을 반영하도록 Quay 배포가 업데이트됩니다.
1.5. 구성 번들 시크릿
spec.configBundleSecret 필드는 QuayRegistry 와 동일한 네임스페이스에 있는 Secret 의 metadata.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를 수동으로 구성할 수 있습니다.
- Amazon S3 (Red Hat Quay에 대한 S3 버킷 정책 구성에 대한 자세한 내용은 S3 IAM 버킷 정책 참조)
- Azure Blob Storage
- Google Cloud Storage
- Ceph Object Gateway(RADOS)
- OpenStack Swift
- CloudFront + S3
2장. OperatorHub에서 Quay Operator 설치
OpenShift 콘솔을 사용하여 Operator → OperatorHub를 선택한 다음 Red Hat Quay Operator를 선택합니다. 둘 이상의 경우 커뮤니티 버전이 아닌 Red Hat Certified Operator를 사용하십시오.
설치 페이지에 기능 및 사전 요구 사항이 요약되어 있습니다.
설치를 선택합니다. Operator 설치 페이지가 표시됩니다.
설치를 사용자 지정하는 데 다음과 같은 선택 사항을 선택할 수 있습니다.
-
업데이트 채널: 최신 릴리스의 경우 업데이트 채널(예:
stable-3.7)을 선택합니다. -
설치 모드:
클러스터 전체에서 Operator를 사용할 수 있도록 하려면 클러스터의 모든 네임스페이스를 선택합니다. 단일네임스페이스 내에서만 배포하려면 클러스터의 특정네임스페이스를 선택합니다. 클러스터 전체에 Operator를 설치하는 것이 좋습니다. 단일 네임스페이스를 선택하면 모니터링 구성 요소를 기본적으로 사용할 수 없습니다. - 승인 전략: 자동 또는 수동 업데이트를 승인하도록 선택합니다. 자동 업데이트 전략이 권장됩니다.
-
업데이트 채널: 최신 릴리스의 경우 업데이트 채널(예:
- 설치를 선택합니다.
- 잠시 후 Operator가 Installed Operators 페이지에 성공적으로 설치되었음을 확인할 수 있습니다.
3장. 배포 전에 Quay 구성
Operator는 OpenShift에 배포할 때 모든 Red Hat Quay 구성 요소를 관리할 수 있으며 이는 기본 구성입니다. 또는 하나 이상의 구성 요소를 외부에서 직접 관리할 수 있으며, 이를 통해 설정을 더 많은 제어할 수 있으며 Operator에서 나머지 구성 요소를 관리할 수 있습니다.
관리되지 않는 구성 요소를 구성하기 위한 표준 패턴은 다음과 같습니다.
-
적절한 설정으로
config.yaml구성 파일을 생성 구성 파일을 사용하여 시크릿 생성
$ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-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: objectstorage managed: falseYAML 파일을 사용하여 레지스트리를 배포합니다.
$ 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_ONLY 를 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 기능을 사용하려면 다음 기능 중 일부 또는 모두를 활성화합니다.
...
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 기능을 사용하려면 다음 기능 중 일부 또는 모두를 활성화합니다.
... 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. 오브젝트 스토리지 구성
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:
- s3Storage3.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:
- googleCloudStorage3.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 Storage
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 스토리지
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를 관리되지 않는 스토리지 구성으로 배포합니다.
절차
- 스토리지 → 오브젝트 버킷 클레임으로 이동하여 {product-title} 콘솔에 NooBaa 오브젝트 버킷 클레임 을 생성합니다.
- 액세스 키, 버킷 이름, 끝점(hostname) 및 시크릿 키를 포함하여 오브젝트 버킷 클레임 데이터 세부 정보를 검색합니다.
오브젝트 버킷 클레임에 대한 정보를 사용하여
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 서비스를 구성하려면 다음 단계를 따르십시오.
- OpenShift 콘솔을 열고 Operator → OperatorHub를 선택한 다음 OpenShift Data Foundation Operator를 선택합니다.
- 설치를 선택합니다. 모든 기본 옵션을 수락하고 다시 설치를 선택합니다.
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.
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 의 단일 인스턴스 배포가 생성됩니다.
다음 명령을 사용하여 구성을 적용합니다.
$ oc create -n openshift-storage -f noobaa.yaml noobaa.noobaa.io/noobaa created
몇 분 후 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
다음으로 게이트웨이에 대한 백업 저장소를 구성합니다. 다음 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다음 명령을 사용하여 구성을 적용합니다.
$ oc create -f noobaa-pv-backing-store.yaml backingstore.noobaa.io/noobaa-pv-backing-store created
이렇게 하면 게이트웨이에 대한 백업 저장소 구성이 생성됩니다. Quay의 모든 이미지는 위의 구성으로 생성된
PersistentVolume의 게이트웨이를 통해 오브젝트로 저장됩니다.마지막으로 다음 명령을 실행하여 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 데이터베이스 사용
요구 사항:
외부에서 관리되는 PostgreSQL 데이터베이스를 사용하는 경우 성공적으로 배포하려면 pg_trgm 확장을 수동으로 활성화해야 합니다.
필요한 데이터베이스 필드를 사용하여 구성 파일
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구성 요소를 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- 다음 섹션에 설명된 대로 레지스트리를 배포합니다.
3.3.2. 데이터베이스 구성
이 섹션에서는 Red Hat Quay 배포에 사용할 수 있는 데이터베이스 구성 필드에 대해 설명합니다.
3.3.2.1. 데이터베이스 URI
Red Hat Quay를 사용하면 필수 DB_URI 필드를 사용하여 데이터베이스에 대한 연결이 구성됩니다.
다음 표에서는 DB_URI 구성 필드에 대해 설명합니다.
표 3.1. 데이터베이스 URI
| 필드 | 유형 | 설명 |
|---|---|---|
|
DB_URI | 문자열 | 자격 증명을 포함하여 데이터베이스에 액세스하기 위한 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 | 부울 |
스레드 로컬 연결 사용 여부입니다. |
| .threadlocals | 부울 |
자동 롤백 연결을 사용할지 여부입니다. |
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/cacertMySQL의 유효한 연결 인수에 대한 정보는 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 .cert 및 ssl.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 인스턴스에서 구성 요소를 관리되지 않음으로 설정합니다.
필요한 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 구성 요소를 관리되지 않음으로 표시하고 생성된 보안을 참조하는 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- 레지스트리 배포
3.5.1.1. Redis 구성 필드
이 섹션에서는 Redis 배포에 사용 가능한 구성 필드에 대해 자세히 설명합니다.
3.5.1.1.1. 빌드 로그
Redis 배포에 다음 빌드 로그 구성 필드를 사용할 수 있습니다.
표 3.5. 빌드 로그 구성
| 필드 | 유형 | 설명 |
|---|---|---|
|
BUILDLOGS_REDIS | 개체 | 빌드 로그 캐싱에 대한 Redis 연결 세부 정보입니다. |
|
.host | 문자열 |
Redis에 액세스할 수 있는 호스트 이름 |
|
.port | 숫자 |
Redis에 액세스할 수 있는 포트입니다. |
| .password | 문자열 |
Redis에 액세스할 수 있는 포트입니다. |
|
.port | 숫자 |
Redis에 액세스할 수 있는 포트입니다. |
| ssl | 부울 | Redis와 Quay 간 TLS 통신을 활성화할지 여부입니다. 기본값은 false입니다. |
3.5.1.1.2. 사용자 이벤트
Redis 배포에 다음 사용자 이벤트 필드를 사용할 수 있습니다.
표 3.6. 사용자 이벤트 구성
| 필드 | 유형 | 설명 |
|---|---|---|
|
USER_SECRETENTS_REDIS | 개체 | 사용자 이벤트 처리에 대한 Redis 연결 세부 정보입니다. |
|
.host | 문자열 |
Redis에 액세스할 수 있는 호스트 이름 |
|
.port | 숫자 |
Redis에 액세스할 수 있는 포트입니다. |
| .password | 문자열 |
Redis에 액세스할 수 있는 포트입니다. |
| 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를 사용하고 ssl 이 true 로 설정된 경우 포트는 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: false3.5.3. 경로 구성 요소 비활성화
Operator가 경로 를 생성하지 못하도록 하려면 다음을 수행합니다.
QuayRegistry에서 구성 요소를 Unmanaged로 표시합니다.apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: components: - kind: route managed: falseconfig.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: false3.5.5. 관리되지 않는 미러링
미러링을 명시적으로 비활성화하려면 다음을 수행합니다.
apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
name: example-registry
namespace: quay-enterprise
spec:
components:
- kind: mirroring
managed: false4장. Quay Operator를 사용하여 Quay 배포
Operator는 명령줄 또는 OpenShift 콘솔에서 배포할 수 있지만 기본 단계는 동일합니다.
4.1. 명령줄에서 Red Hat Quay 배포
-
네임스페이스(예:
quay-enterprise)를 생성합니다. - 배포의 모든 측면을 사전 구성하려면 구성 번들에 대한 시크릿을 생성합니다.
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
프록시가 구성된 경우 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
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_INITIALIZE를true로 설정해야 합니다. - 데이터베이스에 이미 사용자가 있을 수 없습니다.
Red Hat Quay 배포 사전 구성에 대한 자세한 내용은 자동화를 위한 Red Hat Quay 사전 구성 섹션을참조하십시오.
4.1.3.1. API를 사용하여 첫 번째 사용자 생성
다음 절차에 따라 Red Hat Quay 조직에 첫 번째 사용자를 생성합니다.
이 절차에서는 "access_token": true 를 지정하여 OAuth 토큰을 요청합니다.
status.registryEndpointURL을 사용하여/api/v1/user/initializeAPI를 호출하고 다음 명령을 입력하여 사용자 이름, 암호 및 이메일 주소를 전달합니다.$ 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 배포
-
네임스페이스(예:
quay-enterprise)를 생성합니다. - Operator → 설치된 Operator를 선택한 다음 Operator 세부 정보 보기로 이동할 Quay Operator를 선택합니다.
- 'Provided APIs' 아래의 'Quay Registry' 타일에서 '인스턴스 생성'을 클릭합니다.
-
선택적으로
QuayRegistry의 'Name'을 변경합니다. 이는 레지스트리의 호스트 이름에 영향을 미칩니다. 다른 모든 필드는 기본값으로 채워집니다. -
'Create'를 클릭하여 Quay Operator가 배포할
QuayRegistry를 제출합니다. -
QuayRegistry목록 보기로 리디렉션되어야 합니다. 방금 만든QuayRegistry를 클릭하여 세부 정보 보기를 확인합니다. - 'Registry Endpoint'에 값이 있으면 클릭하여 UI를 통해 새 Quay 레지스트리에 액세스합니다. 이제 'Create Account'를 선택하여 사용자를 생성하고 로그인할 수 있습니다.
4.2.1. Quay UI를 사용하여 첫 번째 사용자 생성
이 절차에서는 FEATURE_USER_CREATION config 옵션이 false로 설정되지 않은 것으로 가정합니다. false 인 경우 UI에 대한 계정 생성 기능이 비활성화되며 API를 사용하여 첫 번째 사용자를 만들어야 합니다.
- OpenShift 콘솔에서 적절한 네임스페이스 / 프로젝트를 사용하여 Operator → 설치된 Operator로 이동합니다.
새로 설치된 QuayRegistry를 클릭하여 세부 정보를 확인합니다.
-
Registry Endpoint에 값이 있으면 브라우저에서 이 URL로 이동합니다. Quay 레지스트리 UI에서 'Create Account'를 선택하여 사용자를 생성합니다.
사용자 이름, 암호, 이메일에 대한 세부 정보를 입력하고
Create Account를 클릭합니다.
Quay 레지스트리에 자동으로 로그인되어 있습니다.
5장. OpenShift에서 Quay 구성
배포한 후 Quay 구성 번들 시크릿 spec.configBundleSecret 을 편집하여 Quay 애플리케이션을 구성할 수 있으며 QuayRegistry 리소스의 spec.components 오브젝트에서 구성 요소의 관리 상태를 변경할 수도 있습니다.
또는 6장. 구성 툴을 사용하여 OpenShift에서 Quay 재구성 섹션에 설명된 대로 구성 편집기 UI를 사용하여 Quay 애플리케이션을 구성할 수 있습니다.
5.1. OpenShift 콘솔에서 구성 번들 시크릿 편집
절차
Quay Registry 개요 화면에서 Config Bundle Secret에 대한 링크를 클릭합니다.
시크릿을 편집하려면 작업 → 시크릿 편집을 클릭합니다.
설정을 수정하고 변경 사항을 저장
- 배포를 모니터링하여 성공적으로 완료되고 구성 변경 사항이 적용되었는지 확인합니다.
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 편집기 툴의 암호가 포함된 시크릿
구성 편집기 도구의 사용자 이름과 암호를 확인하려면 다음을 수행합니다.
시크릿을 검색합니다.
$ oc get secret -n quay-enterprise example-registry-quay-config-editor-credentials-fg2gdgtm24 -o yaml apiVersion: v1 data: password: SkZwQkVKTUN0a1BUZmp4dA== username: cXVheWNvbmZpZw== kind: Secret
사용자 이름을 디코딩합니다.
$ echo 'cXVheWNvbmZpZw==' | base64 --decode quayconfig
암호를 디코딩합니다.
$ echo 'SkZwQkVKTUN0a1BUZmp4dA==' | base64 --decode JFpBEJMCtkPTfjxt
5.3. 기존 구성 다운로드
현재 구성에 액세스하는 방법은 여러 가지가 있습니다.
구성 편집기 끝점을 사용하여 구성 편집기의 사용자 이름과 암호를 지정합니다.
$ 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..." } }구성 번들 시크릿 사용
시크릿 데이터를 가져옵니다.
$ oc get secret -n quay-enterprise init-config-bundle-secret -o jsonpath='{.data}'샘플 출력
{ "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo=" }데이터를 디코딩합니다.
$ 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: tls 를 managed: 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. 구성 번들에 인증서 추가
절차
포함된 데이터를 사용하거나 파일을 사용하여 시크릿을 생성합니다.
다음과 같이 구성 세부 정보를 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
또는 원하는 정보가 포함된 파일을 생성한 다음 해당 파일에서 보안을 생성할 수 있습니다.
$ 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
생성된 보안을 참조하여 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
YAML 파일을 사용하여 레지스트리를 배포하거나 업데이트합니다.
oc apply -f quayregistry.yaml
6장. 구성 툴을 사용하여 OpenShift에서 Quay 재구성
6.1. config 편집기에 액세스
QuayRegistry 화면의 세부 정보 섹션에서 구성 편집기의 끝점과 구성 편집기에 로그인할 수 있는 인증 정보가 포함된 보안에 대한 링크도 사용할 수 있습니다.
6.1.1. 구성 편집기 인증 정보 검색
구성 편집기 보안 링크를 클릭합니다.
Secret details 화면의 Data 섹션에서
Reveal 값을클릭하여 구성 편집기에 로그인할 수 있는 인증 정보를 확인합니다.
6.1.2. 구성 편집기에 로그인
구성 편집기 끝점으로 이동한 다음 사용자 이름, 일반적으로 quayconfig 및 해당 암호를 입력하여 구성 툴에 액세스합니다.
6.1.3. 구성 변경
구성을 업데이트하는 이 예에서는 config 편집기 툴을 통해 슈퍼 유저가 추가됩니다.
시간 머신 기능에 대한 만료 기간(예:
4w)을 추가합니다.
-
구성 변경 사항 검증을선택하여 변경 사항이 유효한지 확인합니다. Reconfigure Quay버튼을 눌러 변경 사항을 적용합니다.
구성 툴에서 변경 사항이 Quay에 제출되었음을 알립니다.
구성 도구 UI를 사용하여 Red Hat Quay를 재구성하면 업데이트된 구성이 적용되는 동안 레지스트리를 단기간에 사용할 수 없게 될 수 있습니다.
6.2. UI의 재구성 모니터링
6.2.1. QuayRegistry 리소스
Operator를 재구성한 후 QuayRegistry의 특정 인스턴스에 대해 YAML 탭에서 재배포 진행 상황을 추적할 수 있습니다(이 경우 example-registry ):
상태가 변경될 때마다 데이터를 다시 로드하여 업데이트된 버전을 확인하라는 메시지가 표시됩니다. 결국 Operator는 변경 사항을 조정하고 비정상적인 구성 요소가 보고되지 않습니다.
6.2.2. 이벤트
QuayRegistry의 Events 탭에는 재배포와 관련된 일부 이벤트가 표시됩니다.
재구성의 영향을 받는 네임스페이스의 모든 리소스에 대한 스트리밍 이벤트는 홈 → 이벤트 아래의 OpenShift 콘솔에서 사용할 수 있습니다.
6.3. 재구성 후 업데이트된 정보에 액세스
6.3.1. UI에서 업데이트된 구성 툴 인증 정보에 액세스
Red Hat Quay 3.7을 사용하면 UI를 통해 Quay를 재구성해도 더 이상 새 로그인 암호가 생성되지 않습니다. 이제 암호는 한 번만 생성되며 QuayRegistry 오브젝트를 조정한 후 동일하게 유지됩니다.
6.3.2. UI에서 업데이트된 config.yaml에 액세스
config 번들을 사용하여 업데이트된 config.yaml 파일에 액세스합니다.
- QuayRegistry 세부 정보 화면에서 Config Bundle Secret을 클릭합니다.
-
Secret details 화면의 Data 섹션에서 Reveal 값을 클릭하여
config.yaml파일을 확인합니다. 변경 사항이 적용되었는지 확인합니다. 이 경우
4w는TAG_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 형식인지 확인합니다.
구성 툴에는 업로드된 인증서 목록도 표시됩니다. 사용자 정의 SSL 인증서를 업로드하면 목록에 표시됩니다.
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 레지스트리 인스턴스의 대시보드를 검색합니다.
대시보드에는 다음을 포함한 다양한 통계가 표시됩니다.
- 조직, 리포지토리, 사용자 및 iPXE 계정 수
- CPU 사용량 및 최대 메모리 사용량
- 이미지 가져오기 및 푸시 속도 및 인증 요청
- API 요청 속도
- 대기 시간
7.1.2. 메트릭
UI에서 모니터링 → 메트릭에 액세스하여 Quay 대시보드 뒤의 기본 메트릭을 확인할 수 있습니다. 표현식 필드에 텍스트 quay_ 를 입력하여 사용 가능한 지표 목록을 확인합니다.
샘플 메트릭을 선택합니다(예: quay_org_rows ).
이 메트릭은 레지스트리의 조직 수를 나타내며 대시보드에도 직접 표시됩니다.
7.1.3. 경고
Quay 포드가 너무 자주 다시 시작되면 경고가 발생합니다. consol UI의 Monitoring → Alerting에서 경고 규칙 탭에 액세스하고 Quay별 경고를 검색하여 경고를 구성할 수 있습니다.
QuayPod frequentlyRestarting 규칙 세부 정보를 선택하여 경고를 구성합니다.
7.2. Red Hat Quay용 Clair
Clair v4(Clair)는 이미지 콘텐츠를 구문 분석하고 콘텐츠에 영향을 미치는 취약점을 보고하는 정적 코드를 활용하는 오픈 소스 애플리케이션입니다. Clair는 Red Hat Quay와 함께 패키지되며 독립 실행형 및 Operator 배포에서 모두 사용할 수 있습니다. 엔터프라이즈 환경에 맞게 구성 요소를 별도로 확장할 수 있는 확장성이 높은 구성에서 실행할 수 있습니다.
7.2.1. Clair 취약점 데이터베이스
Clair는 다음 취약점 데이터베이스를 사용하여 이미지의 문제를 보고합니다.
- Ubuntu Oval 데이터베이스
- Debian Oval 데이터베이스
- Red Hat Enterprise Linux (RHEL) Oval 데이터베이스
- SUSE Oval 데이터베이스
- Oracle Oval 데이터베이스
- Alpine SecDB 데이터베이스
- VMware>-< OS 데이터베이스
- AWS(Amazon Web Services) UpdateInfo
- Pyup.io (Python) 데이터베이스
Clair가 다른 데이터베이스와 보안 매핑을 수행하는 방법에 대한 자세한 내용은 ClairCore 심각도 매핑 을 참조하십시오.
7.2.2. OpenShift Container Platform의 Clair
OpenShift Container Platform의 Red Hat Quay 배포에 Clair v4(Clair)를 설정하려면 Red Hat Quay Operator를 사용하는 것이 좋습니다. 기본적으로 Red Hat Quay Operator는 Red Hat Quay 배포와 함께 Clair 배포를 설치하거나 업그레이드하고 Clair를 자동으로 구성합니다.
7.2.3. Clair 테스트
다음 절차에 따라 독립 실행형 Red Hat Quay 배포 또는 OpenShift Container Platform Operator 기반 배포에서 Clair를 테스트합니다.
사전 요구 사항
- Clair 컨테이너 이미지를 배포했습니다.
절차
다음 명령을 입력하여 샘플 이미지를 가져옵니다.
$ podman pull ubuntu:20.04
다음 명령을 입력하여 레지스트리에 이미지를 태그합니다.
$ sudo podman tag docker.io/library/ubuntu:20.04 <quay-server.example.com>/<user-name>/ubuntu:20.04
다음 명령을 입력하여 Red Hat Quay 레지스트리로 이미지를 푸시합니다.
$ sudo podman push --tls-verify=false quay-server.example.com/quayadmin/ubuntu:20.04
- UI를 통해 Red Hat Quay 배포에 로그인합니다.
- 리포지토리 이름을 클릭합니다(예: quayadmin/ubuntu ).
탐색 창에서 태그 를 클릭합니다.
보고서 요약
이미지 보고서 (예: 45 중간 )를 클릭하여 자세한 보고서를 표시합니다.
보고서 세부 정보
7.3. 연방 정보 처리 표준 (FIPS) 준비 및 규정 준수
NIST (National-2019 of Standards and Technology)에서 개발한 FIPS (Federal Information Processing Standard)는 금융, 의료 및 대중 분야와 같이 매우 규제가 높은 영역에서 민감한 데이터를 보호하고 암호화하기 위한 것으로 평가되고 있습니다. RHEL(Red Hat Enterprise Linux) 및 OpenShift Container Platform은 FIPS 모드를 제공하여 FIPS 표준을 지원합니다. 이 모드에서는 openssl 과 같은 특정 FIPS 검증 암호화 모듈만 사용할 수 있습니다. 이렇게 하면 FIPS 규정 준수가 보장됩니다.
Red Hat Quay는 Red Hat Quay 버전 3.5.0의 FIPS 지원 RHEL 및 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. 클러스터 모니터링 구성 맵 생성
cluster-monitoring-configConfigMap 오브젝트가 있는지 확인합니다.$ oc -n openshift-monitoring get configmap cluster-monitoring-config Error from server (NotFound): configmaps "cluster-monitoring-config" not found
ConfigMap 오브젝트가 없는 경우:
다음 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: |
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. 사용자 정의 워크로드 모니터링 구성 맵 생성
user-workload-monitoring-configConfigMap 오브젝트가 있는지 확인합니다.$ oc -n openshift-user-workload-monitoring get configmap user-workload-monitoring-config Error from server (NotFound): configmaps "user-workload-monitoring-config" not found
ConfigMap 오브젝트가 없는 경우:
다음 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: |
ConfigMap 오브젝트를 생성합니다.
$ oc apply -f user-workload-monitoring-config.yaml configmap/user-workload-monitoring-config created
8.2.3. 사용자 정의 프로젝트에 대한 모니터링 활성화
사용자 정의 프로젝트에 대한 모니터링이 실행 중인지 확인합니다.
$ oc get pods -n openshift-user-workload-monitoring No resources found in openshift-user-workload-monitoring namespace.
cluster-monitoring-configConfigMap을 편집합니다.$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
클러스터에서 사용자 정의 프로젝트에 대한 모니터링을 활성화하려면
enableUserWorkload: true를 설정합니다.apiVersion: v1 data: config.yaml: | enableUserWorkload: true kind: ConfigMap metadata: annotations:파일을 저장하여 변경 사항을 적용한 다음 적절한 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 오브젝트 생성
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: ClusterIPService 오브젝트를 생성합니다.
$ oc apply -f quay-service.yaml service/example-registry-quay-metrics created
8.2.5. ServiceMonitor 오브젝트 생성
ServiceMonitor 리소스를 생성하여 지표를 스크랩하도록 OpenShift 모니터링을 구성합니다.
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: monitoringServiceMonitor를 생성합니다.
$ oc apply -f quay-service-monitor.yaml servicemonitor.monitoring.coreos.com/example-registry-quay-metrics-monitor created
8.2.6. OpenShift에서 메트릭 보기
모니터링 → 메트릭에서 OpenShift 콘솔의 메트릭에 액세스할 수 있습니다. 표현식 필드에 텍스트 quay_ 를 입력하여 사용 가능한 지표 목록을 확인합니다.
예를 들어 레지스트리에 사용자를 추가한 경우 quay-users_rows 지표를 선택합니다.
8.3. 관리 스토리지 크기 조정
Quay Operator는 NooBaa 오브젝트(50 Gib)를 생성할 때 RHOCS에서 제공하는 기본값을 사용하여 기본 오브젝트 스토리지를 생성합니다. 이 스토리지를 확장하는 방법에는 두 가지가 있습니다. 기존 PVC의 크기를 조정하거나 새 스토리지 풀에 PVC를 더 추가할 수 있습니다.
8.3.1. Noobaa PVC 크기 조정
-
OpenShift 콘솔에 로그인하고
스토리지→영구 볼륨 클레임을 선택합니다. -
noobaa-default-backing-store-noobaa-pvc-*와 같은PersistentVolumeClaim을 선택합니다. -
Action 메뉴에서
Expand PVC를 선택합니다. -
영구 볼륨 클레임의 새 크기를 입력하고
Expand를 선택합니다.
몇 분 후에 PVC 크기에 따라 확장된 크기는 PVC의 용량 필드에 반영되어야 합니다.
CSI 볼륨 확장은 기술 프리뷰 기능 전용입니다. 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html/storage/expanding-persistent-volumes 에서 참조하십시오.
8.3.2. 다른 스토리지 풀 추가
-
OpenShift 콘솔에 로그인하고
네트워킹→경로를 선택합니다.openshift-storage프로젝트가 선택되었는지 확인합니다. -
noobaa-mgmt경로의위치필드를 클릭합니다. - Noobaa 관리 콘솔에 로그인합니다.
-
기본 대시보드의
스토리지 리소스에서 스토리지 리소스추가를 선택합니다. -
Deploy Kubernetes Pool선택 -
새 풀 이름을 입력합니다.
다음을클릭합니다. -
풀을 관리하고 노드당 크기를 설정할 Pod 수를 선택합니다.
다음을클릭합니다. -
배포를
클릭합니다.
몇 분 후에 Noobaa 리소스에 추가 스토리지 풀이 추가되고 Red Hat Quay에서 사용할 수 있습니다.
8.4. 기본 Operator 이미지 사용자 정의
이 메커니즘 사용은 프로덕션 Quay 환경에서 지원되지 않으며 개발/테스트 목적으로만 권장됩니다. Quay Operator와 함께 기본이 아닌 이미지를 사용할 때 배포가 제대로 작동하는지 보장할 수 없습니다.
특정 상황에서는 Operator에서 사용하는 기본 이미지를 재정의하는 것이 유용할 수 있습니다. Quay Operator ClusterServiceVersion 에서 하나 이상의 환경 변수를 설정하여 이 작업을 수행할 수 있습니다.
8.4.1. 환경 변수
Operator에서 다음 환경 변수는 구성 요소 이미지를 재정의하는 데 사용됩니다.
| 환경 변수 | 구성 요소 |
|
|
|
|
|
|
|
|
|
|
|
|
덮어쓰기 이미지는 태그(: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.6. 고급 Clair 구성
다음 섹션의 절차를 사용하여 고급 Clair 설정을 구성합니다.
8.6.1. 관리되지 않는 Clair 구성
Red Hat Quay 사용자는 Red Hat Quay OpenShift Container Platform Operator를 사용하여 관리되지 않는 Clair 구성을 실행할 수 있습니다. 이 기능을 사용하면 관리되지 않는 Clair 데이터베이스를 생성하거나 관리되지 않는 데이터베이스 없이 사용자 지정 Clair 구성을 실행할 수 있습니다.
관리되지 않는 Clair 데이터베이스를 사용하면 Red Hat Quay Operator가 지역 복제 환경에서 작업할 수 있습니다. 여기서 Operator의 여러 인스턴스가 동일한 데이터베이스와 통신해야 합니다. 관리되지 않는 Clair 데이터베이스는 사용자에게 클러스터 외부에 존재하는 HA(고가용성) Clair 데이터베이스가 필요한 경우에도 사용할 수 있습니다.
8.6.1.1. 관리되지 않는 Clair 데이터베이스를 사용하여 사용자 정의 Clair 구성 실행
다음 절차에 따라 Clair 데이터베이스를 Unmanaged로 설정합니다.
절차
Quay Operator에서
QuayRegistry사용자 정의 리소스의clairpostgres구성 요소를managed: false로 설정합니다.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.6.1.2. 관리되지 않는 Clair 데이터베이스를 사용하여 사용자 정의 Clair 데이터베이스 구성
OpenShift Container Platform용 Red Hat Quay Operator를 사용하면 사용자가 자체 Clair 데이터베이스를 제공할 수 있습니다.
다음 절차에 따라 사용자 지정 Clair 데이터베이스를 생성합니다.
다음 절차에서는 SSL/TLS 인증을 사용하여 Clair를 설정합니다. SSL/TSL 인증을 사용하여 Clair를 설정하지 않는 유사한 프로세스를 보려면 "관리된 Clair 구성을 사용하여 사용자 지정 Clair 데이터베이스 구성"을 참조하십시오.
절차
다음 명령을 입력하여
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에서 확인할 수 있습니다.
-
데이터베이스 인증서는
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 구성 모듈을 사용하여 기본값으로 자동으로 채워집니다.빌드 기록 페이지에서 커밋을 클릭하거나
oc get pods -n <namespace>를 실행하여 Clair Pod의 상태를 확인할 수 있습니다. 예를 들면 다음과 같습니다.$ oc get pods -n <namespace>
출력 예
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Running 0 7s
8.6.2. 관리 Clair 데이터베이스를 사용하여 사용자 정의 Clair 구성 실행
경우에 따라 사용자가 관리 Clair 데이터베이스를 사용하여 사용자 지정 Clair 구성을 실행하려고 할 수 있습니다. 이는 다음 시나리오에서 유용합니다.
- 사용자가 특정 업데이트자 리소스를 비활성화하려는 경우
사용자가 연결이 끊긴 환경에서 Red Hat Quay를 실행하는 경우. 연결이 끊긴 환경에서 Clair를 실행하는 방법에 대한 자세한 내용은 Air-gapped OpenShift 클러스터에서 Clair 데이터베이스에 대한 액세스 구성을 참조하십시오.
참고-
연결이 끊긴 환경에서 Red Hat Quay를 실행하는 경우
clair-config.yaml의airgap매개변수를true로 설정해야 합니다. - 연결이 끊긴 환경에서 Red Hat Quay를 실행하는 경우 모든 업데이트 프로그램 구성 요소를 비활성화해야 합니다.
-
연결이 끊긴 환경에서 Red Hat Quay를 실행하는 경우
8.6.2.1. Clair 데이터베이스를 관리로 설정
다음 절차에 따라 Clair 데이터베이스를 managed로 설정합니다.
절차
Quay Operator에서
QuayRegistry사용자 정의 리소스의clairpostgres구성 요소를managed: true로 설정합니다.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: true
8.6.2.2. 관리 Clair 구성을 사용하여 사용자 정의 Clair 데이터베이스 구성
OpenShift Container Platform용 Red Hat Quay Operator를 사용하면 사용자가 자체 Clair 데이터베이스를 제공할 수 있습니다.
다음 절차에 따라 사용자 지정 Clair 데이터베이스를 생성합니다.
절차
다음 명령을 입력하여
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 config-bundle-secret
Clair
config.yaml파일 예indexer: connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslmode=disable 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 sslmode=disable migrations: true metrics: name: prometheus notifier: connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslmode=disable migrations: true참고-
데이터베이스 인증서는
clair-config.yaml의 Clair 애플리케이션 Pod의/run/certs/rds-ca-2019-root.pem에 마운트됩니다.clair-config.yaml을 구성할 때 지정해야 합니다. -
clair-config.yaml의 예는 OpenShift 구성의 Clair에서 확인할 수 있습니다.
-
데이터베이스 인증서는
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>
참고-
업데이트되면 제공된
clair-config.yaml파일이 Clair 포드에 마운트됩니다. 제공되지 않는 모든 필드는 Clair 구성 모듈을 사용하여 기본값으로 자동으로 채워집니다.
-
업데이트되면 제공된
빌드 기록 페이지에서 커밋을 클릭하거나
oc get pods -n <namespace>를 실행하여 Clair Pod의 상태를 확인할 수 있습니다. 예를 들면 다음과 같습니다.$ oc get pods -n <namespace>
출력 예
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Running 0 7s
8.6.3. 연결이 끊긴 환경의 Clair
Clair는 updaters 라는 구성 요소 집합을 사용하여 다양한 취약점 데이터베이스에서 데이터 가져오기 및 구문 분석을 처리합니다. 업데이트자는 기본적으로 인터넷에서 직접 취약점 데이터를 가져오고 즉시 사용할 수 있도록 설정되어 있습니다. 그러나 일부 사용자는 Red Hat Quay가 연결이 끊긴 환경에서 실행하거나 인터넷에 직접 액세스하지 않고 환경에서 실행해야 할 수 있습니다. Clair는 네트워크 격리를 고려하는 다양한 유형의 업데이트 워크플로우로 작업하여 연결이 끊긴 환경을 지원합니다. 이는 오픈 호스트를 사용하여 인터넷에서 업데이트자 데이터를 가져오고, 격리된 호스트로 안전하게 데이터를 전송한 다음, 분리된 호스트의 업데이트자 데이터를 Clair에 중요한 방식으로 사용하여 clairctl 명령줄 인터페이스 툴을 사용하여 작동합니다.
이 가이드를 사용하여 연결이 끊긴 환경에 Clair를 배포합니다.
현재 Clair 보강 데이터는 CVSS 데이터입니다. 보강 데이터는 현재 연결이 끊긴 환경에서 지원되지 않습니다.
Clair 업데이트기에 대한 자세한 내용은 "Clair updaters"를 참조하십시오.
8.6.3.1. 연결이 끊긴 OpenShift Container Platform 클러스터에서 Clair 설정
다음 절차에 따라 연결이 끊긴 OpenShift Container Platform 클러스터에서 OpenShift Container Platform 프로비저닝된 Clair Pod를 설정합니다.
8.6.3.1.1. OpenShift Container Platform 배포를 위한 clairctl 명령줄 유틸리티 툴 설치
다음 절차에 따라 OpenShift Container Platform 배포를 위한 clairctl CLI 툴을 설치합니다.
절차
다음 명령을 입력하여 OpenShift Container Platform 클러스터에서 Clair 배포에 대한
clairctl프로그램을 설치합니다.$ oc -n quay-enterprise exec example-registry-clair-app-64dd48f866-6ptgw -- cat /usr/bin/clairctl > clairctl
참고비공식적으로
clairctl툴을 다운로드할 수 있습니다.사용자가 실행하고 실행할 수 있도록
clairctl파일의 권한을 설정합니다. 예를 들면 다음과 같습니다.$ chmod u+x ./clairctl
8.6.3.1.2. OpenShift Container Platform에서 Clair 배포에 대한 Clair 구성 시크릿 검색 및 디코딩
다음 절차에 따라 OpenShift Container Platform에서 프로비저닝된 Clair 인스턴스의 구성 시크릿을 검색하고 디코딩합니다.
사전 요구 사항
-
clairctl명령줄 유틸리티 도구를 설치했습니다.
절차
다음 명령을 입력하여 구성 시크릿을 검색하고 디코딩한 다음 Clair 구성 YAML에 저장합니다.
$ oc get secret -n quay-enterprise example-registry-clair-config-secret -o "jsonpath={$.data['config\.yaml']}" | base64 -d > clair-config.yamldisable_updaters및airgap매개변수가true로 설정되도록clair-config.yaml파일을 업데이트합니다. 예를 들면 다음과 같습니다.--- indexer: airgap: true --- matcher: disable_updaters: true ---
8.6.3.1.3. 연결된 Clair 인스턴스에서 업데이트 번들 내보내기
다음 절차에 따라 인터넷에 액세스할 수 있는 Clair 인스턴스에서 업데이트 프로그램 번들을 내보냅니다.
사전 요구 사항
-
clairctl명령줄 유틸리티 도구를 설치했습니다. -
Clair 구성 시크릿을 검색하고 디코딩하여 Clair
config.yaml파일에 저장했습니다. -
Clair
config.yaml파일에서disable_updaters및airgap매개 변수가true로 설정됩니다.
절차
인터넷에 액세스할 수 있는 Clair 인스턴스에서
clairctlCLI 툴을 구성 파일과 함께 사용하여 업데이트 프로그램 번들을 내보냅니다. 예를 들면 다음과 같습니다.$ ./clairctl --config ./config.yaml export-updaters updates.gz
8.6.3.1.4. 연결이 끊긴 OpenShift Container Platform 클러스터에서 Clair 데이터베이스에 대한 액세스 구성
연결 해제된 OpenShift Container Platform 클러스터의 Clair 데이터베이스에 대한 액세스를 구성하려면 다음 절차를 사용하십시오.
사전 요구 사항
-
clairctl명령줄 유틸리티 도구를 설치했습니다. -
Clair 구성 시크릿을 검색하고 디코딩하여 Clair
config.yaml파일에 저장했습니다. -
Clair
config.yaml파일에서disable_updaters및airgap매개 변수가true로 설정됩니다. - 인터넷에 액세스할 수 있는 Clair 인스턴스에서 업데이트 프로그램 번들을 내보내고 있습니다.
절차
ocCLI 툴을 사용하여 Clair 데이터베이스 서비스를 확인합니다. 예를 들면 다음과 같습니다.$ oc 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 데이터베이스 포트를 전달합니다. 예를 들면 다음과 같습니다.
$ oc port-forward -n quay-enterprise service/example-registry-clair-postgres 5432:5432
Clair
config.yaml파일을 업데이트합니다. 예를 들면 다음과 같습니다.indexer: connstring: host=localhost port=5432 dbname=postgres user=postgres password=postgres sslmode=disable 1 scanlock_retry: 10 layer_scan_concurrency: 5 migrations: true scanner: repo: rhel-repository-scanner: 2 repo2cpe_mapping_file: /data/cpe-map.json package: rhel_containerscanner: 3 name2repos_mapping_file: /data/repo-map.json
8.6.3.1.5. 연결이 끊긴 OpenShift Container Platform 클러스터로 업데이트됨 번들 가져오기
다음 절차에 따라 업데이트 프로그램 번들을 연결이 끊긴 OpenShift Container Platform 클러스터로 가져옵니다.
사전 요구 사항
-
clairctl명령줄 유틸리티 도구를 설치했습니다. -
Clair 구성 시크릿을 검색하고 디코딩하여 Clair
config.yaml파일에 저장했습니다. -
Clair
config.yaml파일에서disable_updaters및airgap매개 변수가true로 설정됩니다. - 인터넷에 액세스할 수 있는 Clair 인스턴스에서 업데이트 프로그램 번들을 내보내고 있습니다.
- 업데이트기 번들을 연결이 끊긴 환경으로 전송했습니다.
절차
clairctlCLI 툴을 사용하여 업데이트기 번들을 OpenShift Container Platform에서 배포한 Clair 데이터베이스로 가져옵니다. 예를 들면 다음과 같습니다.$ ./clairctl --config ./clair-config.yaml import-updaters updates.gz
8.6.3.2. 연결이 끊긴 OpenShift Container Platform 클러스터에 대해 Clair 자체 관리 배포 설정
다음 절차에 따라 연결이 끊긴 OpenShift Container Platform 클러스터에 대한 자체 관리 배포를 설정합니다.
8.6.3.2.1. OpenShift Container Platform에서 자체 관리 Clair 배포에 대한 clairctl 명령줄 유틸리티 툴 설치
OpenShift Container Platform에 자체 관리 Clair 배포를 위해 clairctl CLI 툴을 설치하려면 다음 절차를 사용하십시오.
절차
podman cp명령을 사용하여 자체 관리 Clair 배포에 대한clairctl프로그램을 설치합니다. 예를 들면 다음과 같습니다.$ sudo podman cp clairv4:/usr/bin/clairctl ./clairctl
사용자가 실행하고 실행할 수 있도록
clairctl파일의 권한을 설정합니다. 예를 들면 다음과 같습니다.$ chmod u+x ./clairctl
8.6.3.2.2. 연결이 끊긴 OpenShift Container Platform 클러스터에 대해 자체 관리 Clair 컨테이너 배포
연결이 끊긴 OpenShift Container Platform 클러스터에 대해 자체 관리 Clair 컨테이너를 배포하려면 다음 절차를 사용하십시오.
사전 요구 사항
-
clairctl명령줄 유틸리티 도구를 설치했습니다.
절차
Clair 구성 파일의 폴더를 생성합니다. 예를 들면 다음과 같습니다.
$ mkdir /etc/clairv4/config/
disable_updaters매개변수를true로 설정하여 Clair 구성 파일을 생성합니다. 예를 들면 다음과 같습니다.--- indexer: airgap: true --- matcher: disable_updaters: true ---
컨테이너 이미지를 사용하여 Clair를 시작하고 생성한 파일에서 구성에 마운트합니다.
$ sudo podman run -it --rm --name clairv4 \ -p 8081:8081 -p 8088:8088 \ -e CLAIR_CONF=/clair/config.yaml \ -e CLAIR_MODE=combo \ -v /etc/clairv4/config:/clair:Z \ registry.redhat.io/quay/clair-rhel8:v3.8.5
8.6.3.2.3. 연결된 Clair 인스턴스에서 업데이트 번들 내보내기
다음 절차에 따라 인터넷에 액세스할 수 있는 Clair 인스턴스에서 업데이트 프로그램 번들을 내보냅니다.
사전 요구 사항
-
clairctl명령줄 유틸리티 도구를 설치했습니다. - Clair를 배포했습니다.
-
Clair
config.yaml파일에서disable_updaters및airgap매개 변수가true로 설정됩니다.
절차
인터넷에 액세스할 수 있는 Clair 인스턴스에서
clairctlCLI 툴을 구성 파일과 함께 사용하여 업데이트 프로그램 번들을 내보냅니다. 예를 들면 다음과 같습니다.$ ./clairctl --config ./config.yaml export-updaters updates.gz
8.6.3.2.4. 연결이 끊긴 OpenShift Container Platform 클러스터에서 Clair 데이터베이스에 대한 액세스 구성
연결 해제된 OpenShift Container Platform 클러스터의 Clair 데이터베이스에 대한 액세스를 구성하려면 다음 절차를 사용하십시오.
사전 요구 사항
-
clairctl명령줄 유틸리티 도구를 설치했습니다. - Clair를 배포했습니다.
-
Clair
config.yaml파일에서disable_updaters및airgap매개 변수가true로 설정됩니다. - 인터넷에 액세스할 수 있는 Clair 인스턴스에서 업데이트 프로그램 번들을 내보내고 있습니다.
절차
ocCLI 툴을 사용하여 Clair 데이터베이스 서비스를 확인합니다. 예를 들면 다음과 같습니다.$ oc 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 데이터베이스 포트를 전달합니다. 예를 들면 다음과 같습니다.
$ oc port-forward -n quay-enterprise service/example-registry-clair-postgres 5432:5432
Clair
config.yaml파일을 업데이트합니다. 예를 들면 다음과 같습니다.indexer: connstring: host=localhost port=5432 dbname=postgres user=postgres password=postgres sslmode=disable 1 scanlock_retry: 10 layer_scan_concurrency: 5 migrations: true scanner: repo: rhel-repository-scanner: 2 repo2cpe_mapping_file: /data/cpe-map.json package: rhel_containerscanner: 3 name2repos_mapping_file: /data/repo-map.json
8.6.3.2.5. 연결이 끊긴 OpenShift Container Platform 클러스터로 업데이트됨 번들 가져오기
다음 절차에 따라 업데이트 프로그램 번들을 연결이 끊긴 OpenShift Container Platform 클러스터로 가져옵니다.
사전 요구 사항
-
clairctl명령줄 유틸리티 도구를 설치했습니다. - Clair를 배포했습니다.
-
Clair
config.yaml파일에서disable_updaters및airgap매개 변수가true로 설정됩니다. - 인터넷에 액세스할 수 있는 Clair 인스턴스에서 업데이트 프로그램 번들을 내보내고 있습니다.
- 업데이트기 번들을 연결이 끊긴 환경으로 전송했습니다.
절차
clairctlCLI 툴을 사용하여 업데이트기 번들을 OpenShift Container Platform에서 배포한 Clair 데이터베이스로 가져옵니다.$ ./clairctl --config ./clair-config.yaml import-updaters updates.gz
8.6.4. Clair CRDA 활성화
Java 스캔은 공개에 따라 달라집니다. Red Hat은 CRDA(Code Ready Dependency Analytics)라는 API 서비스를 제공합니다. CRDA는 인터넷 액세스에서만 사용할 수 있으며 기본적으로 활성화되어 있지 않습니다.
다음 절차에 따라 CRDA 서비스를 사용자 정의 API 키와 통합하고 Java 및 Python 스캔용 CRDA를 활성화합니다.
사전 요구 사항
- Red Hat Quay 3.7 이상
절차
- API 키 요청 양식을 제출하여 Quay별 CRDA 원격 일치자를 가져옵니다.
clair-config.yaml파일에서 CRDA 구성을 설정합니다.matchers: config: crda: url: https://gw.api.openshift.io/api/v2/ key: <CRDA_API_KEY> 1 source: <QUAY_SERVER_HOSTNAME> 2- 1
- 여기에 API 키 요청 양식에서 Quay별 CRDA 원격 일치자를 삽입합니다.
- 2
- Quay 서버의 호스트 이름입니다.
8.6.5. 리포지토리를 Common Product Enumeration 정보로 매핑
Clair의 RHEL(Red Hat Enterprise Linux) 스캐너는 CVSS(Common Product Enumeration) 파일을 사용하여 RPM 패키지를 해당 보안 데이터에 매핑하여 일치하는 결과를 생성합니다. 이러한 파일은 제품 보안에 의해 소유하고 매일 업데이트됩니다.
스캐너가 RPM 패키지를 올바르게 처리하려면 CPE 파일이 있거나 파일에 액세스할 수 있어야 합니다. 파일이 없으면 컨테이너 이미지에 설치된 RPM 패키지를 스캔하지 않습니다.
표 8.1. Clair CPE 매핑 파일
| CPE | JSON 매핑 파일에 연결 |
|---|---|
|
| |
|
|
Clair 연결이 끊긴 설치의 데이터베이스에 CVE 정보를 업로드하는 것 외에도 매핑 파일을 로컬에서 사용할 수 있도록 해야 합니다.
- 독립 실행형 Red Hat Quay 및 Clair 배포의 경우 매핑 파일을 Clair 포드에 로드해야 합니다.
-
OpenShift Container Platform 및 Clair 배포에 Red Hat Quay Operator 배포의 경우 Clair 구성 요소를
unamanged로 설정해야 합니다. 그런 다음 Clair를 수동으로 배포하여 매핑 파일의 로컬 복사본을 로드하도록 구성을 설정해야 합니다.
8.6.5.1. Common Product Enumeration 예제 구성에 리포지토리 매핑
Clair 구성에서 repo2cpe_mapping_file 및 name2repos_mapping_file 필드를 사용하여 CPE JSON 매핑 파일을 포함합니다. 예를 들면 다음과 같습니다.
indexer:
scanner:
repo:
rhel-repository-scanner:
repo2cpe_mapping_file: /data/cpe-map.json
package:
rhel_containerscanner:
name2repos_mapping_file: /data/repo-map.json자세한 내용은 How to accurately match OVAL security data to installed RPMs 에서 참조하십시오.
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의 향상된 빌드 아키텍처
위 이미지는 향상된 빌드 기능의 예상 설계 흐름 및 아키텍처를 보여줍니다.
이번 개선된 기능을 통해 빌드 관리자는 먼저 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 Container Platform을 사용하여 Red Hat Quay 빌더 환경 생성
이 섹션의 절차에서는 OpenShift Container Platform을 사용하여 Red Hat Quay 가상 빌더 환경을 생성하는 방법을 설명합니다.
9.3.1. OpenShift Container Platform TLS 구성 요소
tls 구성 요소를 사용하면 TLS 구성을 제어할 수 있습니다.
Operator에서 TLS 구성 요소를 관리하는 경우 Red Hat Quay 3는 빌더를 지원하지 않습니다.
tls 를 관리되지 않는 ssl.cert 및 ssl.key 파일을 제공합니다. 이 경우 클러스터가 빌더를 지원하도록 하려면 인증서의 SAN 목록에 Quay 경로와 빌더 경로 이름을 모두 추가하거나 와일드카드를 사용해야 합니다.
빌더 경로를 추가하려면 다음 형식을 사용합니다.
[quayregistry-cr-name]-quay-builder-[ocp-namespace].[ocp-domain-name]:443
9.3.2. Red Hat Quay 빌더에 OpenShift Container Platform 사용
빌더에는 SSL/TLS 인증서가 필요합니다. SSL/TLS 인증서에 대한 자세한 내용은 Red Hat Quay 컨테이너에 TLS 인증서 추가를 참조하십시오.
AWS(Amazon Web Service) S3 스토리지를 사용하는 경우 빌더를 실행하기 전에 AWS 콘솔에서 스토리지 버킷을 수정해야 합니다. 필수 매개변수는 다음 섹션의 "AWS S3 스토리지 버킷 수정"을 참조하십시오.
9.3.2.1. 가상 빌더를 위한 OpenShift Container Platform 준비
다음 절차에 따라 Red Hat Quay 가상 빌더에 OpenShift Container Platform을 준비합니다.
- 이 절차에서는 클러스터가 이미 프로비저닝되어 Quay Operator가 실행되고 있다고 가정합니다.
- 다음 절차에서는 OpenShift Container Platform에서 가상 네임스페이스를 설정하는 데 사용됩니다.
절차
- 클러스터 관리자 계정을 사용하여 Red Hat Quay 클러스터에 로그인합니다.
다음 명령을 실행하여 가상 빌더가 실행될 새 프로젝트를 생성합니다(예:
virtual-builders).$ oc new-project virtual-builders
다음 명령을 입력하여 빌드를 실행하는 데 사용할 프로젝트에
ServiceAccount를 생성합니다.$ oc create sa -n virtual-builders quay-builder
빌드를 실행할 수 있도록 편집 권한이 생성된 서비스 계정을 제공합니다.
$ oc adm policy -n virtual-builders add-role-to-user edit system:serviceaccount:virtual-builders:quay-builder
다음 명령을 입력하여 Quay 빌더
anyuid scc권한을 부여합니다.$ oc adm policy -n virtual-builders add-scc-to-user anyuid -z quay-builder
참고이 작업을 수행하려면 클러스터 관리자 권한이 필요합니다. 이는 권한이 없거나 rootless 빌드가 작동하려면 빌더를 Podman 사용자로 실행해야 하므로 필요합니다.
Quay 빌더 서비스 계정의 토큰을 가져옵니다.
OpenShift Container Platform 4.10 또는 이전 버전을 사용하는 경우 다음 명령을 입력합니다.
oc sa get-token -n virtual-builders quay-builder
OpenShift Container Platform 4.11 이상을 사용하는 경우 다음 명령을 입력합니다.
$ oc create token quay-builder -n virtual-builders
출력 예
eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ...
다음 명령을 입력하여 빌더 경로를 결정합니다.
$ 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 ...
다음 명령을 입력하여 .crt 확장을 사용하여 자체 서명된 SSL/TlS 인증서를 생성합니다.
$ oc extract cm/kube-root-ca.crt -n openshift-apiserver
출력 예
ca.crt
다음 명령을 입력하여
ca.crt파일의 이름을extra_ca_cert_build_cluster.crt로 변경합니다.$ mv ca.crt extra_ca_cert_build_cluster.crt
콘솔에서 구성 번들의 시크릿을 찾고 작업 → 시크릿 편집 을 선택하고 적절한 빌더 구성을 추가합니다.
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
- 빌드 경로는
oc get route -n을 OpenShift Operator의 네임스페이스 이름으로 실행하여 가져옵니다. 포트는 경로 마지막에 제공되어야 하며[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/TLS 인증서가 있는 경우 적절하게 업데이트해야 합니다.
- 4
- 가상 빌더 네임스페이스의 이름과 일치하도록 설정합니다(예:
virtual-builders). - 5
- 초기 액세스의 경우
BUILDER_CONTAINER_IMAGE는 현재quay.io/projectquay/quay-builder:3.7.0-rc.2입니다. 초기 액세스 기간 동안 변경될 수 있습니다. 이 경우 고객에게 경고를 발행합니다. - 6
K8S_API_SERVER는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/TLS 인증서 추가
구성 도구의 알려진 문제로 인해 빌더를 올바르게 실행하려면 사용자 정의 SSL/TLS 인증서를 수동으로 추가해야 합니다. 사용자 정의 SSL/TLS 인증서를 수동으로 추가하려면 다음 절차를 사용하십시오.
SSL/TLS 인증서를 생성하는 방법에 대한 자세한 내용은 Red Hat Quay 컨테이너에 TLS 인증서 추가를 참조하십시오.
9.3.2.2.1. 인증서 생성 및 서명
다음 절차에 따라 SSL/TLS 인증서를 생성하고 서명하십시오.
절차
인증 기관을 생성하고 인증서에 서명합니다. 자세한 내용은 인증 기관 생성 및 인증서에 서명을 참조하십시오.
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 1 DNS.2 = example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org 2
샘플 명령
$ 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를 관리되지 않음으로 설정
다음 절차에 따라 gren :tls 를 Unmanaged로 설정합니다.
절차
Red Hat Quay Registry YAML에서
kind: tls를managed: false로 설정합니다.- kind: tls managed: false이벤트 페이지에서 적절한
config.yaml파일을 설정할 때까지 변경이 차단됩니다. 예를 들면 다음과 같습니다.- 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. 임시 보안 생성
다음 절차에 따라 CA 인증서에 대한 임시 보안을 생성합니다.
절차
CA 인증서의 기본 네임스페이스에 보안을 생성합니다.
$ oc create secret generic -n quay-enterprise temp-crt --from-file extra_ca_cert_build_cluster.crt
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. 구성 YAML에 시크릿 데이터 복사
다음 절차에 따라 시크릿 데이터를 config.yaml 파일에 복사합니다.
절차
- 워크로드 → 시크릿의 콘솔 UI에서 새 보안을 찾습니다.
각 시크릿에 대해 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: Opaquekind: 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다음과 같이 명령을 실행하여 UI에서 Red Hat Quay 레지스트리 구성 번들의 시크릿을 또는 명령줄을 통해 찾습니다.
$ oc get quayregistries.quay.redhat.com -o jsonpath="{.items[0].spec.configBundleSecret}{'\n'}" -n quay-enterpriseOpenShift Container Platform 콘솔에서 구성 번들 시크릿의 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- 저장을 클릭합니다.
다음 명령을 입력하여 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
Red Hat Quay 레지스트리가 재구성된 후 다음 명령을 입력하여 Red Hat Quay 앱 Pod가 실행 중인지 확인합니다.
$ 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
브라우저에서 레지스트리 끝점에 액세스하여 인증서가 적절하게 업데이트되었는지 확인합니다. 예를 들면 다음과 같습니다.
Common Name (CN) example-registry-quay-quay-enterprise.apps.docs.quayteam.org Organisation (O) DOCS Organisational Unit (OU) QUAY
9.3.2.3. UI를 사용하여 빌드 트리거 생성
다음 절차에 따라 UI를 사용하여 빌드 트리거를 생성합니다.
절차
- Red Hat Quay 리포지토리에 로그인합니다.
-
Create New Repository 를 클릭하고 새 레지스트리(예:
testrepo)를 생성합니다. Repositories (리포지토리) 페이지의 탐색 창에서 Builds 탭을 클릭합니다. 또는 해당 URL을 직접 사용합니다.
https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/repository/quayadmin/testrepo?tab=builds
중요경우에 따라 빌더에 호스트 이름을 확인하는 데 문제가 있을 수 있습니다. 이 문제는 작업 오브젝트에 대해
dnsPolicy가default로 설정되는 것과 관련이 있을 수 있습니다. 현재 이 문제에 대한 해결방법이 없습니다. 이 문제는 향후 Red Hat Quay 버전에서 해결될 예정입니다.- 빌드 트리거 생성 → 사용자 지정 Git 리포지토리 내보내기를 클릭합니다.
Git 리포지토리를 복제하는 데 사용되는 HTTPS 또는 SSH 스타일 URL을 입력한 다음 Continue 를 클릭합니다. 예를 들면 다음과 같습니다.
https://github.com/gabriel-rh/actions_test.git
- 분기 또는 태그 이름으로 태그 매니페스트를 확인한 다음 Continue 를 클릭합니다.
-
트리거를 호출할 때 빌드할 Dockerfile의 위치를 입력하고(예:
/Dockerfile) 계속 을 클릭합니다. -
Docker 빌드에 대한 컨텍스트 위치(예:
/)를 입력하고 Continue 를 클릭합니다. - 필요한 경우 WebSocket 계정을 만듭니다. 그렇지 않으면 Continue 를 클릭합니다.
- Continue 를 클릭하여 매개 변수를 확인합니다.
- 빌드 페이지에서 트리거 이름의 옵션 아이콘을 클릭한 다음 지금 트리거 실행을 클릭합니다.
- Git 리포지토리에서 커밋 SHA를 입력하고 Start Build 를 클릭합니다.
빌드 기록 페이지에서 커밋을 클릭하거나
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.
빌드가 완료되면 탐색 창에서 태그 아래에 있는 태그의 상태를 확인할 수 있습니다.
참고초기 액세스 권한을 사용하면 현재 전체 빌드 로그 및 빌드 타임 스탬프를 사용할 수 없습니다.
9.3.2.4. AWS S3 스토리지 버킷 수정
AWS S3 스토리지를 사용하는 경우 빌더를 실행하기 전에 AWS 콘솔에서 스토리지 버킷을 변경해야 합니다.
절차
- s3.console.aws.com 에서 AWS 콘솔에 로그인합니다.
-
검색 창에서 S3 을 검색한 다음
S3을 클릭합니다. -
버킷 이름을 클릭합니다(예:
myawsbucket). - 권한 탭을 클릭합니다.
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 기능
- 지역 복제가 구성되면 컨테이너 이미지 푸시가 해당 Red Hat Quay 인스턴스의 기본 스토리지 엔진에 작성됩니다. 일반적으로 리전 내에서 가장 가까운 스토리지 백엔드입니다.
- 초기 푸시 후 이미지 데이터는 백그라운드에서 다른 스토리지 엔진에 복제됩니다.
- 복제 위치 목록은 구성 가능하며 다른 스토리지 백엔드일 수 있습니다.
- 이미지 풀은 항상 사용 가능한 가장 가까운 스토리지 엔진을 사용하여 가져오기 성능을 극대화합니다.
- 복제가 완료되지 않은 경우 pull은 대신 소스 스토리지 백엔드를 사용합니다.
10.2. 지역 복제 요구 사항 및 제약 조건
- Geo-replicated 설정에서 Red Hat Quay는 다른 모든 리전의 개체 스토리지를 읽고 쓸 수 있어야 합니다. 오브젝트 스토리지는 다른 모든 리전에서 지리적으로 액세스할 수 있어야 합니다.
- 하나의 geo-replicating 사이트의 오브젝트 스토리지 시스템에 오류가 발생하는 경우 해당 사이트의 Red Hat Quay 배포를 종료해야 합니다. 클라이언트가 글로벌 로드 밸런서에 의해 손상되지 않은 스토리지 시스템을 사용하여 나머지 사이트로 리디렉션되도록 해당 사이트의 Red Hat Quay 배포를 종료해야 합니다. 그렇지 않으면 클라이언트가 풀 및 푸시 오류를 경험하게 됩니다.
- Red Hat Quay는 연결된 오브젝트 스토리지 시스템의 상태 또는 가용성에 대한 내부적인 인식이 없습니다. 한 사이트의 오브젝트 스토리지 시스템을 사용할 수 없게 되면 나머지 사이트 또는 사이트 중 나머지 스토리지 시스템 또는 시스템으로 자동 리디렉션되지 않습니다.
- Geo-replication은 비동기식입니다. 사이트를 영구적으로 손실하면 해당 사이트의 개체 스토리지 시스템에 저장된 데이터가 손실되지만 실패 시 아직 남아 있는 사이트로 복제되지 않았습니다.
단일 데이터베이스이므로 모든 메타데이터 및 Red Hat Quay 구성이 모든 리전에서 공유됩니다.
Geo-replication은 데이터베이스를 복제하지 않습니다. 중단이 발생하면 geo-replication이 활성화된 Red Hat Quay는 다른 데이터베이스로 장애 조치되지 않습니다.
- 단일 Redis 캐시는 전체 Red Hat Quay 설정에서 공유되며 모든 Red Hat Quay Pod에서 액세스할 수 있어야 합니다.
-
QUAY_DISTRIBUTED_STORAGE_PREFERENCE환경 변수를 사용하여 명시적으로 구성할 수 있는 스토리지 백엔드를 제외하고 모든 리전에서 정확히 동일한 구성을 사용해야 합니다. - Geo-replication에는 각 리전의 오브젝트 스토리지가 필요합니다. 로컬 스토리지에서는 작동하지 않습니다.
- 각 리전은 네트워크 경로가 필요한 각 리전의 모든 스토리지 엔진에 액세스할 수 있어야 합니다.
- 또는 스토리지 프록시 옵션을 사용할 수 있습니다.
- 전체 스토리지 백엔드(예: 모든 Blob)가 복제됩니다. 반면 저장소 미러링은 조직, 리포지토리 또는 이미지로 제한될 수 있습니다.
- 모든 Red Hat Quay 인스턴스는 일반적으로 로드 밸런서를 통해 동일한 진입점을 공유해야 합니다.
- 모든 Red Hat Quay 인스턴스에는 공통 구성 파일 내에 정의되어 있으므로 동일한 슈퍼 유저 세트가 있어야 합니다.
-
Geo-replication을 사용하려면 Clair 구성을
관리되지 않음으로 설정해야 합니다. 관리되지 않는 Clair 데이터베이스를 사용하면 Red Hat Quay Operator의 여러 인스턴스가 동일한 데이터베이스와 통신해야 하는 지역 복제 환경에서 Red Hat Quay Operator가 작동할 수 있습니다. 자세한 내용은 Advanced Clair 구성을 참조하십시오. - Geo-Replication에는 SSL/TSL 인증서와 키가 필요합니다. 자세한 내용은 Using SSL/TSL to protect connections to Red Hat Quay 를 참조하십시오.
위의 요구 사항을 충족할 수 없는 경우 대신 두 개 이상의 개별 Red Hat Quay 배포를 사용하고 저장소 미러링 기능을 사용해야 합니다.
10.3. Red Hat Quay Operator를 사용하여 geo-replication
위에 표시된 예제에서 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에서 지역 복제 설정
절차
Quay postgres 인스턴스를 배포합니다.
- 데이터베이스에 로그인
Quay의 데이터베이스 생성
CREATE DATABASE quay;
데이터베이스 내에서 pg_trm 확장을 활성화합니다.
\c quay; CREATE EXTENSION IF NOT EXISTS pg_trgm;
Redis 인스턴스를 배포합니다.
참고- 클라우드 공급자에 자체 서비스가 있는 경우 Redis 인스턴스를 배포할 필요가 없습니다.
- 빌더를 활용하는 경우 Redis 인스턴스를 배포해야 합니다.
- Redis의 VM 배포
- Quay가 실행 중인 클러스터에서 액세스할 수 있는지 확인합니다.
- 6379/TCP 포트가 열려 있어야 합니다.
인스턴스 내에서 Redis 실행
sudo dnf install -y podman podman run -d --name redis -p 6379:6379 redis
각 클러스터에 하나씩 두 개의 오브젝트 스토리지 백엔드 생성
이상적으로 하나의 오브젝트 스토리지 버킷은 1차 클러스터(기본)에 근접하고 다른 오브젝트 스토리지 버킷은 2차 클러스터(초)에 더 가깝게 실행됩니다.
- 환경 변수 덮어쓰기를 사용하여 동일한 구성 번들이 있는 클러스터를 배포하여 개별 클러스터에 적합한 스토리지 백엔드를 선택합니다.
- 클러스터에 단일 진입점을 제공하도록 로드 밸런서 구성
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 스토리지를 사용하고 온프레미스에서 Ceph 스토리지를 사용하는 등). 이를 통해 모든 Red Hat Quay 포드 및 클러스터 노드의 모든 스토리지 백엔드에 대한 액세스 권한을 부여하는 주요 요구 사항이 복잡해집니다. 따라서 다음을 사용하는 것이 좋습니다.
- 내부 스토리지의 가시성을 방지하기 위한 VPN, 또는
- Red Hat 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 배포 (상태 조건
Availableis set totrue) -
구성 요소
quay,postgres및objectstorage는managed: true로 설정됩니다. -
구성 요소
clair가managed: true로 설정된 경우 구성 요소clairpostgres도managed: true로 설정됩니다(Red Hat Quay Operator v3.7 이상으로 시작)
배포에 부분적으로 관리되지 않는 데이터베이스 또는 스토리지 구성 요소가 포함되어 있고 Postgres 또는 S3 호환 오브젝트 스토리지에 외부 서비스를 사용하여 Red Hat Quay 배포를 실행하는 경우, 데이터 백업을 생성하려면 서비스 공급자 또는 벤더 설명서를 참조해야 합니다. 이 가이드에 설명된 툴을 외부 Postgres 데이터베이스 또는 오브젝트 스토리지를 백업하는 방법에 대한 시작점으로 참조할 수 있습니다.
11.1.1. Red Hat Quay 구성 백업
QuayRegistry사용자 정의 리소스를 내보내십시오.$ oc get quayregistry <quay-registry-name> -n <quay-namespace> -o yaml > quay-registry.yaml
결과
quayregistry.yaml을 편집하고 status 섹션 및 다음 메타데이터 필드를 제거합니다.metadata.creationTimestamp metadata.finalizers metadata.generation metadata.resourceVersion metadata.uid
관리형 키 시크릿을 백업합니다.
참고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
결과
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>
데이터속성의 모든 정보는 동일하게 유지되어야 합니다.현재 Quay 구성을 백업합니다.
$ oc get secret -n <quay-namespace> $(oc get quayregistry <quay-registry-name> -n <quay-namespace> -o jsonpath='{.spec.configBundleSecret}') -o yaml > config-bundle.yamlQuay 포드 내부에 마운트된
/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에서 관리하지 않음)에서 제공하는 설정을 포함하여 이 단계를 생략하지 마십시오.
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 …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>registry-quay-app,registry-quay-mirror및registry-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 데이터베이스로 구성된 경우 공급업체의 문서를 참조하여 이러한 데이터베이스의 일관된 백업을 생성합니다.
Quay PostgreSQL 포드 이름을 식별합니다.
$ oc get pod -l quay-component=postgres -n <quay-namespace> -o jsonpath='{.items[0].metadata.name}'출력 예:
quayregistry-quay-database-59f54bb7-58xs7
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백업 데이터베이스를 다운로드합니다.
$ 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 스토리지 버킷의 콘텐츠 사본을 생성하는 방법에 대한 공급 업체의 설명서를 참조하십시오.
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)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)새 디렉터리를 만들고 모든 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
11.1.4. Red Hat Quay 배포 백업 확장
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 …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>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,postgres및objectstorage는managed: true로 설정됩니다. -
구성 요소
clair가managed: true로 설정된 경우 구성 요소clairpostgres도managed: 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 백업 가이드의 프로세스를 따라 동일한 이름으로 백업 파일을 생성한다고 가정합니다.
백업된 Red Hat Quay 구성 및 백업에서 생성된 키를 복원합니다.
$ oc create -f ./config-bundle.yaml $ oc create -f ./managed-secret-keys.yaml
중요"./config-bundle.yaml": secrets "config-bundle-secret"을 생성할 때 오류 발생 (AlreadyExists): 오류가 발생하면.yaml로 다시 생성해야 합니다.$ oc delete Secret config-bundle-secret-n <quay-namespace>를 사용하여 기존 리소스를 삭제하고$ oc create -f./config-bundle.yamlQuayRegistry사용자 정의 리소스를 복원합니다.$ oc create -f ./quay-registry.yaml
Red Hat Quay 배포 상태를 확인하고 사용 가능할 때까지 기다립니다.
$ oc wait quayregistry registry --for=condition=Available=true -n <quay-namespace>
11.2.2. Red Hat Quay 배포 축소
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 …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>registry-quay-app,registry-quay-mirror및registry-clair-appPod(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 데이터베이스 복원
Quay 데이터베이스 포드를 식별합니다.
$ oc get pod -l quay-component=postgres -n <quay-namespace> -o jsonpath='{.items[0].metadata.name}'출력 예:
quayregistry-quay-database-59f54bb7-58xs7
로컬 환경 및 Pod에 백업을 복사하여 백업을 업로드합니다.
$ oc cp ./backup.sql -n <quay-namespace> registry-quay-database-66969cd859-n2ssm:/tmp/backup.sql
데이터베이스에 대한 원격 터미널을 엽니다.
$ oc rsh -n <quay-namespace> registry-quay-database-66969cd859-n2ssm
psql을 입력합니다.
bash-4.4$ psql
다음 명령을 실행하여 데이터베이스를 나열할 수 있습니다.
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 |데이터베이스를 삭제합니다.
postgres=# DROP DATABASE "quayregistry-quay-database";
출력 예:
DROP DATABASE
postgres CLI를 종료하여 bash-4.4를 다시 입력합니다.
\q
PostgreSQL 데이터베이스를 백업 데이터베이스로 리디렉션합니다.
sh-4.4$ psql < /tmp/backup.sql
bash를 종료합니다.
sh-4.4$ exit
11.2.4. Red Hat Quay 오브젝트 스토리지 데이터 복원
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)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)다음 명령을 실행하여 모든 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}')
11.2.5. Red Hat Quay 배포 확장
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 …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>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장. Red Hat Quay Operator에 IPv6 배포
Red Hat Quay Operator 배포는 이제 Telco 및 Edge 환경과 같은 IPv6만 지원하는 위치에서 제공할 수 있습니다.
알려진 제한 사항 목록은 IPv6 제한 사항을참조하십시오.
12.1. IPv6 프로토콜 제품군 활성화
독립 실행형 Red Hat Quay 배포에서 IPv6 지원을 활성화하려면 다음 절차를 사용하십시오.
사전 요구 사항
- Red Hat Quay를 3.8로 업데이트했습니다.
- IPv6를 지원하도록 호스트 및 컨테이너 소프트웨어 플랫폼(Docker, Podman)을 구성해야 합니다.
절차
배포의
config.yaml파일에서FEATURE_LISTEN_IP_VERSION매개변수를 추가하고IPv6로 설정합니다. 예를 들면 다음과 같습니다.--- FEATURE_GOOGLE_LOGIN: false FEATURE_INVITE_ONLY_USER_CREATION: false FEATURE_LISTEN_IP_VERSION: IPv6 FEATURE_MAILING: false FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: false ---
- Red Hat Quay 배포를 시작하거나 다시 시작합니다.
다음 명령을 입력하여 배포가 IPv6에 수신 대기 중인지 확인합니다.
$ curl <quay_endpoint>/health/instance {"data":{"services":{"auth":true,"database":true,"disk_space":true,"registry_gunicorn":true,"service_key":true,"web_gunicorn":true}},"status_code":200}
배포의 config.yaml 에서 IPv6를 활성화하면 모든 Red Hat Quay 기능을 정상적으로 사용할 수 있으므로 해당 환경이 IPv6를 사용하도록 구성하고 IPv6 및 이중 스택 제한 사항에 영향을 미치지 않는 한 모든 Red Hat Quay 기능을 정상적으로 사용할 수 있습니다.
환경이 IPv4로 구성되었지만 FEATURE_LISTEN_IP_VERSION 구성 필드가 IPv6 로 설정된 경우 Red Hat Quay가 배포되지 않습니다.
12.2. IPv6 제한 사항
현재 공통 Azure Blob Storage 구성을 사용하여 Red Hat Quay 배포를 구성하려고 하면 IPv6 단일 스택 환경에서 작동하지 않습니다. Azure Blob Storage의 끝점은 IPv6를 지원하지 않기 때문에 이 문제에 대한 해결 방법은 없습니다.Because the endpoint of Azure Blob Storage does not support IPv6 there is no workaround in place for this issue.
자세한 내용은 PROJQUAY-4433 에서 참조하십시오.
현재 Amazon S3 CloudFront를 사용하여 Red Hat Quay 배포를 구성하려고 하면 IPv6 단일 스택 환경에서 작동하지 않습니다. Amazon S3 CloudFront의 엔드포인트에서 IPv6를 지원하지 않기 때문에 이 문제에 대한 해결방법이 없습니다.
자세한 내용은 PROJQUAY-4470 을 참조하십시오.
- 현재 Red Hat Quay가 IPv6 단일 스택 환경에 배포되면 ODF(OpenShift Data Foundations)가 지원되지 않습니다. 그 결과 IPv6 환경에서 ODF를 사용할 수 없습니다. 이 제한은 향후 OpenShift Data Foundations 버전에서 수정될 예정입니다.
- 현재 Red Hat Quay OpenShift Container Platform 배포에서 듀얼 스택(IPv4 및 IPv6)이 지원되지 않습니다. 이중 스택 지원이 활성화된 OpenShift Container Platform에 Red Hat Quay 3.8을 배포하면 Red Hat Quay Operator에서 생성한 Quay 경로는 IPv4 주소가 아닌 IPv4 주소만 생성합니다. 결과적으로 IPv6 주소가 있는 클라이언트는 OpenShift Container Platform에서 Red Hat Quay 애플리케이션에 액세스할 수 없습니다. 이 제한은 향후 OpenShift Container Platform 버전에서 수정될 예정입니다.
13장. Quay Operator 업그레이드 개요
Quay Operator는 동기화된 버전 관리 체계를 따릅니다. 즉, Operator의 각 버전이 Quay 버전 및 관리하는 구성 요소와 연결되어 있습니다. QuayRegistry 사용자 정의 리소스에는 배포할 Quay 버전을 설정하는 필드가 없습니다. Operator는 모든 구성 요소의 단일 버전을 배포하는 방법만 알고 있습니다. 이 스키마는 모든 구성 요소가 서로 잘 작동하도록 하고 Operator에서 Kubernetes에서 다양한 Quay 버전의 라이프사이클을 관리하는 방법을 알아야 하는 복잡성을 줄이기 위해 선택되었습니다.
13.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가 자동으로 업그레이드됩니다. 이를 원하지 않는 경우 수동 승인 전략을 선택해야 합니다.
13.2. Quay Operator 업그레이드
OpenShift에서 설치된 Operator를 업그레이드하는 표준 방법은 설치된 Operator 업그레이드에 설명되어 있습니다.
일반적으로 Red Hat Quay는 이전 (N-1) 마이너 버전의 업그레이드만 지원합니다. 예를 들어 Red Hat Quay 3.0.5에서 최신 3.5 버전으로 직접 업그레이드할 수 없습니다. 대신 사용자는 다음과 같이 업그레이드해야 합니다.
- 3.0.5 → 3.1.3
- 3.1.3 → 3.2.2
- 3.2.2 → 3.3.4
- 3.3.4 → 3.4.z
- 3.4.z → 3.5.z
이는 업그레이드 중에 필요한 모든 데이터베이스 마이그레이션을 올바르게 수행하고 올바른 순서로 수행해야 합니다.
경우에 따라 Red Hat Quay는 이전 (N-2, N-3) 마이너 버전에서 직접 단일 단계 업그레이드를 지원합니다. 이 예외는 이전 마이너 버전 전용의 일반 버전만 제외하고 업그레이드하면 이전 릴리스 고객의 업그레이드 절차를 단순화합니다. 다음과 같은 업그레이드 경로가 지원됩니다.
- 3.3.z → 3.6.z
- 3.4.z → 3.6.z
- 3.4.z → 3.7.z
- 3.5.z → 3.7.z
- 3.7.z → 3.8.z
3.8로 업그레이드하려는 Quay의 독립 실행형 배포에 있는 사용자는 독립 실행형 업그레이드 가이드를 참조하십시오.
13.2.1. Quay 업그레이드
Quay를 하나의 마이너 버전에서 다음 버전으로 업데이트하려면 (예: 3.4 → 3.5) Quay Operator의 업데이트 채널을 변경해야 합니다.
z 스트림 업그레이드(예: 3.4.2 → 3.4.3)의 경우 사용자가 처음 설치하는 동안 사용자가 선택한 메이저 마이너 채널로 업데이트가 릴리스됩니다. z 스트림 업그레이드를 수행하는 절차는 위에 설명된 approvalStrategy 에 따라 다릅니다. 승인 전략이 자동으로 설정된 경우 Quay Operator는 최신 z 스트림으로 자동 업그레이드됩니다. 이로 인해 Quay가 다운타임 없이 최신 z 스트림으로 자동으로 업데이트됩니다. 그렇지 않으면 설치를 시작하기 전에 업데이트를 수동으로 승인해야 합니다.
13.2.2. 3.3.z 또는 3.4.z에서 3.6으로 직접 업그레이드하는 방법에 대한 참고 사항
13.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.termination이none으로 설정되어 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: ...
13.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-upgrade 및 quay-config-editor Pod에서 환경 변수를 정의하는 것입니다.
GODEBUG=x509ignoreCN=0
GODEBUG=x509ignoreCN=0 플래그를 사용하면 SAN이 없을 때 X.509 인증서의 CommonName 필드를 호스트 이름으로 처리하는 기존 동작을 활성화합니다. 그러나 재배포 시 유지되지 않으므로 이 해결방법은 권장되지 않습니다.
13.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 설정을 참조하십시오.
13.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_options 및 tenant_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: *****13.2.4. Operator의 업데이트 채널 변경
설치된 Operator의 서브스크립션은 Operator의 업데이트를 추적하고 수신하는 데 사용되는 업데이트 채널을 지정합니다. Quay Operator를 업그레이드하여 최신 채널에서 업데이트를 추적하고 받으려면 설치된 Quay Operator의 서브스크립션 탭에서 업데이트 채널을 변경합니다. 자동 승인 전략이 있는 서브스크립션의 경우 업그레이드가 자동으로 시작되고 설치된 Operator가 나열된 페이지에서 모니터링할 수 있습니다.
13.2.5. 보류 중인 Operator 업그레이드 수동 승인
설치된 Operator의 서브스크립션에 있는 승인 전략이 Manual 로 설정된 경우 새 업데이트가 현재 업데이트 채널에 릴리스되면 업데이트를 수동으로 승인해야 설치가 시작됩니다. Quay Operator에 업그레이드가 보류 중인 경우 이 상태가 Installed Operator 목록에 표시됩니다. Quay Operator의 서브스크립션 탭에서 설치 계획을 미리 보고 업그레이드할 수 있는 것으로 나열된 리소스를 검토할 수 있습니다. 문제가 발생할 경우 승인을 클릭하고 Installed Operators를 나열하는 페이지로 돌아가 업그레이드 진행 상황을 모니터링합니다.
다음 이미지는 업데이트 채널, 승인 전략, 업그레이드 상태 및 InstallPlan 을 포함하여 UI의 Subscription 탭을 보여줍니다.
설치된 Operator 목록은 현재 Quay 설치에 대한 상위 수준 요약을 제공합니다.
13.3. QuayRegistry 업그레이드
Quay Operator가 시작되면 조사하도록 구성된 네임스페이스에서 찾을 수 있는 모든 QuayRegistries 를 즉시 찾습니다. 이 논리를 찾으면 다음과 같은 논리가 사용됩니다.
-
status.currentVersion이 설정되지 않은 경우 정상으로 조정합니다. -
status.currentVersion이 Operator 버전과 같은 경우 정상으로 조정합니다. -
status.currentVersion이 Operator 버전과 동일하지 않은 경우 업그레이드할 수 있는지 확인합니다. 가능하면 업그레이드 작업을 수행하고 완료되면status.currentVersion을 Operator의 버전으로 설정합니다. 업그레이드할 수 없는 경우 오류를 반환하고QuayRegistry및 배포된 Kubernetes 오브젝트만 그대로 둡니다.
13.4. QuayEcosystem 업그레이드
제한된 구성 집합에 QuayEcosystem API를 사용하는 이전 버전의 Operator에서 업그레이드가 지원됩니다. 마이그레이션이 예기치 않게 발생하지 않도록 하려면 이를 마이그레이션하려면 QuayEcosystem 에 특수 레이블을 적용해야 합니다. Operator가 관리할 수 있도록 새 QuayRegistry 가 생성되지만, 문제가 발생하는 경우에도 QuayEcosystem 을 롤백하고 Quay에 계속 액세스할 수 있도록 이전 QuayEcosystem이 수동으로 삭제될 때까지 유지됩니다. 기존 QuayEcosystem 을 새 QuayRegistry 로 마이그레이션하려면 다음 단계를 따르십시오.
QuayEcosystem의metadata.labels에"quay-operator/migrate": "true"를 추가합니다.$ oc edit quayecosystem <quayecosystemname>
metadata: labels: quay-operator/migrate: "true"-
QuayEcosystem과 동일한metadata.name을 사용하여QuayRegistry가 생성될 때까지 기다립니다.QuayEcosystem은"quay-operator/migration-complete": "true"라벨이 표시됩니다. -
새
QuayRegistry의status.registryEndpoint가 설정되면 Quay에 액세스하여 모든 데이터 및 설정이 성공적으로 마이그레이션되었는지 확인합니다. -
모든 항목이 올바르게 작동했다고 확신하면
QuayEcosystem을 삭제할 수 있으며 Kubernetes 가비지 컬렉션은 이전 리소스를 모두 정리합니다.
13.4.1. QuayEcosystem 업그레이드 되돌리기
QuayEcosystem 에서 QuayRegistry 로 자동 업그레이드하는 동안 문제가 발생하면 다음 단계에 따라 QuayEcosystem 을 사용하여 되돌아갑니다.
UI 또는
kubectl을 사용하여QuayRegistry를 삭제합니다.$ kubectl delete -n <namespace> quayregistry <quayecosystem-name>
-
경로를 사용하여 외부 액세스가 제공된 경우 UI 또는kubectl을 사용하여 원래서비스를가리키도록경로를 변경합니다.
QuayEcosystem 에서 Postgres 데이터베이스를 관리하는 경우 업그레이드 프로세스에서 업그레이드된 Operator가 관리하는 새 Postgres 데이터베이스로 데이터를 마이그레이션합니다. 이전 데이터베이스는 변경 또는 제거되지 않지만 마이그레이션이 완료되면 더 이상 Quay를 사용하지 않습니다. 데이터 마이그레이션 중에 문제가 발생하면 업그레이드 프로세스가 종료되고 관리되지 않는 구성 요소로 데이터베이스를 계속 사용하는 것이 좋습니다.
13.4.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 프로젝트를 참조하십시오.