애플리케이션 빌드

프로세스

1. 홈 → 프로젝트로 이동합니다.
2. Create Project를 클릭합니다.
3. 프로젝트 세부 정보를 입력합니다.
4. Create를 클릭합니다.

1. 프로젝트 드롭다운 메뉴를 클릭하여 사용 가능한 전체 프로젝트 목록을 확인합니다. 프로젝트 생성을 선택합니다.

   그림 2.1. 프로젝트 생성

   
2. 프로젝트 생성 대화 상자에서 이름 필드에 myproject와 같은 고유한 이름을 입력합니다.
3. 선택 사항: 디스플레이 이름 및 프로젝트에 대한 설명 세부 정보를 추가합니다.
4. Create를 클릭합니다.
5. 왼쪽 탐색 패널을 사용하여 프로젝트 보기로 이동하여 프로젝트 대시보드를 확인합니다.

6. 선택 사항:

   • 클러스터의 프로젝트를 모두 나열하려면 화면 위쪽에 있는 프로젝트 드롭다운 메뉴를 사용하여 모든 프로젝트를 선택합니다.
   • 프로젝트 세부 정보를 확인하려면 세부 정보 탭을 사용합니다.
   • 프로젝트에 대한 적절한 권한이 있는 경우 프로젝트 액세스 탭을 사용하여 관리자를 제공하거나 취소하고 프로젝트에 대한 권한을 편집 및 확인할 수 있습니다.

절차

1. 홈 → 프로젝트로 이동합니다.

2. 확인할 프로젝트를 선택합니다.

   이 페이지에서 워크로드를 클릭하여 프로젝트의 워크로드를 확인합니다.

프로세스

1. 프로젝트 목록을 보려면 다음을 실행합니다.

   $ oc get projects

2. CLI 작업을 위해 현재 프로젝트에서 다른 프로젝트로 변경할 수 있습니다. 그러면 지정된 프로젝트가 프로젝트 범위의 콘텐츠를 조작하는 모든 후속 작업에서 사용됩니다.

   $ oc project <project_name>

1. 개발자 화면에서 프로젝트 보기로 이동합니다.
2. 프로젝트 페이지에서 프로젝트 액세스 탭을 선택합니다.

3. 액세스 추가를 클릭하여 기본 권한에 새 권한 행을 추가합니다.

   그림 2.2. 프로젝트 권한

   
4. 사용자 이름을 입력하고 역할 선택 드롭다운 목록을 클릭하고 적절한 역할을 선택합니다.
5. 저장을 클릭하여 새 권한을 추가합니다.

1. 검색 보기에서 리소스 드롭다운 목록을 사용하여 콘솔을 검색합니다.

2. 사용 가능한 옵션에서 Console operator.openshift.io/v1 을 선택합니다.

   그림 2.3. 콘솔 리소스 검색

   
3. 이름 목록에서 클러스터를 선택합니다.
4. YAML 탭으로 이동하여 YAML 코드를 보고 편집합니다.

5. spec 아래의 YAML 코드에서 availableClusterRoles 목록을 추가하거나 편집하고 변경 사항을 저장합니다.

   spec:
     customization:
       projectAccess:
         availableClusterRoles:
         - admin
         - edit
         - view

프로세스

1. 웹 콘솔 탐색 메뉴 위쪽의 컨텍스트 선택기에서 개발자를 선택합니다.
2. +추가를 클릭합니다.
3. 페이지 위쪽에서 추가할 프로젝트 이름을 선택합니다.
4. 프로젝트에 추가하는 방법을 클릭한 다음 워크플로를 따릅니다.

프로세스

1. 홈 → 프로젝트로 이동합니다.
2. 상태를 확인할 프로젝트를 선택합니다.

프로세스

1. 다음을 실행합니다.

   $ oc status

   이 명령은 현재 프로젝트에 대한 고급 개요에 해당 구성 요소와 그 관계를 제공합니다.

프로세스

1. 홈 → 프로젝트로 이동합니다.
2. 프로젝트 목록에서 삭제할 프로젝트를 찾습니다.
3. 프로젝트 목록 맨 오른쪽에 있는 옵션 메뉴 에서 프로젝트 삭제 를 선택합니다.
4. 프로젝트 삭제 창이 열리면 삭제할 프로젝트 이름을 필드에 입력합니다.
5. 삭제를 클릭합니다.

프로세스

1. 다음을 실행합니다.

   $ oc delete project <project_name>

프로세스

1. cluster-admin 권한이 있는 사용자로 로그인합니다.

2. 기본 프로젝트 템플릿을 생성합니다.

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. 텍스트 편집기를 사용하여 오브젝트를 추가하거나 기존 오브젝트를 수정하여 생성된 template.yaml 파일을 수정합니다.

4. 프로젝트 템플릿은 openshift-config 네임스페이스에서 생성해야 합니다. 수정된 템플릿을 불러옵니다.

   $ oc create -f template.yaml -n openshift-config

5. 웹 콘솔 또는 CLI를 사용하여 프로젝트 구성 리소스를 편집합니다.

   • 웹 콘솔에 액세스:

     1. 관리 → 클러스터 설정으로 이동합니다.
     2. Configuration (구성)을 클릭하여 모든 구성 리소스를 확인합니다.
     3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.

   • CLI 사용:

     1. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다.

        $ oc edit project.config.openshift.io/cluster

6. projectRequestTemplate 및 name 매개변수를 포함하도록 spec 섹션을 업데이트하고 업로드된 프로젝트 템플릿의 이름을 설정합니다. 기본 이름은 project-request입니다.

   사용자 정의 프로젝트 템플릿이 포함된 프로젝트 구성 리소스

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. 변경 사항을 저장한 후 새 프로젝트를 생성하여 변경 사항이 성공적으로 적용되었는지 확인합니다.

프로세스

1. cluster-admin 권한이 있는 사용자로 로그인합니다.

2. 다음 명령을 실행하여 self-provisioners 클러스터 역할 바인딩 사용을 확인합니다.

   $ oc describe clusterrolebinding.rbac self-provisioners

   출력 예

   Name:		self-provisioners
   Labels:		<none>
   Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
   Role:
     Kind:	ClusterRole
     Name:	self-provisioner
   Subjects:
     Kind	Name				Namespace
     ----	----				---------
     Group	system:authenticated:oauth

   self-provisioners 섹션의 제목을 검토합니다.

3. 그룹 system:authenticated:oauth에서 self-provisioner 클러스터 역할을 제거합니다.

   • self-provisioners 클러스터 역할 바인딩에서 self-provisioner 역할을 system:authenticated:oauth 그룹에만 바인딩하는 경우 다음 명령을 실행합니다.

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

   • self-provisioners 클러스터 역할 바인딩에서 self-provisioner 역할을 system:authenticated:oauth 그룹 이외에도 추가 사용자, 그룹 또는 서비스 계정에 바인딩하는 경우 다음 명령을 실행합니다.

     $ oc adm policy \
         remove-cluster-role-from-group self-provisioner \
         system:authenticated:oauth

