5.7. 번들 이미지 작업

프로세스

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=$TARGETARCH 로 수정할 수 있습니다. 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 프로젝트 디렉터리에서 다음 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: <operator_namespace>
   spec:
     displayName: My Test
     publisher: Company
     sourceType: grpc
     grpcPodConfig:
       securityContextConfig: <security_mode> 1
     image: quay.io/example/memcached-catalog:v0.0.1 2
     updateStrategy:
       registryPoll:
         interval: 10m

   1

   legacy 또는 restricted 를 지정합니다. 필드가 설정되지 않은 경우 기본값은 legacy 입니다. 향후 OpenShift Dedicated 릴리스에서는 기본값이 제한 될 예정입니다. 제한된 권한으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.

   2

   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: <operator_namespace>
      spec:
        targetNamespaces:
        - <operator_namespace>

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

      Subscription YAML의 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: catalogtest
        namespace: <catalog_namespace>
      spec:
        channel: "alpha"
        installPlanApproval: Manual
        name: catalog
        source: cs-memcached
        sourceNamespace: <operator_namespace>
        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[0006] Creating a File-Based Catalog of the bundle "quay.io/demo/memcached-operator:v0.0.1"
   INFO[0008] Generated a valid File-Based Catalog
   INFO[0012] Created registry pod: quay-io-demo-memcached-operator-v1-0-1
   INFO[0012] Created CatalogSource: memcached-operator-catalog
   INFO[0012] OperatorGroup "operator-sdk-og" created
   INFO[0012] Created Subscription: memcached-operator-v0-0-1-sub
   INFO[0015] Approved InstallPlan install-h9666 for the Subscription: memcached-operator-v0-0-1-sub
   INFO[0015] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.1" to reach 'Succeeded' phase
   INFO[0015] Waiting for ClusterServiceVersion ""my-project/memcached-operator.v0.0.1" to appear
   INFO[0026] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.1" phase: Pending
   INFO[0028] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.1" phase: Installing
   INFO[0059] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.1" phase: Succeeded
   INFO[0059] OLM has successfully installed "memcached-operator.v0.0.1"

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[0008] Generated a valid Upgraded File-Based Catalog
   INFO[0009] 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[0019] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Pending
   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 Dedicated에서 제대로 작동하지 않는 경우 Operator가 호환되는 최대 OpenShift Dedicated 버전을 구성합니다. 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 Dedicated 클러스터 버전을 지정합니다. 예를 들어 value 를 4.9 로 설정하면 이 번들이 클러스터에 설치될 때 OpenShift Dedicated 버전 4.9 이후 버전으로 클러스터를 업그레이드할 수 없습니다.

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

   참고

   이 단계는 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 Dedicated 버전으로 전달되지 않도록 하려면 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가 표시되지 않습니다.