5.8. 번들 이미지 작업

절차

1. Operator 프로젝트 디렉터리에서 다음 make 명령을 실행하여 Operator 이미지를 빌드하고 내보냅니다. 액세스할 수 있는 리포지토리를 참조하려면 다음 단계에서 IMG 인수를 수정합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.

   1. 이미지를 빌드합니다.

      $ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>

      참고

      Operator에 대해 SDK에서 생성한 Dockerfile은 Go 빌드 를 위해 GOARCH=amd64 를 명시적으로 참조합니다. 이는AMD64 이외의 아키텍처의 경우 GOARCH=$CACHEGETARCH 에 수정될 수 있습니다. Docker는 환경 변수를 -platform 에서 지정한 값으로 자동 설정합니다. Buildah를 사용하면 -build-arg 를 목적으로 사용해야 합니다. 자세한 내용은 여러 아키텍처를 참조하십시오.

   2. 이미지를 리포지토리로 내보냅니다.

      $ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>

2. Operator SDK generate bundle 및 bundle validate 명령을 비롯한 다양한 명령을 호출하는 make bundle 명령을 실행하여 Operator 번들 매니페스트를 생성합니다.

   $ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>

   Operator의 번들 매니페스트는 애플리케이션을 표시, 생성, 관리하는 방법을 설명합니다. make bundle 명령은 Operator 프로젝트에서 다음 파일 및 디렉터리를 생성합니다.

   • ClusterServiceVersion 오브젝트를 포함하는 bundle/manifests라는 번들 매니페스트 디렉터리
   • bundle/metadata라는 번들 메타데이터 디렉터리
   • config/crd 디렉터리의 모든 CRD(사용자 정의 리소스 정의)
   • Dockerfile bundle.Dockerfile

   그런 다음 operator-sdk bundle validate를 사용하여 이러한 파일을 자동으로 검증하고 디스크상의 번들 표현이 올바른지 확인합니다.

3. 다음 명령을 실행하여 번들 이미지를 빌드하고 내보냅니다. OLM에서는 하나 이상의 번들 이미지를 참조하는 인덱스 이미지를 통해 Operator 번들을 사용합니다.

   1. 번들 이미지를 빌드합니다. 이미지를 내보낼 레지스트리, 사용자 네임스페이스, 이미지 태그에 대한 세부 정보를 사용하여 BUNDLE_IMG를 설정합니다.

      $ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>

   2. 번들 이미지를 내보냅니다.

      $ docker push <registry>/<user>/<bundle_image_name>:<tag>

절차

1. 다음 명령을 입력하여 클러스터에서 Operator를 실행합니다.

   $ operator-sdk run bundle \
       [-n <namespace>] \1
       <registry>/<user>/<bundle_image_name>:<tag>

   1

   기본적으로 이 명령은 현재 활성 프로젝트의 ~/.kube/config 파일에 Operator를 설치합니다. -n 플래그를 추가하면 설치에 다른 네임스페이스 범위를 설정할 수 있습니다.

   이 명령은 다음 작업을 수행합니다.

   • 번들 이미지를 참조하는 인덱스 이미지를 생성합니다. 인덱스 이미지는 불투명하고 일시적이지만 프로덕션에서 카탈로그에 번들을 추가하는 방법을 정확하게 반영합니다.
   • OperatorHub에서 Operator를 검색할 수 있도록 새 인덱스 이미지를 가리키는 카탈로그 소스를 생성합니다.
   • OperatorGroup,Subscription,InstallPlan 및 RBAC를 포함한 기타 모든 필수 오브젝트를 생성하여 Operator를 클러스터에 배포합니다.

절차

1. Operator 프로젝트 디렉터리에서 다음 make 명령을 실행하여 Operator 번들이 포함된 인덱스 이미지를 빌드합니다.

   $ make catalog-build CATALOG_IMG=<registry>/<user>/<index_image_name>:<tag>

   여기서 CATALOG_IMG 인수는 액세스할 수 있는 리포지토리를 참조합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.

2. 빌드 인덱스 이미지를 리포지토리로 푸시합니다.

   $ make catalog-push CATALOG_IMG=<registry>/<user>/<index_image_name>:<tag>

   작은 정보

   한 번에 여러 작업을 순서대로 수행하는 경우 Operator SDK make 명령을 함께 사용할 수 있습니다. 예를 들어 Operator 프로젝트에 대한 번들 이미지를 아직 빌드하지 않은 경우 다음 구문을 사용하여 번들 이미지와 인덱스 이미지를 빌드하고 푸시할 수 있습니다.

   $ make bundle-build bundle-push catalog-build catalog-push \
       BUNDLE_IMG=<bundle_image_pull_spec> \
       CATALOG_IMG=<index_image_pull_spec>

   또는 Makefile의 IMAGE_TAG_BASE 필드를 기존 리포지토리로 설정할 수도 있습니다.

   IMAGE_TAG_BASE=quay.io/example/my-operator

   다음 구문을 사용하여 자동으로 생성된 이름으로 이미지를 빌드하고 푸시할 수 있습니다 (예: 번들 이미지의 경우 quay.io/example/my-operator-bundle:v0.0.1 및 인덱스 이미지의 경우 quay.io/example/my-operator-catalog:v0.0.1.)

   $ make bundle-build bundle-push catalog-build catalog-push