4. 역할이 자동으로 업데이트되지 않도록 self-provisioners 클러스터 역할 바인딩을 편집합니다. 역할이 자동으로 업데이트되면 클러스터 역할이 기본 상태로 재설정됩니다.

   • CLI를 사용하여 역할 바인딩을 업데이트하려면 다음을 수행합니다.

     1. 다음 명령을 실행합니다.

        $ oc edit clusterrolebinding.rbac self-provisioners

     2. 표시된 역할 바인딩에서 다음 예와 같이 rbac.authorization.kubernetes.io/autoupdate 매개변수 값을 false로 설정합니다.

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
          ...

   • 단일 명령을 사용하여 역할 바인딩을 업데이트하려면 다음을 실행합니다.

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

5. 인증된 사용자로 로그인하여 프로젝트를 더 이상 자체 프로비저닝할 수 없는지 확인합니다.

   $ oc new-project test

   출력 예

   Error from server (Forbidden): You may not request a new project via this API.

   조직과 관련된 더 유용한 지침을 제공하도록 이 프로젝트 요청 메시지를 사용자 정의하는 것이 좋습니다.

절차

1. 웹 콘솔 또는 CLI를 사용하여 프로젝트 구성 리소스를 편집합니다.

   • 웹 콘솔에 액세스:

     1. 관리 → 클러스터 설정으로 이동합니다.
     2. Configuration (구성)을 클릭하여 모든 구성 리소스를 확인합니다.
     3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.

   • CLI 사용:

     1. cluster-admin 권한이 있는 사용자로 로그인합니다.

     2. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다.

        $ oc edit project.config.openshift.io/cluster

2. projectRequestMessage 매개변수를 포함하도록 spec 섹션을 업데이트하고 해당 값을 사용자 정의 메시지로 설정합니다.

   사용자 정의 프로젝트 요청 메시지가 포함된 프로젝트 구성 리소스

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: <message_string>

   예를 들면 다음과 같습니다.

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.

3. 변경 사항을 저장한 후 프로젝트를 자체 프로비저닝하여 변경 사항이 성공적으로 적용되었는지 확인할 수 없는 개발자 또는 서비스 계정으로 새 프로젝트를 생성합니다.

절차

1. +추가 보기에서 샘플 타일을 클릭하여 샘플 페이지를 확인합니다.
2. 샘플 페이지에서 사용 가능한 샘플 애플리케이션 중 하나를 선택하여 샘플 애플리케이션 생성 양식을 확인합니다.

3. 샘플 애플리케이션 생성 양식에서 다음을 수행합니다.

   • 이름 필드에는 기본적으로 배포 이름이 표시됩니다. 필요에 따라 이 이름을 수정할 수 있습니다.
   • 빌더 이미지 버전에는 빌더 이미지가 기본적으로 선택되어 있습니다. 빌더 이미지 버전 드롭다운 목록을 사용하여 이 이미지 버전을 수정할 수 있습니다.
   • 샘플 Git 리포지토리 URL이 기본적으로 추가됩니다.
4. 생성을 클릭하여 샘플 애플리케이션을 생성합니다. 샘플 애플리케이션의 빌드 상태가 토폴로지 보기에 표시됩니다. 샘플 애플리케이션이 생성되면 애플리케이션에 추가된 배포를 볼 수 있습니다.

절차

1. +추가 보기에서 모든 퀵 스타트 보기 링크를 클릭하여 빠른 시작 페이지를 확인합니다.
2. 빠른 시작 페이지에서 사용하려는 퀵 스타트의 타일을 클릭합니다.
3. 시작을 클릭하여 퀵 스타트 를 시작합니다.

절차

1. +추가 보기의 Git 리포지토리 타일 에서 Git 에서 을 클릭하여 Git 에서 가져오기 양식을 확인합니다.
2. Git 섹션에서 애플리케이션을 생성하는 데 사용할 코드베이스의 Git 리포지토리 URL을 입력합니다. 예를 들어 이 샘플 Node.js 애플리케이션의 URL https://github.com/sclorg/nodejs-ex를 입력합니다. 그런 다음 URL을 검증합니다.

3. 선택 사항: 고급 Git 옵션 표시를 클릭하여 다음과 같은 세부 정보를 추가할 수 있습니다.

   • Git 참조: 애플리케이션을 빌드하는 데 사용할 특정 분기의 코드, 태그 또는 커밋을 가리킵니다.
   • 컨텍스트 디렉터리: 애플리케이션을 빌드하는 데 사용할 애플리케이션 소스 코드의 하위 디렉터리를 지정합니다.
   • 소스 시크릿: 프라이빗 리포지토리에서 소스 코드를 가져올 수 있는 자격 증명이 포함된 시크릿 이름을 생성합니다.

4. 선택 사항: Git 리포지토리를 통해 devfile, Dockerfile 또는 빌더 이미지를 가져와서 배포를 추가로 사용자 지정할 수 있습니다.

   • Git 리포지토리에 devfile, Dockerfile 또는 빌더 이미지가 포함된 경우 해당 경로 필드에 자동으로 감지되고 채워집니다. devfile, Dockerfile 및 빌더 이미지가 동일한 리포지토리에서 감지되면 기본적으로 devfile이 선택됩니다.
   • 파일 가져오기 유형을 편집하고 다른 전략을 선택하려면 Edit import strategy 옵션을 클릭합니다.
   • 여러 devfile, Dockerfile 또는 빌더 이미지가 감지되어 특정 devfile, Dockerfile 또는 빌더 이미지를 가져오려면 컨텍스트 디렉터리에 상대적인 해당 경로를 지정합니다.

5. Git URL을 검증한 후 권장 빌더 이미지가 선택되고 별표로 표시됩니다. 빌더 이미지가 자동으로 탐지되지 않으면 빌더 이미지를 선택합니다. https://github.com/sclorg/nodejs-ex Git URL의 경우 기본적으로 Node.js 빌더 이미지가 선택됩니다.

   1. 선택 사항: 빌더 이미지 버전 드롭다운을 사용하여 버전을 지정합니다.
   2. 선택 사항: 가져오기 편집 전략을 사용하여 다른 전략을 선택합니다.
   3. 선택 사항: Node.js 빌더 이미지의 경우 Run command 필드를 사용하여 애플리케이션을 실행하는 명령을 재정의합니다.

6. 일반 섹션에서 다음을 수행합니다.

   1. 애플리케이션 필드에서 애플리케이션 그룹화에 대한 고유 이름을 입력합니다(예: myapp). 애플리케이션 이름이 네임스페이스에서 고유해야 합니다.

   2. 기존 애플리케이션이 없는 경우 이 애플리케이션에 대해 생성된 리소스를 확인하는 이름 필드는 Git 리포지토리 URL에 따라 자동으로 채워집니다. 기존 애플리케이션이 있는 경우에는 기존 애플리케이션 내에 구성 요소를 배포하거나 새 애플리케이션을 생성하거나 구성 요소를 할당하지 않은 상태로 유지하도록 선택할 수 있습니다.

      참고

      리소스 이름은 네임스페이스에서 고유해야 합니다. 오류가 발생하면 리소스 이름을 수정합니다.

