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

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

   그림 2.2. 프로젝트 권한

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

프로세스

1. 관리자 관점에서 관리 → 클러스터 설정으로 이동합니다.
2. 구성 탭을 클릭합니다.
3. 구성 리소스 목록에서 Console operator.openshift.io 를 선택합니다.
4. YAML 탭으로 이동하여 YAML 코드를 보고 편집합니다.

5. spec 아래의 YAML 코드에서 프로젝트 액세스에 대해 사용 가능한 클러스터 역할 목록을 사용자 지정합니다. 다음 예제에서는 기본 admin,edit 및 view 역할을 지정합니다.

   apiVersion: operator.openshift.io/v1
   kind: Console
   metadata:
     name: cluster
   # ...
   spec:
     customization:
       projectAccess:
         availableClusterRoles:
         - admin
         - edit
         - view

6. 저장을 클릭하여 콘솔 구성 리소스에 대한 변경 사항을 저장합니다.

검증

1. 개발자 화면에서 프로젝트 페이지로 이동합니다.
2. 프로젝트 메뉴에서 프로젝트를 선택합니다.
3. 프로젝트 액세스 탭을 선택합니다.
4. Role (역할) 열에서 메뉴를 클릭하고 사용 가능한 역할이 Console 리소스 구성에 적용한 구성과 일치하는지 확인합니다.

프로세스

1. 개발자 화면에서 +추가 페이지로 이동합니다.
2. 프로젝트 메뉴에서 프로젝트를 선택합니다.
3. +추가 페이지에서 항목을 클릭한 다음 워크플로우를 따릅니다.

프로세스

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. 설정을 클릭하여 모든 구성 리소스를 확인합니다.
     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. 설정을 클릭하여 모든 구성 리소스를 확인합니다.
     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. 시작을 클릭하여 퀵 스타트 를 시작합니다.
4. 표시되는 단계를 수행합니다.

절차

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이 기본적으로 선택됩니다.
   • 파일 가져오기 유형을 편집하고 다른 전략을 선택하려면 가져오기 전략 편집 을 클릭합니다.
   • 여러 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. 선택 사항: 다음 고급 옵션을 사용하여 애플리케이션을 추가로 사용자 지정할 수 있습니다.

    라우팅

    라우팅 링크를 클릭하면 다음 작업을 수행할 수 있습니다.

    • 경로의 호스트 이름을 사용자 지정합니다.
    • 라우터에서 감시하는 경로를 지정합니다.
    • 드롭다운 목록에서 트래픽의 대상 포트를 선택합니다.

    • Secure Route 확인란을 선택하여 경로를 보호합니다. 필요한 TLS 종료 유형을 선택하고 해당 드롭다운 목록에서 안전하지 않은 트래픽에 대한 정책을 설정합니다.

      참고

      서버리스 애플리케이션의 경우 Knative 서비스에서 위의 모든 라우팅 옵션을 관리합니다. 그러나 필요한 경우 트래픽에 대한 대상 포트를 사용자 지정할 수 있습니다. 대상 포트를 지정하지 않으면 기본 포트 8080이 사용됩니다.

    도메인 매핑

    Serverless 배포를 생성하는 경우 생성 중에 사용자 정의 도메인 매핑을 Knative 서비스에 추가할 수 있습니다.

    • 고급 옵션 섹션에서 고급 라우팅 옵션 표시를 클릭합니다.

      • 서비스에 매핑할 도메인 매핑 CR이 이미 존재하는 경우 도메인 매핑 드롭다운 메뉴에서 선택할 수 있습니다.
      • 새 도메인 매핑 CR을 생성하려면 도메인 이름을 상자에 입력하고 생성 옵션을 선택합니다. 예를 들어 example.com 을 입력하면 Create "example.com" 옵션이 있습니다.

    상태 점검

    애플리케이션에 준비 상태, 활성 상태, 시작 프로브를 추가하려면 상태 점검 링크를 클릭합니다. 모든 프로브에는 기본 데이터가 미리 채워져 있습니다. 기본 데이터가 포함된 프로브를 추가하거나 필요에 따라 사용자 지정할 수 있습니다.

    상태 프로브를 사용자 지정하려면 다음을 수행합니다.

    • 필요한 경우 준비 상태 프로브 추가를 클릭하여 컨테이너에서 요청을 처리할 준비가 되었는지 확인하도록 매개변수를 수정하고 확인 표시를 선택하여 프로브를 추가합니다.
    • 필요한 경우 활성 상태 프로브 추가를 클릭하여 컨테이너가 아직 실행되고 있는지 확인하도록 매개변수를 수정하고 확인 표시를 선택하여 프로브를 추가합니다.

    • 필요한 경우 시작 프로브 추가를 클릭하여 컨테이너 내 애플리케이션이 시작되었는지 확인하도록 매개변수를 수정하고 확인 표시를 선택하여 프로브를 추가합니다.

      각 프로브의 드롭다운 목록에서 요청 유형을 HTTP GET, 컨테이너 명령 또는 TCP 소켓으로 지정할 수 있습니다. 선택한 요청 유형에 따라 양식이 변경됩니다. 그런 다음 기타 매개변수(예: 프로브의 성공 및 실패 임계값, 컨테이너를 시작한 후 첫 번째 프로브를 수행할 때까지의 시간(초), 프로브 빈도, 시간 제한 값)에 대한 기본값을 수정할 수 있습니다.

    빌드 구성 및 배포

    빌드 구성 및 배포 링크를 클릭하여 해당 구성 옵션을 확인합니다. 일부 옵션은 기본적으로 선택되어 있습니다. 필요한 트리거 및 환경 변수를 추가하여 추가로 사용자 지정할 수 있습니다.

    서버리스 애플리케이션의 경우 Knative 구성 리소스에서 DeploymentConfig 리소스 대신 배포에 필요한 상태를 유지 관리하므로 배포 옵션이 표시되지 않습니다.

    스케일링

    처음에 배포할 애플리케이션의 Pod 수 또는 인스턴스 수를 정의하려면 스케일링 링크를 클릭합니다.

    서버리스 배포를 생성하는 경우 다음 설정을 구성할 수도 있습니다.

    • min Pod 는 Knative 서비스의 지정된 시간에 실행되어야 하는 Pod 수에 대한 하한값을 결정합니다. 이는 minScale 설정이라고도 합니다.
    • Max Pod 는 Knative 서비스에 대해 언제든지 실행할 수 있는 Pod 수의 상한을 결정합니다. 이 설정을 maxScale 설정이라고도 합니다.
    • 동시성 대상은 지정된 시간에 애플리케이션의 각 인스턴스에 필요한 동시 요청 수를 결정합니다.
    • 동시성 제한 은 지정된 시간에 애플리케이션의 각 인스턴스에 대해 허용된 동시 요청 수에 대한 제한을 결정합니다.
    • 동시성 사용률 은 Knative에서 추가 트래픽을 처리하기 위해 추가 Pod를 확장하기 전에 충족해야 하는 동시 요청 제한의 백분율을 결정합니다.
    • autoscale 창은 자동 스케일러가 패닉 모드가 아닌 경우 스케일링 결정에 대한 입력을 제공하는 평균 메트릭에 대한 시간 창을 정의합니다. 이 창 중에 요청이 수신되지 않으면 서비스가 확장됩니다. 자동 스케일링 창의 기본 기간은 60s 입니다. 이를 안정된 창이라고도 합니다.

    리소스 제한

    컨테이너 실행 시 컨테이너에서 사용하도록 보장하거나 허용하는 CPU 및 메모리 리소스의 양을 설정하려면 리소스 제한 링크를 클릭합니다.

    라벨

    라벨 링크를 클릭하여 애플리케이션에 사용자 정의 라벨을 추가합니다.