3. 방금 생성한 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 정의한 다음 oc apply 명령 또는 웹 콘솔을 사용하여 오브젝트를 생성합니다.

   CatalogSource YAML의 예

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: cs-memcached
     namespace: default
   spec:
     displayName: My Test
     publisher: Company
     sourceType: grpc
     image: quay.io/example/memcached-catalog:v0.0.1 1
     updateStrategy:
       registryPoll:
         interval: 10m

   1

   CATALOG_IMG 인수와 함께 이전에 사용한 이미지 가져오기 사양으로 image를 설정합니다.

4. 카탈로그 소스를 확인합니다.

   $ oc get catalogsource

   출력 예

   NAME           DISPLAY     TYPE   PUBLISHER   AGE
   cs-memcached   My Test     grpc   Company     4h31m

검증

1. 카탈로그를 사용하여 Operator를 설치합니다.

   1. OperatorGroup 오브젝트를 정의하고 oc apply 명령 또는 웹 콘솔을 사용하여 생성합니다.

      OperatorGroup YAML의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: my-test
        namespace: default
      spec:
        targetNamespaces:
        - default

   2. Subscription 오브젝트를 정의하고 oc apply 명령 또는 웹 콘솔을 사용하여 생성합니다.

      Subscription YAML의 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: catalogtest
        namespace: default
      spec:
        channel: "alpha"
        installPlanApproval: Manual
        name: catalog
        source: cs-memcached
        sourceNamespace: default
        startingCSV: memcached-operator.v0.0.1

2. 설치된 Operator가 실행 중인지 확인합니다.

   1. Operator 그룹을 확인합니다.

      $ oc get og

      출력 예

      NAME             AGE
      my-test           4h40m

   2. CSV(클러스터 서비스 버전)를 확인합니다.

      $ oc get csv

      출력 예

      NAME                        DISPLAY   VERSION   REPLACES   PHASE
      memcached-operator.v0.0.1   Test      0.0.1                Succeeded

   3. Operator의 Pod를 확인합니다.

      $ oc get pods

      출력 예

      NAME                                                              READY   STATUS      RESTARTS   AGE
      9098d908802769fbde8bd45255e69710a9f8420a8f3d814abe88b68f8ervdj6   0/1     Completed   0          4h33m
      catalog-controller-manager-7fd5b7b987-69s4n                       2/2     Running     0          4h32m
      cs-memcached-7622r                                                1/1     Running     0          4h33m

절차

1. OLM을 사용하여 Operator가 아직 설치되지 않은 경우 run bundle 하위 명령을 사용하거나 기존 OLM 설치와 함께 이전 버전을 설치합니다.

   참고

   OLM을 사용하여 이전 버전의 번들이 설치된 경우 카탈로그 소스에서 참조하는 인덱스 이미지에 업그레이드하려는 최신 번들이 없어야 합니다. 그렇지 않으면 패키지 및 CSV(클러스터 서비스 버전)를 제공하는 인덱스에서 최신 번들을 이미 참조하므로 run bundle-upgrade 하위 명령을 실행하면 레지스트리 pod가 실패합니다.

   예를 들어 이전 번들 이미지를 지정하여 Memcached Operator에 다음 run bundle 하위 명령을 사용할 수 있습니다.

   $ operator-sdk run bundle <registry>/<user>/memcached-operator:v0.0.1

   출력 예

   INFO[0009] Successfully created registry pod: quay-io-demo-memcached-operator-v0-0-1
   INFO[0009] Created CatalogSource: memcached-operator-catalog
   INFO[0010] OperatorGroup "operator-sdk-og" created
   INFO[0010] Created Subscription: memcached-operator-v0-0-1-sub
   INFO[0013] Approved InstallPlan install-bqggr for the Subscription: memcached-operator-v0-0-1-sub
   INFO[0013] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.1" to reach 'Succeeded' phase
   INFO[0013]   Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.1" to appear
   INFO[0019]   Found ClusterServiceVersion "my-project/memcached-operator.v0.0.1" phase: Succeeded