7. 리소스 섹션에서 다음 옵션을 선택합니다.

   • 배포: 일반 Kubernetes 형식으로 애플리케이션을 생성합니다.
   • 배포 구성: OpenShift Container Platform 스타일 애플리케이션을 생성합니다.

   • 서버리스 배포: Knative 서비스를 생성합니다.

     참고

     Serverless Deployment 옵션은 OpenShift Serverless Operator가 클러스터에 설치된 경우에만 Git 에서 가져오기 양식에 표시됩니다. 자세한 내용은 OpenShift Serverless 설명서를 참조하십시오.

8. 파이프라인 섹션에서 파이프라인 추가를 선택한 다음 파이프라인 시각화 표시를 클릭하여 애플리케이션의 파이프라인을 확인합니다. 기본 파이프라인이 선택되었지만 애플리케이션에 사용 가능한 파이프라인 목록에서 원하는 파이프라인을 선택할 수 있습니다.

9. 선택 사항: 고급 옵션 섹션에서 대상 포트 와 애플리케이션에 대한 경로 생성 은 공개적으로 사용 가능한 URL을 사용하여 애플리케이션에 액세스할 수 있도록 기본적으로 선택됩니다.

   애플리케이션에서 기본 공용 포트, 80에 해당 데이터를 노출하지 않으면 확인란을 지우고 노출하려는 대상 포트 번호를 설정합니다.

10. 선택 사항: 다음 고급 옵션을 사용하여 애플리케이션을 추가로 사용자 지정할 수 있습니다.

절차

1. 토폴로지 보기에서 아무 곳이나 마우스 오른쪽 버튼으로 클릭하여 프로젝트에 추가 메뉴를 확인합니다.
2. Add to Project 메뉴 위로 마우스를 올리면 메뉴 옵션을 확인한 다음 JAR 파일 업로드 옵션을 선택하여 JAR 파일 업로드 폼을 확인합니다. 또는 JAR 파일을 토폴로지 보기로 드래그할 수 있습니다.
3. JAR 파일 필드에서 로컬 시스템에 필요한 JAR 파일을 찾아 업로드합니다. 또는 JAR 파일을 필드로 드래그할 수 있습니다. 호환되지 않는 파일 유형을 토폴로지 보기로 드래그하면 오른쪽 상단에 경고가 표시됩니다. 호환되지 않는 파일 유형이 업로드 양식의 필드에 삭제되면 필드 오류가 표시됩니다.
4. 런타임 아이콘 및 빌더 이미지는 기본적으로 선택됩니다. 빌더 이미지가 자동으로 탐지되지 않으면 빌더 이미지를 선택합니다. 필요한 경우 빌더 이미지 버전 드롭다운 목록을 사용하여 버전을 변경할 수 있습니다.
5. 선택 사항: 애플리케이션 이름 필드에 리소스 레이블링에 사용할 애플리케이션의 고유 이름을 입력합니다.
6. 이름 필드에 고유한 구성 요소 이름을 입력하여 관련 리소스의 이름을 지정합니다.
7. 리소스 필드에서 애플리케이션의 리소스 유형을 선택합니다.
8. 고급 옵션 메뉴에서 애플리케이션에 대한 경로 생성을 클릭하여 배포된 애플리케이션의 공용 URL을 구성합니다.
9. 생성을 클릭하여 애플리케이션을 배포합니다. JAR 파일이 업로드되고 있음을 알리는 알림이 표시됩니다. 알림에는 빌드 로그를 볼 수 있는 링크도 포함됩니다.

프로세스

1. Developer Perspective → +Add → Developer Catalog → All Services 로 이동합니다. 개발자 카탈로그에서 사용 가능한 모든 서비스 목록이 표시됩니다.
2. All Services 에서 Devfiles 를 선택하여 특정 언어 또는 프레임워크를 지원하는 devfile을 찾습니다. 또는 키워드 필터를 사용하여 이름, 태그 또는 설명을 사용하여 특정 devfile을 검색할 수 있습니다.
3. 애플리케이션을 생성하는 데 사용할 devfile을 클릭합니다. devfile 타일에는 name, description, provider, devfile 설명서를 포함하여 devfile의 세부 정보가 표시됩니다.
4. 생성 을 클릭하여 애플리케이션을 생성하고 토폴로지 보기에서 애플리케이션을 확인합니다.

프로세스

1. 개발자 화면에서 +추가 보기 및 개발자 카탈로그 타일로 이동하여 All Services (모든 서비스)를 클릭하여 개발자 카탈로그에서 사용 가능한 모든 서비스를 확인합니다.
2. All Services 에서 프로젝트에 추가해야 하는 서비스 종류 또는 구성 요소를 선택합니다. 이 예제에서는 데이터베이스를 선택하여 모든 데이터베이스 서비스를 나열하고 MariaDB를 클릭하여 서비스 세부 정보를 확인합니다.

3. 템플릿 인스턴스화를 클릭하여 MariaDB 서비스 세부 정보가 자동으로 채워진 템플릿을 확인한 다음 생성을 클릭하여 토폴로지 보기에서 MariaDB 서비스를 생성하고 확인합니다.

   그림 3.1. 토폴로지의 MariaDB

   

프로세스

1. 이 절차를 위해 OpenShift Container Platform 웹 콘솔에 새 프로젝트를 생성합니다. 이 예제에서는 my-etcd라는 프로젝트를 사용합니다.

2. Operator → 설치된 Operator 페이지로 이동합니다. 이 페이지에는 클러스터 관리자가 클러스터에 설치하여 사용할 수 있는 Operator가 CSV(클러스터 서비스 버전) 목록으로 표시됩니다. CSV는 Operator에서 제공하는 소프트웨어를 시작하고 관리하는 데 사용됩니다.

   작은 정보

   다음을 사용하여 CLI에서 이 목록을 가져올 수 있습니다.

   $ oc get csv

3. 자세한 내용과 사용 가능한 작업을 확인하려면 설치된 Operator 페이지에서 etcd Operator를 클릭합니다.

   이 Operator에서는 제공된 API 아래에 표시된 것과 같이 etcd 클러스터(EtcdCluster 리소스)용 하나를 포함하여 새로운 리소스 유형 세 가지를 사용할 수 있습니다. 이러한 오브젝트는 내장된 네이티브 Kubernetes 오브젝트(예: Deployment 또는 ReplicaSet)와 비슷하게 작동하지만 etcd 관리와 관련된 논리가 포함됩니다.

4. 새 etcd 클러스터를 생성합니다.

   1. etcd 클러스터 API 상자에서 인스턴스 생성을 클릭합니다.
   2. 다음 화면을 사용하면 클러스터 크기와 같은 EtcdCluster 오브젝트의 최소 시작 템플릿을 수정할 수 있습니다. 지금은 생성을 클릭하여 종료하십시오. 그러면 Operator에서 새 etcd 클러스터의 Pod, 서비스 및 기타 구성 요소를 가동합니다.