11. 생성을 클릭하여 애플리케이션을 생성하고 성공 알림이 표시됩니다. 토폴로지 보기에서 애플리케이션의 빌드 상태를 확인할 수 있습니다.

프로세스

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. 유형 에서 Devfiles 를 클릭하여 특정 언어 또는 프레임워크를 지원하는 devfile을 찾습니다. 또는 키워드 필터를 사용하여 해당 이름, 태그 또는 설명을 사용하여 특정 devfile을 검색할 수 있습니다.
3. 애플리케이션을 생성하는 데 사용할 devfile을 클릭합니다. devfile 타일은 name, description, provider, documentation of the devfile을 포함한 devfile 세부 정보를 표시합니다.
4. 생성을 클릭하여 애플리케이션을 생성하고 토폴로지 보기에서 애플리케이션을 확인합니다.

절차

1. 개발자 화면에서 +추가 보기로 이동하고 개발자 카탈로그 타일에서 All Services 를 클릭하여 개발자 카탈로그에서 사용 가능한 모든 서비스를 확인합니다.
2. 모든 서비스 아래에서 프로젝트에 추가해야 하는 서비스 종류 또는 구성 요소를 선택합니다. 이 예제에서는 데이터베이스를 선택하여 모든 데이터베이스 서비스를 나열하고 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. Filter by keyword 상자를 사용하여 카탈로그에서 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. Installed Operatortekton-#189 ready for use( 사용할 수 있는 준비) 창에서 View Operator 를 클릭합니다. Installed Operators 페이지의 목록에 해당 Operator가 나타납니다.
7. Service Binding Operator가 성공적으로 설치되었는지 확인하려면 Status 가 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:ubi8-14.4-0
     postgresVersion: 14
     instances:
       - name: instance1
         dataVolumeClaimSpec:
           accessModes:
           - "ReadWriteOnce"
           resources:
             requests:
               storage: 1Gi
     backups:
       pgbackrest:
         image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:ubi8-2.38-0
         repos:
         - name: repo1
           volume:
             volumeClaimSpec:
               accessModes:
               - "ReadWriteOnce"
               resources:
                 requests:
                   storage: 1Gi
   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-9rxm-88rzq                   0/1     Completed   0          2m2s
   hippo-instance1-6psd-0                    4/4     Running     0          3m28s
   hippo-repo-host-0                         2/2     Running     0          3m28s

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