2. 최신 Operator 버전에 번들 이미지를 지정하여 설치한 Operator를 업그레이드합니다.

   $ operator-sdk run bundle-upgrade <registry>/<user>/memcached-operator:v0.0.2

   출력 예

   INFO[0002] Found existing subscription with name memcached-operator-v0-0-1-sub and namespace my-project
   INFO[0002] Found existing catalog source with name memcached-operator-catalog and namespace my-project
   INFO[0009] Successfully created registry pod: quay-io-demo-memcached-operator-v0-0-2
   INFO[0009] Updated catalog source memcached-operator-catalog with address and annotations
   INFO[0010] Deleted previous registry pod with name "quay-io-demo-memcached-operator-v0-0-1"
   INFO[0041] Approved InstallPlan install-gvcjh for the Subscription: memcached-operator-v0-0-1-sub
   INFO[0042] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.2" to reach 'Succeeded' phase
   INFO[0042]   Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: InstallReady
   INFO[0043]   Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Installing
   INFO[0044]   Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Succeeded
   INFO[0044] Successfully upgraded to "memcached-operator.v0.0.2"

3. 설치된 Operator를 정리합니다.

   $ operator-sdk cleanup memcached-operator

절차

1. 특정 Operator 번들이 지원되지 않고 특정 클러스터 버전 이후의 OpenShift Container Platform에서 올바르게 작동하지 않는 경우 Operator가 호환되는 최대 버전의 OpenShift Container Platform을 구성합니다. Operator 프로젝트의 CSV(클러스터 서비스 버전)에서 olm.maxOpenShiftVersion 주석을 설정하여 설치된 Operator를 호환 버전으로 업그레이드하기 전에 관리자가 클러스터를 업그레이드하지 못하도록 합니다.

   중요

   Operator 번들 버전이 이후 버전에서 작동할 수 없는 경우에만 olm.maxOpenShiftVersion 주석을 사용해야 합니다. 클러스터 관리자는 솔루션이 설치된 클러스터를 업그레이드할 수 없습니다. 이후 버전 및 유효한 업그레이드 경로를 제공하지 않으면 클러스터 관리자가 Operator를 제거하고 클러스터 버전을 업그레이드할 수 있습니다.

   olm.maxOpenShiftVersion 주석이 있는 CSV의 예

   apiVersion: operators.coreos.com/v1alpha1
   kind: ClusterServiceVersion
   metadata:
     annotations:
       "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]' 1

   1

   Operator와 호환되는 최대 OpenShift Container Platform 클러스터 버전을 지정합니다. 예를 들어 value를 4.9로 설정하면 이 번들을 클러스터에 설치할 때 OpenShift Container Platform 버전 4.9 이후 버전으로 클러스터를 업그레이드할 수 없습니다.

2. 번들이 Red Hat 제공 Operator 카탈로그에 배포되도록 설계된 경우 다음 속성을 설정하여 Operator에 대해 호환되는 OpenShift Container Platform 버전을 구성합니다. 이 구성을 사용하면 Operator가 OpenShift Container Platform의 대상 호환 버전을 대상으로 하는 카탈로그에만 포함됩니다.

   참고

   이 단계는 Red Hat 제공 카탈로그에서 Operator를 게시할 때만 유효합니다. 번들이 사용자 지정 카탈로그의 배포 전용인 경우 이 단계를 건너뛸 수 있습니다. 자세한 내용은 "Red Hat 제공 Operator 카탈로그"를 참조하십시오.

   1. 프로젝트의 bundle/metadata/annotations.yaml 파일에com.redhat.openshift.versions 주석을 설정합니다.

      호환 버전이 있는 bundle/metadata/annotations.yaml 파일의 예

      com.redhat.openshift.versions: "v4.7-v4.9" 1

      1

      범위 또는 단일 버전으로 설정합니다.

   2. 번들이 호환되지 않는 OpenShift Container Platform 버전으로 전달되지 않도록 하려면 Operator 번들 이미지에 있는 적절한 com.redhat.openshift.versions 라벨을 사용하여 인덱스 이미지가 생성되어야 합니다. 예를 들어 Operator SDK를 사용하여 프로젝트가 생성된 경우 bundle.Dockerfile 파일을 업데이트합니다.

      호환 버전이 있는 bundle.Dockerfile의 예

      LABEL com.redhat.openshift.versions="<versions>" 1

      1

      범위 또는 단일 버전으로 설정합니다 (예: v4.7-v4.9 ). 이 설정은 Operator를 배포해야 하는 클러스터 버전을 정의하고 범위 외부에 있는 클러스터 버전의 카탈로그에는 Operator가 표시되지 않습니다.