5. 예제 etcd 클러스터를 클릭한 다음 리소스 탭을 클릭하여 Operator에서 자동으로 생성 및 구성한 리소스 수가 프로젝트에 포함되는지 확인합니다.

   프로젝트의 다른 Pod에서 데이터베이스에 액세스할 수 있도록 Kubernetes 서비스가 생성되었는지 확인합니다.

6. 지정된 프로젝트에서 edit 역할을 가진 모든 사용자는 클라우드 서비스와 마찬가지로 셀프 서비스 방식으로 프로젝트에 이미 생성된 Operator에서 관리하는 애플리케이션 인스턴스(이 예제의 etcd 클러스터)를 생성, 관리, 삭제할 수 있습니다. 이 기능을 사용하여 추가 사용자를 활성화하려면 프로젝트 관리자가 다음 명령을 사용하여 역할을 추가하면 됩니다.

   $ oc policy add-role-to-user edit <user> -n <target_project>

절차

1. 웹 콘솔의 관리자 화면에서 Operator → OperatorHub로 이동합니다.
2. 키워드로 필터링 상자를 사용하여 카탈로그에서 Service Binding Operator 를 검색합니다. Service Binding Operator 타일을 클릭합니다.
3. Service Binding Operator 페이지에서 Operator에 대한 간략한 설명을 읽으십시오. 설치를 클릭합니다.

4. Operator 설치 페이지에서 다음을 수행합니다.

   1. Installation Mode로 All namespaces on the cluste(default)를 선택합니다. 이 모드에서는 기본 openshift-operators 네임스페이스에 Operator가 설치되므로 Operator가 클러스터의 모든 네임스페이스를 감시하고 사용 가능하게 만들 수 있습니다.
   2. Approval Strategy으로 Automatic을 선택합니다. 그러면 Operator에 향후 지원되는 업그레이드가 OLM(Operator Lifecycle Manager)에 의해 자동으로 처리됩니다. Manual 승인 전략을 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.

   3. Update Channel을 선택합니다.

      • 기본적으로 stable 채널을 사용하면 Service Binding Operator의 안정적인 최신 릴리스를 설치할 수 있습니다.

5. 설치를 클릭합니다.

   참고

   Operator는 openshift-operators 네임스페이스에 자동으로 설치됩니다.

6. 설치된 Operatorhiera-octetsready에서 사용 가능한 창에서 View Operator 를 클릭합니다. Installed Operators 페이지의 목록에 해당 Operator가 나타납니다.
7. Service Binding Operator가 성공적으로 설치되었는지 확인하려면 상태가 Succeeded 로 설정되어 있는지 확인합니다.

절차

1. 쉘에서 다음 명령을 실행하여 my-petclinic 네임스페이스에 PostgresCluster CR을 생성합니다.

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: postgres-operator.crunchydata.com/v1beta1
   kind: PostgresCluster
   metadata:
     name: hippo
   spec:
     image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0
     postgresVersion: 13
     instances:
       - name: instance1
         dataVolumeClaimSpec:
           accessModes:
           - "ReadWriteOnce"
           resources:
             requests:
               storage: 1Gi
     backups:
       pgbackrest:
         image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:centos8-2.33-2
         repos:
         - name: repo1
           volume:
             volumeClaimSpec:
               accessModes:
               - "ReadWriteOnce"
               resources:
                 requests:
                   storage: 1Gi
         - name: repo2
           volume:
             volumeClaimSpec:
               accessModes:
               - "ReadWriteOnce"
               resources:
                 requests:
                   storage: 1Gi
     proxy:
       pgBouncer:
         image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbouncer:centos8-1.15-2
   EOD

   이 PostgresCluster CR에 추가된 주석은 서비스 바인딩 연결을 활성화하고 Operator 조정을 트리거합니다.

   출력은 데이터베이스 인스턴스가 생성되었는지 확인합니다.

   출력 예

   postgrescluster.postgres-operator.crunchydata.com/hippo created

2. 데이터베이스 인스턴스를 생성한 후 my-petclinic 네임스페이스의 모든 Pod가 실행 중인지 확인합니다.

   $ oc get pods -n my-petclinic

   표시되는 데 몇 분이 걸리는 출력은 데이터베이스가 생성 및 구성되어 있는지 확인합니다.

   출력 예

   NAME                               READY   STATUS    RESTARTS   AGE
   hippo-backup-nqjg-2rq94            1/1     Running   0          35s
   hippo-instance1-nw92-0             3/3     Running   0          112s
   hippo-pgbouncer-57b98f4476-znsk5   2/2     Running   0          112s
   hippo-repo-host-0                  1/1     Running   0          112s

   데이터베이스가 구성된 후 샘플 애플리케이션을 배포하고 데이터베이스 서비스에 연결할 수 있습니다.

절차

1. 쉘에서 다음 명령을 실행하여 PostgresCluster CR(사용자 정의 리소스)을 사용하여 spring-petclinic 애플리케이션을 배포합니다.

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: spring-petclinic
     labels:
       app: spring-petclinic
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: spring-petclinic
     template:
       metadata:
         labels:
           app: spring-petclinic
       spec:
         containers:
           - name: app
             image: quay.io/service-binding/spring-petclinic:latest
             imagePullPolicy: Always
             env:
             - name: SPRING_PROFILES_ACTIVE
               value: postgres
             ports:
             - name: http
               containerPort: 8080
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: spring-petclinic
     name: spring-petclinic
   spec:
     type: NodePort
     ports:
       - port: 80
         protocol: TCP
         targetPort: 8080
     selector:
       app: spring-petclinic
   EOD

   출력은 Spring PetClinic 샘플 애플리케이션이 생성되고 배포되었는지 확인합니다.

   출력 예

   deployment.apps/spring-petclinic created
   service/spring-petclinic created

   참고

   웹 콘솔의 개발자 화면에서 컨테이너 이미지를 사용하여 애플리케이션을 배포하는 경우 고급 옵션 의 배포 섹션에 다음 환경 변수를 입력해야 합니다.

   • 이름: SPRING_PROFILES_ACTIVE
   • 값: Postgres

2. 다음 명령을 실행하여 애플리케이션이 데이터베이스 서비스에 아직 연결되지 않았는지 확인합니다.

   $ oc get pods -n my-petclinic

   출력에서 CrashLoopBackOff 상태를 표시하는 데 몇 분이 걸립니다.

   출력 예

   NAME                                READY   STATUS             RESTARTS      AGE
   spring-petclinic-5b4c7999d4-wzdtz   0/1     CrashLoopBackOff   4 (13s ago)   2m25s

   이 단계에서는 Pod가 시작되지 않습니다. 애플리케이션과 상호 작용하려고 하면 오류가 반환됩니다.