절차

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

   참고

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

   • 이름: 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가 시작되지 않습니다. 애플리케이션과 상호 작용하려고 하면 오류가 반환됩니다.

3. 애플리케이션의 경로를 생성하기 위해 서비스를 노출합니다.

   $ oc expose service spring-petclinic -n my-petclinic

   출력은 Spring -petclinic 서비스가 노출되고 Spring PetClinic 샘플 애플리케이션의 경로가 생성되는 것을 확인합니다.

   출력 예

   route.route.openshift.io/spring-petclinic exposed

절차

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. my-petclinic 네임스페이스에 Dev4Devs PostgreSQL Operator를 배포하려면 쉘에서 다음 명령을 실행합니다.

검증

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

   참고

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

   • 이름: 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. 바인딩 데이터를 환경 변수로 프로젝션하려면 CR(사용자 정의 리소스)의 ServiceBinding 리소스에서 .spec.bindAsFiles 매개변수 값을 false 로 설정합니다.

절차

1. 개발자 관점에서 관련 프로젝트(예: my-petclinic )로 전환합니다.

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

   그림 6.2. 시각적 커넥터

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

5. 선택 사항: 이러한 단계를 반복하여 생성한 다른 애플리케이션과 구성 요소 간 시각적 연결을 설정할 수 있습니다.

   그림 6.3. 여러 애플리케이션 연결

   

절차

1. 개발자 관점에서 관련 프로젝트(예: my-petclinic )로 전환합니다.
2. 토폴로지 보기에서 Spring PetClinic 샘플 애플리케이션 위에 커서를 올리면 노드에서 출발하는 화살표가 표시됩니다.
3. 화살표를 Postgres 클러스터의 hippo 데이터베이스 아이콘으로 드래그 앤 드롭하여 Spring PetClinic 샘플 애플리케이션과 바인딩합니다.

4. 서비스 바인딩 생성 대화 상자에서 기본 이름을 유지하거나 서비스 바인딩에 다른 이름을 추가한 다음 생성 을 클릭합니다.

   그림 6.4. 서비스 바인딩 대화 상자

   
5. 선택 사항: 토폴로지 보기를 사용하여 바인딩 연결에 어려움이 있는 경우 +추가 → YAML → 가져오기 YAML 로 이동합니다.

6. 선택 사항: YAML 편집기에서 ServiceBinding 리소스를 추가합니다.

   apiVersion: binding.operators.coreos.com/v1alpha1
   kind: ServiceBinding
   metadata:
       name: spring-petclinic-pgcluster
       namespace: my-petclinic
   spec:
       services:
       - group: postgres-operator.crunchydata.com
         version: v1beta1
         kind: PostgresCluster
         name: hippo
       application:
         name: spring-petclinic
         group: apps
         version: v1
         resource: deployments

   서비스 바인딩 요청이 생성되고 ServiceBinding 리소스를 통해 바인딩 연결이 생성됩니다. 데이터베이스 서비스 연결 요청이 성공하면 애플리케이션이 재배포되고 연결이 설정됩니다.

   그림 6.5. 바인딩 커넥터

   
   작은 정보

   왼쪽 화살표를 드래그하여 operator 지원 서비스에 바인딩 연결을 추가하여 컨텍스트 메뉴를 사용할 수도 있습니다.

   그림 6.6. 바인딩 연결을 생성하는 컨텍스트 메뉴

   
7. 탐색 메뉴에서 토폴로지 를 클릭합니다. 토폴로지 보기의 spring-petclinic 배포에는 웹 페이지를 볼 수 있는 Open URL 링크가 포함되어 있습니다.
8. Open URL 링크를 클릭합니다.

절차

1. 서비스 바인딩에 성공하면 바인딩 커넥터를 클릭합니다. 세부 정보 탭에 연결된 상태가 표시되는 측면 패널이 나타납니다.

   선택적으로 개발자 화면에서 다음 페이지에서 연결된 상태를 볼 수 있습니다.

   • ServiceBindings 페이지입니다.
   • ServiceBinding 세부 정보 페이지. 또한 페이지 제목에는 연결된 배지가 표시됩니다.

2. 서비스 바인딩에 실패하면 바인딩 커넥터에 빨간색 화살표 헤드가 표시되고 연결 중간에 빨간색 화살표 헤드가 표시됩니다. 이 커넥터를 클릭하여 세부 정보 탭의 측면 패널에서 Error 상태를 확인합니다. 필요한 경우 오류 상태를 클릭하여 기본 문제에 대한 특정 정보를 확인합니다.

   개발자 화면에서 다음 페이지의 오류 상태 및 툴팁을 볼 수도 있습니다.

   • ServiceBindings 페이지입니다.
   • ServiceBinding 세부 정보 페이지. 또한 페이지 제목에는 오류 배지가 표시됩니다.

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 및 IBM® 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 차트에 릴리스 노트가 있는 경우 이 차트가 사전에 선택되고 오른쪽 패널에 해당 릴리스의 릴리스 노트가 표시됩니다.
   5. 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 라이프사이클 후크를 실행합니다.