절차

1. 바인딩 데이터를 프로젝트에 대한 ServiceBinding CR을 생성합니다.

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: binding.operators.coreos.com/v1alpha1
   kind: ServiceBinding
   metadata:
     name: spring-petclinic-pgcluster
   spec:
     services: 1
       - group: postgres-operator.crunchydata.com
         version: v1beta1
         kind: PostgresCluster 2
         name: hippo
     application: 3
       name: spring-petclinic
       group: apps
       version: v1
       resource: deployments
   EOD

   1

   서비스 리소스 목록을 지정합니다.

   2

   데이터베이스의 CR입니다.

   3

   포함된 PodSpec이 있는 Deployment 또는 기타 유사한 리소스를 가리키는 샘플 애플리케이션입니다.

   출력은 바인딩 데이터를 샘플 애플리케이션에 프로젝트에 생성하기 위해 ServiceBinding CR이 생성되었는지 확인합니다.

   출력 예

   servicebinding.binding.operators.coreos.com/spring-petclinic created

2. 서비스 바인딩 요청이 성공했는지 확인합니다.

   $ oc get servicebindings -n my-petclinic

   출력 예

   NAME                         READY   REASON              AGE
   spring-petclinic-pgcluster   True    ApplicationsBound   7s

   기본적으로 데이터베이스 서비스의 바인딩 데이터의 값은 샘플 애플리케이션을 실행하는 워크로드 컨테이너에 파일로 프로젝션됩니다. 예를 들어 Secret 리소스의 모든 값은 bindings/spring-petclinic-pgcluster 디렉터리에 예상됩니다.

   참고

   필요한 경우 디렉터리 콘텐츠를 출력하여 애플리케이션의 파일에 예상 바인딩 데이터가 포함되어 있는지 확인할 수도 있습니다.

   $ for i in username password host port type; do oc exec -it deploy/spring-petclinic -n my-petclinic -- /bin/bash -c 'cd /tmp; find /bindings/*/'$i' -exec echo -n {}:" " \; -exec cat {} \;'; echo; done

   출력 예: 보안 리소스의 모든 값 사용

   /bindings/spring-petclinic-pgcluster/username: <username>
   /bindings/spring-petclinic-pgcluster/password: <password>
   /bindings/spring-petclinic-pgcluster/host: hippo-primary.my-petclinic.svc
   /bindings/spring-petclinic-pgcluster/port: 5432
   /bindings/spring-petclinic-pgcluster/type: postgresql

3. 로컬 환경에서 샘플 애플리케이션에 액세스하려면 애플리케이션 포트에서 포트 전달을 설정합니다.

   $ oc port-forward --address 0.0.0.0 svc/spring-petclinic 8080:80 -n my-petclinic

   출력 예

   Forwarding from 0.0.0.0:8080 -> 8080
   Handling connection for 8080

4. http://localhost:8080/petclinic 에 액세스 .

   이제 localhost:8080에서 Spring PetClinic 샘플 애플리케이션에 원격으로 액세스하여 애플리케이션이 데이터베이스 서비스에 연결되어 있는지 확인할 수 있습니다.

절차

1. Dev4Devs PostgreSQL Operator를 my-petclinic 네임스페이스에 배포하려면 쉘에서 다음 명령을 실행합니다.

검증

1. Operator가 설치되면 openshift-operators 네임스페이스에 Operator 서브스크립션을 나열합니다.

   $ oc get subs -n openshift-operators

   출력 예

   NAME                               PACKAGE                            SOURCE                  CHANNEL
   postgresql-operator-dev4devs-com   postgresql-operator-dev4devs-com   ibm-multiarch-catalog   alpha
   rh-service-binding-operator        rh-service-binding-operator        redhat-operators        stable

절차

1. 쉘에서 다음 명령을 실행하여 my-petclinic 네임스페이스에 Database CR을 생성합니다.

   $ oc apply -f - << EOD
   apiVersion: postgresql.dev4devs.com/v1alpha1
   kind: Database
   metadata:
     name: sampledatabase
     namespace: my-petclinic
     annotations:
       host: sampledatabase
       type: postgresql
       port: "5432"
       service.binding/database: 'path={.spec.databaseName}'
       service.binding/port: 'path={.metadata.annotations.port}'
       service.binding/password: 'path={.spec.databasePassword}'
       service.binding/username: 'path={.spec.databaseUser}'
       service.binding/type: 'path={.metadata.annotations.type}'
       service.binding/host: 'path={.metadata.annotations.host}'
   spec:
     databaseCpu: 30m
     databaseCpuLimit: 60m
     databaseMemoryLimit: 512Mi
     databaseMemoryRequest: 128Mi
     databaseName: "sampledb"
     databaseNameKeyEnvVar: POSTGRESQL_DATABASE
     databasePassword: "samplepwd"
     databasePasswordKeyEnvVar: POSTGRESQL_PASSWORD
     databaseStorageRequest: 1Gi
     databaseUser: "sampleuser"
     databaseUserKeyEnvVar: POSTGRESQL_USER
     image: registry.redhat.io/rhel8/postgresql-13:latest
     databaseStorageClassName: nfs-storage-provisioner
     size: 1
   EOD

   이 데이터베이스 CR에 추가된 주석을 사용하면 서비스 바인딩 연결을 활성화하고 Operator 조정을 트리거합니다.

   출력은 데이터베이스 인스턴스가 생성되었는지 확인합니다.

   출력 예

   database.postgresql.dev4devs.com/sampledatabase created

2. 데이터베이스 인스턴스를 생성한 후 my-petclinic 네임스페이스의 모든 Pod가 실행 중인지 확인합니다.

   $ oc get pods -n my-petclinic

   표시되는 데 몇 분이 걸리는 출력은 데이터베이스가 생성 및 구성되어 있는지 확인합니다.

   출력 예

   NAME                                     READY    STATUS      RESTARTS   AGE
   sampledatabase-cbc655488-74kss            0/1     Running        0       32s

절차

1. 쉘에서 다음 명령을 실행하여 PostgresCluster CR(사용자 정의 리소스)을 사용하여 spring-petclinic 애플리케이션을 배포합니다.

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: spring-petclinic
     labels:
       app: spring-petclinic
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: spring-petclinic
     template:
       metadata:
         labels:
           app: spring-petclinic
       spec:
         containers:
           - name: app
             image: quay.io/service-binding/spring-petclinic:latest
             imagePullPolicy: Always
             env:
             - name: SPRING_PROFILES_ACTIVE
               value: postgres
             - name: org.springframework.cloud.bindings.boot.enable
               value: "true"
             ports:
             - name: http
               containerPort: 8080
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: spring-petclinic
     name: spring-petclinic
   spec:
     type: NodePort
     ports:
       - port: 80
         protocol: TCP
         targetPort: 8080
     selector:
       app: spring-petclinic
   EOD

   출력은 Spring PetClinic 샘플 애플리케이션이 생성되고 배포되었는지 확인합니다.

   출력 예

   deployment.apps/spring-petclinic created
   service/spring-petclinic created

   참고

   웹 콘솔의 개발자 화면에서 컨테이너 이미지를 사용하여 애플리케이션을 배포하는 경우 고급 옵션 의 배포 섹션에 다음 환경 변수를 입력해야 합니다.

   • 이름: SPRING_PROFILES_ACTIVE
   • 값: Postgres

2. 다음 명령을 실행하여 애플리케이션이 데이터베이스 서비스에 아직 연결되지 않았는지 확인합니다.

   $ oc get pods -n my-petclinic

   CrashLoopBackOff 상태가 표시될 때까지 몇 분이 걸립니다.

   출력 예

   NAME                                READY   STATUS             RESTARTS      AGE
   spring-petclinic-5b4c7999d4-wzdtz   0/1     CrashLoopBackOff   4 (13s ago)   2m25s

   이 단계에서는 Pod가 시작되지 않습니다. 애플리케이션과 상호 작용하려고 하면 오류가 반환됩니다.

절차

1. 바인딩 데이터를 프로젝트에 대한 ServiceBinding CR을 생성합니다.

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: binding.operators.coreos.com/v1alpha1
   kind: ServiceBinding
   metadata:
       name: spring-petclinic-pgcluster
   spec:
     services: 1
       - group: postgresql.dev4devs.com
         kind: Database 2
         name: sampledatabase
         version: v1alpha1
     application: 3
       name: spring-petclinic
       group: apps
       version: v1
       resource: deployments
   EOD

   1

   서비스 리소스 목록을 지정합니다.

   2

   데이터베이스의 CR입니다.

   3

   포함된 PodSpec이 있는 Deployment 또는 기타 유사한 리소스를 가리키는 샘플 애플리케이션입니다.

   출력은 바인딩 데이터를 샘플 애플리케이션에 프로젝트에 생성하기 위해 ServiceBinding CR이 생성되었는지 확인합니다.

   출력 예

   servicebinding.binding.operators.coreos.com/spring-petclinic created

2. 서비스 바인딩 요청이 성공했는지 확인합니다.

   $ oc get servicebindings -n my-petclinic

   출력 예

   NAME                          READY   REASON              AGE
   spring-petclinic-postgresql   True    ApplicationsBound   47m

   기본적으로 데이터베이스 서비스의 바인딩 데이터의 값은 샘플 애플리케이션을 실행하는 워크로드 컨테이너에 파일로 프로젝션됩니다. 예를 들어 Secret 리소스의 모든 값은 bindings/spring-petclinic-pgcluster 디렉터리에 예상됩니다.

3. 이 구성을 만든 후에는 토폴로지로 이동하여 시각적 연결을 확인할 수 있습니다.

   그림 6.1. Spring-petclinic을 샘플 데이터베이스에 연결

   

4. 로컬 환경에서 샘플 애플리케이션에 액세스하려면 애플리케이션 포트에서 포트 전달을 설정합니다.

   $ oc port-forward --address 0.0.0.0 svc/spring-petclinic 8080:80 -n my-petclinic

   출력 예

   Forwarding from 0.0.0.0:8080 -> 8080
   Handling connection for 8080

5. http://localhost:8080 에 액세스 .

   이제 localhost:8080에서 Spring PetClinic 샘플 애플리케이션에 원격으로 액세스하여 애플리케이션이 데이터베이스 서비스에 연결되어 있는지 확인할 수 있습니다.

1. 기본적으로 파일로 설정됩니다.
2. 환경 변수로 ServiceBinding 리소스에서 .spec.bindAsFiles 매개변수를 구성합니다.

절차

1. 바인딩 데이터를 파일로 프로젝션하려면 기존 SERVICE_BINDING_ROOT 환경 변수가 워크로드가 실행되는 컨테이너에 있는지 확인하여 대상 폴더를 결정합니다.
2. 바인딩 데이터를 환경 변수로 프로젝션하려면 .spec.bindAsFiles 매개변수 값을 CR(사용자 정의 리소스)의 ServiceBinding 리소스에서 false 로 설정합니다.

절차

1. Spring PetClinic 샘플 애플리케이션 위에 커서를 올리면 노드에서 출발하는 화살표가 표시됩니다.

   그림 6.2. Visual connector

   
2. 화살표를 클릭하고 hippo-pgbouncer 배포로 드래그하여 Spring PetClinic 샘플 애플리케이션을 연결합니다.
3. spring-petclinic 배포를 클릭하여 개요 패널을 확인합니다. 세부 정보 탭에서 주석 섹션의 편집 아이콘을 클릭하여 배포에 추가된 Key = app.openshift.io/connects-to 및 Value = [{"apiVersion":"apps/v1","kind":"Deployment","name":"hippo-pgbouncer"}] 주석을 확인합니다.

절차

1. Developer 관점으로 전환하고 적절한 프로젝트(예: my-petclinic )에 있는지 확인합니다. 토폴로지 보기에서 Spring PetClinic 샘플 애플리케이션을 마우스 커서로 이동하여 노드에서 출발하는 화살표를 확인합니다.

2. 화살표를 클릭하고 Postgres 클러스터의 hippo 데이터베이스로 드래그하여 Spring PetClinic 샘플 애플리케이션과 바인딩을 연결합니다. 서비스 바인딩 생성 대화 상자가 나타납니다.

   1. 이름을 입력하고 생성 을 클릭합니다.

      그림 6.4. 서비스 바인딩 모달

      

1. Helm 바이너리를 다운로드하여 경로에 추가합니다.

   • Linux (x86_64, amd64)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm

   • Linux on IBM Z 및 LinuxONE(s390x)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-s390x -o /usr/local/bin/helm

   • Linux on IBM Power(ppc64le)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-ppc64le -o /usr/local/bin/helm

2. 바이너리 파일을 실행 가능하게 합니다.

   # chmod +x /usr/local/bin/helm

3. 설치된 버전을 확인합니다.

   $ helm version

   출력 예

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

1. 최신 .exe 파일을 다운로드하여 기본 설정 디렉터리에 배치합니다.
2. 시작을 마우스 오른쪽 버튼으로 클릭하고 제어판을 클릭합니다.
3. 시스템 및 보안을 선택하고 시스템을 클릭합니다.
4. 왼쪽 메뉴에서 고급 시스템 설정을 선택하고 아래에 있는 환경 변수를 클릭합니다.
5. 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
6. 새로 생성을 클릭하고 필드에 .exe 파일이 있는 폴더의 경로를 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.

1. 최신 .exe 파일을 다운로드하여 기본 설정 디렉터리에 배치합니다.
2. 검색을 클릭하고 env 또는 environment를 입력합니다.
3. 계정의 환경 변수 편집을 선택합니다.
4. 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
5. 새로 생성을 클릭하고 필드에 exe 파일이 있는 디렉터리의 경로를 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.

1. Helm 바이너리를 다운로드하여 경로에 추가합니다.

   # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm

2. 바이너리 파일을 실행 가능하게 합니다.

   # chmod +x /usr/local/bin/helm

3. 설치된 버전을 확인합니다.

   $ helm version

   출력 예

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

절차

1. 새 프로젝트를 생성합니다.

   $ oc new-project vault

2. 로컬 Helm 클라이언트에 Helm 차트 리포지터리를 추가합니다.

   $ helm repo add openshift-helm-charts https://charts.openshift.io/

   출력 예

   "openshift-helm-charts" has been added to your repositories

3. 리포지터리를 업데이트합니다.

   $ helm repo update

4. HashiCorp Vault 예제를 설치합니다.

   $ helm install example-vault openshift-helm-charts/hashicorp-vault

   출력 예

   NAME: example-vault
   LAST DEPLOYED: Fri Mar 11 12:02:12 2022
   NAMESPACE: vault
   STATUS: deployed
   REVISION: 1
   NOTES:
   Thank you for installing HashiCorp Vault!

5. 차트가 성공적으로 설치되었는지 확인합니다.

   $ helm list

   출력 예

   NAME         	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART       	APP VERSION
   example-vault	vault    	1       	2022-03-11 12:02:12.296226673 +0530 IST	deployed	vault-0.19.0	1.9.2

1. 개발자 화면에서 +추가 보기로 이동하여 프로젝트를 선택합니다. 그런 다음 Helm 차트 옵션을 클릭하여 개발자 카탈로그의 모든 Helm 차트를 확인합니다.
2. 차트를 선택하고 해당 차트에 대한 설명, README 및 기타 세부 정보를 읽습니다.

3. Helm 차트 설치를 클릭합니다.

   그림 7.1. 개발자 카탈로그의 Helm 차트

   

4. Helm 차트 설치 페이지에서 다음을 수행합니다.

   1. 릴리스 이름 필드에 고유한 릴리스 이름을 입력합니다.
   2. 차트 버전 드롭다운 목록에서 필요한 차트 버전을 선택합니다.

   3. 보기에서 또는 YAML 보기를 사용하여 Helm 차트를 구성합니다.

      참고

      가능한 경우 YAML 보기 및 양식 보기를 전환할 수 있습니다. 다른 보기로 전환해도 데이터는 유지됩니다.

   4. 설치를 클릭하여 Helm 릴리스를 생성합니다. 릴리스가 표시되는 토폴로지 보기로 리디렉션됩니다. Helm 차트에 릴리스 노트가 있는 경우 이 차트가 사전에 선택되고 오른쪽 패널에 해당 릴리스의 릴리스 노트가 표시됩니다.

프로세스

1. 새 프로젝트를 생성합니다.

   $ oc new-project nodejs-ex-k

2. OpenShift Container Platform 오브젝트가 포함된 Node.js 차트 예를 다운로드합니다.

   $ git clone https://github.com/redhat-developer/redhat-helm-charts

3. 샘플 차트가 있는 디렉터리로 이동합니다.

   $ cd redhat-helm-charts/alpha/nodejs-ex-k/

4. Chart.yaml 파일을 편집하고 차트에 대한 설명을 추가합니다.

   apiVersion: v2 1
   name: nodejs-ex-k 2
   description: A Helm chart for OpenShift 3
   icon: https://static.redhat.com/libs/redhat/brand-assets/latest/corp/logo.svg 4
   version: 0.2.1 5

   1

   차트 API 버전. Helm 3 이상이 필요한 Helm 차트 v2여야 합니다.

   2

   차트 이름.

   3

   차트 설명.

   4

   아이콘으로 사용할 이미지의 URL.

   5

   Semantic Versioning (SemVer) 2.0.0 사양에 따라 차트 버전입니다.

5. 차트 형식이 올바르게 지정되었는지 확인합니다.

   $ helm lint

   출력 예

   [INFO] Chart.yaml: icon is recommended
   
   1 chart(s) linted, 0 chart(s) failed

6. 이전 디렉터리 수준으로 이동합니다.

   $ cd ..

7. 차트를 설치합니다.

   $ helm install nodejs-chart nodejs-ex-k

8. 차트가 성공적으로 설치되었는지 확인합니다.

   $ helm list

   출력 예

   NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
   nodejs-chart nodejs-ex-k 1 2019-12-05 15:06:51.379134163 -0500 EST deployed nodejs-0.1.0  1.16.0

프로세스

1. 새 Helm 차트 리포지터리를 추가하려면 클러스터에 Helm 차트 리포지터리 CR(사용자 정의 리소스)을 추가해야 합니다.

   샘플 Helm 차트 리포지터리 CR

   apiVersion: helm.openshift.io/v1beta1
   kind: HelmChartRepository
   metadata:
     name: <name>
   spec:
    # optional name that might be used by console
    # name: <chart-display-name>
     connectionConfig:
       url: <helm-chart-repository-url>

   예를 들어 Azure 샘플 차트 리포지터리를 추가하려면 다음을 실행합니다.

   $ cat <<EOF | oc apply -f -
   apiVersion: helm.openshift.io/v1beta1
   kind: HelmChartRepository
   metadata:
     name: azure-sample-repo
   spec:
     name: azure-sample-repo
     connectionConfig:
       url: https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
   EOF

2. 웹 콘솔에서 개발자 카탈로그로 이동하여 차트 리포지터리의 Helm 차트가 표시되는지 확인합니다.

   예를 들어 차트 리포지터리 필터를 사용하여 리포지터리의 Helm 차트를 검색합니다.

   그림 7.2. 차트 리포지터리 필터

   
   참고

   클러스터 관리자가 모든 차트 리포지터리를 제거하는 경우 +추가 보기, 개발자 카탈로그 및 왼쪽 탐색 패널에서 Helm 옵션을 볼 수 없습니다.

프로세스

1. 새 네임스페이스 범위의 Helm 차트 리포지터리를 추가하려면 네임스페이스에 Helm 차트 리포지터리 CR(사용자 정의 리소스)을 추가해야 합니다.

   샘플 네임스페이스 범위의 Helm 차트 리포지터리 CR

   apiVersion: helm.openshift.io/v1beta1
   kind: ProjectHelmChartRepository
   metadata:
     name: <name>
   spec:
     url: https://my.chart-repo.org/stable
   
     # optional name that might be used by console
     name: <chart-repo-display-name>
   
     # optional and only needed for UI purposes
     description: <My private chart repo>
   
     # required: chart repository URL
     connectionConfig:
       url: <helm-chart-repository-url>

   예를 들어 my-namespace 네임스페이스로 범위가 지정된 Azure 샘플 차트 리포지터리를 추가하려면 다음을 실행합니다.

   $ cat <<EOF | oc apply --namespace my-namespace -f -
   apiVersion: helm.openshift.io/v1beta1
   kind: ProjectHelmChartRepository
   metadata:
     name: azure-sample-repo
   spec:
     name: azure-sample-repo
     connectionConfig:
       url: https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
   EOF

   출력에서 네임스페이스 범위의 Helm 차트 리포지터리 CR이 생성되었는지 확인합니다.

   출력 예

   projecthelmchartrepository.helm.openshift.io/azure-sample-repo created

2. 웹 콘솔에서 개발자 카탈로그 로 이동하여 차트 리포지터리의 Helm 차트가 my-namespace 네임스페이스에 표시되는지 확인합니다.

   예를 들어 차트 리포지터리 필터를 사용하여 리포지터리의 Helm 차트를 검색합니다.

   그림 7.3. 네임스페이스에서 차트 리포지터리 필터

   

   또는 다음을 실행합니다.

   $ oc get projecthelmchartrepositories --namespace my-namespace

   출력 예

   NAME                     AGE
   azure-sample-repo        1m

   참고

   클러스터 관리자 또는 적절한 RBAC 권한이 있는 일반 사용자가 특정 네임스페이스의 모든 차트 리포지터리를 제거하는 경우 +추가 보기, 개발자 카탈로그, 해당 특정 네임스페이스의 왼쪽 탐색 패널에서 Helm 옵션을 볼 수 없습니다.

1. openshift-config 네임스페이스에서 PEM 인코딩 형식의 사용자 정의 CA 인증서로 ConfigMap 오브젝트를 생성한 후 구성 맵 내의 ca-bundle.crt 키에 저장합니다.

   $ oc create configmap helm-ca-cert \
   --from-file=ca-bundle.crt=/path/to/certs/ca.crt \
   -n openshift-config

2. openshift-config 네임스페이스에서 Secret 오브젝트를 생성하여 클라이언트 TLS 구성을 추가합니다.

   $ oc create secret tls helm-tls-configs \
   --cert=/path/to/certs/client.crt \
   --key=/path/to/certs/client.key \
   -n openshift-config

   클라이언트 인증서 및 키는 PEM 인코딩 형식이어야 하며 각각 tls.crt 및 tls.key 키에 저장되어야 합니다.

3. 다음과 같이 Helm 리포지터리를 추가합니다.

   $ cat <<EOF | oc apply -f -
   apiVersion: helm.openshift.io/v1beta1
   kind: HelmChartRepository
   metadata:
     name: <helm-repository>
   spec:
     name: <helm-repository>
     connectionConfig:
       url: <URL for the Helm repository>
       tlsConfig:
           name: helm-tls-configs
       ca:
   	name: helm-ca-cert
   EOF

   ConfigMap 및 Secret은 tlsConfig 및 ca 필드를 사용하는 HelmChartRepository CR에서 사용됩니다. 이러한 인증서는 Helm 리포지터리 URL에 연결하는 데 사용됩니다.

4. 기본적으로 모든 인증된 사용자는 모든 구성된 차트에 액세스할 수 있습니다. 하지만 인증서가 필요한 차트 리포지터리의 경우 다음과 같이 사용자에게 openshift-config 네임스페이스의 helm-ca-cert 구성 맵과 helm-tls-configs 시크릿에 대한 읽기 액세스 권한을 제공해야 합니다.

   $ cat <<EOF | kubectl apply -f -
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     namespace: openshift-config
     name: helm-chartrepos-tls-conf-viewer
   rules:
   - apiGroups: [""]
     resources: ["configmaps"]
     resourceNames: ["helm-ca-cert"]
     verbs: ["get"]
   - apiGroups: [""]
     resources: ["secrets"]
     resourceNames: ["helm-tls-configs"]
     verbs: ["get"]
   ---
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     namespace: openshift-config
     name: helm-chartrepos-tls-conf-viewer
   subjects:
     - kind: Group
       apiGroup: rbac.authorization.k8s.io
       name: 'system:authenticated'
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: helm-chartrepos-tls-conf-viewer
   EOF

프로세스

1. 개발자 화면에서 +추가 보기로 이동하여 프로젝트를 선택합니다.
2. 개발자 카탈로그 타일에서 Helm 차트 옵션을 선택하여 개발자 카탈로그의 모든 Helm 차트를 확인합니다.

3. 필요한 차트를 필터링하려면 Helm 차트 목록 왼쪽에 있는 필터를 사용합니다.

   • 차트 리포지토리 필터를 사용하여 Red Hat 인증 차트 또는 OpenShift Helm 차트에서 제공하는 차트를 필터링합니다.
   • 소스 필터를 사용하여 파트너,커뮤니티 또는 Red Hat에서 제공한 차트를 필터링합니다. 인증 차트는 ( ) 아이콘으로 표시됩니다.

프로세스

1. 토폴로지 보기에서 Helm 릴리스를 선택하여 측면 패널을 확인합니다.
2. 작업 → Helm 릴리스 업그레이드를 클릭합니다.
3. Helm 릴리스 업그레이드 페이지에서 업그레이드할 차트 버전을 선택한 다음 업그레이드를 클릭하면 또 하나의 Helm 릴리스가 생성됩니다. Helm 릴리스 페이지에 두 가지 리버전이 표시됩니다.

1. 개발자 화면에서 Helm 보기로 이동하여 네임스페이스에서 Helm 릴리스를 확인합니다.
2. 나열된 릴리스 옆에 있는 옵션 메뉴 를 클릭하고 롤백을 선택합니다.
3. 롤백 Helm 릴리스 페이지에서 롤백할 리버전을 선택하고 롤백을 클릭합니다.
4. Helm 릴리스 페이지에서 차트를 클릭하여 해당 릴리스의 세부 정보 및 리소스를 확인합니다.

5. 리버전 내역 탭으로 이동하여 차트의 리버전을 모두 확인합니다.

   그림 7.4. Helm 리버전 내역

   
6. 필요한 경우 특정 리버전 옆에 있는 옵션 메뉴 를 사용하여 롤백할 리버전을 선택할 수 있습니다.

프로세스

1. 토폴로지 보기에서 Helm 릴리스를 마우스 오른쪽 버튼으로 클릭하고 Helm 릴리스 설치 제거를 선택합니다.
2. 확인 프롬프트에서 차트 이름을 입력하고 설치 제거를 클릭합니다.

1. ReplicationController 정의의 요소
2. 새 배포를 자동으로 생성하는 트리거
3. 배포 간 전환을 위한 전략
4. 라이프사이클 후크

1. pre 라이프사이클 후크를 실행합니다.
2. 서지 수에 따라 새 복제 컨트롤러를 확장합니다.
3. 사용할 수 없는 최대 수에 따라 이전 복제 컨트롤러를 축소합니다.
4. 새 복제 컨트롤러가 원하는 복제본 수에 도달하고 이전 복제 컨트롤러가 0으로 스케일링될 때까지 이 스케일링을 반복합니다.
5. post 라이프사이클 후크를 실행합니다.

1. pre 라이프사이클 후크를 실행합니다.
2. 이전 배포를 0으로 축소합니다.
3. mid 라이프사이클 후크를 실행합니다.
4. 새 배포를 확장합니다.
5. post 라이프사이클 후크를 실행합니다.