관리 가이드


Red Hat OpenShift Dev Spaces 3.18

Red Hat OpenShift Dev Spaces 3.18 관리

Red Hat Developer Group Documentation Team

초록

Red Hat OpenShift Dev Spaces를 운영하는 관리자를 위한 정보입니다.

1장. 보안 모범 사례

보다 유연한 개발 환경을 구축하는 데 도움이 될 수 있는 Red Hat OpenShift Dev Spaces의 주요 보안 관행에 대한 개요를 살펴보십시오.

Red Hat OpenShift Dev Spaces는 플랫폼을 제공하는 OpenShift 상단에서 실행되며 그 위에 작동하는 제품의 기반을 제공합니다. OpenShift 문서는 보안 강화의 진입점입니다.

OpenShift에서 프로젝트 격리

OpenShift에서 프로젝트 격리는 Kubernetes의 네임스페이스 격리와 유사하지만 프로젝트의 개념을 통해 달성됩니다. OpenShift의 프로젝트는 클러스터 내의 다양한 애플리케이션, 팀 또는 워크로드 간에 격리 및 협업을 제공하는 최상위 조직 단위입니다.

기본적으로 OpenShift Dev Spaces는 각 사용자에 대해 고유한 < username>-devspaces 프로젝트를 프로비저닝합니다. 또는 클러스터 관리자는 OpenShift 수준에서 프로젝트 자체 프로비저닝을 비활성화하고 CheCluster 사용자 정의 리소스에서 자동 네임스페이스 프로비저닝을 끌 수 있습니다.

devEnvironments:
  defaultNamespace:
    autoProvision: false
Copy to Clipboard

이 설정을 사용하면 클러스터 관리자가 각 사용자에 대한 프로비저닝을 제어하고 리소스 제한 및 할당량을 포함하여 다양한 설정을 명시적으로 구성할 수 있는 OpenShift Dev Space에 대한 선별된 액세스 권한을 얻을 수 있습니다. 4.2.2절. “사전 프로비저닝 프로젝트” 에서 프로젝트 프로비저닝에 대해 자세히 알아보십시오.

RBAC(역할 기반 액세스 제어)

기본적으로 OpenShift Dev Spaces Operator는 다음 ClusterRoles를 생성합니다.

  • <namespace>-cheworkspaces-clusterrole
  • <namespace>-cheworkspaces-devworkspace-clusterrole
참고

& lt;namespace > 접두사는 Red Hat OpenShift Dev Spaces CheCluster CR이 있는 프로젝트 이름에 해당합니다.

사용자가 Red Hat OpenShift Dev Spaces에 처음 액세스하면 < username>-devspaces 프로젝트에서 해당 RoleBinding이 생성됩니다.

네임스페이스에 사용할 수 있는 권한을 사용자에게 부여할 수 있는 모든 리소스 및 작업은 아래에 나열되어 있습니다.

표 1.1. 사용자 네임스페이스에서 사용할 수 있는 리소스 및 작업에 대한 개요입니다.
Resources작업

pods

"get", "list", "watch", "create", "delete", "update", "patch"

pods/exec

"get", "create"

pods/log

"get", "list", "watch"

pods/portforward

"get", "list", "create"

configmaps

"get", "list", "create", "update", "patch", "delete"

이벤트

"list", "watch"

secrets

"get", "list", "create", "update", "patch", "delete"

services

"get", "list", "create", "delete", "update", "patch"

routes

"get", "list", "create", "delete"

persistentvolumeclaims

"get", "list", "watch", "create", "delete", "update", "patch"

앱/배포

"get", "list", "watch", "create", "patch", "delete"

apps/replicasets

"get", "list", "patch", "delete"

네임스페이스

"get", "list"

projects

"get"

DevWorkspace

"get", "create", "delete", "list", "update", "patch", "watch"

devworkspacetemplates

"get", "create", "delete", "list", "update", "patch", "watch"

중요

각 사용자에게는 네임스페이스에만 권한이 부여되며 다른 사용자의 리소스에는 액세스할 수 없습니다. 클러스터 관리자는 사용자에게 추가 권한을 추가할 수 있습니다. 기본적으로 부여된 권한은 제거해서는 안 됩니다.

Red Hat OpenShift Dev Spaces 사용자의 클러스터 역할을 구성하려면 제품 설명서 를 참조하십시오.

역할 기반 액세스 제어에 대한 자세한 내용은 OpenShift 설명서에서 확인할 수 있습니다.

dev 환경 격리

개발 환경의 격리는 OpenShift 프로젝트를 사용하여 구현됩니다. 모든 개발자에게는 다음 오브젝트가 생성되고 관리되는 프로젝트가 있습니다.

  • IDE 서버를 포함한 CDE(Cloud Development Environment) 포드.
  • Git 토큰, SSH 키 및 Kubernetes 토큰과 같은 개발자 인증 정보가 포함된 시크릿입니다.
  • Git 이름 및 이메일과 같은 개발자별 구성이 있는 ConfigMap입니다.
  • CDE Pod가 중지된 경우에도 소스 코드와 같은 데이터를 보관하는 볼륨.
중요

네임스페이스의 리소스에 대한 액세스는 해당 리소스를 소유하는 개발자로 제한해야 합니다. 다른 개발자에게 읽기 액세스 권한을 부여하는 것은 개발자 자격 증명을 공유하는 것과 동일하므로 피해야 합니다.

권한 강화

현재 추세는 대규모 단연적 OpenShift 클러스터 대신 여러 " 목적의 적용" 클러스터로 인프라를 분할하는 것입니다. 그러나 관리자는 여전히 세분화된 액세스를 제공하고 특정 사용자에게 특정 기능의 가용성을 제한해야 할 수 있습니다.

참고

OpenShift 클러스터는 특정 사용 사례 또는 워크로드의 요구 사항과 목표를 충족하도록 특별히 설계 및 구성된 클러스터를 나타냅니다. 이는 관리할 워크로드의 특성을 기반으로 성능, 리소스 사용률 및 기타 요인을 최적화하도록 조정됩니다. Red Hat OpenShift Dev Spaces의 경우 이러한 유형의 클러스터가 프로비저닝된 것이 좋습니다.

이를 위해 다양한 그룹 및 사용자에 대한 세분화된 액세스를 설정하는 데 사용할 수 있는 선택적 속성을 CheCluster 사용자 정의 리소스에서 사용할 수 있습니다.

  • 허용 사용자
  • allowGroups
  • DenyUsers
  • denyGroups

다음은 액세스 구성의 예입니다.

 networking:
    auth:
      advancedAuthorization:
        allowUsers:
          - user-a
          - user-b
        denyUsers:
          - user-c
        allowGroups:
          - openshift-group-a
          - openshift-group-b
        denyGroups:
          - openshift-group-c
Copy to Clipboard
참고

denyUsersdenyGroup 카테고리의 사용자는 Red Hat OpenShift Dev Spaces를 사용할 수 없으며 사용자 대시보드에 액세스하려고 할 때 경고가 표시됩니다.

인증

인증된 OpenShift 사용자만 Red Hat OpenShift Dev Spaces에 액세스할 수 있습니다. 게이트웨이 Pod는 RBAC(역할 기반 액세스 제어) 하위 시스템을 사용하여 개발자가 CDE(Cloud Development Environment)에 액세스할 수 있는지 여부를 결정합니다.

CDE Gateway 컨테이너는 개발자의 Kubernetes 역할을 확인합니다. 해당 역할이 CDE 포드에 액세스할 수 있는 경우 개발 환경에 대한 연결이 허용됩니다. 기본적으로 네임스페이스의 소유자만 CDE Pod에 액세스할 수 있습니다.

중요

네임스페이스의 리소스에 대한 액세스는 해당 리소스를 소유하는 개발자로 제한해야 합니다. 다른 개발자에게 읽기 액세스 권한을 부여하는 것은 개발자 자격 증명을 공유하는 것과 동일하므로 피해야 합니다.

보안 컨텍스트 및 보안 컨텍스트 제약 조건

Red Hat OpenShift Dev Spaces는 CDE Pod 컨테이너 보안 컨텍스트 사양에 SETGIDSETUID 기능을 추가합니다.

"spec": {
  "containers": [
    "securityContext": {
            "allowPrivilegeEscalation": true,
            "capabilities": {
               "add": ["SETGID", "SETUID"],
               "drop": ["ALL","KILL","MKNOD"]
            },
            "readOnlyRootFilesystem": false,
            "runAsNonRoot": true,
            "runAsUser": 1001110000
   }
  ]
 }
Copy to Clipboard

이를 통해 사용자가 CDE 내에서 컨테이너 이미지를 빌드할 수 있습니다.

기본적으로 Red Hat OpenShift Dev Spaces는 이러한 기능으로 Pod를 시작할 수 있는 사용자에게 특정 SCC( SecurityContextConstraint )를 할당합니다. 이 SCC는 기본 restricted SCC에 비해 사용자에게 더 많은 기능을 부여하지만 anyuid SCC에 비해 더 적은 기능을 제공합니다. 이 기본 SCC는 OpenShift Dev Spaces 네임스페이스에서 미리 생성되었으며 container-build 라는 이름으로 지정됩니다.

CheCluster 사용자 정의 리소스에서 다음 속성을 설정하면 추가 기능 및 SCC를 사용자에게 할당할 수 없습니다.

spec:
  devEnvironments:
    disableContainerBuildCapabilities: true
Copy to Clipboard

리소스 할당량 및 제한 범위

리소스 할당량 및 제한 범위는 클러스터 내에서 잘못된 행위자 및 리소스 오용을 방지하는 데 사용할 수 있는 Kubernetes 기능입니다. 특히 Pod 및 컨테이너에 대한 리소스 사용 제약 조건을 설정할 수 있습니다. 리소스 할당량 및 제한 범위를 결합하여 잘못된 행위자가 과도한 리소스를 사용하지 못하도록 프로젝트별 정책을 시행할 수 있습니다.

이러한 메커니즘은 OpenShift 클러스터 내에서 리소스 관리, 안정성 및 공정성을 개선하는 데 기여합니다. 리소스 할당량제한 범위에 대한 자세한 내용은 OpenShift 설명서에서 확인할 수 있습니다.

연결이 끊긴 환경

Air-gapped OpenShift 연결이 끊긴 클러스터는 인터넷 또는 외부 네트워크와 분리된 OpenShift 클러스터를 나타냅니다. 이러한 격리는 잠재적인 데이터 위협으로부터 민감하거나 중요한 시스템을 보호하는 보안상의 이유로 발생하는 경우가 많습니다. Air-gapped 환경에서 클러스터는 외부 리포지토리 또는 레지스트리에 액세스하여 컨테이너 이미지, 업데이트 또는 종속 항목을 다운로드할 수 없습니다.

Red Hat OpenShift Dev Spaces가 지원되며 제한된 환경에 설치할 수 있습니다. 설치 지침은 공식 문서에서 확인할 수 있습니다.

확장 관리

기본적으로 Red Hat OpenShift Dev Spaces에는 Microsoft Visual Studio Code - Open Source 편집기에 대한 제한된 확장 세트가 포함된 임베디드 Open VSX 레지스트리가 포함되어 있습니다. 또는 클러스터 관리자는 수천 개의 확장 기능이 포함된 https://open-vsx.org 와 같이 사용자 정의 리소스에 다른 플러그인 레지스트리를 지정할 수 있습니다. 또한 사용자 지정 Open VSX 레지스트리를 빌드할 수도 있습니다. IDE 확장 관리에 대한 자세한 내용은 공식 문서에서 확인할 수 있습니다.

중요

추가 확장을 설치하면 잠재적인 위험이 발생할 수 있습니다. 이러한 위험을 최소화하려면 신뢰할 수 있는 소스의 확장만 설치하고 정기적으로 업데이트해야 합니다.

보안

사용자의 네임스페이스에 Kubernetes 시크릿으로 중요한 데이터를 기밀로 유지합니다(예:PAT(개인 액세스 토큰) 및 SSH 키).

Git 리포지토리

익숙한 Git 리포지토리와 신뢰할 수 있는 Git 리포지토리 내에서 작업하는 것이 중요합니다. 새 종속성을 리포지토리에 통합하기 전에 해당 종속성이 잘 유지 관리되고 정기적으로 업데이트되어 해당 코드에서 식별된 보안 취약점을 해결합니다.

2장. 설치 준비

OpenShift Dev Spaces 설치를 준비하려면 OpenShift Dev Spaces 에코시스템 및 배포 제약 조건에 대해 알아보십시오.

2.1. 지원되는 플랫폼

OpenShift Dev Spaces는 다음 CPU 아키텍처의 OpenShift 4.14-4.17에서 실행됩니다.

  • AMD64 및 Intel 64 (x86_64)
  • IBM Z (s390x)

다음 CPU 아키텍처에서는 OpenShift Dev Spaces를 실행하려면 Openshift 4.13-4.17이 필요합니다.

  • IBM Power (ppc64le)

추가 리소스

2.2. dsc 관리 툴 설치

Microsoft Windows, Apple MacOS 및 Linux에서 Red Hat OpenShift Dev Spaces 명령줄 관리 툴인 dsc 를 설치할 수 있습니다. dsc 를 사용하면 서버 시작, 중지, 업데이트 및 삭제와 같은 OpenShift Dev Spaces 서버를 수행할 수 있습니다.

사전 요구 사항

프로세스

  1. https://developers.redhat.com/products/openshift-dev-spaces/download 에서 $HOME 과 같은 디렉터리로 아카이브를 다운로드합니다.
  2. 아카이브에서 tar xvzf 를 실행하여 /dsc 디렉터리를 추출합니다.
  3. 추출된 /dsc/bin 하위 디렉터리를 $PATH 에 추가합니다.

검증

  • dsc 를 실행하여 이에 대한 정보를 봅니다.

    $ dsc
    Copy to Clipboard

추가 리소스

2.3. 아키텍처

그림 2.1. Dev Workspace Operator를 사용한 고급 OpenShift Dev Spaces 아키텍처

devworkspace와 상호 작용하는 devspace

OpenShift Dev Spaces는 세 가지 구성 요소 그룹에서 실행됩니다.

OpenShift Dev Spaces 서버 구성 요소
사용자 프로젝트 및 작업 공간을 관리합니다. 기본 구성 요소는 사용자가 작업 공간을 제어하는 사용자 대시보드입니다.
dev Workspace Operator
사용자 작업 영역을 실행하는 데 필요한 OpenShift 오브젝트를 생성하고 제어합니다. Pod,서비스PersistentVolume을 포함합니다.
사용자 작업 공간
컨테이너 기반 개발 환경인 IDE가 포함되어 있습니다.

이러한 OpenShift 기능의 역할은 핵심입니다.

dev Workspace 사용자 정의 리소스
유효한 OpenShift 오브젝트는 사용자 작업 공간을 나타내며 OpenShift Dev Spaces에서 조작합니다. 구성 요소의 세 그룹에 대한 통신 채널입니다.
OpenShift 역할 기반 액세스 제어(RBAC)
모든 리소스에 대한 액세스를 제어합니다.

2.3.1. 서버 구성 요소

OpenShift Dev Spaces 서버 구성 요소는 멀티 테넌시 및 작업 공간 관리를 보장합니다.

그림 2.2. OpenShift Dev Spaces 서버 구성 요소는 Dev Workspace Operator와 상호 작용

devworkspace와 상호 작용하는 devspaces 배포
2.3.1.1. dev Spaces Operator

OpenShift Dev Spaces Operator는 OpenShift Dev Spaces 서버 구성 요소의 전체 라이프사이클 관리를 보장합니다. 도입할 수 있습니다.

CheCluster CRD(사용자 정의 리소스 정의)
CheCluster OpenShift 오브젝트를 정의합니다.
OpenShift Dev Spaces 컨트롤러
포드, 서비스, 영구 볼륨과 같은 OpenShift Dev Spaces 인스턴스를 실행하는 데 필요한 OpenShift 오브젝트를 생성하고 제어합니다.
CheCluster CR(사용자 정의 리소스)

OpenShift Dev Spaces Operator가 있는 클러스터에서 CheCluster CR(사용자 정의 리소스)을 생성할 수 있습니다. OpenShift Dev Spaces Operator는 이 OpenShift Dev Spaces 인스턴스에서 OpenShift Dev Spaces 서버 구성 요소의 전체 라이프사이클 관리를 보장합니다.

2.3.1.2. dev Workspace Operator

Dev Workspace Operator는 OpenShift를 확장하여 Dev Workspace 지원을 제공합니다. 도입할 수 있습니다.

dev Workspace 사용자 정의 리소스 정의
Devfile v2 사양에서 Dev Workspace OpenShift 오브젝트를 정의합니다.
dev Workspace 컨트롤러
포드, 서비스 및 영구 볼륨과 같은 Dev Workspace를 실행하는 데 필요한 OpenShift 오브젝트를 생성하고 제어합니다.
dev Workspace 사용자 정의 리소스
Dev Workspace Operator가 있는 클러스터에서 Dev Workspace CR(사용자 정의 리소스)을 생성할 수 있습니다. Dev Workspace CR은 Devfile의 OpenShift 표현입니다. OpenShift 클러스터에서 사용자 작업 공간을 정의합니다.

추가 리소스

2.3.1.3. 게이트웨이

OpenShift Dev Spaces 게이트웨이에는 다음과 같은 역할이 있습니다.

  • 라우팅 요청. trle fik를 사용합니다.
  • OpenID Connect(OIDC)로 사용자 인증. OpenShift OAuth2 프록시 를 사용합니다.
  • OpenShift Dev Spaces 리소스에 대한 액세스를 제어하는 OpenShift 역할 기반 액세스 제어(RBAC) 정책을 적용합니다. 'kube-rbac-proxy' 를 사용합니다.

OpenShift Dev Spaces Operator는 이를 che-gateway 배포로 관리합니다.

다음에 대한 액세스를 제어합니다.

그림 2.3. OpenShift Dev Spaces 게이트웨이와 다른 구성 요소 간의 상호 작용

OpenShift Dev Spaces 게이트웨이와 다른 구성 요소 간의 상호 작용
2.3.1.4. 사용자 대시보드

사용자 대시보드는 Red Hat OpenShift Dev Spaces의 방문 페이지입니다. OpenShift Dev Spaces 사용자는 사용자 대시보드를 검색하여 작업 공간에 액세스하고 관리합니다. 이는 React 애플리케이션입니다. OpenShift Dev Spaces 배포는 devspaces-dashboard Deployment에서 시작합니다.

액세스할 수 있어야 합니다.

그림 2.4. 다른 구성 요소와 사용자 대시보드 상호 작용

다른 구성 요소와 사용자 대시보드 상호 작용

사용자가 사용자 대시보드를 요청하여 작업 영역을 시작할 때 사용자 대시보드는 이러한 작업 시퀀스를 실행합니다.

  1. 리포지토리 URL을 2.3.1.5절. “dev Spaces 서버” 로 전송하고 사용자가 원격 devfile에서 작업 공간을 생성할 때 반환되는 devfile이 필요합니다.
  2. 작업 공간을 설명하는 devfile을 읽습니다.
  3. 2.3.1.6절. “플러그인 레지스트리” 에서 추가 메타데이터를 수집합니다.
  4. 정보를 Dev Workspace 사용자 정의 리소스로 변환합니다.
  5. OpenShift API를 사용하여 사용자 프로젝트에서 Dev Workspace 사용자 지정 리소스를 생성합니다.
  6. Dev Workspace 사용자 정의 리소스 상태를 감시합니다.
  7. 사용자를 실행 중인 작업 공간 IDE로 리디렉션합니다.
2.3.1.5. dev Spaces 서버

추가 리소스

OpenShift Dev Spaces 서버 주요 기능은 다음과 같습니다.

  • 사용자 네임스페이스 생성.
  • 필수 보안 및 구성 맵을 사용하여 사용자 네임스페이스를 프로비저닝합니다.
  • Git 서비스 공급자와 통합하여 devfile 및 인증을 가져오고 검증합니다.

OpenShift Dev Spaces 서버는 HTTP REST API를 노출하는 Java 웹 서비스이며 다음에 액세스해야 합니다.

  • Git 서비스 공급자
  • OpenShift API

그림 2.5. OpenShift Dev Spaces 다른 구성 요소와의 서버 상호 작용

OpenShift Dev Spaces 다른 구성 요소와의 서버 상호 작용
2.3.1.6. 플러그인 레지스트리

각 OpenShift Dev Spaces 작업 공간은 특정 편집기와 관련 확장 세트로 시작됩니다. OpenShift Dev Spaces 플러그인 레지스트리는 사용 가능한 편집기 및 편집기 확장 목록을 제공합니다. Devfile v2는 각 편집기 또는 확장을 설명합니다.

2.3.1.4절. “사용자 대시보드” 에서 레지스트리 콘텐츠를 읽고 있습니다.

그림 2.6. 다른 구성 요소와의 플러그인 레지스트리 상호 작용

다른 구성 요소와의 플러그인 레지스트리 상호 작용

2.3.2. 사용자 작업 공간

그림 2.7. 다른 구성 요소와의 사용자 작업 공간 상호 작용

다른 구성 요소와의 사용자 작업 공간 상호 작용

사용자 작업 영역은 컨테이너에서 실행되는 웹 IDE입니다.

사용자 작업 공간은 웹 애플리케이션입니다. 브라우저에서 실행되는 최신 IDE의 모든 서비스를 제공하는 컨테이너에서 실행되는 마이크로 서비스로 구성됩니다.

  • 편집기
  • 언어 자동 완료
  • 언어 서버
  • 디버깅 툴
  • 플러그인
  • 애플리케이션 런타임

작업 공간은 작업 공간 컨테이너 및 활성화된 플러그인과 관련 OpenShift 구성 요소를 포함하는 하나의 OpenShift Deployment입니다.

  • 컨테이너
  • ConfigMaps
  • 서비스
  • 끝점
  • 인그레스 또는 경로
  • 보안
  • 영구 볼륨(PV)

OpenShift Dev Spaces 작업 공간에는 프로젝트의 소스 코드가 포함되어 있으며 OpenShift PV(영구 볼륨)에 유지됩니다. 마이크로 서비스에는 이 공유 디렉터리에 대한 읽기/쓰기 액세스 권한이 있습니다.

devfile v2 형식을 사용하여 OpenShift Dev Spaces 작업 공간의 툴 및 런타임 애플리케이션을 지정합니다.

다음 다이어그램에서는 OpenShift Dev Spaces 작업 공간 및 해당 구성 요소를 실행하는 방법을 보여줍니다.

그림 2.8. OpenShift Dev Spaces 작업 공간 구성 요소

Workspace 구성 요소

다이어그램에는 실행 중인 작업 공간이 하나씩 있습니다.

2.4. Dev Spaces 리소스 요구 사항 계산

OpenShift Dev Spaces Operator, Dev Workspace Controller 및 사용자 작업 공간은 Pod 세트로 구성됩니다. Pod는 CPU 및 메모리 제한 및 요청의 리소스 소비에 기여합니다.

참고

devfile 예제에 대한 다음 링크는 업스트림 커뮤니티의 자료를 가리키는 포인터입니다. 이 자료에서는 사용 가능한 최신 콘텐츠와 최신 모범 사례를 나타냅니다. 이러한 팁은 Red Hat의 QE 부서에 의해 아직 진행되지 않았으며 다양한 사용자 그룹에서는 아직 검증되지 않았습니다. 이 정보를 신중하게 사용하십시오. '프로덕션' 용도 대신 교육 및 '개발' 목적에 가장 적합합니다.

프로세스

  1. 개발 환경을 정의하는 데 사용되는 devfile에 따라 달라지는 작업 공간 리소스 요구 사항을 식별합니다. 여기에는 devfile의 구성 요소 섹션에 명시적으로 지정된 작업 공간 구성 요소를 식별하는 작업이 포함됩니다.

    • 다음은 다음 구성 요소가 있는 devfile의 예입니다.

      예 2.1.

      devfile의 구성 요소는 다음 요청 및 제한을 정의합니다.

          memoryLimit: 6G
          memoryRequest: 512M
          cpuRequest: 1000m
          cpuLimit: 4000m
      Copy to Clipboard
    • 작업 영역을 시작하는 동안 내부 che-gateway 컨테이너는 다음 요청 및 제한을 사용하여 암시적으로 프로비저닝됩니다.

          memoryLimit: 256M
          memoryRequest: 64M
          cpuRequest: 50m
          cpuLimit: 500m
      Copy to Clipboard
  2. 각 작업 공간에 필요한 리소스 합계를 계산합니다. 여러 devfile을 사용하려면 예상되는 모든 devfile에 대해 이 계산을 반복합니다.

    예 2.2. 이전 단계에서 예제 devfile 의 작업 공간 요구 사항

    목적Pod컨테이너 이름메모리 제한메모리 요청CPU 제한CPU 요청

    개발자 툴

    Workspace

    6GiB

    512MiB

    4000m

    1000m

    OpenShift Dev Spaces 게이트웨이

    Workspace

    che-gateway

    256MiB

    64MiB

    500m

    50m

    합계

    6.3 GiB

    576MiB

    4500m

    1050 m

  3. 모든 사용자가 동시에 실행할 것으로 예상되는 작업 공간 수와 작업 공간당 계산된 리소스를 곱합니다.
  4. OpenShift Dev Spaces Operator, Operand 및 Dev Workspace Controller의 요구 사항 합계를 계산합니다.

    표 2.1. OpenShift Dev Spaces Operator, Operand 및 Dev Workspace Controller에 대한 기본 요구 사항
    목적Pod 이름컨테이너 이름메모리 제한메모리 요청CPU 제한CPU 요청

    OpenShift Dev Spaces Operator

    devspaces-operator

    devspaces-operator

    256MiB

    64MiB

    500m

    100m

    OpenShift Dev Spaces Server

    devspaces

    devspaces-server

    1GiB

    512MiB

    1000m

    100m

    OpenShift Dev Spaces 대시보드

    devspaces-dashboard

    devspaces-dashboard

    256MiB

    32MiB

    500m

    100m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    traefik

    4GiB

    128MiB

    1000m

    100m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    configbump

    256MiB

    64MiB

    500m

    50m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    oauth-proxy

    512MiB

    64MiB

    500m

    100m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    kube-rbac-proxy

    512MiB

    64MiB

    500m

    100m

    devfile 레지스트리

    devfile-registry

    devfile-registry

    256MiB

    32MiB

    500m

    100m

    플러그인 레지스트리

    plugin-registry

    plugin-registry

    256MiB

    32MiB

    500m

    100m

    dev Workspace Controller Manager

    devworkspace-controller-manager

    devworkspace-controller

    1GiB

    100MiB

    1000m

    250 m

    dev Workspace Controller Manager

    devworkspace-controller-manager

    kube-rbac-proxy

    해당 없음

    해당 없음

    해당 없음

    해당 없음

    dev Workspace webhook 서버

    devworkspace-webhook-server

    webhook-server

    300MiB

    20MiB

    200 m

    100m

    dev Workspace Operator Catalog

    devworkspace-operator-catalog

    registry-server

    해당 없음

    50MiB

    해당 없음

    10 m

    dev Workspace Webhook 서버

    devworkspace-webhook-server

    webhook-server

    300MiB

    20MiB

    200 m

    100m

    dev Workspace Webhook 서버

    devworkspace-webhook-server

    kube-rbac-proxy

    해당 없음

    해당 없음

    해당 없음

    해당 없음

    합계

    9 GiB

    1.2 GiB

    6.9

    1.3

3장. Dev Spaces 설치

이 섹션에서는 Red Hat OpenShift Dev Spaces를 설치하는 방법을 설명합니다.

클러스터당 하나의 OpenShift Dev Spaces 인스턴스만 배포할 수 있습니다.

3.1. 클라우드에 Dev Spaces 설치

클라우드에서 Red Hat OpenShift Dev Spaces를 배포하고 실행합니다.

사전 요구 사항

  • OpenShift Dev Spaces를 배포할 OpenShift 클러스터입니다.
  • DSC: Red Hat OpenShift Dev Spaces 명령줄 툴입니다. 2.2절. “dsc 관리 툴 설치” 을 참조하십시오.

3.1.1. 클라우드에 OpenShift Dev Spaces 배포

아래 지침에 따라 dsc 툴을 사용하여 클라우드에서 OpenShift Dev Spaces Server를 시작합니다.

3.1.2. CLI를 사용하여 OpenShift에 Dev Spaces 설치

OpenShift에 OpenShift Dev Spaces를 설치할 수 있습니다.

사전 요구 사항

프로세스

  1. 선택 사항: 이전에 이 OpenShift 클러스터에 OpenShift Dev Spaces를 배포한 경우 이전 OpenShift Dev Spaces 인스턴스가 제거되었는지 확인합니다.

    $ dsc server:delete
    Copy to Clipboard
  2. OpenShift Dev Spaces 인스턴스를 생성합니다.

    $ dsc server:deploy --platform openshift
    Copy to Clipboard

검증 단계

  1. OpenShift Dev Spaces 인스턴스 상태를 확인합니다.

    $ dsc server:status
    Copy to Clipboard
  2. OpenShift Dev Spaces 클러스터 인스턴스로 이동합니다.

    $ dsc dashboard:open
    Copy to Clipboard

3.1.3. 웹 콘솔을 사용하여 OpenShift에 Dev Spaces 설치

명령줄에 OpenShift Dev Spaces를 설치하는 데 문제가 있는 경우 OpenShift 웹 콘솔을 통해 설치할 수 있습니다.

사전 요구 사항

프로세스

  1. OpenShift 웹 콘솔의 관리자 보기에서 OperatorOperatorHub 로 이동하여 Red Hat OpenShift Dev Spaces 를 검색합니다.
  2. Red Hat OpenShift Dev Spaces Operator를 설치합니다.

    작은 정보

    웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.

    경고

    Red Hat OpenShift Dev Spaces Operator는 Dev Workspace Operator에 따라 다릅니다. Red Hat OpenShift Dev Spaces Operator를 기본이 아닌 네임스페이스에 수동으로 설치하는 경우 Dev Workspace Operator도 동일한 네임스페이스에 설치되어 있는지 확인합니다. 이는 Operator Lifecycle Manager에서 Red Hat OpenShift Dev Spaces Operator 네임스페이스의 종속성으로 Dev Workspace Operator를 설치하려고 시도하므로 후자가 다른 네임스페이스에 설치된 경우 Dev Workspace Operator의 두 가지 충돌이 발생할 수 있습니다.

경고

클러스터에서 Web Terminal Operator 를 온보드하려면 Dev Workspace Operator에 의존하므로 Red Hat OpenShift Dev Spaces Operator와 동일한 설치 네임스페이스를 사용해야 합니다. Web Terminal Operator, Red Hat OpenShift Dev Spaces Operator 및 Dev Workspace Operator가 동일한 네임스페이스에 설치되어 있어야 합니다.

  1. 다음과 같이 OpenShift에서 openshift-devspaces 프로젝트를 생성합니다.

    oc create namespace openshift-devspaces
    Copy to Clipboard
  2. Operator → 설치된 Operator Red Hat OpenShift Dev Spaces 인스턴스 사양CheClusterYAML 보기로 이동합니다.
  3. YAML 보기에서 namespace: openshift-operatorsnamespace: openshift-devspaces 로 바꿉니다.
  4. 생성을 선택합니다.

    작은 정보

검증

  1. Red Hat OpenShift Dev Spaces 인스턴스 사양에서 devspaces 로 이동하여 세부 정보 탭을 시작합니다.

  1. Message 에서 None 이 있는지 확인합니다. 즉, 오류가 없음을 의미합니다.
  2. Red Hat OpenShift Dev Spaces URL 에서 OpenShift Dev Spaces 인스턴스의 URL이 표시될 때까지 기다린 다음 URL을 열어 OpenShift Dev Spaces 대시보드를 확인합니다.
  3. 리소스 탭에서 OpenShift Dev Spaces 배포의 리소스와 해당 상태를 확인합니다.

3.1.4. 제한된 환경에서 Dev Spaces 설치

제한된 네트워크에서 작동하는 OpenShift 클러스터에서는 공용 리소스를 사용할 수 없습니다.

그러나 OpenShift Dev Spaces 및 실행 중인 작업 공간을 배포하려면 다음과 같은 공용 리소스가 필요합니다.

  • Operator 카탈로그
  • 컨테이너 이미지
  • 샘플 프로젝트

이러한 리소스를 사용할 수 있도록 하려면 OpenShift 클러스터에서 액세스할 수 있는 레지스트리의 사본으로 교체할 수 있습니다.

사전 요구 사항

프로세스

  1. 미러링 스크립트를 다운로드하여 실행하여 사용자 정의 Operator 카탈로그를 설치하고 관련 이미지( prepare-restricted-environment.sh )를 미러링합니다.

    $ bash prepare-restricted-environment.sh \
      --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.17\
      --devworkspace_operator_version "v0.32.0" \
      --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.17" \
      --prod_operator_package_name "devspaces" \
      --prod_operator_bundle_name "devspacesoperator" \
      --prod_operator_version "v3.18.0" \
      --my_registry "<my_registry>" 
    1
    Copy to Clipboard
    1
    이미지를 미러링할 프라이빗 Docker 레지스트리
  2. 이전 단계에서 che-operator-cr-patch.yaml 에 설정된 구성으로 OpenShift Dev Spaces를 설치합니다.

    $ dsc server:deploy \
      --platform=openshift \
      --olm-channel stable \
      --catalog-source-name=devspaces-disconnected-install \
      --catalog-source-namespace=openshift-marketplace \
      --skip-devworkspace-operator \
      --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml
    Copy to Clipboard
  3. OpenShift Dev Spaces 네임스페이스에서 사용자 프로젝트의 모든 Pod로 들어오는 트래픽을 허용합니다. 4.8.1절. “네트워크 정책 구성” 을 참조하십시오.
3.1.4.1. Ansible 샘플 설정

제한된 환경에서 Ansible 샘플을 사용하려면 다음 단계를 따르십시오.

사전 요구 사항

  • Microsoft Visual Studio Code - 오픈 소스 IDE
  • 64비트 x86 시스템.

프로세스

  1. 다음 이미지를 미러링합니다.

    ghcr.io/ansible/ansible-devspaces@sha256:a28fa23d254ff1b3ae10b95a0812132148f141bda4516661e40d0c49c4ace200
    registry.access.redhat.com/ubi8/python-39@sha256:301fec66443f80c3cc507ccaf72319052db5a1dc56deb55c8f169011d4bbaacb
    Copy to Clipboard
  2. 다음 도메인에 대한 액세스를 허용하도록 클러스터 프록시를 구성합니다.

    .ansible.com
    .ansible-galaxy-ng.s3.dualstack.us-east-1.amazonaws.com
    Copy to Clipboard
참고

다음 IDE 및 CPU 아키텍처에 대한 지원은 향후 릴리스에 대해 계획되어 있습니다.

  • IDE

  • CPU 아키텍처

    • IBM Power (ppc64le)
    • IBM Z (s390x)

3.2. FQDN(정규화된 도메인 이름) 찾기

명령줄 또는 OpenShift 웹 콘솔에서 조직의 OpenShift Dev Spaces 인스턴스의 FQDN(정규화된 도메인 이름)을 가져올 수 있습니다.

작은 정보

다음과 같이 OpenShift 웹 콘솔의 관리자 보기에서 조직의 OpenShift Dev Spaces 인스턴스의 FQDN을 찾을 수 있습니다. Operator → 설치된 Operator Red Hat OpenShift Dev Spaces 인스턴스 사양devspacesRed Hat OpenShift Dev Spaces URL 로 이동합니다.

사전 요구 사항

프로세스

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

    oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.status.cheURL}'
    Copy to Clipboard

3.3. Dev Spaces를 설치할 수 있는 권한

Red Hat OpenShift Dev Spaces를 다른 Kubernetes 클러스터에 설치하는 데 필요한 권한에 대해 알아봅니다.

3.3.1. CLI를 사용하여 OpenShift에 Dev Spaces를 설치할 수 있는 권한

다음은 dsc를 사용하여 OpenShift 클러스터에 OpenShift Dev Spaces를 설치하는 데 필요한 최소한의 권한 집합입니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: devspaces-install-dsc
rules:
- apiGroups: ["org.eclipse.che"]
  resources: ["checlusters"]
  verbs: ["*"]
- apiGroups: ["project.openshift.io"]
  resources: ["projects"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "create"]
- apiGroups: [""]
  resources: ["pods", "configmaps"]
  verbs: ["get", "list"]
- apiGroups: ["route.openshift.io"]
  resources: ["routes"]
  verbs: ["get", "list"]
  # OLM resources permissions
- apiGroups: ["operators.coreos.com"]
  resources: ["catalogsources", "subscriptions"]
  verbs: ["create", "get", "list", "watch"]
- apiGroups: ["operators.coreos.com"]
  resources: ["operatorgroups", "clusterserviceversions"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["operators.coreos.com"]
  resources: ["installplans"]
  verbs: ["patch", "get", "list", "watch"]
- apiGroups: ["packages.operators.coreos.com"]
  resources: ["packagemanifests"]
  verbs: ["get", "list"]
Copy to Clipboard

3.3.2. 웹 콘솔을 사용하여 OpenShift에 Dev Spaces를 설치할 수 있는 권한

다음은 웹 콘솔을 사용하여 OpenShift 클러스터에 OpenShift Dev Spaces를 설치하는 데 필요한 최소한의 권한 집합입니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: devspaces-install-web-console
rules:
- apiGroups: ["org.eclipse.che"]
  resources: ["checlusters"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "create"]
- apiGroups: ["project.openshift.io"]
  resources: ["projects"]
  verbs: ["get", "list", "create"]
  # OLM resources permissions
- apiGroups: ["operators.coreos.com"]
  resources: ["subscriptions"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["operators.coreos.com"]
  resources: ["operatorgroups"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["operators.coreos.com"]
  resources: ["clusterserviceversions", "catalogsources", "installplans"]
  verbs: ["get", "list", "watch", "delete"]
- apiGroups: ["packages.operators.coreos.com"]
  resources: ["packagemanifests", "packagemanifests/icon"]
  verbs: ["get", "list", "watch"]
  # Workaround related to viewing operators in OperatorHub
- apiGroups: ["operator.openshift.io"]
  resources: ["cloudcredentials"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["config.openshift.io"]
  resources: ["infrastructures", "authentications"]
  verbs: ["get", "list", "watch"]
Copy to Clipboard

4장. Dev Spaces 구성

이 섹션에서는 Red Hat OpenShift Dev Spaces의 구성 방법 및 옵션에 대해 설명합니다.

4.1. CheCluster 사용자 정의 리소스 이해

OpenShift Dev Spaces의 기본 배포는 Red Hat OpenShift Dev Spaces Operator에 의해 매개변수화된 CheCluster 사용자 정의 리소스로 구성됩니다.

CheCluster 사용자 정의 리소스는 Kubernetes 오브젝트입니다. CheCluster 사용자 정의 리소스 YAML 파일을 편집하여 구성할 수 있습니다. 이 파일에는 devWorkspace,cheServer,pluginRegistry,devfileRegistry,대시보드imagePuller 와 같은 각 구성 요소를 구성하는 섹션이 포함되어 있습니다.

Red Hat OpenShift Dev Spaces Operator는 CheCluster 사용자 정의 리소스를 OpenShift Dev Spaces 설치의 각 구성 요소에서 사용할 수 있는 구성 맵으로 변환합니다.

OpenShift 플랫폼은 각 구성 요소에 구성을 적용하고 필요한 Pod를 생성합니다. OpenShift가 구성 요소의 구성 변경을 감지하면 Pod를 적절하게 재시작합니다.

예 4.1. OpenShift Dev Spaces 서버 구성 요소의 기본 속성 구성

  1. cheServer 구성 요소 섹션에서 적절한 수정 사항을 사용하여 CheCluster 사용자 정의 리소스 YAML 파일을 적용합니다.
  2. Operator는 che ConfigMap 을 생성합니다.
  3. OpenShift는 ConfigMap 의 변경 사항을 감지하고 OpenShift Dev Spaces 포드를 다시 시작합니다.

4.1.1. dsc를 사용하여 설치 중에 CheCluster 사용자 정의 리소스 구성

적절한 구성으로 OpenShift Dev Spaces를 배포하려면 OpenShift Dev Spaces를 설치하는 동안 CheCluster 사용자 정의 리소스 YAML 파일을 편집합니다. 그렇지 않으면 OpenShift Dev Spaces 배포는 Operator에서 매개변수화된 기본 구성을 사용합니다.

사전 요구 사항

프로세스

  • 구성할 CheCluster 사용자 정의 리소스의 하위 집합이 포함된 che-operator-cr-patch.yaml YAML 파일을 생성합니다.

    spec:
      <component>:
          <property_to_configure>: <value>
    Copy to Clipboard
  • OpenShift Dev Spaces를 배포하고 che-operator-cr-patch.yaml 파일에 설명된 변경 사항을 적용합니다.

    $ dsc server:deploy \
    --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml \
    --platform <chosen_platform>
    Copy to Clipboard

검증

  1. 구성된 속성의 값을 확인합니다.

    $ oc get configmap che -o jsonpath='{.data.<configured_property>}' \
    -n openshift-devspaces
    Copy to Clipboard

4.1.2. CLI를 사용하여 CheCluster 사용자 정의 리소스 구성

OpenShift Dev Spaces의 실행 중인 인스턴스를 구성하려면 CheCluster 사용자 정의 리소스 YAML 파일을 편집합니다.

사전 요구 사항

  • OpenShift에서 OpenShift Dev Spaces의 인스턴스입니다.
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. 클러스터에서 CheCluster 사용자 정의 리소스를 편집합니다.

    $ oc edit checluster/devspaces -n openshift-devspaces
    Copy to Clipboard
  2. 파일을 저장하고 종료하여 변경 사항을 적용합니다.

검증

  1. 구성된 속성의 값을 확인합니다.

    $ oc get configmap che -o jsonpath='{.data.<configured_property>}' \
    -n openshift-devspaces
    Copy to Clipboard

4.1.3. CheCluster 사용자 정의 리소스 필드 참조

이 섹션에서는 CheCluster 사용자 정의 리소스를 사용자 정의하는 데 사용할 수 있는 모든 필드에 대해 설명합니다.

예 4.2. CheCluster 사용자 정의 리소스 최소 예.

apiVersion: org.eclipse.che/v2
kind: CheCluster
metadata:
  name: devspaces
  namespace: openshift-devspaces
spec:
  components: {}
  devEnvironments: {}
  networking: {}
Copy to Clipboard
표 4.1. 개발 환경 구성 옵션.
속성설명기본

allowedSources

AllowedSources는 작업 공간을 시작할 수 있는 허용된 소스를 정의합니다.

 

containerBuildConfiguration

컨테이너 빌드 구성.

 

defaultComponents

DevWorkspaces에 적용되는 기본 구성 요소입니다. 이러한 기본 구성 요소는 구성 요소가 포함되지 않은 Devfile 때 사용해야 합니다.

 

defaultEditor

를 사용하여 만들 작업 공간에 대한 기본 편집기입니다. 플러그인 ID 또는 URI일 수 있습니다. 플러그인 ID에는 게시자/이름/버전 형식이 있어야 합니다. URI는 http:// 또는 https:// 에서 시작해야 합니다.

 

defaultNamespace

사용자의 기본 네임스페이스.

{ "autoProvision": true, "template": "<username>-che"}

defaultPlugins

DevWorkspaces에 적용되는 기본 플러그인입니다.

 

deploymentStrategy

DeploymentStrategy는 기존 작업 공간 Pod를 새로 교체하는 데 사용할 배포 전략을 정의합니다. 사용 가능한 배포 계층은 RecreateRollingUpdate 입니다. Recreate 배포 전략을 사용하면 새 작업 공간이 생성되기 전에 기존 작업 공간 포드가 종료됩니다. RollingUpdate 배포 전략을 사용하면 새 작업 공간 Pod가 생성되고 새 작업 공간 Pod가 준비 상태인 경우에만 기존 작업 공간 Pod가 삭제됩니다. 지정하지 않으면 기본 Recreate 배포 전략이 사용됩니다.

 

disableContainerBuildCapabilities

컨테이너 빌드 기능을 비활성화합니다. false (기본값)로 설정하면 devEnvironments.security.containerSecurityContext 필드가 무시되고 다음 컨테이너 SecurityContext가 적용됩니다. containerSecurityContext: allowPrivilegeEscalation: true capabilities: add: - SETGID - SETUID

 

gatewayContainer

GatewayContainer 구성

 

ignoredUnrecoverableEvents

IgnoredUnrecoverableEvents는 시작 중인 작업 공간 실패 여부를 결정할 때 무시해야 하는 Kubernetes 이벤트 이름 목록을 정의합니다. 이 옵션은 일시적인 클러스터 문제가 false-positives를 트리거하는 경우 사용해야 합니다(예: 클러스터가 FailedScheduling 이벤트가 발생하는 경우). 여기에 나열된 이벤트는 작업 공간 실패를 트리거하지 않습니다.

[ "FailedScheduling"]

imagePullPolicy

imagePullPolicy는 DevWorkspace의 컨테이너에 사용되는 imagePullPolicy를 정의합니다.

 

maxNumberOfRunningWorkspacesPerCluster

전체 Kubernetes 클러스터에서 동시에 실행 중인 최대 작업 공간 수입니다. 이는 시스템의 모든 사용자에게 적용됩니다. 값을 -1로 설정하면 실행 중인 작업 공간 수에 제한이 없음을 의미합니다.

 

maxNumberOfRunningWorkspacesPerUser

사용자당 실행 중인 최대 작업 공간 수입니다. 값 -1을 사용하면 사용자가 무제한의 작업 공간을 실행할 수 있습니다.

 

maxNumberOfWorkspacesPerUser

사용자가 유지할 수 있는 총 작업 공간 수(중지 및 실행 중) 수입니다. 값 -1을 사용하면 사용자가 무제한의 작업 공간을 유지할 수 있습니다.

-1

nodeSelector

노드 선택기는 작업 공간 Pod를 실행할 수 있는 노드를 제한합니다.

 

persistUserHome

PersistUserhome은 작업 영역에서 사용자 홈 디렉터리를 유지하기 위한 구성 옵션을 정의합니다.

 

podSchedulerName

작업 공간 Pod를 위한 Pod 스케줄러입니다. 지정하지 않으면 Pod 스케줄러가 클러스터의 기본 스케줄러로 설정됩니다.

 

projectCloneContainer

프로젝트 복제 컨테이너 구성입니다.

 

runtimeClassName

runtimeClassName은 작업 공간 Pod의 spec.runtimeClassName을 지정합니다.

 

secondsOfInactivityBeforeIdling

작업 공간에 대한 유휴 시간(초)입니다. 이 시간 초과는 활동이 없는 경우 작업 공간이 유휴 상태가 되는 기간입니다. 비활성으로 인한 작업 공간 유휴 상태를 비활성화하려면 이 값을 -1로 설정합니다.

1800

secondsOfRunBeforeIdling

작업 공간에 대한 시간 초과를 초 단위로 실행합니다. 이 시간 초과는 작업 공간이 실행되는 최대 기간입니다. 작업 공간 실행 시간 초과를 비활성화하려면 이 값을 -1로 설정합니다.

-1

보안

작업 공간 보안 구성.

 

serviceAccount

작업 공간을 시작할 때 DevWorkspace Operator에서 사용하는 ServiceAccount입니다.

 

serviceAccountTokens

예상 볼륨으로 작업 공간 Pod에 마운트될 ServiceAccount 토큰 목록입니다.

 

startTimeoutSeconds

StartTimeoutSeconds는 자동으로 실패하기 전에 작업 공간을 시작하는 데 사용할 수 있는 최대 기간(초)을 결정합니다. 지정하지 않으면 기본값 300초(5분)가 사용됩니다.

300

storage

작업 공간 영구 스토리지.

{ "pvcStrategy": "per-user"}

허용 오차

작업 공간 Pod의 Pod 허용 오차는 작업 공간 Pod를 실행할 수 있는 위치를 제한합니다.

 

trustedCerts

신뢰할 수 있는 인증서 설정

 

user

사용자 구성.

 

workspacesPodAnnotations

WorkspacesPodAnnotations는 작업 공간 Pod에 대한 추가 주석을 정의합니다.

 
표 4.2. defaultNamespace 옵션.
속성설명기본

autoProvision

가 사용자 네임스페이스를 자동으로 생성할 수 있는지 여부를 나타냅니다. false로 설정하면 클러스터 관리자가 사용자 네임스페이스를 미리 생성해야 합니다.

true

템플릿

사용자 네임스페이스를 사전에 생성하지 않으면 이 필드는 첫 번째 작업 공간을 시작할 때 생성된 Kubernetes 네임스페이스를 정의합니다. < username > 및 < userid > 자리 표시자(예: che-workspace-<username>)를 사용할 수 있습니다.

"<username>-che"

표 4.3. defaultPlugins 옵션.
속성설명기본

편집기

기본 플러그인을 지정할 편집기 ID입니다. 플러그인 ID에는 게시자/이름/버전 형식이 있어야 합니다.

 

plugins

지정된 편집기의 기본 플러그인 URI입니다.

 
표 4.4. gatewayContainer 옵션.
속성설명기본

env

컨테이너에서 설정할 환경 변수 목록입니다.

 

image

컨테이너 이미지. Operator에서 제공하는 기본 컨테이너 이미지를 사용하도록 생략하거나 비워 둡니다.

 

imagePullPolicy

이미지 가져오기 정책. 기본값은 항상 Night ly,next 또는 latest 이미지의 경우 및 IfNotPresent 입니다.

 

name

컨테이너 이름.

 

resources

이 컨테이너에 필요한 컴퓨팅 리소스입니다.

 
표 4.5. 스토리지 옵션.
속성설명기본

perUserStrategyPvcConfig

사용자 PVC 전략을 사용할 때 PVC 설정입니다.

 

perWorkspaceStrategyPvcConfig

작업 공간 PVC 전략을 사용할 때 PVC 설정입니다.

 

pvcStrategy

OpenShift Dev Spaces 서버의 영구 볼륨 클레임 전략입니다. 지원되는 전략은 사용자별 (한 볼륨의 모든 작업 공간 PVC), 작업 공간 당(각 작업 공간에는 개별 PVC가 지정됨) 및 임시 (작업 공간이 중지될 때 로컬 변경 사항이 손실되는 비영구 스토리지)입니다.

"per-user"

표 4.6. 사용자별 PVC 전략 옵션.
속성설명기본

claimSize

영구 볼륨 클레임 크기. 클레임 크기를 업데이트하려면 크기 조정을 지원해야 하는 스토리지 클래스입니다.

 

storageClass

영구 볼륨 클레임의 스토리지 클래스입니다. 생략하거나 비워 두면 기본 스토리지 클래스가 사용됩니다.

 
표 4.7. 작업별 PVC 전략 옵션.
속성설명기본

claimSize

영구 볼륨 클레임 크기. 클레임 크기를 업데이트하려면 크기 조정을 지원해야 하는 스토리지 클래스입니다.

 

storageClass

영구 볼륨 클레임의 스토리지 클래스입니다. 생략하거나 비워 두면 기본 스토리지 클래스가 사용됩니다.

 
표 4.8. trustedCerts 옵션.
속성설명기본

disableWorkspaceCaBundleMount

기본적으로 Operator는 '/public-certs' 및 '/etc/pki/ca-trust/extracted/pem'의 두 위치에서 사용자 작업 공간에 CA 인증서 번들을 포함하는 'ca-certs-merged' ConfigMap을 생성하고 마운트합니다. '/etc/pki/ca-trust/extracted/pem' 디렉터리에는 시스템이 Red Hat에 신뢰할 수 있는 인증 기관(예: CentOS, Fedora)에 대해 추출된 CA 인증서를 저장하는 디렉터리입니다. 이 옵션은 '/etc/pki/ca-trust/extracted/pem' 디렉터리에 CA 번들 마운트를 비활성화하며, 여전히 '/public-certs'에 마운트됩니다.

 

gitTrustedCertsConfigMapName

ConfigMap에는 OpenShift Dev Spaces 구성 요소로 전파하고 Git에 대한 특정 구성을 제공하는 인증서가 포함되어 있습니다. https://www.eclipse.org/che/docs/stable/administration-guide/deploying-che-with-support-for-git-repositories-with-self-signed-certificates/ ConfigMap에는 app.kubernetes.io/part-of=che.eclipse.org 레이블이 있어야 합니다.

 
표 4.9. containerBuildConfiguration options.
속성설명기본

openShiftSecurityContextConstraint

컨테이너를 빌드하는 OpenShift 보안 컨텍스트 제약 조건입니다.

"container-build"

표 4.10. OpenShift Dev Spaces 구성 요소 구성.
속성설명기본

cheServer

OpenShift Dev Spaces 서버와 관련된 일반 구성 설정

{ "debug": false, "logLevel": "INFO"}

대시보드

OpenShift Dev Spaces 설치에서 사용하는 대시보드와 관련된 구성 설정입니다.

 

devWorkspace

DevWorkspace Operator 구성.

 

devfileRegistry

OpenShift Dev Spaces 설치에서 사용하는 devfile 레지스트리와 관련된 구성 설정

 

imagePuller

Kubernetes 이미지 가져오기 구성.

 

메트릭

OpenShift Dev Spaces 서버 지표 구성.

{ "enable": true}

pluginRegistry

OpenShift Dev Spaces 설치에서 사용하는 플러그인 레지스트리와 관련된 구성 설정

 
표 4.11. OpenShift Dev Spaces 서버 구성 요소와 관련된 일반 구성 설정
속성설명기본

Clusterroles

OpenShift Dev Spaces ServiceAccount에 할당된 추가 ClusterRoles. 각 역할에는 app.kubernetes.io/part-of=che.eclipse.org 레이블이 있어야 합니다. 기본값은 - < devspaces-namespace>-cheworkspaces-clusterrole - < devspaces-namespace>-cheworkspaces-namespaces-clusterrole - < devspaces-namespace>-cheworkspaces-devworkspace-clusterrole 입니다. 여기서 <devspaces-namespace>는 CheCluster CR이 생성되는 네임스페이스입니다. OpenShift Dev Spaces Operator는 이미 이러한 ClusterRoles에 있는 모든 권한을 부여해야 합니다.

 

debug

OpenShift Dev Spaces 서버의 디버그 모드를 활성화합니다.

false

배포

배포 덮어쓰기 옵션.

 

extraProperties

CheCluster CR(사용자 정의 리소스)의 다른 필드에서 이미 생성된 값 외에도 OpenShift Dev Spaces 서버에서 사용할 생성된 che ConfigMap에 적용된 추가 환경 변수 맵입니다. extraProperties 필드에 다른 CR 필드에서 che ConfigMap에 일반적으로 생성된 속성이 포함된 경우 extraProperties 에 정의된 값이 대신 사용됩니다.

 

logLevel

OpenShift Dev Spaces 서버의 로그 수준: INFO 또는 DEBUG.

"INFO"

proxy

Kubernetes 클러스터의 프록시 서버 설정 OpenShift 클러스터에 추가 구성이 필요하지 않습니다. OpenShift 클러스터에 대한 이러한 설정을 지정하면 OpenShift 프록시 구성을 덮어씁니다.

 
표 4.12. 프록시 옵션.
속성설명기본

credentialsSecretName

프록시 서버의 사용자암호 가 포함된 시크릿 이름입니다. 시크릿에는 app.kubernetes.io/part-of=che.eclipse.org 레이블이 있어야 합니다.

 

nonProxyHosts

프록시를 바이패스하여 직접 연결할 수 있는 호스트 목록입니다. 와일드카드 도메인을 사용하여 .<DOMAIN > 양식을 지정합니다. 예를 들어 - localhost - 127.0.0.1 - my.host.com - 123.42.12.32 프록시 구성이 필요한 경우에만 사용합니다. Operator는 OpenShift 클러스터 전체 프록시 구성을 준수하여 사용자 정의 리소스에서 nonProxyHosts 를 정의하면 클러스터 프록시 구성에서 비프록시 호스트 목록과 사용자 정의 리소스에 정의된 호스트 목록이 병합됩니다. 다음 페이지를 참조하십시오. https://docs.openshift.com/container-platform/latest/networking/enable-cluster-wide-proxy.html. 일부 프록시 구성에서 localhost는 127.0.0.1로 변환되지 않을 수 있습니다. 이 경우 localhost와 127.0.0.1을 모두 지정해야 합니다.

 

port

프록시 서버 포트.

 

url

프록시 서버의 URL(protocol+hostname)입니다. 프록시 구성이 필요한 경우에만 사용합니다. Operator는 OpenShift 클러스터 전체 프록시 구성을 준수하여 사용자 정의 리소스에서 url 을 정의하면 클러스터 프록시 구성을 덮어씁니다. 다음 페이지를 참조하십시오. https://docs.openshift.com/container-platform/latest/networking/enable-cluster-wide-proxy.html.

 
표 4.13. OpenShift Dev Spaces 설치에서 사용하는 플러그인 레지스트리 구성 요소와 관련된 구성 설정
속성설명기본

배포

배포 덮어쓰기 옵션.

 

disableInternalRegistry

내부 플러그인 레지스트리를 비활성화합니다.

 

externalPluginRegistries

외부 플러그인 레지스트리.

 

openVSXURL

VSX 레지스트리 URL을 엽니다. 포함된 인스턴스를 생략하면 사용됩니다.

 
표 4.14. externalPluginRegistries options.
속성설명기본

url

플러그인 레지스트리의 공용 URL입니다.

 
표 4.15. OpenShift Dev Spaces 설치에서 사용하는 Devfile 레지스트리 구성 요소와 관련된 구성 설정
속성설명기본

배포

더 이상 사용되지 않는 배포 덮어쓰기 옵션

 

disableInternalRegistry

내부 devfile 레지스트리를 비활성화합니다.

 

externalDevfileRegistries

즉시 사용 가능한 샘플 devfile을 제공하는 외부 devfile 레지스트리입니다.

 
표 4.16. externalDevfileRegistries options.
속성설명기본

url

즉시 사용할 수 있는 devfile 샘플에 서비스를 제공하는 devfile 레지스트리의 공개 기관.

 
표 4.17. OpenShift Dev Spaces 설치에서 사용하는 대시보드 구성 요소와 관련된 구성 설정입니다.
속성설명기본

브랜딩

대시보드 브랜딩 리소스.

 

배포

배포 덮어쓰기 옵션.

 

headerMessage

대시보드 헤더 메시지.

 

logLevel

대시보드의 로그 수준입니다.

"ERROR"

표 4.18. headerMessage 옵션.
속성설명기본

표시

메시지를 표시하도록 대시보드에 지시합니다.

 

text

사용자 대시보드에 경고 메시지가 표시됩니다.

 
표 4.19. Kubernetes 이미지 가져오기 구성 요소 구성입니다.
속성설명기본

enable

커뮤니티 지원 Kubernetes Image Puller Operator를 설치하고 구성합니다. 사양을 제공하지 않고 값을 true 로 설정하면 Operator에서 관리하는 기본 Kubernetes Image Puller 오브젝트가 생성됩니다. 값을 false 로 설정하면 Kubernetes Image Puller 오브젝트가 삭제되고 사양이 제공되었는지 여부에 관계없이 Operator가 제거됩니다. spec.images 필드를 비워 두면 권장되는 작업 공간 관련 이미지 세트가 자동으로 감지되고 설치 후 미리 가져옵니다. 이 Operator와 해당 동작은 커뮤니티 지원이지만 해당 페이로드는 상업적으로 지원되는 이미지를 가져오는 데 상업적으로 지원될 수 있습니다.

 

spec

CheCluster에서 이미지 풀러를 구성하는 Kubernetes 이미지 Puller 사양입니다.

 
표 4.20. OpenShift Dev Spaces 서버 지표 구성 요소 구성 요소.
속성설명기본

enable

OpenShift Dev Spaces 서버 엔드포인트에 대한 지표 를 활성화합니다.

true

표 4.21. 사용자가 원격 Git 리포지토리에서 작업할 수 있는 구성 설정입니다.
속성설명기본

azure

사용자가 Azure DevOps Service(dev.azure.com)에서 호스팅되는 리포지토리를 사용할 수 있습니다.

 

Bitbucket

사용자가 Bitbucket(bitbucket.org 또는 자체 호스팅)에서 호스팅되는 리포지토리를 사용할 수 있습니다.

 

github

사용자가 GitHub에서 호스팅되는 리포지토리(github.com 또는 GitHub Enterprise)로 작업할 수 있습니다.

 

gitlab

사용자가 GitLab(gitlab.com 또는 자체 호스팅)에서 호스팅되는 리포지토리를 사용할 수 있습니다.

 
표 4.22. GitHub 옵션.
속성설명기본

disableSubdomainIsolation

하위 도메인 격리를 비활성화합니다. 더 이상 사용되지 않는 che.eclipse.org/scm-github-disable-subdomain-isolation 주석입니다. 자세한 내용은 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-github/.

 

endpoint

GitHub 서버 엔드 포인트 URL. 더 이상 사용되지 않는 che.eclipse.org/scm-server-endpoint 주석입니다. 자세한 내용은 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-github/.

 

secretName

base64로 인코딩된 GitHub OAuth 클라이언트 ID 및 GitHub OAuth 클라이언트 시크릿이 포함된 Kubernetes 시크릿입니다. 자세한 내용은 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-github/.

 
표 4.23. GitLab 옵션.
속성설명기본

endpoint

GitLab 서버 엔드 포인트 URL. 더 이상 사용되지 않는 che.eclipse.org/scm-server-endpoint 주석입니다. 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-gitlab/.

 

secretName

base64로 인코딩된 GitHub 애플리케이션 ID 및 GitLab Application Client 시크릿이 포함된 Kubernetes 시크릿입니다. 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-gitlab/.

 
표 4.24. Bitbucket 옵션.
속성설명기본

endpoint

Bitbucket 서버 끝점 URL. 더 이상 사용되지 않는 che.eclipse.org/scm-server-endpoint 주석입니다. 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-1-for-a-bitbucket-server/.

 

secretName

base64로 인코딩된 Bitbucket OAuth 1.0 또는 OAuth 2.0 데이터가 포함된 Kubernetes 시크릿입니다. 자세한 내용은 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-1-for-a-bitbucket-server/https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-the-bitbucket-cloud/.

 
표 4.25. Azure 옵션.
속성설명기본

secretName

base64로 인코딩된 Azure DevOps 서비스 애플리케이션 ID 및 클라이언트 시크릿이 포함된 Kubernetes 시크릿입니다. 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-microsoft-azure-devops-services

 
표 4.26. 네트워킹, OpenShift Dev Spaces 인증 및 TLS 구성.
속성설명기본

annotations

Ingress(OpenShift 플랫폼의 경로)에 설정할 주석을 정의합니다. kubernetes 플랫폼의 기본값은 kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-read-timeout: "3600", nginx.ingress.kubernetes.io/proxy-connect-timeout: "3600", nginx.ingress.kubernetes.io/ssl-redirect: "true"입니다.

 

auth

인증 설정.

{ "gateway": { "configLabels": { "app": "che", "component": "che-gateway-config" } }}

domain

OpenShift 클러스터의 경우 Operator는 도메인을 사용하여 경로의 호스트 이름을 생성합니다. 생성된 호스트 이름은 che-<devspaces-namespace>.<domain>이라는 패턴을 따릅니다. <devspaces-namespace>는 CheCluster CRD가 생성되는 네임스페이스입니다. 레이블과 함께 기본이 아닌 Ingress 컨트롤러에서 제공하는 경로를 생성합니다. Kubernetes 클러스터의 경우 글로벌 인그레스 도메인이 포함되어 있습니다. 기본값이 없습니다. 이 값을 지정해야 합니다.

 

hostname

설치된 OpenShift Dev Spaces 서버의 공개 호스트 이름입니다.

 

ingressClassName

IngressClassName은 IngressClass 클러스터 리소스의 이름입니다. 클래스 이름이 IngressClassName 필드와 kubernetes.io/ingress.class 주석 모두에 정의된 경우 IngressClassName 필드가 우선합니다.

 

labels

Ingress(OpenShift 플랫폼의 경로)에 설정할 레이블을 정의합니다.

 

tlsSecretName

Ingress TLS 종료를 설정하는 데 사용되는 시크릿의 이름입니다. 필드가 빈 문자열인 경우 기본 클러스터 인증서가 사용됩니다. 시크릿에는 app.kubernetes.io/part-of=che.eclipse.org 레이블이 있어야 합니다.

 
표 4.27. 인증 옵션.
속성설명기본

advancedAuthorization

사전 인증 설정 Che에 액세스할 수 있는 사용자 및 그룹을 결정합니다. 사용자가 allowUsers 목록에 있거나 allowGroups 목록의 그룹 멤버인 경우 OpenShift Dev Spaces에 액세스할 수 있으며 denyUsers 목록도 denyGroups 목록의 멤버가 아닌 경우 OpenShift Dev Spaces에 액세스할 수 있습니다. allowUsersallowGroups 가 비어 있으면 모든 사용자가 Che에 액세스할 수 있습니다. denyUsersdenyGroups 가 비어 있으면 Che에 액세스할 수 없는 사용자는 없습니다.

 

gateway

게이트웨이 설정.

{ "configLabels": { "app": "che", "component": "che-gateway-config" }}

identityProviderURL

ID 공급자 서버의 공용 URL입니다.

 

identityToken

업스트림으로 전달할 ID 토큰입니다. id_tokenaccess_token 의 두 가지 유형이 지원됩니다. 기본값은 id_token 입니다. 이 필드는 Kubernetes용으로 만든 OpenShift Dev Spaces 설치에만 해당하며 OpenShift에서만 무시됩니다.

 

oAuthAccessTokenInactivityTimeoutSeconds

OpenShift 측에 ID 페더레이션을 설정하는 데 사용되는 OpenShift OAuthClient 리소스에서 설정할 토큰의 비활성 타임아웃입니다. 0은 이 클라이언트의 토큰이 시간 초과되지 않음을 의미합니다.

 

oAuthAccessTokenMaxAgeSeconds

OpenShift 측에 ID 페더레이션을 설정하는 데 사용되는 OpenShift OAuthClient 리소스에 토큰을 설정하는 데 사용할 토큰의 최대 기간에 액세스합니다. 0은 만료를 의미합니다.

 

oAuthClientName

OpenShift 측에 ID 페더레이션을 설정하는 데 사용되는 OpenShift OAuthClient 리소스의 이름입니다.

 

oAuthScope

액세스 토큰 범위. 이 필드는 Kubernetes용으로 만든 OpenShift Dev Spaces 설치에만 해당하며 OpenShift에서만 무시됩니다.

 

oAuthSecret

OpenShift 측에 ID 페더레이션을 설정하는 데 사용되는 OpenShift OAuthClient 리소스에 설정된 시크릿의 이름입니다. Kubernetes의 경우 일반 텍스트 oAuthSecret 값 또는 키 oAuthSecret 이 포함된 kubernetes 시크릿의 이름일 수 있으며 값은 보안입니다. 참고: 이 시크릿은 CheCluster 리소스와 동일한 네임스페이스에 있어야 하며 app.kubernetes.io/part-of=che.eclipse.org 레이블을 포함해야 합니다.

 
표 4.28. 게이트웨이 옵션.
속성설명기본

configLabels

게이트웨이 구성 레이블입니다.

{ "app": "che", "component": "che-gateway-config"}

배포

배포 덮어쓰기 옵션. 게이트웨이 배포는 여러 컨테이너로 구성되므로, 구성에서 이름별로 구분해야 합니다. - gateway - configbump - oauth-proxy - kube-rbac-proxy

 

kubeRbacProxy

OpenShift Dev Spaces 게이트웨이 Pod 내에서 kube-rbac-proxy 구성

 

oAuthProxy

OpenShift Dev Spaces 게이트웨이 포드 내에서 oauth-proxy 구성

 

traefik

OpenShift Dev Spaces 게이트웨이 포드 내에서 Restoreefik 구성

 
표 4.29. OpenShift Dev Spaces 이미지를 저장하는 대체 레지스트리 구성.
속성설명기본

hostname

이미지를 가져올 대체 컨테이너 레지스트리의 선택적 호스트 이름 또는 URL입니다. 이 값은 OpenShift Dev Spaces 배포와 관련된 모든 기본 컨테이너 이미지에 정의된 컨테이너 레지스트리 호스트 이름을 재정의합니다. 이는 제한된 환경에 OpenShift Dev Space를 설치하는 데 특히 유용합니다.

 

조직

이미지를 가져올 대체 레지스트리의 선택적 리포지토리 이름입니다. 이 값은 OpenShift Dev Spaces 배포와 관련된 모든 기본 컨테이너 이미지에 정의된 컨테이너 레지스트리 조직을 재정의합니다. 이는 제한된 환경에 OpenShift Dev Space를 설치하는 데 특히 유용합니다.

 
표 4.30. 배포 옵션.
속성설명기본

컨테이너

Pod에 속하는 컨테이너 목록입니다.

 

nodeSelector

노드 선택기는 Pod를 실행할 수 있는 노드를 제한합니다.

 

securityContext

Pod를 사용하여 실행해야 하는 보안 옵션입니다.

 

허용 오차

Pod를 실행할 수 있는 구성 요소 Pod 제한의 Pod 허용 오차입니다.

 
표 4.31. 컨테이너 옵션.
속성설명기본

env

컨테이너에서 설정할 환경 변수 목록입니다.

 

image

컨테이너 이미지. Operator에서 제공하는 기본 컨테이너 이미지를 사용하도록 생략하거나 비워 둡니다.

 

imagePullPolicy

이미지 가져오기 정책. 기본값은 항상 Night ly,next 또는 latest 이미지의 경우 및 IfNotPresent 입니다.

 

name

컨테이너 이름.

 

resources

이 컨테이너에 필요한 컴퓨팅 리소스입니다.

 
표 4.32. 컨테이너 옵션.
속성설명기본

limits

허용되는 최대 컴퓨팅 리소스 양을 설명합니다.

 

요청

필요한 최소 컴퓨팅 리소스 양을 설명합니다.

 
표 4.33. 요청 옵션.
속성설명기본

cpu

CPU(코어)입니다. (500m = .5 cores) 값을 지정하지 않으면 구성 요소에 따라 기본값이 설정됩니다. value가 0 이면 구성 요소에 대한 값이 설정되지 않습니다.

 

메모리

메모리(바이트)입니다. (500GI = 500GiB = 500 * 1024 * 1024 * 1024) 값을 지정하지 않으면 구성 요소에 따라 기본값이 설정됩니다. value가 0 이면 구성 요소에 대한 값이 설정되지 않습니다.

 
표 4.34. 제한 옵션.
속성설명기본

cpu

CPU(코어)입니다. (500m = .5 cores) 값을 지정하지 않으면 구성 요소에 따라 기본값이 설정됩니다. value가 0 이면 구성 요소에 대한 값이 설정되지 않습니다.

 

메모리

메모리(바이트)입니다. (500GI = 500GiB = 500 * 1024 * 1024 * 1024) 값을 지정하지 않으면 구성 요소에 따라 기본값이 설정됩니다. value가 0 이면 구성 요소에 대한 값이 설정되지 않습니다.

 
표 4.35. securityContext options.
속성설명기본

fsGroup

Pod의 모든 컨테이너에 적용되는 특수 추가 그룹입니다. 기본값은 1724 입니다.

 

runAsUser

컨테이너 프로세스의 진입점을 실행하는 UID입니다. 기본값은 1724 입니다.

 
표 4.36. CheCluster 사용자 정의 리소스 상태는 OpenShift Dev Spaces 설치의 관찰 상태를 정의합니다.
속성설명기본

chePhase

OpenShift Dev Spaces 배포의 현재 단계를 지정합니다.

 

cheURL

OpenShift Dev Spaces 서버의 공개 URL입니다.

 

cheVersion

현재 설치된 OpenShift Dev Spaces 버전입니다.

 

devfileRegistryURL

내부 devfile 레지스트리의 공용 URL을 더 이상 사용되지 않습니다.

 

gatewayPhase

게이트웨이 배포의 현재 단계를 지정합니다.

 

message

OpenShift Dev Spaces 배포가 현재 단계에 있는 이유에 대한 세부 정보를 나타내는 사람이 읽을 수 있는 메시지입니다.

 

pluginRegistryURL

내부 플러그인 레지스트리의 공용 URL입니다.

 

reason

OpenShift Dev Spaces 배포가 현재 단계에 있는 이유에 대한 세부 정보를 나타내는 간략한 CamelCase 메시지입니다.

 

workspaceBaseDomain

확인된 작업 공간 기본 도메인입니다. 사양에서 명시적으로 정의된 동일한 이름의 속성 사본이거나 사양에 정의되지 않고 OpenShift에서 실행 중인 경우 경로의 basedomain이 자동으로 확인됩니다.

 

4.2. 프로젝트 구성

각 사용자에 대해 OpenShift Dev Spaces는 프로젝트의 작업 공간을 격리합니다. OpenShift Dev Spaces는 레이블 및 주석이 있는 사용자 프로젝트를 식별합니다. 작업 영역을 시작할 때 필요한 프로젝트가 없는 경우 OpenShift Dev Spaces는 템플릿 이름을 사용하여 프로젝트를 생성합니다.

다음을 통해 OpenShift Dev Spaces 동작을 수정할 수 있습니다.

4.2.1. 프로젝트 이름 구성

OpenShift Dev Spaces에서 작업 공간을 시작할 때 필요한 프로젝트를 생성하는 데 사용하는 프로젝트 이름 템플릿을 구성할 수 있습니다.

유효한 프로젝트 이름 템플릿은 다음과 같은 규칙을 따릅니다.

  • &lt ;username> 또는 & lt;userid& gt; 자리 표시자는 필수입니다.
  • 사용자 이름과 ID에는 잘못된 문자를 포함할 수 없습니다. 사용자 이름 또는 ID 형식이 OpenShift 오브젝트의 이름 지정 규칙과 호환되지 않는 경우 OpenShift Dev Spaces는 호환되지 않는 문자를 - 기호로 교체하여 사용자 이름 또는 ID를 유효한 이름으로 변경합니다.
  • OpenShift Dev Spaces는 < userid > 자리 표시자를 14자 긴 문자열로 평가하고 ID가 충돌하지 않도록 임의의 6자 길이 접미사를 추가합니다. 결과는 재사용을 위해 사용자 기본 설정에 저장됩니다.
  • Kubernetes는 프로젝트 이름의 길이를 63자로 제한합니다.
  • OpenShift는 길이를 49자로 더 제한합니다.

프로세스

  • CheCluster 사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      components:
        devEnvironments:
          defaultNamespace:
            template: <workspace_namespace_template_>
    Copy to Clipboard

    예 4.3. 사용자 작업 공간 프로젝트 이름 템플릿 예

    사용자 작업 공간 프로젝트 이름 템플릿결과 프로젝트 예

    <username>-devspaces (기본값)

    user1-devspaces

    <userid>-namespace

    cge1egvsb2nhba-namespace-ul1411

    <userid>-aka-<username>-namespace

    cgezegvsb2nhba-aka-user1-namespace-6m2w2b

4.2.2. 사전 프로비저닝 프로젝트

자동 프로비저닝을 사용하는 대신 작업 공간 프로젝트를 사전에 프로비저닝할 수 있습니다. 각 사용자에 대해 절차를 반복합니다.

프로세스

  1. CheCluster 수준에서 자동 네임스페이스 프로비저닝을 비활성화합니다.

    devEnvironments:
      defaultNamespace:
        autoProvision: false
    Copy to Clipboard
  2. 다음 라벨 및 주석을 사용하여 < username > 사용자에 대한 <project_name > 프로젝트를 생성합니다.

    kind: Namespace
    apiVersion: v1
    metadata:
      name: <project_name> 
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-namespace
      annotations:
        che.eclipse.org/username: <username>
    Copy to Clipboard
    1
    선택한 프로젝트 이름을 사용합니다.

4.2.3. 사용자 네임스페이스 구성

이 절차에서는 OpenShift Dev Spaces를 사용하여 ConfigMaps,Secrets,PersistentVolumeClaim 및 기타 Kubernetes 오브젝트를 openshift-devspaces 네임스페이스에서 다양한 사용자별 네임스페이스로 복제하는 프로세스를 안내합니다. OpenShift Dev Spaces는 사용자 네임스페이스에 대한 공유 자격 증명, 구성 파일 및 인증서와 같은 중요한 구성 데이터의 동기화를 자동화합니다.

openshift-devspaces 네임스페이스에서 Kubernetes 리소스를 변경하면 OpenShift Dev Spaces가 모든 사용자 네임스페이스에서 변경 사항을 즉시 복제합니다. 반대로 Kubernetes 리소스가 사용자 네임스페이스에서 수정되면 OpenShift Dev Spaces가 변경 사항을 즉시 되돌립니다.

프로세스

  1. 아래 ConfigMap 을 생성하여 모든 사용자 네임스페이스에 복제합니다. 구성 가능성을 개선하기 위해 추가 라벨 및 주석을 추가하여 ConfigMap 을 사용자 지정할 수 있습니다. 기타 가능한 라벨 및 주석은 자동 마운트 볼륨, configmaps 및 시크릿 을 참조하십시오.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: devspaces-user-configmap
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
    data:
      ...
    Copy to Clipboard

    예 4.4. settings.xml 파일을 사용자 작업 공간에 마운트합니다.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: devspaces-user-configmap
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/.m2
    data:
      settings.xml: |
        <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
          <localRepository>/home/user/.m2/repository</localRepository>
          <interactiveMode>true</interactiveMode>
          <offline>false</offline>
        </settings>
    Copy to Clipboard
  2. 아래 Secret 을 생성하여 모든 사용자 네임스페이스에 복제합니다. 구성 가능성을 개선하기 위해 추가 라벨 및 주석을 추가하여 보안 을 사용자 지정할 수 있습니다. 기타 가능한 라벨 및 주석은 자동 마운트 볼륨, configmaps 및 시크릿 을 참조하십시오.

    kind: Secret
    apiVersion: v1
    metadata:
      name: devspaces-user-secret
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
    data:
      ...
    Copy to Clipboard

    예 4.5. 사용자 작업 공간에 인증서 마운트:

    kind: Secret
    apiVersion: v1
    metadata:
      name: devspaces-user-secret
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /etc/pki/ca-trust/source/anchors
    stringData:
      trusted-certificates.crt: |
        ...
    Copy to Clipboard
    참고

    작업 영역 시작 시 update-ca-trust 명령을 실행하여 인증서를 가져옵니다. 수동으로 또는 devfile의 postStart 이벤트에 이 명령을 추가하여 수행할 수 있습니다. devfile의 이벤트 바인딩 추가를 참조하십시오.

    예 4.6. 사용자 작업 공간에 환경 변수 마운트:

    kind: Secret
    apiVersion: v1
    metadata:
      name: devspaces-user-secret
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
      annotations:
        controller.devfile.io/mount-as: env
    stringData:
      ENV_VAR_1: value_1
      ENV_VAR_2: value_2
    Copy to Clipboard
  3. 아래의 PersistentVolumeClaim 을 생성하여 모든 사용자 네임스페이스에 복제합니다.

    구성 가능성을 개선하기 위해 추가 라벨 및 주석을 추가하여 PersistentVolumeClaim 을 사용자 지정할 수 있습니다. 기타 가능한 라벨 및 주석은 자동 마운트 볼륨, configmaps 및 시크릿 을 참조하십시오.

    PersistentVolumeClaim 을 수정하려면 openshift-devspaces 네임스페이스에 새VolumeClaim을 삭제하고 생성합니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: devspaces-user-pvc
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
    spec:
      ...
    Copy to Clipboard

    예 4.7. 사용자 작업 공간에 PersistentVolumeClaim 마운트:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: devspaces-user-pvc
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
        controller.devfile.io/mount-to-devworkspace: 'true'
      annotations:
        controller.devfile.io/mount-path: /home/user/data
        controller.devfile.io/read-only: 'true'
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi
      volumeMode: Filesystem
    Copy to Clipboard
  4. OpenShift Kubernetes Engine을 활용하려면 템플릿 오브젝트를 생성하여 각 사용자 네임스페이스에서 템플릿에 정의된 모든 리소스를 복제할 수 있습니다.

    이전에 언급한 ConfigMap,Secret, PersistentVolumeClaim 외에도Template 오브젝트에는 다음이 포함될 수 있습니다.

    • LimitRange
    • NetworkPolicy
    • resourceQuota
    • Role
    • RoleBinding

      apiVersion: template.openshift.io/v1
      kind: Template
      metadata:
        name: devspaces-user-namespace-configurator
        namespace: openshift-devspaces
        labels:
          app.kubernetes.io/part-of: che.eclipse.org
          app.kubernetes.io/component: workspaces-config
      objects:
        ...
      parameters:
      - name: PROJECT_NAME
      - name: PROJECT_ADMIN_USER
      Copy to Clipboard

      매개변수는 선택 사항이며 사용할 수 있는 매개변수를 정의합니다. 현재 PROJECT_NAMEPROJECT_ADMIN_USER 만 지원됩니다. PROJECT_NAME 은 OpenShift Dev Spaces 네임스페이스의 이름이며 PROJECT_ADMIN_USER 는 네임스페이스의 OpenShift Dev Spaces 사용자입니다.

      오브젝트의 네임스페이스 이름은 동기화 중에 사용자의 네임스페이스 이름으로 교체됩니다.

      예 4.8. Kubernetes 리소스를 사용자 네임스페이스에 복제합니다.

      apiVersion: template.openshift.io/v1
      kind: Template
      metadata:
        name: devspaces-user-namespace-configurator
        namespace: openshift-devspaces
        labels:
          app.kubernetes.io/part-of: che.eclipse.org
          app.kubernetes.io/component: workspaces-config
      objects:
      - apiVersion: v1
        kind: ResourceQuota
        metadata:
          name: devspaces-user-resource-quota
        spec:
          ...
      - apiVersion: v1
        kind: LimitRange
        metadata:
          name: devspaces-user-resource-constraint
        spec:
          ...
      - apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: devspaces-user-roles
        rules:
          ...
      - apiVersion: rbac.authorization.k8s.io/v1
        kind: RoleBinding
        metadata:
          name: devspaces-user-rolebinding
        roleRef:
          apiGroup: rbac.authorization.k8s.io
          kind: Role
          name: devspaces-user-roles
        subjects:
        - kind: User
          apiGroup: rbac.authorization.k8s.io
          name: ${PROJECT_ADMIN_USER}
      parameters:
      - name: PROJECT_ADMIN_USER
      Copy to Clipboard
      참고

      템플릿 Kubernetes 리소스 생성은 OpenShift에서만 지원됩니다.

4.3. 서버 구성 요소 구성

4.3.1. 보안 또는 ConfigMap을 파일 또는 환경 변수로 Red Hat OpenShift Dev Spaces 컨테이너에 마운트

Secret은 다음과 같은 중요한 데이터를 저장하는 OpenShift 오브젝트입니다.

  • 사용자 이름
  • 암호
  • 인증 토큰

암호화된 형태로 제공됩니다.

사용자는 다음과 같이 OpenShift Dev Spaces 관리 컨테이너에 구성이 포함된 중요한 데이터 또는 ConfigMap이 포함된 OpenShift 보안을 마운트할 수 있습니다.

  • 파일
  • 환경 변수

마운트 프로세스에서는 표준 OpenShift 마운트 메커니즘을 사용하지만 추가 주석과 레이블이 필요합니다.

4.3.1.1. OpenShift Dev Spaces 컨테이너에 파일로 시크릿 또는 ConfigMap 마운트

사전 요구 사항

  • Red Hat OpenShift Dev Spaces의 실행 중인 인스턴스.

프로세스

  1. OpenShift Dev Spaces가 배포된 OpenShift 프로젝트에서 새 OpenShift Secret 또는 ConfigMap을 생성합니다. 생성하려는 오브젝트의 레이블은 레이블 세트와 일치해야 합니다.

    • app.kubernetes.io/part-of: che.eclipse.org
    • app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
    • & lt;DEPLOYMENT_NAME >은 다음 배포에 해당합니다.

      • devspaces-dashboard
      • devfile-registry
      • plugin-registry
      • devspaces

    • & lt;OBJECT_KIND> 는 다음 중 하나입니다.

      • Secret

        또는

      • configmap

예 4.9. 예제:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

또는

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard
  1. 주석 값을 구성합니다. 주석은 지정된 오브젝트가 파일로 마운트되었음을 나타냅니다.

    • Che.eclipse.org/mount-as: file - 오브젝트가 파일로 마운트됨을 나타냅니다.
    • Che.eclipse.org/mount-path: < TARGET_PATH > - 필요한 마운트 경로를 제공합니다.

예 4.10. 예제:

apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

또는

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard

OpenShift 오브젝트에는 이름이 컨테이너에 마운트된 원하는 파일 이름과 일치해야 하는 여러 항목이 포함될 수 있습니다.

예 4.11. 예제:

apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <base64 encoded data content here>
Copy to Clipboard

또는

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <data content here>
Copy to Clipboard

그러면 ca.crt 라는 파일이 OpenShift Dev Spaces 컨테이너의 /data 경로에 마운트됩니다.

중요

OpenShift Dev Spaces 컨테이너를 변경하려면 Secret 또는 ConfigMap 오브젝트를 완전히 다시 생성합니다.

4.3.1.2. OpenShift Dev Spaces 컨테이너에 하위 경로로 시크릿 또는 ConfigMap 마운트

사전 요구 사항

  • Red Hat OpenShift Dev Spaces의 실행 중인 인스턴스.

프로세스

  1. OpenShift Dev Spaces가 배포된 OpenShift 프로젝트에서 새 OpenShift Secret 또는 ConfigMap을 생성합니다. 생성하려는 오브젝트의 레이블은 레이블 세트와 일치해야 합니다.

    • app.kubernetes.io/part-of: che.eclipse.org
    • app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
    • & lt;DEPLOYMENT_NAME >은 다음 배포에 해당합니다.

      • devspaces-dashboard
      • devfile-registry
      • plugin-registry
      • devspaces

    • & lt;OBJECT_KIND> 는 다음 중 하나입니다.

      • Secret

        또는

      • configmap

예 4.12. 예제:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

또는

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard
  1. 주석 값을 구성합니다. 주석은 지정된 오브젝트가 하위 경로로 마운트되었음을 나타냅니다.

    • Che.eclipse.org/mount-as: subpath - 오브젝트가 subPath로 마운트됨을 나타냅니다.
    • Che.eclipse.org/mount-path: < TARGET_PATH > - 필요한 마운트 경로를 제공합니다.

예 4.13. 예제:

apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

또는

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard

OpenShift 오브젝트에는 이름이 컨테이너에 마운트된 파일 이름과 일치해야 하는 여러 항목이 포함될 수 있습니다.

예 4.14. 예제:

apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <base64 encoded data content here>
Copy to Clipboard

또는

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <data content here>
Copy to Clipboard

그러면 ca.crt 라는 파일이 OpenShift Dev Spaces 컨테이너의 /data 경로에 마운트됩니다.

중요

OpenShift Dev Spaces 컨테이너를 변경하려면 Secret 또는 ConfigMap 오브젝트를 완전히 다시 생성합니다.

4.3.1.3. OpenShift Dev Spaces 컨테이너에 환경 변수로 시크릿 또는 ConfigMap 마운트

사전 요구 사항

  • Red Hat OpenShift Dev Spaces의 실행 중인 인스턴스.

프로세스

  1. OpenShift Dev Spaces가 배포된 OpenShift 프로젝트에서 새 OpenShift Secret 또는 ConfigMap을 생성합니다. 생성하려는 오브젝트의 레이블은 레이블 세트와 일치해야 합니다.

    • app.kubernetes.io/part-of: che.eclipse.org
    • app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
    • & lt;DEPLOYMENT_NAME >은 다음 배포에 해당합니다.

      • devspaces-dashboard
      • devfile-registry
      • plugin-registry
      • devspaces

    • & lt;OBJECT_KIND> 는 다음 중 하나입니다.

      • Secret

        또는

      • configmap

예 4.15. 예제:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

또는

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard
  1. 주석 값을 구성합니다. 주석은 지정된 오브젝트가 환경 변수로 마운트되었음을 나타냅니다.

    • Che.eclipse.org/mount-as: env - 오브젝트가 환경 변수로 마운트됨을 나타냅니다.
    • Che.eclipse.org/env-name: <Fcnf _ENV > - 개체 키 값을 마운트하는 데 필요한 환경 변수 이름을 제공합니다.

예 4.16. 예제:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/env-name: FOO_ENV
    che.eclipse.org/mount-as: env
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
data:
  mykey: myvalue
Copy to Clipboard

또는

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/env-name: FOO_ENV
    che.eclipse.org/mount-as: env
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
data:
  mykey: myvalue
Copy to Clipboard

그러면 다음 두 가지 환경 변수가 생성됩니다.

  • FOO_ENV
  • myValue

OpenShift Dev Spaces 컨테이너에 프로비저닝됩니다.

오브젝트가 두 개 이상의 데이터 항목을 제공하는 경우 다음과 같이 각 데이터 키에 대해 환경 변수 이름을 제공해야 합니다.

예 4.17. 예제:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/mount-as: env
    che.eclipse.org/mykey_env-name: FOO_ENV
    che.eclipse.org/otherkey_env-name: OTHER_ENV
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
stringData:
  mykey: <data_content_here>
  otherkey: <data_content_here>
Copy to Clipboard

또는

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/mount-as: env
    che.eclipse.org/mykey_env-name: FOO_ENV
    che.eclipse.org/otherkey_env-name: OTHER_ENV
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
data:
  mykey: <data content here>
  otherkey: <data content here>
Copy to Clipboard

그러면 다음 두 가지 환경 변수가 생성됩니다.

  • FOO_ENV
  • OTHER_ENV

OpenShift Dev Spaces 컨테이너에 프로비저닝됩니다.

참고

OpenShift 오브젝트의 최대 주석 이름의 길이는 63자입니다. 여기서 9 문자는 / 로 끝나는 접두사용으로 예약되어 있습니다. 이는 오브젝트에 사용할 수 있는 최대 키 길이에 대한 제한으로 작동합니다.

중요

OpenShift Dev Spaces 컨테이너를 변경하려면 Secret 또는 ConfigMap 오브젝트를 완전히 다시 생성합니다.

4.3.2. Dev Spaces 서버에 대한 고급 구성 옵션

다음 섹션에서는 OpenShift Dev Spaces 서버 구성 요소의 고급 배포 및 구성 방법에 대해 설명합니다.

4.3.2.1. OpenShift Dev Spaces 서버 고급 구성 이해

다음 섹션에서는 배포에 대한 OpenShift Dev Spaces 서버 구성 요소 고급 구성 요소에 대해 설명합니다.

다음과 같은 고급 구성이 필요합니다.

  • 표준 CheCluster 사용자 정의 리소스 필드에서 Operator가 자동으로 생성하지 않은 환경 변수를 추가합니다.
  • 표준 CheCluster 사용자 정의 리소스 필드에서 Operator가 생성한 속성을 자동으로 재정의합니다.

CheCluster 사용자 정의 리소스 서버 설정의 일부인 customCheProperties 필드에는 OpenShift Dev Spaces 서버 구성 요소에 적용할 추가 환경 변수 맵이 포함되어 있습니다.

예 4.18. 작업 공간의 기본 메모리 제한 덮어쓰기

  • CheCluster 사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    apiVersion: org.eclipse.che/v2
    kind: CheCluster
    spec:
      components:
        cheServer:
          extraProperties:
            CHE_LOGS_APPENDERS_IMPL: json
    Copy to Clipboard
참고

이전 버전의 OpenShift Dev Spaces Operator에는 이 역할을 수행하기 위해 custom 이라는 ConfigMap이 있었습니다. OpenShift Dev Spaces Operator에서 사용자 지정 이름으로 configMap 을 찾으면 custom CheProperties 필드에 포함된 데이터를 추가하고 OpenShift Dev Spaces를 재배포하고 사용자 정의 configMap 을 삭제합니다.

4.4. 자동 스케일링 구성

Red Hat OpenShift Dev Spaces 자동 스케일링의 다양한 측면에 대해 알아보십시오.

4.4.1. Red Hat OpenShift Dev Spaces 컨테이너의 복제본 수 구성

Kubernetes HorizontalPodAutoscaler (HPA)를 사용하여 OpenShift Dev Spaces 피연산자의 복제본 수를 구성하려면 배포에 대한 HPA 리소스를 정의할 수 있습니다. HPA 는 지정된 메트릭을 기반으로 복제본 수를 동적으로 조정합니다.

프로세스

  1. 대상 지표와 원하는 복제본 수를 지정하여 배포에 대한 HPA 리소스를 생성합니다.

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: scaler
      namespace: openshift-devspaces
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <deployment_name> 
    1
    
      ...
    Copy to Clipboard
    1
    & lt;deployment_name >은 다음 배포에 해당합니다.
    • devspaces
    • che-gateway
    • devspaces-dashboard
    • plugin-registry
    • devfile-registry

예 4.19. devspaces 배포를 위한 HorizontalPodAutoscaler 를 생성합니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: devspaces-scaler
  namespace: openshift-devspaces
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: devspaces
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75
Copy to Clipboard

이 예에서 HPA는 최소 2개의 복제본, 최대 5개의 복제본 및 CPU 사용률을 기반으로 하는 스케일링을 사용하여 devspace라는 배포를 대상으로 합니다.

4.4.2. 머신 자동 스케일링 구성

리소스 요구 사항에 따라 노드 수를 조정하도록 클러스터를 구성한 경우 OpenShift Dev Spaces 작업 공간의 원활한 작동을 유지하기 위해 추가 구성이 필요합니다.

자동 스케일러가 노드를 추가하고 제거할 때 작업 공간을 특별히 고려해야 합니다.

자동 스케일러에서 새 노드를 추가하면 노드 프로비저닝이 완료될 때까지 작업 공간 시작 시간이 평상보다 오래 걸릴 수 있습니다.

반대로 노드를 제거하면 작업 공간을 사용하는 동안 중단을 방지하고 저장된 데이터가 손실될 가능성이 있는 자동 스케일러에서 작업 공간 Pod를 실행하는 노드를 제거할 수 없습니다.

4.4.2.1. 자동 스케일러가 새 노드를 추가하는 경우

새 노드를 추가하는 동안 적절한 작업 공간을 시작하도록 OpenShift Dev Spaces 설치를 구성해야 합니다.

프로세스

  1. CheCluster 사용자 지정 리소스에서 자동 스케일러가 새 노드를 프로비저닝할 때 적절한 작업 공간 시작을 허용하도록 다음 필드를 설정합니다.

    spec:
      devEnvironments:
        startTimeoutSeconds: 600 
    1
    
        ignoredUnrecoverableEvents: 
    2
    
          - FailedScheduling
    Copy to Clipboard
    1
    작업 영역을 시작하는 동안 새 노드를 프로비저닝할 수 있도록 하려면 최소 600초로 설정합니다.
    2
    새 노드가 프로비저닝될 때 작업 영역을 계속 시작할 수 있도록 FailedScheduling 이벤트를 무시합니다. 이 설정은 기본적으로 활성화되어 있습니다.
4.4.2.2. 자동 스케일러가 노드를 제거하는 경우

자동 스케일러가 노드를 제거해야 할 때 작업 공간 Pod가 제거되지 않도록 하려면 모든 작업 공간 Pod에 "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" 주석을 추가합니다.

프로세스

  1. CheCluster 사용자 정의 리소스에서 spec.devEnvironments.workspacesPodAnnotations 필드에 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 주석을 추가합니다.

    spec:
      devEnvironments:
        workspacesPodAnnotations:
          cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
    Copy to Clipboard

검증 단계

  1. 작업 영역을 시작하고 작업 공간 Pod에 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 주석이 포함되어 있는지 확인합니다.

    $ oc get pod <workspace_pod_name> -o jsonpath='{.metadata.annotations.cluster-autoscaler\.kubernetes\.io/safe-to-evict}'
    false
    Copy to Clipboard

4.5. 전역적으로 작업 공간 구성

이 섹션에서는 관리자가 전역적으로 작업 공간을 구성할 수 있는 방법에 대해 설명합니다.

4.5.1. 사용자가 유지할 수 있는 작업 공간 수 제한

기본적으로 사용자는 대시보드에 무제한의 작업 공간을 유지할 수 있지만 이 수를 제한하여 클러스터의 수요를 줄일 수 있습니다.

이 구성은 CheCluster 사용자 정의 리소스의 일부입니다.

spec:
  devEnvironments:
    maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>
1
Copy to Clipboard
1
사용자당 최대 작업 공간 수를 설정합니다. 기본값 -1 을 사용하면 사용자가 무제한의 작업 공간을 유지할 수 있습니다. 양의 정수를 사용하여 사용자당 최대 작업 공간 수를 설정합니다.

프로세스

  1. OpenShift Dev Spaces 네임스페이스의 이름을 가져옵니다. 기본값은 openshift-devspaces 입니다.

    $ oc get checluster --all-namespaces \
      -o=jsonpath="{.items[*].metadata.namespace}"
    Copy to Clipboard
  2. maxNumberOfWorkspacesPerUser 를 구성합니다.

    $ oc patch checluster/devspaces -n openshift-devspaces \
    1
    
    --type='merge' -p \
    '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'
    2
    Copy to Clipboard
    1
    1단계에서 가져온 OpenShift Dev Spaces 네임스페이스입니다.
    2
    < kept_workspaces_limit> 값을 선택합니다.

4.5.2. 모든 사용자가 동시에 실행할 수 있는 작업 공간 수 제한

기본적으로 모든 사용자는 무제한 작업 공간을 실행할 수 있습니다. 모든 사용자가 동시에 실행할 수 있는 작업 공간 수를 제한할 수 있습니다. 이 구성은 CheCluster 사용자 정의 리소스의 일부입니다.

spec:
  devEnvironments:
    maxNumberOfRunningWorkspacesPerCluster: <running_workspaces_limit>
1
Copy to Clipboard
1
전체 Kubernetes 클러스터에서 동시에 실행 중인 최대 작업 공간 수입니다. 이는 시스템의 모든 사용자에게 적용됩니다. 값을 -1로 설정하면 실행 중인 작업 공간 수에 제한이 없음을 의미합니다.

프로세스

  1. maxNumberOfRunningWorkspacesPerCluster 를 구성합니다.

    oc patch checluster/devspaces -n openshift-devspaces \
    --type='merge' -p \
    '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerCluster": <running_workspaces_limit>}}}'
    1
    Copy to Clipboard
    1
    < running_workspaces_limit> 값을 선택합니다.

4.5.3. 사용자가 여러 작업 공간을 동시에 실행 가능

기본적으로 사용자는 한 번에 하나의 작업 공간만 실행할 수 있습니다. 사용자가 여러 작업 공간을 동시에 실행할 수 있습니다.

참고

기본 스토리지 방법을 사용하는 경우 Pod가 다중 노드 클러스터의 노드에 분산되는 경우 사용자가 동시에 작업 공간을 실행할 때 문제가 발생할 수 있습니다. 사용자별 공통 스토리지 전략에서 작업별 스토리지 전략으로 전환하거나 임시 스토리지 유형을 사용하면 이러한 문제를 방지하거나 해결할 수 있습니다.

이 구성은 CheCluster 사용자 정의 리소스의 일부입니다.

spec:
  devEnvironments:
    maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
1
Copy to Clipboard
1
사용자당 동시에 실행 중인 최대 작업 공간 수를 설정합니다. -1 값을 사용하면 사용자가 무제한의 작업 공간을 실행할 수 있습니다. 기본값은 1 입니다.

프로세스

  1. OpenShift Dev Spaces 네임스페이스의 이름을 가져옵니다. 기본값은 openshift-devspaces 입니다.

    $ oc get checluster --all-namespaces \
      -o=jsonpath="{.items[*].metadata.namespace}"
    Copy to Clipboard
  2. maxNumberOfRunningWorkspacesPerUser 를 구성합니다.

    $ oc patch checluster/devspaces -n openshift-devspaces \
    1
    
    --type='merge' -p \
    '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerUser": <running_workspaces_limit>}}}'
    2
    Copy to Clipboard
    1
    1단계에서 가져온 OpenShift Dev Spaces 네임스페이스입니다.
    2
    < running_workspaces_limit> 값을 선택합니다.

4.5.4. 자체 서명된 인증서가 있는 Git

자체 서명된 인증서를 사용하는 Git 공급자의 작업을 지원하도록 OpenShift Dev Spaces를 구성할 수 있습니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. OpenShift CLI 시작하기를 참조하십시오.
  • Git 버전 2 이상

프로세스

  1. Git 서버에 대한 세부 정보를 사용하여 새 ConfigMap 을 생성합니다.

    $ oc create configmap che-git-self-signed-cert \
      --from-file=ca.crt=<path_to_certificate> \  
    1
    
      --from-literal=githost=<git_server_url> -n openshift-devspaces  
    2
    Copy to Clipboard
    1
    자체 서명된 인증서의 경로입니다.
    2
    Git 서버 URL을 지정하는 선택적 매개변수(예: https://git.example.com:8443 ). 생략하면 자체 서명된 인증서는 HTTPS를 통해 모든 리포지토리에 사용됩니다.
    참고
    • 인증서 파일은 일반적으로 다음과 같은 Base64 ASCII 파일로 저장됩니다. .pem, .crt, .ca-bundle. 인증서 파일이 있는 모든 ConfigMap 은 바이너리 데이터 인증서 대신 Base64 ASCII 인증서를 사용해야 합니다.
    • 신뢰의 인증서 체인이 필요합니다. ca.crt 가 CA(인증 기관)에서 서명한 경우 ca.crt 파일에 CA 인증서를 포함해야 합니다.
  2. ConfigMap에 필요한 라벨을 추가합니다.

    $ oc label configmap che-git-self-signed-cert \
      app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
    Copy to Clipboard
  3. Git 리포지토리에 자체 서명된 인증서를 사용하도록 OpenShift Dev Spaces 피연산자를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      devEnvironments:
        trustedCerts:
          gitTrustedCertsConfigMapName: che-git-self-signed-cert
    Copy to Clipboard

검증 단계

  • 새 작업 공간을 만들고 시작합니다. 작업 영역에서 사용하는 모든 컨테이너는 자체 서명된 인증서가 있는 파일이 포함된 특수 볼륨을 마운트합니다. 컨테이너의 /etc/gitconfig 파일에는 Git 서버 호스트(URL) 및 http 섹션의 인증서 경로에 대한 정보가 포함되어 있습니다( git-config에 대한 Git 문서 참조).

    예 4.20. /etc/gitconfig 파일의 내용

    [http "https://10.33.177.118:3000"]
    sslCAInfo = /etc/config/che-git-tls-creds/certificate
    Copy to Clipboard

4.5.5. 작업 공간 nodeSelector 구성

이 섹션에서는 OpenShift Dev Spaces 작업 공간의 Pod에 nodeSelector 를 구성하는 방법을 설명합니다.

프로세스

  1. NodeSelector 사용

    OpenShift Dev Spaces는 CheCluster 사용자 정의 리소스를 사용하여 nodeSelector 를 구성합니다.

    spec:
      devEnvironments:
        nodeSelector:
          key: value
    Copy to Clipboard

    이 섹션에는 nodeSelector 규칙을 형성하려면 각 노드 라벨 에 대한 키=값 쌍 세트가 포함되어야 합니다.

  2. Taints 및 Tolerations 사용

    이 방법은 nodeSelector 와 반대의 방식으로 작동합니다. Pod가 예약될 노드를 지정하는 대신 Pod를 예약할 수 없는 노드를 지정합니다. 자세한 내용은 https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration 을 참조하십시오.

    OpenShift Dev Spaces는 CheCluster 사용자 정의 리소스를 사용하여 허용 오차 를 구성합니다.

    spec:
      devEnvironments:
        tolerations:
          - effect: NoSchedule
            key: key
            value: value
            operator: Equal
    Copy to Clipboard
중요

nodeSelector 는 OpenShift Dev Spaces 설치 중에 구성해야 합니다. 이렇게 하면 기존 작업 공간 PVC 및 Pod가 다른 영역에서 예약되므로 볼륨 선호도 충돌로 인해 기존 작업 공간이 실행되지 않습니다.

Pod 및 PVC가 대규모 다중 영역 클러스터의 다른 영역에 예약되지 않도록 하려면 PVC 생성 프로세스를 조정하는 추가 StorageClass 오브젝트( allowedTopologies 필드에 주의를 기울임)를 생성합니다.

CheCluster 사용자 정의 리소스를 통해 새로 생성된 이 StorageClass 의 이름을 OpenShift Dev Spaces에 전달합니다. 자세한 내용은 4.9.1절. “스토리지 클래스 구성” 을 참조하십시오.

4.5.6. 클라우드 개발 환경에 허용되는 URL 구성

허용된 URL은 클라우드 개발 환경(CDE)의 시작을 보호하는 데 중요한 역할을 하며, 이를 권한 있는 소스에서만 시작할 수 있도록 합니다. * 와 같은 와일드카드 지원을 사용하면 조직은 유연한 URL 패턴을 구현하여 도메인 내의 다양한 경로에 걸쳐 동적 및 보안 CDE를 시작할 수 있습니다.

  1. 허용되는 소스를 구성합니다.

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' \
        -p \
    '{
       "spec": {
         "devEnvironments": {
           "allowedSources": {
             "urls": ["url_1", "url_2"] 
    1
    
           }
         }
       }
     }'
    Copy to Clipboard
    1
    클라우드 개발 환경(CDE)을 시작하기 위해 승인된 URL의 배열입니다. CDE는 이러한 URL에서만 시작할 수 있습니다. 와일드카드 * 는 URL에서 지원됩니다. 예를 들어 https://example.com/* 에서는 example.com 내의 모든 경로에서 CDE를 시작할 수 있습니다.

4.6. 더 빠른 작업 공간 시작을 위해 이미지 캐싱

OpenShift Dev Spaces 작업 공간의 시작 시간 성능을 개선하려면 OpenShift 클러스터의 이미지를 사전 가져오는 데 사용할 수 있는 OpenShift Dev Spaces 관련 구성 요소인 Image Puller를 사용합니다.

Image Puller는 각 노드에서 관련 OpenShift Dev Spaces 작업 공간을 사전 가져오도록 구성할 수 있는 DaemonSet 을 생성하는 추가 OpenShift 배포입니다. 이러한 이미지는 OpenShift Dev Spaces 작업 공간이 시작될 때 이미 사용 가능하므로 작업 공간 시작 시간이 단축됩니다.

4.6.1. Kubernetes 이미지 가져오기 설치

다양한 사용 사례에 대해 Kubernetes Image Puller를 설치하려면 아래 지침을 따르십시오.

4.6.1.1. Kubernetes 이미지 가져오기 설치
4.6.1.2. CLI를 사용하여 OpenShift에 이미지 가져오기 설치

OpenShift oc 관리 툴을 사용하여 OpenShift에 Kubernetes 이미지 가져오기를 설치할 수 있습니다.

중요

oc CLI를 사용하여 ImagePuller를 설치하는 경우 CheCluster 사용자 정의 리소스를 통해 구성할 수 없습니다.

사전 요구 사항

프로세스

  1. doc에 따라 가져올 관련 컨테이너 이미지 목록을 수집합니다. 4.6.3절. “Kubernetes Image Puller의 기본 이미지 목록 검색”
  2. 메모리 요청 및 제한 매개 변수를 정의하여 가져온 컨테이너와 플랫폼에 충분한 메모리가 있는지 확인합니다.

    CACHING_MEMORY_REQUEST 또는 CACHING_MEMORY_LIMIT 에 대한 최소 값을 정의할 때 가져올 각 컨테이너 이미지를 실행하는 데 필요한 메모리 양을 고려하십시오.

    CACHING_MEMORY_REQUEST 또는 CACHING_MEMORY_LIMIT 의 최대 값을 정의할 때 클러스터의 DaemonSet Pod에 할당된 총 메모리를 고려하십시오.

    (memory limit) * (number of images) * (number of nodes in the cluster)
    Copy to Clipboard

    컨테이너 메모리 제한 20Mi 를 사용하여 20개의 노드에서 5개의 이미지를 가져오려면 2000Mi 의 메모리가 필요합니다.

  3. 이미지 Puller 리포지토리를 복제하고 OpenShift 템플릿이 포함된 디렉터리에 가져옵니다.

    git clone https://github.com/che-incubator/kubernetes-image-puller
    cd kubernetes-image-puller/deploy/openshift
    Copy to Clipboard
  4. 다음 매개변수를 사용하여 app.yaml,configmap.yamlserviceaccount.yaml OpenShift 템플릿을 구성합니다.

    표 4.37. app.yaml의 이미지 Puller OpenShift 템플릿 매개변수
    현재의사용법기본

    DEPLOYMENT_NAME

    ConfigMap의 DEPLOYMENT_NAME

    kubernetes-image-puller

    IMAGE

    kubernetes-image-puller 배포에 사용되는 이미지

    registry.redhat.io/devspaces/imagepuller-rhel8

    IMAGE_TAG

    가져올 이미지 태그

    latest

    SERVICEACCOUNT_NAME

    배포에서 생성하고 사용하는 ServiceAccount의 이름

    kubernetes-image-puller

    표 4.38. configmap.yaml의 이미지 Puller OpenShift 템플릿 매개변수
    현재의사용법기본

    CACHING_CPU_LIMIT

    ConfigMap의 CACHING_CPU_LIMIT

    .2

    CACHING_CPU_REQUEST

    ConfigMap의 CACHING_CPU_REQUEST

    .05

    CACHING_INTERVAL_HOURS

    ConfigMap의 CACHING_INTERVAL_HOURS 의 값

    "1"

    CACHING_MEMORY_LIMIT

    ConfigMap의 CACHING_MEMORY_LIMIT

    "20Mi"

    CACHING_MEMORY_REQUEST

    ConfigMap의 CACHING_MEMORY_REQUEST

    "10Mi"

    DAEMONSET_NAME

    ConfigMap의 DAEMONSET_NAME

    kubernetes-image-puller

    DEPLOYMENT_NAME

    ConfigMap의 DEPLOYMENT_NAME

    kubernetes-image-puller

    IMAGES

    ConfigMap의 IMAGES

    {}

    NAMESPACE

    ConfigMap의 NAMESPACE

    k8s-image-puller

    NODE_SELECTOR

    ConfigMap의 NODE_SELECTOR

    "{}"

    표 4.39. serviceaccount.yaml의 이미지 Puller OpenShift 템플릿 매개변수
    현재의사용법기본

    SERVICEACCOUNT_NAME

    배포에서 생성하고 사용하는 ServiceAccount의 이름

    kubernetes-image-puller

    KIP_IMAGE

    절전 바이너리를 복사하는 이미지 풀러 이미지

    registry.redhat.io/devspaces/imagepuller-rhel8:latest

  5. 이미지 가져오기를 호스팅할 OpenShift 프로젝트를 생성합니다.

    oc new-project <k8s-image-puller>
    Copy to Clipboard
  6. 템플릿을 처리하고 적용하여 가져오기를 설치합니다.

    oc process -f serviceaccount.yaml | oc apply -f -
    oc process -f configmap.yaml | oc apply -f -
    oc process -f app.yaml | oc apply -f -
    Copy to Clipboard

검증 단계

  1. < kubernetes-image-puller > 배포 및 < kubernetes-image-puller > DaemonSet이 있는지 확인합니다. DaemonSet에는 클러스터의 각 노드에 대한 Pod가 있어야 합니다.

    oc get deployment,daemonset,pod --namespace <k8s-image-puller>
    Copy to Clipboard
  2. < kubernetes-image-puller > ConfigMap 의 값을 확인합니다.

    oc get configmap <kubernetes-image-puller> --output yaml
    Copy to Clipboard
4.6.1.3. 웹 콘솔을 사용하여 OpenShift에 이미지 Puller 설치

OpenShift 웹 콘솔을 사용하여 OpenShift에 커뮤니티 지원 Kubernetes Image Puller Operator를 설치할 수 있습니다.

사전 요구 사항

프로세스

  1. 커뮤니티 지원 Kubernetes Image Puller Operator를 설치합니다. 웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.
  2. 커뮤니티 지원 Kubernetes Image Puller Operator에서 kubernetes-image-puller KubernetesImagePuller 피연산자를 생성합니다. 설치된 Operator에서 애플리케이션 생성 을 참조하십시오.

4.6.2. Kubernetes 이미지 가져오기 구성

이 섹션에서는 다양한 사용 사례에 맞게 Kubernetes 이미지 Puller를 구성하는 방법에 대해 설명합니다.

4.6.2.1. Kubernetes 이미지 가져오기 구성
4.6.2.2. 기본 Dev Spaces 이미지를 사전 가져오도록 이미지 Puller 구성

기본 OpenShift Dev Spaces 이미지를 사전 가져오도록 Kubernetes 이미지 가져오기를 구성할 수 있습니다. Red Hat OpenShift Dev Spaces Operator는 사전 가져올 이미지 목록을 제어하고 OpenShift Dev Spaces 업그레이드에서 자동으로 업데이트합니다.

사전 요구 사항

  • 조직의 OpenShift Dev Spaces 인스턴스가 Kubernetes 클러스터에 설치되어 실행 중입니다.
  • 이미지 Puller는 Kubernetes 클러스터에 설치됩니다.
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. OpenShift Dev Spaces 이미지를 사전 가져오도록 이미지 Puller를 구성합니다.

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' \
        --patch '{
                  "spec": {
                    "components": {
                      "imagePuller": {
                        "enable": true
                      }
                    }
                  }
                }'
    Copy to Clipboard
4.6.2.3. 사용자 정의 이미지를 사전 가져오도록 이미지 가져오기 구성

사용자 정의 이미지를 사전 가져오도록 Kubernetes 이미지 가져오기를 구성할 수 있습니다.

사전 요구 사항

  • 조직의 OpenShift Dev Spaces 인스턴스가 Kubernetes 클러스터에 설치되어 실행 중입니다.
  • 이미지 Puller는 Kubernetes 클러스터에 설치됩니다.
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. 사용자 지정 이미지를 사전 가져오도록 이미지 가져오기를 구성합니다.

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' \
        --patch '{
                  "spec": {
                    "components": {
                      "imagePuller": {
                        "enable": true,
                        "spec": {
                          "images": "NAME-1=IMAGE-1;NAME-2=IMAGE-2" 
    1
    
                        }
                      }
                    }
                  }
                }'
    Copy to Clipboard
    1
    이미지--------------------
4.6.2.4. 추가 이미지를 사전 가져오도록 이미지 가져오기 구성

추가 OpenShift Dev Spaces 이미지를 미리 가져오도록 Kubernetes 이미지 가져오기를 구성할 수 있습니다.

사전 요구 사항

  • 조직의 OpenShift Dev Spaces 인스턴스가 Kubernetes 클러스터에 설치되어 실행 중입니다.
  • 이미지 Puller는 Kubernetes 클러스터에 설치됩니다.
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. k8s-image-puller 네임스페이스를 생성합니다.

    oc create namespace k8s-image-puller
    Copy to Clipboard
  2. KubernetesImagePuller 사용자 정의 리소스를 생성합니다.

    oc apply -f - <<EOF
    apiVersion: che.eclipse.org/v1alpha1
    kind: KubernetesImagePuller
    metadata:
      name: k8s-image-puller-images
      namespace: k8s-image-puller
    spec:
      images: "__NAME-1__=__IMAGE-1__;__NAME-2__=__IMAGE-2__" 
    1
    
    EOF
    Copy to Clipboard
    1
    이미지--------------------

4.6.3. Kubernetes Image Puller의 기본 이미지 목록 검색

Kubernetes Image Puller에서 사용하는 기본 이미지 목록을 검색하는 방법을 알아봅니다. 이 기능은 이러한 이미지의 하위 집합만 미리 사용하도록 이미지 Puller를 검토 및 구성하려는 관리자에게 유용할 수 있습니다.

사전 요구 사항

  • 조직의 OpenShift Dev Spaces 인스턴스가 Kubernetes 클러스터에 설치되어 실행 중입니다.
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. OpenShift Dev Spaces Operator가 배포된 네임스페이스를 찾습니다.

    OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
    Copy to Clipboard
  2. Image Puller에서 사전 가져올 수 있는 이미지를 확인합니다.

    oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- cat /tmp/external_images.txt
    Copy to Clipboard

4.7. 관찰 기능 구성

OpenShift Dev Spaces 관찰 기능을 구성하려면 다음을 참조하십시오.

4.7.1. Woopra Telemetry 플러그인

Woopra Telemetry 플러그인 은 Red Hat OpenShift Dev Spaces 설치에서 Segment 및 Woopra로 Telemetry를 전송하도록 빌드된 플러그인입니다. 이 플러그인은 Red Hat에서 호스팅하는 Eclipse Che에서 사용하지만 Red Hat OpenShift Dev Spaces 배포는 이 플러그인을 활용할 수 있습니다. 유효한 Woopra 도메인 및 Segment Write 키 이외의 종속성이 없습니다. plugin.yaml 의 devfile v2에는 플러그인에 전달할 수 있는 4개의 환경 변수가 있습니다.

  • WECDHEPRA_DOMAIN - 이벤트를 보낼 Woopra 도메인입니다.
  • SEGMENT_WRITE_KEY - 이벤트를 Segment 및 Woopra에 보낼 쓰기 키입니다.
  • WECDHEPRA_DOMAIN_ENDPOINT - Woopra 도메인에서 직접 전달하지 않으려면 플러그인은 Woopra 도메인을 반환하는 제공된 HTTP 끝점에서 가져옵니다.
  • SEGMENT_WRITE_KEY_ENDPOINT - Segment 쓰기 키를 직접 전달하지 않으려면 플러그인에서 Segment 쓰기 키를 반환하는 제공된 HTTP 끝점에서 가져옵니다.

Red Hat OpenShift Dev Spaces 설치에서 Woopra 플러그인을 활성화하려면 다음을 수행합니다.

프로세스

  • plugin.yaml devfile v2 파일을 환경 변수가 올바르게 설정된 HTTP 서버에 배포합니다.

    1. CheCluster 사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

      spec:
        devEnvironments:
          defaultPlugins:
          - editor: eclipse/che-theia/next     
      1
      
            plugins:                           
      2
      
            - 'https://your-web-server/plugin.yaml'
      Copy to Clipboard
      1
      원격 분석 플러그인을 설정하는 editorId 입니다.
      2
      Telemetry 플러그인의 devfile v2 정의에 대한 URL입니다.

4.7.2. Telemetry 플러그인 생성

이 섹션에서는 Abstract AnalyticsManager 를 확장하고 다음 메서드를 구현하는 AnalyticsManager 클래스를 생성하는 방법을 설명합니다.

  • IsEnabled() - Telemetry 백엔드가 올바르게 작동하는지 여부를 결정합니다. 이는 항상 true 를 반환하거나 더 복잡한 검사(예: 연결 속성이 누락된 경우 false )를 반환하는 것을 의미할 수 있습니다.
  • destroy() - 원격 분석 백엔드를 종료하기 전에 실행되는 정리 방법입니다. 이 메서드는 WORKSPACE_STOPPED 이벤트를 보냅니다.
  • onActivity() - 일부 활동이 지정된 사용자에게 여전히 발생하고 있음을 알립니다. 이는 주로 WORKSPACE_INACTIVE 이벤트를 보내는 데 사용됩니다.
  • onEvent() - 원격 분석 이벤트를 원격 분석 서버에(예: WORKSPACE_USED 또는 WORKSPACE_STARTED )에 제출합니다.
  • increaseDuration() - 작은 시간 프레임으로 많은 이벤트를 보내는 대신 현재 이벤트의 기간을 늘립니다.

다음 섹션에서 다룹니다.

  • 이벤트를 표준 출력에 에코하는 원격 분석 서버를 생성합니다.
  • OpenShift Dev Spaces 원격 분석 클라이언트를 확장하고 사용자의 사용자 지정 백엔드를 구현합니다.
  • 사용자 지정 백엔드의 Dev Workspace 플러그인을 나타내는 plugin.yaml 파일을 생성합니다.
  • CheCluster 사용자 정의 리소스에서 workspacesDefaultPlugins 속성을 설정하여 OpenShift Dev Spaces 사용자 지정 플러그인의 위치를 지정합니다.
4.7.2.1. 시작하기

이 문서에서는 OpenShift Dev Spaces 원격 분석 시스템을 확장하여 사용자 지정 백엔드와 통신하는 데 필요한 단계를 설명합니다.

  1. 이벤트를 수신하는 서버 프로세스 생성
  2. OpenShift Dev Spaces 라이브러리를 확장하여 이벤트를 서버로 보내는 백엔드를 생성합니다.
  3. 컨테이너에 Telemetry 백엔드 패키징 및 이미지 레지스트리에 배포
  4. 백엔드용 플러그인 추가 및 OpenShift Dev Spaces가 Dev Workspaces에서 플러그인을 로드하도록 지시

원격 분석 백엔드의 완료된 예는 여기에서 확인할 수 있습니다.

4.7.2.2. 이벤트를 수신하는 서버 생성

이 예제에서는 Telemetry 플러그인에서 이벤트를 수신하고 표준 출력에 쓰는 서버를 생성하는 방법을 보여줍니다.

프로덕션 사용 사례의 경우 자체 Telemetry 서버를 생성하는 대신 타사 Telemetry 시스템(예: Segment, Woopra)과 통합하는 것이 좋습니다. 이 경우 공급자의 API를 사용하여 사용자 지정 백엔드에서 시스템으로 이벤트를 보냅니다.

다음 Go 코드는 포트 8080 에서 서버를 시작하고 이벤트를 표준 출력에 씁니다.

예 4.21. main.go

package main

import (
	"io/ioutil"
	"net/http"

	"go.uber.org/zap"
)

var logger *zap.SugaredLogger

func event(w http.ResponseWriter, req *http.Request) {
	switch req.Method {
	case "GET":
		logger.Info("GET /event")
	case "POST":
		logger.Info("POST /event")
	}
	body, err := req.GetBody()
	if err != nil {
		logger.With("err", err).Info("error getting body")
		return
	}
	responseBody, err := ioutil.ReadAll(body)
	if err != nil {
		logger.With("error", err).Info("error reading response body")
		return
	}
	logger.With("body", string(responseBody)).Info("got event")
}

func activity(w http.ResponseWriter, req *http.Request) {
	switch req.Method {
	case "GET":
		logger.Info("GET /activity, doing nothing")
	case "POST":
		logger.Info("POST /activity")
		body, err := req.GetBody()
		if err != nil {
			logger.With("error", err).Info("error getting body")
			return
		}
		responseBody, err := ioutil.ReadAll(body)
		if err != nil {
			logger.With("error", err).Info("error reading response body")
			return
		}
		logger.With("body", string(responseBody)).Info("got activity")
	}
}

func main() {

	log, _ := zap.NewProduction()
	logger = log.Sugar()

	http.HandleFunc("/event", event)
	http.HandleFunc("/activity", activity)
	logger.Info("Added Handlers")

	logger.Info("Starting to serve")
	http.ListenAndServe(":8080", nil)
}
Copy to Clipboard

이 코드를 기반으로 컨테이너 이미지를 생성하고 openshift-devspaces 프로젝트에서 OpenShift에 배포로 노출합니다. 예제 Telemetry 서버의 코드는 telemetry-server-example 에서 사용할 수 있습니다. 원격 분석 서버를 배포하려면 리포지토리를 복제하고 컨테이너를 빌드합니다.

$ git clone https://github.com/che-incubator/telemetry-server-example
$ cd telemetry-server-example
$ podman build -t registry/organization/telemetry-server-example:latest .
$ podman push registry/organization/telemetry-server-example:latest
Copy to Clipboard

manifest_with_ingress.yamlmanifest_with_route 둘 다 배포 및 서비스에 대한 정의가 포함되어 있습니다. 전자는 Kubernetes 인그레스도 정의하고 후자는 OpenShift 경로를 정의합니다.

매니페스트 파일에서 내보낸 이미지와 일치하도록 이미지호스트 필드와 OpenShift 클러스터의 공용 호스트 이름을 바꿉니다. 그런 다음 실행합니다.

$ kubectl apply -f manifest_with_[ingress|route].yaml -n openshift-devspaces
Copy to Clipboard
4.7.2.3. 백엔드 프로젝트 생성
참고

개발 시 신속한 피드백을 받으려면 Dev Workspace 내에서 개발을 수행하는 것이 좋습니다. 이렇게 하면 클러스터에서 애플리케이션을 실행하고 프런트 엔드 Telemetry 플러그인에서 이벤트를 수신할 수 있습니다.

  1. Maven Quarkus 프로젝트 스캐폴드:

    mvn io.quarkus:quarkus-maven-plugin:2.7.1.Final:create \
        -DprojectGroupId=mygroup -DprojectArtifactId=devworkspace-telemetry-example-plugin \
    -DprojectVersion=1.0.0-SNAPSHOT
    Copy to Clipboard
  2. src/main/java/mygroupsrc/test/java/mygroup 아래에 있는 파일을 제거합니다.
  3. 최신 버전 및 backend-base 의 Maven 좌표는 GitHub 패키지를 참조하십시오.
  4. pom.xml 에 다음 종속성을 추가합니다.

    예 4.22. pom.xml

    <!-- Required -->
    <dependency>
        <groupId>org.eclipse.che.incubator.workspace-telemetry</groupId>
        <artifactId>backend-base</artifactId>
        <version>LATEST VERSION FROM PREVIOUS STEP</version>
    </dependency>
    
    
    <!-- Used to make http requests to the telemetry server -->
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-rest-client</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-rest-client-jackson</artifactId>
    </dependency>
    Copy to Clipboard
  5. GitHub 패키지에서 org.eclipse.che.incubator.workspace-telemetry:backend-base 종속성을 다운로드할 수 있는 read:packages 권한으로 개인 액세스 토큰을 생성합니다.
  6. ~/.m2/settings.xml 파일에 GitHub 사용자 이름, 개인 액세스 토큰 및 che-incubator 리포지토리 세부 정보를 추가합니다.

    예 4.23. settings.xml

    <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
    http://maven.apache.org/xsd/settings-1.0.0.xsd">
       <servers>
          <server>
             <id>che-incubator</id>
             <username>YOUR GITHUB USERNAME</username>
             <password>YOUR GITHUB TOKEN</password>
          </server>
       </servers>
    
       <profiles>
          <profile>
             <id>github</id>
             <activation>
                <activeByDefault>true</activeByDefault>
             </activation>
             <repositories>
                <repository>
                   <id>central</id>
                   <url>https://repo1.maven.org/maven2</url>
                   <releases><enabled>true</enabled></releases>
                   <snapshots><enabled>false</enabled></snapshots>
                   </repository>
                   <repository>
                   <id>che-incubator</id>
                   <url>https://maven.pkg.github.com/che-incubator/che-workspace-telemetry-client</url>
                </repository>
             </repositories>
          </profile>
       </profiles>
    </settings>
    Copy to Clipboard
4.7.2.4. AnalyticsManager의 구체적인 구현 생성 및 특수 논리 추가

src/main/java/mygroup 아래에 프로젝트에 두 개의 파일을 생성합니다.

  • MainConfiguration.java - AnalyticsManager 에 제공된 구성이 포함되어 있습니다.
  • analyticsManager.java - Telemetry 시스템과 관련된 논리가 포함되어 있습니다.

예 4.24. MainConfiguration.java

package org.my.group;

import java.util.Optional;

import javax.enterprise.context.Dependent;
import javax.enterprise.inject.Alternative;

import org.eclipse.che.incubator.workspace.telemetry.base.BaseConfiguration;
import org.eclipse.microprofile.config.inject.ConfigProperty;

@Dependent
@Alternative
public class MainConfiguration extends BaseConfiguration {
    @ConfigProperty(name = "welcome.message")      
1

    Optional<String> welcomeMessage;               
2

}
Copy to Clipboard
1
MicroProfile 구성 주석은 welcome.message 구성을 삽입하는 데 사용됩니다.

백엔드와 관련된 구성 속성을 설정하는 방법에 대한 자세한 내용은 Quarkus 구성 참조 가이드를 참조하십시오.

예 4.25. AnalyticsManager.java

package org.my.group;

import java.util.HashMap;
import java.util.Map;

import javax.enterprise.context.Dependent;
import javax.enterprise.inject.Alternative;
import javax.inject.Inject;

import org.eclipse.che.incubator.workspace.telemetry.base.AbstractAnalyticsManager;
import org.eclipse.che.incubator.workspace.telemetry.base.AnalyticsEvent;
import org.eclipse.che.incubator.workspace.telemetry.finder.DevWorkspaceFinder;
import org.eclipse.che.incubator.workspace.telemetry.finder.UsernameFinder;
import org.eclipse.microprofile.rest.client.inject.RestClient;
import org.slf4j.Logger;

import static org.slf4j.LoggerFactory.getLogger;

@Dependent
@Alternative
public class AnalyticsManager extends AbstractAnalyticsManager {

    private static final Logger LOG = getLogger(AbstractAnalyticsManager.class);

    public AnalyticsManager(MainConfiguration mainConfiguration, DevWorkspaceFinder devworkspaceFinder, UsernameFinder usernameFinder) {
        super(mainConfiguration, devworkspaceFinder, usernameFinder);

        mainConfiguration.welcomeMessage.ifPresentOrElse(     
1

            (str) -> LOG.info("The welcome message is: {}", str),
            () -> LOG.info("No welcome message provided")
        );
    }

    @Override
    public boolean isEnabled() {
        return true;
    }

    @Override
    public void destroy() {}

    @Override
    public void onEvent(AnalyticsEvent event, String ownerId, String ip, String userAgent, String resolution, Map<String, Object> properties) {
        LOG.info("The received event is: {}", event);         
2

    }

    @Override
    public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) { }

    @Override
    public void onActivity() {}
}
Copy to Clipboard
1
시작 메시지가 제공된 경우 기록합니다.
2
프런트 엔드 플러그인에서 수신한 이벤트를 기록합니다.

org.my.group.AnalyticsManagerorg.my.group.MainConfiguration 은 대체 빈이므로 src/main/resources/application.propertiesquarkus.arc.selected-alternatives 속성을 사용하여 지정합니다.

예 4.26. application.properties

quarkus.arc.selected-alternatives=MainConfiguration,AnalyticsManager
Copy to Clipboard
4.7.2.5. Dev Workspace 내에서 애플리케이션 실행
  1. Dev Workspace에서 DEVWORKSPACE_TELEMETRY_BACKEND_PORT 환경 변수를 설정합니다. 여기서 값은 4167 로 설정됩니다.

    spec:
      template:
        attributes:
          workspaceEnv:
            - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT
              value: '4167'
    Copy to Clipboard
  2. Red Hat OpenShift Dev Spaces 대시보드에서 Dev Workspace를 다시 시작합니다.
  3. Dev Workspace의 터미널 창에서 다음 명령을 실행하여 애플리케이션을 시작합니다. --settings 플래그를 사용하여 GitHub 액세스 토큰이 포함된 settings.xml 파일의 위치에 대한 경로를 지정합니다.

    $ mvn --settings=settings.xml quarkus:dev -Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}
    Copy to Clipboard

    이제 애플리케이션은 프런트 엔드 플러그인에서 포트 4167 을 통해 원격 분석 이벤트를 수신합니다.

검증 단계

  1. 다음 출력이 기록되었는지 확인합니다.

    INFO  [org.ecl.che.inc.AnalyticsManager] (Quarkus Main Thread) No welcome message provided
    INFO  [io.quarkus] (Quarkus Main Thread) devworkspace-telemetry-example-plugin 1.0.0-SNAPSHOT on JVM (powered by Quarkus 2.7.2.Final) started in 0.323s. Listening on: http://localhost:4167
    INFO  [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.
    INFO  [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, kubernetes-client, rest-client, rest-client-jackson, resteasy, resteasy-jsonb, smallrye-context-propagation, smallrye-openapi, swagger-ui, vertx]
    Copy to Clipboard
  2. AnalyticsManageronEvent() 메서드가 프런트 엔드 플러그인에서 이벤트를 수신하는지 확인하려면 l 키를 눌러 Quarkus 실시간 코딩을 비활성화하고 IDE 내의 모든 파일을 편집합니다. 다음 출력을 로깅해야 합니다.

    INFO  [io.qua.dep.dev.RuntimeUpdatesProcessor] (Aesh InputStream Reader) Live reload disabled
    INFO  [org.ecl.che.inc.AnalyticsManager] (executor-thread-2) The received event is: Edit Workspace File in Che
    Copy to Clipboard
4.7.2.6. isEnabled()구현

예제의 목적을 위해 이 메서드는 호출될 때마다 항상 true 를 반환합니다.

예 4.27. AnalyticsManager.java

@Override
public boolean isEnabled() {
    return true;
}
Copy to Clipboard

isEnabled() 에 더 복잡한 논리를 배치할 수 있습니다. 예를 들어 호스팅된 OpenShift Dev Spaces Woopra 백엔드 는 백엔드가 활성화되어 있는지 확인하기 전에 구성 속성이 있는지 확인합니다.

4.7.2.7. onEvent()구현

onEvent() 는 백엔드에서 수신한 이벤트를 원격 분석 시스템으로 전송합니다. 예제 애플리케이션의 경우 원격 분석 서버에서 /event 끝점으로 HTTP POST 페이로드를 보냅니다.

4.7.2.7.1. 예제 Telemetry 서버로 POST 요청 전송

다음 예에서 Telemetry 서버 애플리케이션은 다음 URL에서 OpenShift에 배포됩니다. 여기서 apps-crc.testing 은 OpenShift 클러스터의 수신 도메인 이름입니다.

  1. TelemetryService.java를 만들어 REST REST Client 설정

    예 4.28. TelemetryService.java

    package org.my.group;
    
    import java.util.Map;
    
    import javax.ws.rs.Consumes;
    import javax.ws.rs.POST;
    import javax.ws.rs.Path;
    import javax.ws.rs.core.MediaType;
    import javax.ws.rs.core.Response;
    
    import org.eclipse.microprofile.rest.client.inject.RegisterRestClient;
    
    @RegisterRestClient
    public interface TelemetryService {
        @POST
        @Path("/event") 
    1
    
        @Consumes(MediaType.APPLICATION_JSON)
        Response sendEvent(Map<String, Object> payload);
    }
    Copy to Clipboard
    1
    POST 요청을 할 끝점입니다.
  2. src/main/resources/application.properties 파일에서 TelemetryService 의 기본 URL을 지정합니다.

    예 4.29. application.properties

    org.my.group.TelemetryService/mp-rest/url=http://little-telemetry-server-che.apps-crc.testing
    Copy to Clipboard
  3. TelemetryServiceAnalyticsManager 에 삽입하고 onEvent()POST 요청을 보냅니다.

    예 4.30. AnalyticsManager.java

    @Dependent
    @Alternative
    public class AnalyticsManager extends AbstractAnalyticsManager {
        @Inject
        @RestClient
        TelemetryService telemetryService;
    
    ...
    
    @Override
    public void onEvent(AnalyticsEvent event, String ownerId, String ip, String userAgent, String resolution, Map<String, Object> properties) {
        Map<String, Object> payload = new HashMap<String, Object>(properties);
        payload.put("event", event);
        telemetryService.sendEvent(payload);
    }
    Copy to Clipboard

    그러면 HTTP 요청을 Telemetry 서버로 전송하고 일정 기간 동안 동일한 이벤트를 자동으로 지연합니다. 기본 기간은 1500밀리초입니다.

4.7.2.8. increaseDuration()구현

많은 원격 분석 시스템은 이벤트 기간을 인식합니다. AbstractAnalyticsManager 는 동일한 시간에 발생하는 유사한 이벤트를 하나의 이벤트로 병합합니다. 이 increaseDuration() 구현은 no-op입니다. 이 방법은 사용자 Telemetry 공급자의 API를 사용하여 이벤트 증가 기간을 반영하도록 이벤트 또는 이벤트 속성을 변경합니다.

예 4.31. AnalyticsManager.java

@Override
public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) {}
Copy to Clipboard
4.7.2.9. onActivity()구현

비활성 타임아웃 제한을 설정하고 onActivity() 를 사용하여 마지막 이벤트 시간이 시간 초과보다 긴 경우 WORKSPACE_INACTIVE 이벤트를 보냅니다.

예 4.32. AnalyticsManager.java

public class AnalyticsManager extends AbstractAnalyticsManager {

    ...

    private long inactiveTimeLimit = 60000 * 3;

    ...

    @Override
    public void onActivity() {
        if (System.currentTimeMillis() - lastEventTime >= inactiveTimeLimit) {
            onEvent(WORKSPACE_INACTIVE, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties);
        }
    }
Copy to Clipboard
4.7.2.10. destroy()구현

destroy() 가 호출되면 WORKSPACE_STOPPED 이벤트를 전송하고 연결 풀과 같은 모든 리소스를 종료합니다.

예 4.33. AnalyticsManager.java

@Override
public void destroy() {
    onEvent(WORKSPACE_STOPPED, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties);
}
Copy to Clipboard

4.7.2.5절. “Dev Workspace 내에서 애플리케이션 실행” 에 설명된 대로 mvn quarkus:dev 를 실행하고 Ctrl+C 사용하여 애플리케이션을 종료하면 WORKSPACE_STOPPED 이벤트가 서버에 전송됩니다.

4.7.2.11. Quarkus 애플리케이션 패키징

컨테이너에 애플리케이션을 패키징하는 가장 좋은 방법은 Quarkus 설명서 를 참조하십시오. 컨테이너를 빌드하여 선택한 컨테이너 레지스트리로 내보냅니다.

4.7.2.11.1. JVM으로 실행되는 Quarkus 이미지를 빌드하는 샘플 Dockerfile

예 4.34. Dockerfile.jvm

FROM registry.access.redhat.com/ubi8/openjdk-11:1.11

ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en'

COPY --chown=185 target/quarkus-app/lib/ /deployments/lib/
COPY --chown=185 target/quarkus-app/*.jar /deployments/
COPY --chown=185 target/quarkus-app/app/ /deployments/app/
COPY --chown=185 target/quarkus-app/quarkus/ /deployments/quarkus/

EXPOSE 8080
USER 185

ENTRYPOINT ["java", "-Dquarkus.http.host=0.0.0.0", "-Djava.util.logging.manager=org.jboss.logmanager.LogManager", "-Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}", "-jar", "/deployments/quarkus-run.jar"]
Copy to Clipboard

이미지를 빌드하려면 다음을 실행합니다.

mvn package && \
podman build -f src/main/docker/Dockerfile.jvm -t image:tag .
Copy to Clipboard
4.7.2.11.2. Quarkus 기본 이미지를 빌드하는 샘플 Dockerfile

예 4.35. Dockerfile.native

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5
WORKDIR /work/
RUN chown 1001 /work \
    && chmod "g+rwX" /work \
    && chown 1001:root /work
COPY --chown=1001:root target/*-runner /work/application

EXPOSE 8080
USER 1001

CMD ["./application", "-Dquarkus.http.host=0.0.0.0", "-Dquarkus.http.port=$DEVWORKSPACE_TELEMETRY_BACKEND_PORT}"]
Copy to Clipboard

이미지를 빌드하려면 다음을 실행합니다.

mvn package -Pnative -Dquarkus.native.container-build=true && \
podman build -f src/main/docker/Dockerfile.native -t image:tag .
Copy to Clipboard
4.7.2.12. 플러그인에 대한 plugin.yaml 생성

Dev Workspace Pod에서 사용자 지정 백엔드를 실행하는 Dev Workspace 플러그인을 나타내는 plugin.yaml devfile v2 파일을 생성합니다. devfile v2에 대한 자세한 내용은 Devfile v2 문서를 참조하십시오.

예 4.36. plugin.yaml

schemaVersion: 2.1.0
metadata:
  name: devworkspace-telemetry-backend-plugin
  version: 0.0.1
  description: A Demo telemetry backend
  displayName: Devworkspace Telemetry Backend
components:
  - name: devworkspace-telemetry-backend-plugin
    attributes:
      workspaceEnv:
        - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT
          value: '4167'
    container:
      image: YOUR IMAGE            
1

      env:
        - name: WELCOME_MESSAGE    
2

          value: 'hello world!'
Copy to Clipboard
1
4.7.2.11절. “Quarkus 애플리케이션 패키징” 에서 빌드된 컨테이너 이미지를 지정합니다.
2
Example 4에서 welcome.message 선택적 구성 속성 값을 설정합니다.

일반적으로 사용자는 이 파일을 회사 웹 서버에 배포합니다. 이 가이드에서는 OpenShift에서 Apache 웹 서버를 생성하고 플러그인을 호스팅하는 방법을 보여줍니다.

plugin.yaml 파일을 참조하는 ConfigMap 오브젝트를 생성합니다.

$ oc create configmap --from-file=plugin.yaml -n openshift-devspaces telemetry-plugin-yaml
Copy to Clipboard

배포, 서비스 및 웹 서버를 노출하는 경로를 생성합니다. 배포는 이 ConfigMap 오브젝트를 참조하고 /var/www/html 디렉터리에 배치합니다.

예 4.37. manifest.yaml

kind: Deployment
apiVersion: apps/v1
metadata:
  name: apache
spec:
  replicas: 1
  selector:
    matchLabels:
      app: apache
  template:
    metadata:
      labels:
        app: apache
    spec:
      volumes:
        - name: plugin-yaml
          configMap:
            name: telemetry-plugin-yaml
            defaultMode: 420
      containers:
        - name: apache
          image: 'registry.redhat.io/rhscl/httpd-24-rhel7:latest'
          ports:
            - containerPort: 8080
              protocol: TCP
          resources: {}
          volumeMounts:
            - name: plugin-yaml
              mountPath: /var/www/html
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600
---
kind: Service
apiVersion: v1
metadata:
  name: apache
spec:
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  selector:
    app: apache
  type: ClusterIP
---
kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: apache
spec:
  host: apache-che.apps-crc.testing
  to:
    kind: Service
    name: apache
    weight: 100
  port:
    targetPort: 8080
  wildcardPolicy: None
Copy to Clipboard
$ oc apply -f manifest.yaml
Copy to Clipboard

검증 단계

  • 배포가 시작되면 웹 서버에서 plugin.yaml 을 사용할 수 있는지 확인합니다.

    $ curl apache-che.apps-crc.testing/plugin.yaml
    Copy to Clipboard
4.7.2.13. Dev Workspace에서 Telemetry 플러그인 지정
  1. 기존 Dev Workspace의 components 필드에 다음을 추가합니다.

    components:
      ...
      - name: telemetry-plugin
        plugin:
          uri: http://apache-che.apps-crc.testing/plugin.yaml
    Copy to Clipboard
  2. OpenShift Dev Spaces 대시보드에서 Dev Workspace를 시작합니다.

검증 단계

  1. 원격 분석 플러그인 컨테이너가 Dev Workspace Pod에서 실행 중인지 확인합니다. 여기에서는 편집기 내에서 Workspace 보기를 확인하여 확인합니다.

    dev Workspace Telemetry 플러그인
  2. 편집기 내에서 파일을 편집하고 예제 Telemetry 서버의 로그에서 해당 이벤트를 관찰합니다.
4.7.2.14. 모든 Dev Workspace에 대한 Telemetry 플러그인 적용

Telemetry 플러그인을 기본 플러그인으로 설정합니다. 기본 플러그인은 신규 및 기존 Dev Workspaces에 대해 Dev Workspace 시작에 적용됩니다.

  • CheCluster 사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      devEnvironments:
        defaultPlugins:
        - editor: eclipse/che-theia/next     
    1
    
          plugins:                           
    2
    
          - 'http://apache-che.apps-crc.testing/plugin.yaml'
    Copy to Clipboard
    1
    기본 플러그인을 설정하는 편집기 ID입니다.
    2
    devfile v2 플러그인에 대한 URL 목록입니다.

검증 단계

  1. Red Hat OpenShift Dev Spaces 대시보드에서 새 또는 기존 Dev Workspace를 시작합니다.
  2. 4.7.2.13절. “Dev Workspace에서 Telemetry 플러그인 지정” 의 확인 단계에 따라 Telemetry 플러그인이 작동하는지 확인합니다.
4.7.2.15. 서버 로깅 구성

OpenShift Dev Spaces 서버에서 사용할 수 있는 개별 로거의 로그 수준을 미세 조정할 수 있습니다.

전체 OpenShift Dev Spaces 서버의 로그 수준은 Operator의 cheLogLevel 구성 속성을 사용하여 전역적으로 구성됩니다. 4.1.3절. “CheCluster 사용자 정의 리소스 필드 참조”을 참조하십시오. Operator에서 관리하지 않는 설치의 글로벌 로그 수준을 설정하려면 che ConfigMap에서 CHE_LOG_LEVEL 환경 변수를 지정합니다.

CHE_LOGGER_CONFIG 환경 변수를 사용하여 OpenShift Dev Spaces 서버에서 개별 로거의 로그 수준을 구성할 수 있습니다.

4.7.2.15.1. 로그 수준 구성

프로세스

  • CheCluster 사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_LOGGER_CONFIG: "<key1=value1,key2=value2>" 
    1
    Copy to Clipboard
    1
    쉼표로 구분된 키-값 쌍 목록입니다. 여기서 키는 OpenShift Dev Spaces 서버 로그 출력에 표시된 대로 로거의 이름이며 값은 필요한 로그 수준입니다.

    예 4.38. WorkspaceManager의 디버그 모드 구성

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_LOGGER_CONFIG: "org.eclipse.che.api.workspace.server.WorkspaceManager=DEBUG"
    Copy to Clipboard
4.7.2.15.2. 로거 이름 지정

로거의 이름은 해당 로거를 사용하는 내부 서버 클래스의 클래스 이름을 따릅니다.

4.7.2.15.3. HTTP 트래픽 로깅

프로세스

  • OpenShift Dev Spaces 서버와 Kubernetes 또는 OpenShift 클러스터의 API 서버 간 HTTP 트래픽을 로깅하려면 CheCluster 사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_LOGGER_CONFIG: "che.infra.request-logging=TRACE"
    Copy to Clipboard
4.7.2.16. dsc를 사용하여 로그 수집

Red Hat OpenShift Dev Spaces 설치는 OpenShift 클러스터에서 실행되는 여러 컨테이너로 구성됩니다. 실행 중인 각 컨테이너에서 수동으로 로그를 수집할 수 있지만 dsc 는 프로세스를 자동화하는 명령을 제공합니다.

dsc 툴을 사용하여 OpenShift 클러스터에서 Red Hat OpenShift Dev Spaces 로그를 수집하는 데 사용할 수 있는 명령은 다음과 같습니다.

DSC 서버:logs

기존 Red Hat OpenShift Dev Spaces 서버 로그를 수집하여 로컬 시스템의 디렉터리에 저장합니다. 기본적으로 로그는 머신의 임시 디렉터리로 다운로드됩니다. 그러나 -d 매개변수를 지정하여 덮어쓸 수 있습니다. 예를 들어 OpenShift Dev Spaces 로그를 /home/user/che-logs/ 디렉터리에 다운로드하려면 명령을 사용합니다.

dsc server:logs -d /home/user/che-logs/
Copy to Clipboard

실행하면 dsc server:logs 가 로그 파일을 저장할 디렉터리를 지정하는 콘솔에 메시지를 출력합니다.

Red Hat OpenShift Dev Spaces logs will be available in '/tmp/chectl-logs/1648575098344'
Copy to Clipboard

Red Hat OpenShift Dev Spaces가 기본이 아닌 프로젝트에 설치된 경우 dsc server:logs 에는 -n <NAMESPACE > 매개변수가 필요합니다. 여기서 < NAMESPACE >는 Red Hat OpenShift Dev Spaces가 설치된 OpenShift 프로젝트입니다. 예를 들어, my-namespace 프로젝트의 OpenShift Dev Spaces에서 로그를 가져오려면 명령을 사용합니다.

dsc server:logs -n my-namespace
Copy to Clipboard
DSC server:deploy
dsc 를 사용하여 설치할 때 OpenShift Dev Spaces 설치 중에 로그가 자동으로 수집됩니다. dsc server:logs 와 마찬가지로 디렉터리 로그는 -d 매개변수를 사용하여 에 저장할 수 있습니다.

추가 리소스

4.7.3. Dev Workspace Operator 모니터링

Dev Workspace Operator가 노출하는 메트릭을 스크랩하도록 OpenShift in-cluster 모니터링 스택을 구성할 수 있습니다.

4.7.3.1. Dev Workspace Operator 지표 수집

클러스터 내 Prometheus 인스턴스를 사용하여 Dev Workspace Operator에 대한 지표를 수집, 저장 및 쿼리하려면 다음을 수행합니다.

사전 요구 사항

  • 조직의 OpenShift Dev Spaces 인스턴스가 Red Hat OpenShift에서 설치 및 실행됩니다.
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.
  • devworkspace-controller-metrics 서비스는 포트 8443 에 지표를 노출합니다. 이는 기본적으로 사전 구성되어 있습니다.

프로세스

  1. Dev Workspace Operator 지표 서비스를 감지하기 위한 ServiceMonitor를 생성합니다.

    예 4.39. ServiceMonitor

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: devworkspace-controller
      namespace: openshift-devspaces 
    1
    
    spec:
      endpoints:
        - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
          interval: 10s 
    2
    
          port: metrics
          scheme: https
          tlsConfig:
            insecureSkipVerify: true
      namespaceSelector:
        matchNames:
          - openshift-operators
      selector:
        matchLabels:
          app.kubernetes.io/name: devworkspace-controller
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    대상이 스크랩되는 비율입니다.
  2. 클러스터 내 Prometheus 인스턴스에서 OpenShift Dev Spaces 네임스페이스에서 ServiceMonitor를 감지할 수 있습니다. 기본 OpenShift Dev Spaces 네임스페이스는 openshift-devspaces 입니다.

    $ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
    Copy to Clipboard

검증

  1. OpenShift Dev Spaces를 새로 설치하려면 대시보드에서 OpenShift Dev Spaces 작업 공간을 생성하여 지표를 생성합니다.
  2. OpenShift 웹 콘솔의 관리자 보기에서 모니터링메트릭 으로 이동합니다.
  3. PromQL 쿼리를 실행하여 메트릭을 사용할 수 있는지 확인합니다. 예를 들어 devworkspace_started_total 을 입력하고 쿼리 실행을 클릭합니다.

    더 많은 메트릭은 4.7.3.2절. “dev Workspace별 메트릭” 에서 참조하십시오.

작은 정보

누락된 메트릭을 해결하려면 가능한 RBAC 관련 오류에 대한 Prometheus 컨테이너 로그를 확인합니다.

  1. Prometheus Pod의 이름을 가져옵니다.

    $ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
    Copy to Clipboard
  2. 이전 단계의 Prometheus Pod에서 Prometheus 컨테이너 로그의 마지막 20행을 출력합니다.

    $ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
    Copy to Clipboard
4.7.3.2. dev Workspace별 메트릭

다음 표에서는 devworkspace-controller-metrics 서비스에서 노출하는 Dev Workspace별 메트릭을 설명합니다.

표 4.40. 지표
이름유형설명라벨

devworkspace_started_total

카운터

Dev Workspace 시작 이벤트 수입니다.

소스,라우팅 클래스

devworkspace_started_success_total

카운터

실행 중인 단계에 성공적으로 들어오는 Dev Workspace 수입니다.

소스,라우팅 클래스

devworkspace_fail_total

카운터

실패한 Dev Workspace 수입니다.

소스,이유

devworkspace_startup_time

히스토그램

Dev Workspace를 시작하는 데 걸린 총 시간(초)입니다.

소스,라우팅 클래스

표 4.41. 라벨
이름설명

소스

Dev Workspace의 controller.devfile.io/devworkspace-source 레이블입니다.

string

라우팅 클래스

Dev Workspace의 spec.routingclass.

"basic|cluster|cluster-tls|web-terminal"

reason

작업 공간 시작 실패 이유

"BadRequest|InfrastructureFailure|Unknown"

표 4.42. 시작 실패 이유
이름설명

BadRequest

Dev Workspace를 생성하는 데 사용되는 잘못된 devfile으로 인한 시작 실패.

InfrastructureFailure

다음과 같은 오류로 인해 시작 실패: CreateContainerError,RunContainerError,FailedScheduling,FailedMount.

알 수 없음

알 수 없는 실패 이유

4.7.3.3. OpenShift 웹 콘솔 대시보드에서 Dev Workspace Operator 지표 보기

Dev Workspace Operator 지표를 수집하도록 클러스터 내 Prometheus 인스턴스를 구성한 후 OpenShift 웹 콘솔의 관리자 화면에서 사용자 정의 대시보드에서 메트릭을 볼 수 있습니다.

사전 요구 사항

  • 조직의 OpenShift Dev Spaces 인스턴스가 Red Hat OpenShift에서 설치 및 실행됩니다.
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.
  • 클러스터 내 Prometheus 인스턴스는 지표를 수집하고 있습니다. 4.7.3.1절. “Dev Workspace Operator 지표 수집”을 참조하십시오.

프로세스

  • openshift-config-managed 프로젝트에서 대시보드 정의에 대한 ConfigMap을 생성하고 필요한 레이블을 적용합니다.

    1. $ oc create configmap grafana-dashboard-dwo \
        --from-literal=dwo-dashboard.json="$(curl https://raw.githubusercontent.com/devfile/devworkspace-operator/main/docs/grafana/openshift-console-dashboard.json)" \
        -n openshift-config-managed
      Copy to Clipboard
      참고

      이전 명령에는 업스트림 커뮤니티의 자료에 대한 링크가 포함되어 있습니다. 이 자료에서는 사용 가능한 최신 콘텐츠와 최신 모범 사례를 나타냅니다. 이러한 팁은 Red Hat의 QE 부서에 의해 아직 진행되지 않았으며 다양한 사용자 그룹에서는 아직 검증되지 않았습니다. 이 정보를 신중하게 사용하십시오.

    2. $ oc label configmap grafana-dashboard-dwo console.openshift.io/dashboard=true -n openshift-config-managed
      Copy to Clipboard
      참고

      대시보드 정의는 Grafana 6.x 대시보드를 기반으로 합니다. OpenShift 웹 콘솔에서 모든 Grafana 6.x 대시보드 기능이 지원되는 것은 아닙니다.

검증 단계

  1. OpenShift 웹 콘솔의 관리자 보기에서 모니터링대시보드 로 이동합니다.
  2. 대시보드Che 서버 JVM 으로 이동하여 대시보드 패널에 데이터가 포함되어 있는지 확인합니다.
4.7.3.4. Dev Workspace Operator 대시보드

OpenShift 웹 콘솔 사용자 정의 대시보드는 Grafana 6.x를 기반으로 하며 Dev Workspace Operator에서 다음 지표를 표시합니다.

참고

Grafana 6.x 대시보드의 모든 기능이 OpenShift 웹 콘솔 대시보드로 지원되는 것은 아닙니다.

4.7.3.4.1. dev Workspace 지표

Dev Workspace별 지표는 Dev Workspace Metrics 패널에 표시됩니다.

그림 4.1. Dev Workspace Metrics 패널

'DevWorkspace 시작과 관련된 메트릭이 포함된 Grafana 대시보드 패널
평균 작업 공간 시작 시간
평균 작업 공간 시작 기간입니다.
Workspace 시작
성공 및 실패한 작업 공간 시작 수입니다.
dev Workspace 성공 및 실패
성공적인 Dev Workspace 시작과 실패한 Dev Workspace 시작 간의 비교입니다.
dev Workspace 실패율
실패한 작업 공간 시작 수와 총 작업 공간 시작 수 간의 비율입니다.
dev Workspace 시작 실패 이유

작업 영역 시작 실패의 배포를 표시하는 원형 차트입니다.

  • BadRequest
  • InfrastructureFailure
  • 알 수 없음
4.7.3.4.2. Operator 지표

Operator별 지표가 Operator 지표 패널에 표시됩니다.

그림 4.2. Operator 지표 패널

Operator 메트릭이 포함된 Grafana 대시보드 패널
이동 중 Webhook
서로 다른 Webhook 요청 수를 비교합니다.
작업 대기열 깊이
작업 큐에 있는 조정 요청 수입니다.
메모리
Dev Workspace 컨트롤러 및 Dev Workspace 웹 후크 서버의 메모리 사용량입니다.
초당 평균 조정 수(DWO)
Dev Workspace 컨트롤러의 초당 평균 조정 수입니다.

4.7.4. Dev Spaces 서버 모니터링

OpenShift Dev Spaces를 구성하여 JVM 메모리와 같은 JVM 메트릭을 노출하고 OpenShift Dev Spaces Server에 대한 클래스 로드를 구성할 수 있습니다.

4.7.4.1. OpenShift Dev Spaces 서버 메트릭 활성화 및 노출

OpenShift Dev Spaces는 che-host 서비스의 포트 8087 에 JVM 지표를 노출합니다. 이 동작을 구성할 수 있습니다.

프로세스

4.7.4.2. Prometheus를 사용하여 OpenShift Dev Spaces Server 지표 수집

in-cluster Prometheus 인스턴스를 사용하여 OpenShift Dev Spaces Server에 대한 JVM 지표를 수집, 저장 및 쿼리하려면 다음을 수행합니다.

사전 요구 사항

  • 조직의 OpenShift Dev Spaces 인스턴스가 Red Hat OpenShift에서 설치 및 실행됩니다.
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.
  • OpenShift Dev Spaces는 포트 8087 에서 지표를 노출합니다. OpenShift Dev Spaces 서버 JVM 메트릭 활성화 및 노출을 참조하십시오.

프로세스

  1. OpenShift Dev Spaces JVM 메트릭 서비스를 감지하기 위한 ServiceMonitor를 생성합니다.

    예 4.40. ServiceMonitor

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: che-host
      namespace: openshift-devspaces 
    1
    
    spec:
      endpoints:
        - interval: 10s 
    2
    
          port: metrics
          scheme: http
      namespaceSelector:
        matchNames:
          - openshift-devspaces 
    3
    
      selector:
        matchLabels:
          app.kubernetes.io/name: devspaces
    Copy to Clipboard
    1 3
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    대상이 스크랩되는 비율입니다.
  2. Prometheus가 메트릭을 볼 수 있도록 Role 및 RoleBinding을 생성합니다.

    예 4.41. Role

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: prometheus-k8s
      namespace: openshift-devspaces 
    1
    
    rules:
      - verbs:
          - get
          - list
          - watch
        apiGroups:
          - ''
        resources:
          - services
          - endpoints
          - pods
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.

    예 4.42. RoleBinding

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: view-devspaces-openshift-monitoring-prometheus-k8s
      namespace: openshift-devspaces 
    1
    
    subjects:
      - kind: ServiceAccount
        name: prometheus-k8s
        namespace: openshift-monitoring
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: prometheus-k8s
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
  3. 클러스터 내 Prometheus 인스턴스에서 OpenShift Dev Spaces 네임스페이스에서 ServiceMonitor를 감지할 수 있습니다. 기본 OpenShift Dev Spaces 네임스페이스는 openshift-devspaces 입니다.

    $ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
    Copy to Clipboard

검증

  1. OpenShift 웹 콘솔의 관리자 보기에서 모니터링메트릭 으로 이동합니다.
  2. PromQL 쿼리를 실행하여 메트릭을 사용할 수 있는지 확인합니다. 예를 들어 process_uptime_seconds{job="che-host"} 를 입력하고 Run queries 를 클릭합니다.
작은 정보

누락된 메트릭을 해결하려면 가능한 RBAC 관련 오류에 대한 Prometheus 컨테이너 로그를 확인합니다.

  1. Prometheus Pod의 이름을 가져옵니다.

    $ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
    Copy to Clipboard
  2. 이전 단계의 Prometheus Pod에서 Prometheus 컨테이너 로그의 마지막 20행을 출력합니다.

    $ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
    Copy to Clipboard
4.7.4.3. OpenShift 웹 콘솔 대시보드에서 OpenShift Dev Spaces Server 보기

OpenShift Dev Spaces Server JVM 지표를 수집하도록 클러스터 내 Prometheus 인스턴스를 구성한 후 OpenShift 웹 콘솔의 관리자 화면에서 사용자 정의 대시보드에서 메트릭을 볼 수 있습니다.

사전 요구 사항

프로세스

  • openshift-config-managed 프로젝트에서 대시보드 정의에 대한 ConfigMap을 생성하고 필요한 레이블을 적용합니다.

    1. $ oc create configmap grafana-dashboard-devspaces-server \
        --from-literal=devspaces-server-dashboard.json="$(curl https://raw.githubusercontent.com/eclipse-che/che-server/main/docs/grafana/openshift-console-dashboard.json)" \
        -n openshift-config-managed
      Copy to Clipboard
      참고

      이전 명령에는 업스트림 커뮤니티의 자료에 대한 링크가 포함되어 있습니다. 이 자료에서는 사용 가능한 최신 콘텐츠와 최신 모범 사례를 나타냅니다. 이러한 팁은 Red Hat의 QE 부서에 의해 아직 진행되지 않았으며 다양한 사용자 그룹에서는 아직 검증되지 않았습니다. 이 정보를 신중하게 사용하십시오.

    2. $ oc label configmap grafana-dashboard-devspaces-server console.openshift.io/dashboard=true -n openshift-config-managed
      Copy to Clipboard
      참고

      대시보드 정의는 Grafana 6.x 대시보드를 기반으로 합니다. OpenShift 웹 콘솔에서 모든 Grafana 6.x 대시보드 기능이 지원되는 것은 아닙니다.

검증 단계

  1. OpenShift 웹 콘솔의 관리자 보기에서 모니터링대시보드 로 이동합니다.
  2. DashboardDev Workspace Operator 로 이동하여 대시보드 패널에 데이터가 포함되어 있는지 확인합니다.

    그림 4.3. 빠른 사실

    *JVM 빠른 사실* 패널

    그림 4.4. JVM 메모리

    *JVM 메모리* 패널

    그림 4.5. JVM Misc

    *JVM Misc* 패널

    그림 4.6. JVM 메모리 풀(heap)

    *JVM 메모리 풀(heap)* 패널

    그림 4.7. JVM 메모리 풀(Non-Heap)

    *JVM 메모리 풀(heap이 아닌)* 패널

    그림 4.8. 가비지 컬렉션

    *JVM 가비지 컬렉션* 패널

    그림 4.9. 클래스 로드

    *JVM 클래스 로드* 패널

    그림 4.10. 버퍼 풀

    *JVM 버퍼 풀* 패널

4.8. 네트워킹 구성

4.8.1. 네트워크 정책 구성

기본적으로 OpenShift 클러스터의 모든 Pod는 서로 다른 네임스페이스에 있는 경우에도 서로 통신할 수 있습니다. OpenShift Dev Spaces의 컨텍스트에서 한 사용자 프로젝트의 작업 공간 Pod가 다른 사용자 프로젝트의 다른 작업 공간 Pod로 트래픽을 보낼 수 있습니다.

보안을 위해 NetworkPolicy 오브젝트를 사용하여 사용자 프로젝트에서 Pod와 들어오는 모든 통신을 제한하여 다중 테넌트 격리를 구성할 수 있습니다. 그러나 OpenShift Dev Spaces 프로젝트의 Pod는 사용자 프로젝트에서 Pod와 통신할 수 있어야 합니다.

사전 요구 사항

  • OpenShift 클러스터에는 다중 테넌트 격리와 같은 네트워크 제한 사항이 있습니다.

프로세스

  • 각 사용자 프로젝트에 allow-from-openshift-devspaces NetworkPolicy를 적용합니다. allow-from-openshift-devspaces NetworkPolicy를 사용하면 OpenShift Dev Spaces 네임스페이스에서 사용자 프로젝트의 모든 Pod로 들어오는 트래픽을 허용합니다.

    예 4.43. allow-from-openshift-devspaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
        name: allow-from-openshift-devspaces
    spec:
        ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                    kubernetes.io/metadata.name: openshift-devspaces   
    1
    
        podSelector: {}   
    2
    
        policyTypes:
        - Ingress
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    podSelector 는 프로젝트의 모든 포드를 선택합니다.
  • OPTIONAL: 네트워크 정책으로 다중 테넌트 격리 구성을 적용한 경우 allow-from-openshift-apiserverallow-from-workspaces-namespaces NetworkPolicies를 openshift-devspaces 에도 적용해야 합니다. allow-from-openshift-apiserver NetworkPolicy를 사용하면 openshift-apiserver 네임스페이스에서 devworkspace-webhook-server 로 들어오는 트래픽을 사용할 수 있습니다. allow-from-workspaces-namespaces NetworkPolicy는 각 사용자 프로젝트에서 che-gateway Pod로 들어오는 트래픽을 허용합니다.

    예 4.44. allow-from-openshift-apiserver.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-apiserver
      namespace: openshift-devspaces   
    1
    
    spec:
      podSelector:
        matchLabels:
          app.kubernetes.io/name: devworkspace-webhook-server   
    2
    
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: openshift-apiserver
      policyTypes:
        - Ingress
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    podSelector 는 devworkspace-webhook-server Pod만 선택합니다.

    예 4.45. allow-from-workspaces-namespaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-workspaces-namespaces
      namespace: openshift-devspaces   
    1
    
    spec:
      podSelector: {}   
    2
    
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  app.kubernetes.io/component: workspaces-namespace
      policyTypes:
        - Ingress
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    podSelector 는 OpenShift Dev Spaces 네임스페이스에서 모든 포드를 선택합니다.
  • 4.2절. “프로젝트 구성”
  • 네트워크 격리
  • 네트워크 정책으로 다중 테넌트 격리 구성

4.8.2. Dev Spaces 호스트 이름 구성

다음 절차에서는 사용자 지정 호스트 이름을 사용하도록 OpenShift Dev Space를 구성하는 방법을 설명합니다.

사전 요구 사항

  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.
  • 인증서 및 개인 키 파일이 생성됩니다.
중요

개인 키 및 인증서 쌍을 생성하려면 다른 OpenShift Dev Spaces 호스트에 대해 동일한 CA(인증 기관)를 사용해야 합니다.

중요

DNS 공급자에게 클러스터 인그레스에 대한 사용자 지정 호스트 이름을 가리키도록 요청합니다.

프로세스

  1. OpenShift Dev Spaces용 프로젝트를 사전 생성합니다.

    $ oc create project openshift-devspaces
    Copy to Clipboard
  2. TLS 시크릿을 생성합니다.

    $ oc create secret TLS <tls_secret_name> \ 
    1
    
    --key <key_file> \ 
    2
    
    --cert <cert_file> \ 
    3
    
    -n openshift-devspaces
    Copy to Clipboard
    1
    TLS 시크릿 이름
    2
    개인 키가 있는 파일
    3
    인증서가 있는 파일
  3. 보안에 필요한 레이블을 추가합니다.

    $ oc label secret <tls_secret_name> \ 
    1
    
    app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
    Copy to Clipboard
    1
    TLS 시크릿 이름
  4. CheCluster 사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      networking:
        hostname: <hostname>     
    1
    
        tlsSecretName: <secret>  
    2
    Copy to Clipboard
    1
    사용자 지정 Red Hat OpenShift Dev Spaces 서버 호스트 이름
    2
    TLS 시크릿 이름
  5. OpenShift Dev Spaces가 이미 배포된 경우 모든 OpenShift Dev Spaces 구성 요소의 롤아웃이 완료될 때까지 기다립니다.

4.8.3. 신뢰할 수 없는 TLS 인증서 가져오기를 Dev Spaces

외부 서비스와의 OpenShift Dev Spaces 구성 요소 통신은 TLS로 암호화됩니다. 신뢰할 수 있는 CA(인증 기관)에서 서명한 TLS 인증서가 필요합니다. 따라서 다음과 같은 외부 서비스에서 사용하는 신뢰할 수 없는 모든 CA 체인으로 OpenShift Dev Space로 가져와야 합니다.

  • 프록시
  • ID 공급자(OIDC)
  • 소스 코드 리포지토리 공급자(Git)

OpenShift Dev Spaces는 OpenShift Dev Spaces 프로젝트에서 레이블이 지정된 ConfigMap을 TLS 인증서의 소스로 사용합니다. ConfigMaps에는 각각 임의의 양의 인증서가 있는 임의의 양의 키가 있을 수 있습니다. Operator는 모든 ConfigMap을 ca-certs-merged 라는 이름으로 병합하여 OpenShift Dev Spaces 서버, 대시보드 및 작업 공간 Pod에 볼륨으로 마운트합니다. 기본적으로 Operator는 /public-certs/etc/pki/ca-trust/extracted/pem 의 사용자 작업 공간에 ca-certs-merged ConfigMap을 마운트합니다. /etc/pki/ca-trust/extracted/pem 디렉터리에는 시스템이 Red Hat에 신뢰할 수 있는 인증 기관을 위해 추출된 CA 인증서를 저장합니다(예: CentOS, Fedora). CLI 툴에서는 사용자의 작업 공간이 가동되어 실행될 때 시스템에서 신뢰하는 위치에서 인증서를 자동으로 사용합니다.

참고

OpenShift 클러스터에 클러스터 전체 프록시 구성을 통해 추가된 클러스터 전체의 신뢰할 수 있는 CA 인증서가 포함된 경우 OpenShift Dev Spaces Operator는 해당 인증서를 탐지하고 config.openshift.io/inject-trusted-cabundle="true" 라벨을 사용하여 ConfigMap에 자동으로 삽입합니다. 이 주석을 기반으로 OpenShift는 ConfigMap의 ca-bundle.crt 키에 클러스터 전체의 신뢰할 수 있는 CA 인증서를 자동으로 삽입합니다.

사전 요구 사항

  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.
  • openshift-devspaces 프로젝트가 있습니다.
  • 가져올 각 CA 체인의 경우: PEM 형식의 루트 CA 및 중간 인증서의 ca-cert-for-devspaces- <count > .pem 파일입니다.

프로세스

  1. 모든 CA 체인 PEM 파일을 custom-ca-certificates.pem 파일에 연결하고 Java 신뢰 저장소와 호환되지 않는 반환 문자를 제거합니다.

    $ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem
    Copy to Clipboard
  2. 필요한 TLS 인증서를 사용하여 custom-ca-certificates ConfigMap을 생성합니다.

    $ oc create configmap custom-ca-certificates \
        --from-file=custom-ca-certificates.pem \
        --namespace=openshift-devspaces
    Copy to Clipboard
  3. custom-ca-certificates ConfigMap에 레이블을 지정합니다.

    $ oc label configmap custom-ca-certificates \
        app.kubernetes.io/component=ca-bundle \
        app.kubernetes.io/part-of=che.eclipse.org \
        --namespace=openshift-devspaces
    Copy to Clipboard
  4. 이전에 배포되지 않은 경우 OpenShift Dev Spaces를 배포합니다. 그렇지 않으면 OpenShift Dev Spaces 구성 요소 롤아웃이 완료될 때까지 기다립니다.
  5. 변경 사항을 적용하려면 실행 중인 작업 공간을 다시 시작합니다.

검증 단계

  1. ConfigMap에 사용자 정의 CA 인증서가 포함되어 있는지 확인합니다. 이 명령은 CA 번들 인증서를 PEM 형식으로 반환합니다.

    $ oc get configmap \
        --namespace=openshift-devspaces \
        --output='jsonpath={.items[0:].data.custom-ca-certificates\.pem}' \
        --selector=app.kubernetes.io/component=ca-bundle,app.kubernetes.io/part-of=che.eclipse.org
    Copy to Clipboard
  2. OpenShift Dev Spaces 서버 로그에서 가져온 인증서 수가 null이 아닌지 확인합니다.

    $ oc logs deploy/devspaces --namespace=openshift-devspaces \
        | grep tls-ca-bundle.pem
    Copy to Clipboard
  3. 작업 공간을 시작하고, 생성된 프로젝트 이름(< workspace_namespace >)을 가져오고, 작업 공간이 시작될 때까지 기다립니다.
  4. ca-certs-merged ConfigMap에 사용자 정의 CA 인증서가 포함되어 있는지 확인합니다. 이 명령은 OpenShift Dev Spaces CA 번들 인증서를 PEM 형식으로 반환합니다.

    $ oc get configmap che-trusted-ca-certs \
        --namespace=<workspace_namespace> \
        --output='jsonpath={.data.tls-ca-bundle\.pem}'
    Copy to Clipboard
  5. 작업 공간 Pod가 ca-certs-merged ConfigMap을 마운트하는지 확인합니다.

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \
        | grep ca-certs-merged
    Copy to Clipboard
  6. 작업 공간 Pod 이름 < workspace_pod_name >을 가져옵니다.

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].metadata.name}' \
    Copy to Clipboard
  7. 작업 공간 컨테이너에 사용자 정의 CA 인증서가 있는지 확인합니다. 이 명령은 OpenShift Dev Spaces CA 번들 인증서를 PEM 형식으로 반환합니다.

    $ oc exec <workspace_pod_name> \
        --namespace=<workspace_namespace> \
        -- cat /public-certs/tls-ca-bundle.pem
    Copy to Clipboard

4.8.4. 레이블 및 주석 추가

4.8.4.1. 라우터 공유에서 작동하도록 OpenShift 경로 구성

OpenShift 경로의 레이블, 주석 및 도메인이 라우터 분할에서 작동하도록 구성할 수 있습니다.

사전 요구 사항

프로세스

  • CheCluster 사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      networking:
        labels: <labels> 
    1
    
        domain: <domain> 
    2
    
        annotations: <annotations> 
    3
    Copy to Clipboard
    1
    대상 Ingress 컨트롤러에서 서비스 경로 세트를 필터링하는 데 사용하는 레이블의 구조화되지 않은 키 값 맵입니다.
    2
    대상 Ingress 컨트롤러에서 서비스를 제공하는 DNS 이름입니다.
    3
    리소스와 함께 저장된 구조화되지 않은 키 값 맵입니다.

4.9. 스토리지 구성

주의

OpenShift Dev Spaces는 NFS(Network File System) 프로토콜을 지원하지 않습니다.

4.9.1. 스토리지 클래스 구성

구성된 인프라 스토리지를 사용하도록 OpenShift Dev Spaces를 구성하려면 스토리지 클래스를 사용하여 OpenShift Dev Spaces를 설치합니다. 이는 기본이 아닌 프로비저너에서 제공하는 영구 볼륨을 바인딩하려는 경우 특히 유용합니다.

OpenShift Dev Spaces에는 데이터를 저장하기 위해 영구 볼륨이 필요한 하나의 구성 요소가 있습니다.

  • OpenShift Dev Spaces 작업 공간. OpenShift Dev Spaces 작업 공간은 볼륨을 사용하여 소스 코드를 저장합니다(예: /projects 볼륨).
참고

OpenShift Dev Spaces 작업 공간 소스 코드는 작업 공간이 임시가 아닌 경우에만 영구 볼륨에 저장됩니다.

영구 볼륨 클레임 팩트:

  • OpenShift Dev Spaces는 인프라에서 영구 볼륨을 생성하지 않습니다.
  • OpenShift Dev Spaces는 PVC(영구 볼륨 클레임)를 사용하여 영구 볼륨을 마운트합니다.
  • 2.3.1.2절. “dev Workspace Operator” 는 영구 볼륨 클레임을 생성합니다.

    OpenShift Dev Spaces PVC의 스토리지 클래스 기능을 사용하도록 OpenShift Dev Spaces 구성에 스토리지 클래스 이름을 정의합니다.

프로세스

CheCluster 사용자 정의 리소스 정의를 사용하여 스토리지 클래스를 정의합니다.

  1. 스토리지 클래스 이름을 정의합니다. CheCluster 사용자 정의 리소스를 구성하고 OpenShift Dev Spaces를 설치합니다. 4.1.1절. “dsc를 사용하여 설치 중에 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      devEnvironments:
        storage:
          perUserStrategyPvcConfig:
            claimSize: <claim_size> 
    1
    
            storageClass: <storage_class_name> 
    2
    
          perWorkspaceStrategyPvcConfig:
            claimSize: <claim_size> 
    3
    
            storageClass: <storage_class_name> 
    4
    
          pvcStrategy: <pvc_strategy> 
    5
    Copy to Clipboard
    1 3
    영구 볼륨 클레임 크기.
    2 4
    영구 볼륨 클레임의 스토리지 클래스입니다. 생략하거나 비워 두면 기본 스토리지 클래스가 사용됩니다.
    5
    영구 볼륨 클레임 전략. 지원되는 전략은 사용자당(한 볼륨의 모든 작업 공간) 볼륨 클레임, 작업 공간당(각 작업 공간에는 개별 영구 볼륨 클레임) 및 임시(작업 공간이 중지될 때 로컬 변경 사항이 손실되는 비영구 스토리지)입니다.

4.9.2. 스토리지 전략 구성

OpenShift Dev Spaces는 스토리지 전략을 선택하여 작업 공간에 영구 스토리지 또는 비영구 스토리지를 제공하도록 구성할 수 있습니다. 선택한 스토리지 전략은 기본적으로 새로 생성된 모든 작업 공간에 적용됩니다. 사용자는 devfile 의 작업 공간 또는 URL 매개변수를 통해 기본이 아닌 스토리지 전략을 선택할 수 있습니다.

사용 가능한 스토리지 전략:

  • 사용자별: 사용자가 생성한 모든 작업 공간에 단일 PVC를 사용합니다.
  • 작업별: 각 작업 공간에는 자체 PVC가 제공됩니다.
  • ephemeral: 비영구 스토리지; 작업 영역을 중지하면 로컬 변경 사항이 손실됩니다.

OpenShift Dev Spaces에 사용되는 기본 스토리지 전략은 사용자당 입니다.

프로세스

  1. Che Cluster 사용자 정의 리소스의 pvcStrategy 필드를 사용자당,Workspace별 또는 임시 로 설정합니다.
참고
spec:
  devEnvironments:
    storage:
      pvc:
        pvcStrategy: 'per-user' 
1
Copy to Clipboard
1
사용 가능한 스토리지 전략은 사용자당,작업당임시 입니다.

4.9.3. 스토리지 크기 구성

사용자 또는 작업 스토리지 전략을 사용하여 PVC(영구 볼륨 클레임) 크기를 구성할 수 있습니다. CheCluster 사용자 정의 리소스에서 PVC 크기를 Kubernetes 리소스 수량 의 형식으로 지정해야 합니다. 사용 가능한 스토리지 전략에 대한 자세한 내용은 이 페이지를 참조하십시오.

기본 영구 볼륨 클레임 크기:

  • per-user: 10Gi
    Copy to Clipboard
  • per-workspace: 5Gi
    Copy to Clipboard

프로세스

  1. Che Cluster 사용자 정의 리소스에서 원하는 스토리지 전략에 적절한 claimSize 필드를 설정합니다.
참고
spec:
  devEnvironments:
    storage:
      pvc:
        pvcStrategy: '<strategy_name>'  
1

        perUserStrategyPvcConfig: 
2

          claimSize: <resource_quantity> 
3

        perWorkspaceStrategyPvcConfig:  
4

          claimSize: <resource_quantity> 
5
Copy to Clipboard
1
스토리지 전략( 사용자별 또는 작업별 또는 임시 )을 선택합니다. 참고: 임시 스토리지 전략에서는 영구 스토리지를 사용하지 않으므로 스토리지 크기 또는 기타 PVC 관련 속성을 구성할 수 없습니다.
2 4
다음 행에서 클레임 크기를 지정하거나 다음 행을 생략하여 기본 클레임 크기 값을 설정합니다. 지정된 클레임 크기는 이 스토리지 전략을 선택할 때만 사용됩니다.
3 5
클레임 크기는 Kubernetes 리소스 수로 지정해야 합니다. 사용 가능한 양 단위는 Ei,Pi,Ti,Gi,MiKi 가 포함됩니다.

4.9.4. 영구 사용자 홈

Red Hat OpenShift Dev Spaces는 각 비임스페이스 작업 공간을 사용하여 작업 공간 재시작 시 /home/user 디렉토리를 유지할 수 있는 영구적인 홈 디렉터리 기능을 제공합니다. spec.devEnvironments.persistUserhome.enabledtrue 로 설정하여 CheCluster에서 이 기능을 활성화할 수 있습니다.

새로 시작된 작업 공간의 경우 이 기능은 툴 컨테이너의 /home/user 경로에 마운트된 PVC를 생성합니다. 이 문서에서는 devfile의 첫 번째 컨테이너를 참조하는 데 "tools 컨테이너"가 사용됩니다. 이 컨테이너는 기본적으로 프로젝트 소스 코드가 포함된 컨테이너입니다.

PVC가 처음 마운트되면 영구 볼륨의 콘텐츠가 비어 있으므로 /home/user 디렉터리 콘텐츠로 채워야 합니다.

기본적으로 persistUserhome 기능은 init -persistent-home 이라는 새 작업 공간 Pod마다 init 컨테이너를 생성합니다. 이 init 컨테이너는 툴 컨테이너 이미지로 생성되며 stow 명령을 실행하여 영구 볼륨에 심볼릭 링크를 생성하여 /home/user 디렉터리를 채웁니다.

참고

.viminfo.bashrc 파일과 같이 /home/user 디렉터리에 심볼릭 링크할 수 없는 파일의 경우 stow 대신 cp 를 사용합니다.

stow 명령의 주요 기능은 다음을 실행하는 것입니다.

stow -t /home/user/ -d /home/tooling/ --no-folding
Copy to Clipboard

위의 명령은 /home/tooling에 있는 파일 및 디렉토리에 대한 /home/user 에 대한 심볼릭 링크를 만듭니다. 이렇게 하면 영구 볼륨이 /home/tooling 의 콘텐츠에 대한 심볼릭 링크로 채워집니다. 결과적으로 persistentUserHome 기능은 툴링 이미지에 /home/user/ 콘텐츠가 /home/tooling 내에 있을 것으로 예상합니다.

예를 들어 툴 컨테이너 이미지에 .config 및 .config -folder /another-file 과 같은 홈/tooling 디렉터리에 파일이 포함된 경우 stow는 다음과 같은 방식으로 영구 볼륨에 심볼릭 링크를 생성합니다.

그림 4.11. persistUserhome이 활성화된 툴 컨테이너

영구 사용자 홈 예제 시나리오

init 컨테이너는 stow 명령의 출력을 /home/user/.stow.log 에 쓰고 영구 볼륨이 작업 공간에 처음 마운트될 때만 stow 를 실행합니다.

stow 명령을 사용하여 영구 볼륨에서 /home/user 콘텐츠를 채우면 다음과 같은 두 가지 주요 이점이 있습니다.

  1. 심볼릭 링크를 만드는 것은 영구 볼륨에 /home/user 디렉터리 콘텐츠의 복사본을 생성하는 것보다 적은 스토리지를 사용하는 속도가 빠릅니다. 다르게 설정하기 위해 이 경우 영구 볼륨에는 실제 파일 자체가 아닌 심볼릭 링크가 포함되어 있습니다.
  2. 툴 이미지가 최신 버전의 기존 바이너리, 구성 및 파일로 업데이트되면 기존 심볼릭 링크가 이미 /home/tooling 의 최신 버전에 연결되므로 init 컨테이너가 새 버전을 중단할 필요가 없습니다.
참고

툴링 이미지가 추가 바이너리 또는 파일로 업데이트되면 stow 명령이 다시 실행되지 않기 때문에 /home/user 디렉터리에 심볼릭 링크되지 않습니다. 이 경우 사용자는 /home/user/.stow_completed 파일을 삭제하고 작업 공간을 다시 시작하여 stow 를 재실행해야 합니다.

persistUserhome 툴 이미지 요구 사항

persistUserhome 은 작업 공간에 사용되는 툴 이미지에 따라 다릅니다. 기본적으로 OpenShift Dev Spaces는 샘플 작업 공간에 UDI(Universal Developer Image)를 사용하며 이 이미지는 즉시 persistUser home을 지원합니다.

사용자 지정 이미지를 사용하는 경우 persistUser home 기능을 지원하기 위해 충족해야 하는 세 가지 요구 사항이 있습니다.

  1. 툴 이미지에 stow 버전 >= 2.4.0이 포함되어야 합니다.
  2. $HOME 환경 변수는 /home/user 로 설정됩니다.
  3. 툴 이미지에서 /home/user 콘텐츠를 포함하기 위한 디렉터리는 /home/tooling 입니다.

요구 사항 3으로 인해 기본 UDI 이미지는 예를 들어 /home/user 콘텐츠를 /home/tooling 에 추가하고 실행합니다.

RUN stow -t /home/user/ -d /home/tooling/ --no-folding
Copy to Clipboard

Dockerfile에서 /home/tooling 의 파일은 persistUserhome Home 기능을 사용하지 않는 경우에도 /home/user 에서 액세스할 수 있습니다.

4.10. 대시보드 구성

4.10.1. 시작하기 샘플 구성

다음 절차에서는 사용자 정의 샘플을 표시하도록 OpenShift Dev Spaces 대시보드를 구성하는 방법을 설명합니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. 샘플 구성으로 JSON 파일을 생성합니다. 파일에는 각 오브젝트가 샘플을 나타내는 오브젝트 배열이 포함되어야 합니다.

    cat > my-samples.json <<EOF
    [
      {
        "displayName": "<display_name>", 
    1
    
        "description": "<description>", 
    2
    
        "tags": <tags>, 
    3
    
        "url": "<url>", 
    4
    
        "icon": {
          "base64data": "<base64data>", 
    5
    
          "mediatype": "<mediatype>" 
    6
    
        }
      }
    ]
    EOF
    Copy to Clipboard
    1
    샘플의 표시 이름입니다.
    2
    샘플에 대한 설명입니다.
    3
    태그의 JSON 배열(예: ["java", "spring"].
    4
    devfile을 포함하는 리포지토리의 URL입니다.
    5
    아이콘의 base64로 인코딩된 데이터입니다.
    6
    아이콘의 미디어 유형입니다. 예를 들면 image/png 입니다.
  2. 샘플 구성을 사용하여 ConfigMap을 생성합니다.

    oc create configmap getting-started-samples --from-file=my-samples.json -n openshift-devspaces
    Copy to Clipboard
  3. ConfigMap에 필요한 라벨을 추가합니다.

    oc label configmap getting-started-samples app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=getting-started-samples -n openshift-devspaces
    Copy to Clipboard
  4. 새 샘플을 보려면 OpenShift Dev Spaces 대시보드 페이지를 새로 고칩니다.

4.10.2. 편집기 정의 구성

OpenShift Dev Spaces 편집기 정의를 구성하는 방법을 알아봅니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. 편집기 정의 구성을 사용하여 my-editor-definition-devfile.yaml YAML 파일을 만듭니다.

    중요

    metadata.attributes 에서 게시자버전의 실제 값을 제공해야 합니다. 게시자/이름/버전 형식의 편집기 이름과 함께 편집기 ID를 구성하는 데 사용됩니다.

    아래에서 지원되는 값(선택 사항 포함)을 찾을 수 있습니다.

    # Version of the devile schema
    schemaVersion: 2.2.2
    # Meta information of the editor
    metadata:
      # (MANDATORY) The editor name
      # Must consist of lower case alphanumeric characters, '-' or '.'
      name: editor-name
      displayName: Display Name
      description: Run Editor Foo on top of Eclipse Che
      # (OPTIONAL) Array of tags of the current editor. The Tech-Preview tag means the option is considered experimental and is not recommended for production environments. While it can include new features and improvements, it may still contain bugs or undergo significant changes before reaching a stable version.
      tags:
        - Tech-Preview
      # Additional attributes
      attributes:
        title: This is my editor
        # (MANDATORY) The publisher name
        publisher: publisher
        # (MANDATORY) The editor version
        version: version
        repository: https://github.com/editor/repository/
        firstPublicationDate: '2024-01-01'
        iconMediatype: image/svg+xml
        iconData: |
          <icon-content>
    # List of editor components
    components:
      # Name of the component
      - name: che-code-injector
        # Configuration of devworkspace-related container
        container:
          # Image of the container
          image: 'quay.io/che-incubator/che-code:insiders'
          # The command to run in the dockerimage component instead of the default one provided in the image
          command:
            - /entrypoint-init-container.sh
          # (OPTIONAL) List of volumes mounts that should be mounted in this container
          volumeMounts:
              # The name of the mount
            - name: checode
              # The path of the mount
              path: /checode
          # (OPTIONAL) The memory limit of the container
          memoryLimit: 256Mi
          # (OPTIONAL) The memory request of the container
          memoryRequest: 32Mi
          # (OPTIONAL) The CPU limit of the container
          cpuLimit: 500m
          # (OPTIONAL) The CPU request of the container
          cpuRequest: 30m
      # Name of the component
      - name: che-code-runtime-description
        # (OPTIONAL) Map of implementation-dependant free-form YAML attributes
        attributes:
          # The component within the architecture
          app.kubernetes.io/component: che-code-runtime
          # The name of a higher level application this one is part of
          app.kubernetes.io/part-of: che-code.eclipse.org
          # Defines a container component as a "container contribution". If a flattened DevWorkspace has a container component with the merge-contribution attribute, then any container contributions are merged into that container component
          controller.devfile.io/container-contribution: true
        container:
          # Can be a dummy image because the component is expected to be injected into workspace dev component
          image: quay.io/devfile/universal-developer-image:latest
          # (OPTIONAL) List of volume mounts that should be mounted in this container
          volumeMounts:
              # The name of the mount
            - name: checode
              # (OPTIONAL) The path in the component container where the volume should be mounted. If no path is defined, the default path is the is /<name>
              path: /checode
          # (OPTIONAL) The memory limit of the container
          memoryLimit: 1024Mi
          # (OPTIONAL) The memory request of the container
          memoryRequest: 256Mi
          # (OPTIONAL) The CPU limit of the container
          cpuLimit: 500m
          # (OPTIONAL) The CPU request of the container
          cpuRequest: 30m
          # (OPTIONAL) Environment variables used in this container
          env:
            - name: ENV_NAME
              value: value
          # Component endpoints
          endpoints:
            # Name of the editor
            - name: che-code
              # (OPTIONAL) Map of implementation-dependant string-based free-form attributes
              attributes:
                # Type of the endpoint. You can only set its value to main, indicating that the endpoint should be used as the mainUrl in the workspace status (i.e. it should be the URL used to access the editor in this context)
                type: main
                # An attribute that instructs the service to automatically redirect the unauthenticated requests for current user authentication. Setting this attribute to true has security consequences because it makes Cross-site request forgery (CSRF) attacks possible. The default value of the attribute is false.
                cookiesAuthEnabled: true
                # Defines an endpoint as "discoverable", meaning that a service should be created using the endpoint name (i.e. instead of generating a service name for all endpoints, this endpoint should be statically accessible)
                discoverable: false
                # Used to secure the endpoint with authorization on OpenShift, so that not anyone on the cluster can access the endpoint, the attribute enables authentication.
                urlRewriteSupported: true
              # Port number to be used within the container component
              targetPort: 3100
              # (OPTIONAL) Describes how the endpoint should be exposed on the network (public, internal, none)
              exposure: public
              # (OPTIONAL) Describes whether the endpoint should be secured and protected by some authentication process
              secure: true
              # (OPTIONAL) Describes the application and transport protocols of the traffic that will go through this endpoint
              protocol: https
        # Mandatory name that allows referencing the component from other elements
      - name: checode
        # (OPTIONAL) Allows specifying the definition of a volume shared by several other components. Ephemeral volumes are not stored persistently across restarts. Defaults to false
        volume: {ephemeral: true}
    # (OPTIONAL) Bindings of commands to events. Each command is referred-to by its name
    events:
      # IDs of commands that should be executed before the devworkspace start. These commands would typically be executed in an init container
      preStart:
        - init-container-command
      # IDs of commands that should be executed after the devworkspace has completely started. In the case of Che-Code, these commands should be executed after all plugins and extensions have started, including project cloning. This means that those commands are not triggered until the user opens the IDE within the browser
      postStart:
        - init-che-code-command
    # (OPTIONAL) Predefined, ready-to-use, devworkspace-related commands
    commands:
        # Mandatory identifier that allows referencing this command
      - id: init-container-command
        apply:
          # Describes the component for the apply command
          component: che-code-injector
        # Mandatory identifier that allows referencing this command
      - id: init-che-code-command
        # CLI Command executed in an existing component container
        exec:
          # Describes component for the exec command
          component: che-code-runtime-description
          # The actual command-line string
          commandLine: 'nohup /checode/entrypoint-volume.sh > /checode/entrypoint-logs.txt
            2>&1 &'
    Copy to Clipboard
  2. 편집기 정의 콘텐츠를 사용하여 ConfigMap을 생성합니다.

    oc create configmap my-editor-definition --from-file=my-editor-definition-devfile.yaml -n openshift-devspaces
    Copy to Clipboard
  3. ConfigMap에 필요한 라벨을 추가합니다.

    oc label configmap my-editor-definition app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=editor-definition -n openshift-devspaces
    Copy to Clipboard
  4. 사용 가능한 새 편집기를 보려면 OpenShift Dev Spaces 대시보드 페이지를 새로 고칩니다.
4.10.2.1. 편집기 정의 검색

편집기 정의는 다음 URL의 OpenShift Dev Spaces 대시보드 API에서도 제공합니다.

https://<openshift_dev_spaces_fqdn>/dashboard/api/editors

4.10.2절. “편집기 정의 구성” 의 예제에서는 다음 URL에 액세스하여 편집기 정의를 검색할 수 있습니다.

https:// <openshift_dev_spaces_fqdn> /dashboard/api/editors/devfile?che-editor=publisher/editor-name/version

작은 정보

OpenShift 클러스터 내에서 편집기 정의를 검색할 때 대시보드 서비스를 통해 OpenShift Dev Spaces 대시보드 API에 액세스할 수 있습니다. http://devspaces-dashboard.openshift-devspaces.svc.cluster.local:8080/dashboard/api/editors

추가 리소스

4.10.3. 기본 편집기 정의 구성

OpenShift Dev Spaces 기본 편집기 정의를 구성하는 방법을 알아봅니다.

사전 요구 사항

프로세스

  1. 사용 가능한 편집기의 ID를 확인합니다.

    oc exec deploy/devspaces-dashboard -n openshift-devspaces  \
        -- curl -s http://localhost:8080/dashboard/api/editors | jq -r '.[] | "\(.metadata.attributes.publisher)/\(.metadata.name)/\(.metadata.attributes.version)"'
    Copy to Clipboard
  2. defaultEditor 를 구성합니다.

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' \
        -p '{"spec":{"devEnvironments":{"defaultEditor": "<default_editor>"}}}'
    1
    Copy to Clipboard
    1
    작업 영역을 생성하는 기본 편집기는 플러그인 ID 또는 URI를 사용하여 지정할 수 있습니다. 플러그인 ID는 publisher/name/version 형식을 따라야 합니다. 첫 번째 단계에서 사용 가능한 편집기 ID를 참조하십시오.

4.10.4. 편집기 정의 숨기기

OpenShift Dev Spaces 편집기 정의를 숨기는 방법을 알아봅니다. 이 기능은 대시보드 UI에서 선택한 편집기를 숨기고, 예를 들어 IntelliJ IDEA Cryostat를 숨기고 Visual Studio Code - 오픈 소스만 표시하려는 경우에 유용합니다.

사전 요구 사항

프로세스

  1. OpenShift Dev Spaces Operator가 배포된 네임스페이스를 찾습니다.

    OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
    Copy to Clipboard
  2. 사용 가능한 편집기 정의 파일을 찾습니다.

    oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- ls /tmp/editors-definitions
    Copy to Clipboard

    출력은 다음 예와 유사해야 합니다.

    che-code-insiders.yaml
    che-code-latest.yaml
    che-idea-latest.yaml
    che-idea-next.yaml
    Copy to Clipboard
  3. 숨길 편집기 정의를 선택합니다. 예를 들어 che-idea-next.yaml 편집기 정의를 숨기려면 편집기 정의 파일 이름을 설정합니다.

    CHE_EDITOR_CONCEAL_FILE_NAME=che-idea-next.yaml
    Copy to Clipboard
  4. 숨겨진 편집기 정의의 ConfigMap 이름을 정의합니다.

    CHE_EDITOR_CONCEAL_CONFIGMAP_NAME=che-conceal-$CHE_EDITOR_CONCEAL_FILE_NAME
    Copy to Clipboard
  5. ConfigMap을 생성합니다.

    oc create configmap $CHE_EDITOR_CONCEAL_CONFIGMAP_NAME \
        --namespace $OPERATOR_NAMESPACE \
        --from-literal=$CHE_EDITOR_CONCEAL_FILE_NAME=""
    Copy to Clipboard
  6. Operator 서브스크립션 이름과 네임스페이스(있는 경우)를 확인합니다.

    SUBSCRIPTION=$(oc get subscriptions \
        --all-namespaces \
        --output json \
            | jq -r '.items[] | select(.spec.name=="devspaces")')
    SUBSCRIPTION_NAMESPACE=$(echo $SUBSCRIPTION | jq -r '.metadata.namespace')
    SUBSCRIPTION_NAME=$(echo $SUBSCRIPTION | jq -r '.metadata.name')
    Copy to Clipboard
  7. Kubernetes 리소스를 패치하여 빈 편집기 정의로 ConfigMap을 마운트합니다. 패치할 리소스는 Operator 서브스크립션이 있는지에 따라 다릅니다. 서브스크립션이 존재하는 경우 서브스크립션을 패치해야 합니다. 그렇지 않은 경우 Operator 배포를 패치합니다.

    if [[ -n $SUBSCRIPTION_NAMESPACE ]]; then
        if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config}') == "" ]]; then
            oc patch subscription $SUBSCRIPTION_NAME \
              --namespace $SUBSCRIPTION_NAMESPACE \
              --type json \
              --patch '[{
                    "op":"add",
                    "path":"/spec/config",
                    "value": {}
                }]'
        fi
    
        if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config.volumes}') == "" ]]; then
            oc patch subscription $SUBSCRIPTION_NAME \
              --namespace $SUBSCRIPTION_NAMESPACE \
              --type json \
              --patch '[{
                    "op":"add",
                    "path":"/spec/config/volumes",
                    "value": []
                }]'
        fi
    
        if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config.volumeMounts}') == "" ]]; then
            oc patch subscription $SUBSCRIPTION_NAME \
              --namespace $SUBSCRIPTION_NAMESPACE \
              --type json \
              --patch '[{
                    "op":"add",
                    "path":"/spec/config/volumeMounts",
                    "value": []
                }]'
        fi
    
        oc patch subscription $SUBSCRIPTION_NAME \
          --namespace $SUBSCRIPTION_NAMESPACE \
          --type json \
          --patch '[{
            "op":"add",
            "path":"/spec/config/volumes/-",
            "value": {
                "name":"'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'",
                "configMap": {
                    "name": "'$CHE_EDITOR_CONCEAL_CONFIGMAP_NAME'"
                }
            }
          },
          {
            "op":"add",
            "path":"/spec/config/volumeMounts/-",
            "value":{
                "name": "'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'",
                "subPath":"'$CHE_EDITOR_CONCEAL_FILE_NAME'",
                "mountPath": "/tmp/editors-definitions/'$CHE_EDITOR_CONCEAL_FILE_NAME'"
            }
          }]'
    else
        oc patch deployment devspaces-operator \
          --namespace $OPERATOR_NAMESPACE \
          --type json \
          --patch '[{
            "op":"add",
            "path":"/spec/template/spec/volumes/-",
            "value": {
                "name":"'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'",
                "configMap": {
                    "name": "'$CHE_EDITOR_CONCEAL_CONFIGMAP_NAME'"
                }
            }
        },
        {
            "op":"add",
            "path":"/spec/template/spec/containers/0/volumeMounts/-",
            "value":{
                "name": "'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'",
                "subPath":"'$CHE_EDITOR_CONCEAL_FILE_NAME'",
                "mountPath": "/tmp/editors-definitions/'$CHE_EDITOR_CONCEAL_FILE_NAME'"
            }
        }
    ]'
    fi
    Copy to Clipboard

4.11. ID 및 권한 관리

이 섹션에서는 Red Hat OpenShift Dev Spaces의 ID 및 권한 부여 관리의 다양한 측면을 설명합니다.

4.11.1. Git 공급자의 OAuth 구성

참고

Red Hat OpenShift Dev Spaces에서 작업 공간 시작 시 개인 액세스 토큰을 강제로 새로 고치는 실험적 기능을 활성화하려면 다음과 같이 사용자 정의 리소스 구성을 수정합니다.

spec:
  components:
    cheServer:
      extraProperties:
        CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN: "true"
Copy to Clipboard

OpenShift Dev Spaces와 Git 공급자 간에 OAuth를 구성하여 사용자가 원격 Git 리포지토리에서 작업할 수 있습니다.

4.11.1.1. GitHub용 OAuth 2.0 구성

사용자가 GitHub에서 호스팅되는 원격 Git 리포지토리를 사용할 수 있도록 하려면 다음을 수행합니다.

  1. GitHub OAuth 앱(OAuth 2.0)을 설정합니다.
  2. GitHub OAuth 앱 시크릿을 적용합니다.
4.11.1.1.1. GitHub OAuth 앱 설정

OAuth 2.0을 사용하여 GitHub OAuth 앱을 설정합니다.

사전 요구 사항

  • GitHub에 로그인되어 있습니다.

프로세스

  1. https://github.com/settings/applications/new 로 이동합니다.
  2. 다음 값을 입력합니다.

    1. 애플리케이션 이름: &lt;애플리케이션 이름>
    2. Homepage URL: https://<openshift_dev_spaces_fqdn>/
    3. Authorization callback URL: https://<openshift_dev_spaces_fqdn>/api/oauth/callback
  3. Register application을 클릭합니다.
  4. 새 클라이언트 시크릿 생성 을 클릭합니다.
  5. GitHub OAuth 앱 시크릿을 적용할 때 사용할 GitHub OAuth 클라이언트 ID 를 복사하고 저장합니다.
  6. GitHub OAuth 앱 시크릿을 적용할 때 사용할 GitHub OAuth 클라이언트 시크릿을 복사하고 저장합니다.
4.11.1.1.2. GitHub OAuth 앱 시크릿 적용

GitHub OAuth 앱 시크릿을 준비하고 적용합니다.

사전 요구 사항

  • GitHub OAuth 앱 설정이 완료되었습니다.
  • GitHub OAuth 앱을 설정할 때 생성된 다음 값이 준비됩니다.

    • GitHub OAuth 클라이언트 ID
    • GitHub OAuth 클라이언트 시크릿
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. 보안을 준비합니다.

    kind: Secret
    apiVersion: v1
    metadata:
      name: github-oauth-config
      namespace: openshift-devspaces 
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: github
        che.eclipse.org/scm-server-endpoint: <github_server_url> 
    2
    
        che.eclipse.org/scm-github-disable-subdomain-isolation: 'false' 
    3
    
    type: Opaque
    stringData:
      id: <GitHub_OAuth_Client_ID> 
    4
    
      secret: <GitHub_OAuth_Client_Secret> 
    5
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    조직에서 사용하는 GitHub 제품에 따라 다릅니다. GitHub.com 또는 GitHub Enterprise Cloud에서 리포지토리를 호스팅하는 경우 이 행을 생략하거나 기본 https://github.com 을 입력합니다. GitHub Enterprise Server에서 리포지토리를 호스팅하는 경우 GitHub Enterprise Server URL을 입력합니다.
    3
    비활성화된 하위 도메인 격리 옵션과 함께 GitHub Enterprise Server를 사용하는 경우 주석을 true 로 설정해야 합니다. 그러지 않으면 주석을 생략하거나 false 로 설정할 수 있습니다.
    4
    GitHub OAuth 클라이언트 ID.
    5
    GitHub OAuth 클라이언트 시크릿.
  2. 보안을 적용합니다.

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard
  3. 출력에서 Secret이 생성되었는지 확인합니다.

다른 GitHub 공급자에 대해 OAuth 2.0을 구성하려면 위의 단계를 반복하고 다른 이름으로 두 번째 GitHub OAuth 시크릿을 생성해야 합니다.

4.11.1.2. GitLab에 대한 OAuth 2.0 구성

사용자가 GitLab 인스턴스를 사용하여 호스팅되는 원격 Git 리포지토리에서 작업할 수 있도록 하려면 다음을 수행합니다.

  1. GitLab 인증 애플리케이션(OAuth 2.0)을 설정합니다.
  2. GitLab 인증 애플리케이션 시크릿을 적용합니다.
4.11.1.2.1. GitLab 인증 애플리케이션 설정

OAuth 2.0을 사용하여 GitLab 인증 애플리케이션을 설정합니다.

사전 요구 사항

  • GitLab에 로그인되어 있습니다.

프로세스

  1. avatar를 클릭하고 Edit profileApplications 로 이동합니다.
  2. 이름으로 OpenShift Dev Spaces입력합니다.
  3. Redirect URIhttps:// <openshift_dev_spaces_fqdn> /api/oauth/callback 을 입력합니다.
  4. ConfidentialExpire 액세스 토큰 확인란을 선택합니다.
  5. Scopes 에서 api,write_repository, openid 체크박스를 선택합니다.
  6. Save application 을 클릭합니다.
  7. GitLab 인증 애플리케이션 시크릿을 적용할 때 사용할 GitLab 애플리케이션 ID 를 복사하고 저장합니다.
  8. GitLab-authorized 애플리케이션 시크릿을 적용할 때 사용할 GitLab 클라이언트 시크릿을 복사하고 저장합니다.
4.11.1.2.2. GitLab 인증 애플리케이션 시크릿 적용

GitLab 인증 애플리케이션 시크릿을 준비하고 적용합니다.

사전 요구 사항

  • GitLab 인증 애플리케이션 설정이 완료되었습니다.
  • GitLab 인증 애플리케이션을 설정할 때 생성된 다음 값이 준비됩니다.

    • GitLab Application ID
    • GitLab 클라이언트 시크릿
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. 보안을 준비합니다.

    kind: Secret
    apiVersion: v1
    metadata:
      name: gitlab-oauth-config
      namespace: openshift-devspaces 
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: gitlab
        che.eclipse.org/scm-server-endpoint: <gitlab_server_url> 
    2
    
    type: Opaque
    stringData:
      id: <GitLab_Application_ID> 
    3
    
      secret: <GitLab_Client_Secret> 
    4
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    GitLab 서버 URL 입니다. SAAS 버전에 https://gitlab.com 를 사용합니다.
    3
    GitLab 애플리케이션 ID 입니다.
    4
    GitLab 클라이언트 시크릿.
  2. 보안을 적용합니다.

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard
  3. 출력에서 Secret이 생성되었는지 확인합니다.

다른 Gitlab 공급자에 대해 OAuth 2.0을 구성하려면 위의 단계를 반복하고 다른 이름으로 두 번째 Gitlab OAuth 시크릿을 생성해야 합니다.

4.11.1.3. Bitbucket 서버에 대한 OAuth 2.0 구성

OAuth 2.0을 사용하여 사용자가 Bitbucket 서버에서 호스팅되는 원격 Git 리포지토리로 작업할 수 있습니다.

  1. Bitbucket 서버에서 OAuth 2.0 애플리케이션 링크를 설정합니다.
  2. Bitbucket 서버에 대한 애플리케이션 링크 시크릿을 적용합니다.
4.11.1.4. Bitbucket Cloud에 대한 OAuth 2.0 구성

사용자가 Bitbucket Cloud에서 호스팅되는 원격 Git 리포지토리에서 작업할 수 있습니다.

  1. Bitbucket Cloud에서 OAuth 소비자(OAuth 2.0)를 설정합니다.
  2. Bitbucket Cloud에 OAuth 소비자 시크릿을 적용합니다.
4.11.1.4.1. Bitbucket 클라우드에서 OAuth 소비자 설정

Bitbucket Cloud에서 OAuth 2.0에 대한 OAuth 소비자를 설정합니다.

사전 요구 사항

  • Bitbucket Cloud에 로그인되어 있습니다.

프로세스

  1. avatar를 클릭하고 모든 작업 공간 페이지로 이동합니다.
  2. 작업 영역을 선택하고 클릭합니다.
  3. 설정OAuth 소비자 추가 소비자 로 이동합니다.
  4. 이름으로 OpenShift Dev Spaces입력합니다.
  5. 콜백 URLhttps:// <openshift_dev_spaces_fqdn> /api/oauth/callback 을 입력합니다.
  6. 권한 에서 모든 계정리포지토리 확인란을 선택하고 저장을 클릭합니다.
  7. 추가된 소비자를 확장한 다음 Bitbucket OAuth 소비자 시크릿을 적용할 때 사용할 Key 값을 복사하여 저장합니다.
  8. Bitbucket OAuth 소비자 시크릿을 적용할 때 사용할 Secret 값을 복사하고 저장합니다.
4.11.1.4.2. Bitbucket Cloud에 대한 OAuth 소비자 시크릿 적용

Bitbucket Cloud에 대한 OAuth 소비자 시크릿을 준비하고 적용합니다.

사전 요구 사항

  • OAuth 소비자는 Bitbucket Cloud에서 설정됩니다.
  • Bitbucket OAuth 소비자를 설정할 때 생성된 다음 값이 준비됩니다.

    • Bitbucket OAuth 소비자 키
    • Bitbucket OAuth 소비자 시크릿
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. 보안을 준비합니다.

    kind: Secret
    apiVersion: v1
    metadata:
      name: bitbucket-oauth-config
      namespace: openshift-devspaces 
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: bitbucket
    type: Opaque
    stringData:
      id: <Bitbucket_Oauth_Consumer_Key> 
    2
    
      secret: <Bitbucket_Oauth_Consumer_Secret> 
    3
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    Bitbucket OAuth 소비자 키.
    3
    Bitbucket OAuth 소비자 시크릿.
  2. 보안을 적용합니다.

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard
  3. 출력에서 Secret이 생성되었는지 확인합니다.
4.11.1.5. Bitbucket 서버에 대한 OAuth 1.0 구성

사용자가 Bitbucket 서버에서 호스팅되는 원격 Git 리포지토리에서 작업할 수 있도록 하려면 다음을 수행합니다.

  1. Bitbucket 서버에서 애플리케이션 링크(OAuth 1.0)를 설정합니다.
  2. Bitbucket 서버에 대한 애플리케이션 링크 시크릿을 적용합니다.
4.11.1.6. Microsoft Azure DevOps Services용 OAuth 2.0 구성

사용자가 Microsoft Azure Repos에서 호스팅되는 원격 Git 리포지토리에서 작업할 수 있도록 하려면 다음을 수행합니다.

  1. Microsoft Azure DevOps Services OAuth App(OAuth 2.0)을 설정합니다.
  2. Microsoft Azure DevOps Services OAuth 앱 시크릿을 적용합니다.

4.11.1.6.1. Microsoft Azure DevOps Services OAuth 앱 설정

OAuth 2.0을 사용하여 Microsoft Azure DevOps Services OAuth 앱을 설정합니다.

사전 요구 사항

  • Microsoft Azure DevOps Services 에 로그인되어 있습니다.

    중요

    OAuth를 통한 타사 애플리케이션 액세스 는 조직에 대해 활성화됩니다. 조직의 애플리케이션 연결 및 보안 정책 변경을 참조하십시오.

    프로세스

    1. https://app.vsaex.visualstudio.com/app/register/.
    2. 다음 값을 입력합니다.

      1. 회사 이름:OpenShift Dev Spaces
      2. 애플리케이션 이름:OpenShift Dev Spaces
      3. Application website: https://<openshift_dev_spaces_fqdn>/
      4. Authorization callback URL: https://<openshift_dev_spaces_fqdn>/api/oauth/callback
    3. 인증 범위 선택에서 코드(읽기 및 쓰기) 를 선택합니다.
    4. 애플리케이션 생성을 클릭합니다.
    5. Microsoft Azure DevOps Services OAuth 앱 시크릿을 적용할 때 사용할 앱 ID 를 복사하고 저장합니다.
    6. 표시 를 클릭하여 클라이언트 시크릿 을 표시합니다.
    7. Microsoft Azure DevOps Services OAuth 앱 시크릿을 적용할 때 사용할 클라이언트 시크릿을 복사하고 저장합니다.

4.11.1.6.2. Microsoft Azure DevOps Services OAuth 앱 시크릿 적용

Microsoft Azure DevOps Services 시크릿을 준비하고 적용합니다.

사전 요구 사항

  • Microsoft Azure DevOps Services OAuth 앱 설정이 완료되었습니다.
  • Microsoft Azure DevOps 서비스 OAuth 앱을 설정할 때 생성된 다음 값이 준비됩니다.

    • 앱 ID
    • 클라이언트 시크릿
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. 보안을 준비합니다.

    kind: Secret
    apiVersion: v1
    metadata:
      name: azure-devops-oauth-config
      namespace: openshift-devspaces
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: azure-devops
    type: Opaque
    stringData:
      id: <Microsoft_Azure_DevOps_Services_OAuth_App_ID>
    2
    
      secret: <Microsoft_Azure_DevOps_Services_OAuth_Client_Secret>
    3
    Copy to Clipboard
    1
    OpenShift Dev Spaces 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    Microsoft Azure DevOps Services OAuth 앱 ID.
    3
    Microsoft Azure DevOps Services OAuth 클라이언트 시크릿.
  2. 보안을 적용합니다.

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard
  3. 출력에서 Secret이 생성되었는지 확인합니다.
  4. OpenShift Dev Spaces 서버 구성 요소의 롤아웃이 완료될 때까지 기다립니다.

4.11.2. Dev Spaces 사용자에 대한 클러스터 역할 구성

해당 사용자에게 클러스터 역할을 추가하여 OpenShift Dev Spaces 사용자에게 더 많은 클러스터 권한을 부여할 수 있습니다.

사전 요구 사항

  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. 사용자 역할 이름을 정의합니다.

    $ USER_ROLES=<name> 
    1
    Copy to Clipboard
    1
    고유한 리소스 이름입니다.
  2. OpenShift Dev Spaces Operator가 배포된 네임스페이스를 찾습니다.

    $ OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
    Copy to Clipboard
  3. 필요한 역할을 생성합니다.

    $ kubectl apply -f - <<EOF
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: ${USER_ROLES}
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
    rules:
      - verbs:
          - <verbs> 
    1
    
        apiGroups:
          - <apiGroups> 
    2
    
        resources:
          - <resources> 
    3
    
    EOF
    Copy to Clipboard
    1
    & lt;verbs > 로서 이 규칙에 포함된 모든 ResourceKinds 및 AttributeRestrictions에 적용되는 모든 Verbs를 나열합니다. * 를 사용하여 모든 동사를 표시할 수 있습니다.
    2
    & lt;apiGroups& gt; 로서 리소스를 포함하는 APIGroups의 이름을 지정합니다.
    3
    & lt;resources& gt; 로서 이 규칙이 적용되는 모든 리소스를 나열합니다. * 를 사용하여 모든 동사를 표시할 수 있습니다.
  4. OpenShift Dev Spaces Operator에 역할을 위임합니다.

    $ kubectl apply -f - <<EOF
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: ${USER_ROLES}
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
    subjects:
      - kind: ServiceAccount
        name: devspaces-operator
        namespace: ${OPERATOR_NAMESPACE}
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: ${USER_ROLES}
    EOF
    Copy to Clipboard
  5. che 서비스 계정에 역할을 위임하도록 OpenShift Dev Spaces Operator를 구성합니다.

    $ kubectl patch checluster devspaces \
      --patch '{"spec": {"components": {"cheServer": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \
      --type=merge -n openshift-devspaces
    Copy to Clipboard
  6. 사용자에게 역할을 위임하도록 OpenShift Dev Spaces 서버를 구성합니다.

    $ kubectl patch checluster devspaces \
      --patch '{"spec": {"devEnvironments": {"user": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \
      --type=merge -n openshift-devspaces
    Copy to Clipboard
  7. OpenShift Dev Spaces 서버 구성 요소의 롤아웃이 완료될 때까지 기다립니다.
  8. 사용자에게 로그아웃하고 로그인하여 새 역할을 적용하도록 요청합니다.

4.11.3. 고급 권한 부여 구성

OpenShift Dev Spaces에 액세스할 수 있는 사용자 및 그룹을 확인할 수 있습니다.

사전 요구 사항

  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. CheCluster 사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      networking:
        auth:
          advancedAuthorization:
            allowUsers:
              - <allow_users> 
    1
    
            allowGroups:
              - <allow_groups> 
    2
    
            denyUsers:
              - <deny_users> 
    3
    
            denyGroups:
              - <deny_groups> 
    4
    Copy to Clipboard
    1
    Red Hat OpenShift Dev Spaces에 액세스할 수 있는 사용자 목록입니다.
    2
    Red Hat OpenShift Dev Spaces에 액세스할 수 있는 사용자 그룹 목록(OpenShift Container Platform 전용).
    3
    사용자 목록은 Red Hat OpenShift Dev Spaces에 대한 액세스를 거부했습니다.
    4
    Red Hat OpenShift Dev Spaces 액세스는 거부된 사용자 그룹 목록입니다(OpenShift Container Platform만 해당).
  2. OpenShift Dev Spaces 서버 구성 요소의 롤아웃이 완료될 때까지 기다립니다.
참고

사용자가 OpenShift Dev Spaces에 액세스할 수 있도록 허용하려면 allowUsers 목록에 추가합니다. 또는 사용자가 멤버인 그룹을 선택하고 allowGroups 목록에 그룹을 추가합니다. OpenShift Dev Spaces에 대한 사용자 액세스를 거부하려면 denyUsers 목록에 추가합니다. 또는 사용자가 멤버인 그룹을 선택하고 denyGroups 목록에 그룹을 추가합니다. 사용자가 허용거부 목록 모두에 있는 경우 OpenShift Dev Spaces에 대한 액세스가 거부됩니다.

allowUsersallowGroups 가 비어 있으면 거부 목록에 있는 항목을 제외한 모든 사용자가 OpenShift Dev Spaces에 액세스할 수 있습니다. denyUsersdenyGroups 가 비어 있으면 허용 목록의 사용자만 OpenShift Dev Spaces에 액세스할 수 있습니다.

허용거부 목록이 모두 비어 있으면 모든 사용자가 OpenShift Dev Spaces에 액세스할 수 있습니다.

4.11.4. GDPR 준수로 사용자 데이터 제거

사용자는 일반 데이터 보호 규정(GDPR) 을 준수하여 OpenShift Container Platform에서 사용자의 데이터를 제거하여 개인 데이터를 삭제할 수 있는 권리를 행사할 수 있습니다. 다른 Kubernetes 인프라의 프로세스는 다를 수 있습니다. Red Hat OpenShift Dev Spaces 설치에 사용하는 공급자의 사용자 관리 모범 사례를 따르십시오.

주의

다음과 같이 사용자 데이터를 제거하는 것은 되돌릴 수 없습니다! 삭제된 모든 데이터는 삭제되고 복구할 수 없습니다!

사전 요구 사항

  • OpenShift Container Platform 클러스터에 대한 관리 권한이 있는 활성 oc 세션입니다. OpenShift CLI 시작하기를 참조하십시오.

프로세스

  1. 다음 명령을 사용하여 OpenShift 클러스터의 모든 사용자를 나열합니다.

    $ oc get users
    Copy to Clipboard
  2. 사용자 항목을 삭제합니다.
중요

사용자에게 연결된 리소스(예: 프로젝트, 역할 또는 서비스 계정)가 있는 경우 사용자를 삭제하기 전에 먼저 해당 리소스를 삭제해야 합니다.

$ oc delete user <username>
Copy to Clipboard

4.12. fuse-overlayfs 구성

기본적으로 UBI(Universal Developer Image)에는 작업 공간 내에서 컨테이너 이미지를 빌드하고 내보내는 데 사용할 수 있는 Podman 및 Buildah가 포함되어 있습니다. 그러나 UDI의 Podman 및 Buildah는 COW(Copy-On-Write) 지원을 제공하지 않는 vfs 스토리지 드라이버를 사용하도록 구성됩니다. 보다 효율적인 이미지 관리를 위해 루트 없는 환경에서 COW(Copy-On-Write)를 지원하는 fuse-overlayfs 스토리지 드라이버를 사용하십시오.

4.15 이전 버전의 OpenShift의 작업 공간에 fuse-overlayfs를 활성화하려면 관리자가 먼저 4.12.1절. “4.15 이전의 OpenShift 버전에 대한 액세스 활성화” 를 통해 클러스터에서 /dev/fuse 액세스를 활성화해야 합니다.

/dev/fuse 장치는 기본적으로 사용 가능하므로 OpenShift 버전 4.15 이상에는 필요하지 않습니다. 릴리스 정보를 참조하십시오.

/dev/fuse 액세스를 활성화한 후 다음 두 가지 방법으로 fuse-overlayfs를 활성화할 수 있습니다.

  1. 클러스터 내의 모든 사용자 작업 공간 4.12.2절. “모든 작업 공간에 fuse-overlayfs 활성화”을 참조하십시오.
  2. 특정 사용자에게 속한 작업 공간의 경우 https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.18/html-single/user_guide/index#end-user-guide:using-the-fuse-overlay-storage-driver 을 참조하십시오.

4.12.1. 4.15 이전의 OpenShift 버전에 대한 액세스 활성화

fuse-overlayfs를 사용하려면 먼저 작업 공간 컨테이너에서 /dev/fuse 에 액세스할 수 있도록 해야 합니다.

참고

/dev/fuse 장치를 기본적으로 사용할 수 있으므로 OpenShift 버전 4.15 이상에는 이 절차가 필요하지 않습니다. 릴리스 정보를 참조하십시오.

주의

OpenShift 클러스터에서 MachineConfig 리소스를 생성하는 것은 클러스터에 대한 고급 시스템 수준의 변경을 수행하기 때문에 잠재적으로 위험한 작업입니다.

자세한 내용 및 가능한 위험은 MachineConfig 문서를 참조하십시오.

사전 요구 사항

  • Butane 툴(butane)은 사용 중인 운영 체제에 설치됩니다.
  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.

프로세스

  1. OpenShift 클러스터 유형(단일 노드 클러스터 또는 별도의 컨트롤 플레인 및 작업자 노드가 있는 다중 노드 클러스터)에 따라 환경 변수를 설정합니다.

    • 단일 노드 클러스터의 경우 다음을 설정합니다.

      $ NODE_ROLE=master
      Copy to Clipboard
    • 다중 노드 클러스터의 경우 다음을 설정합니다.

      $ NODE_ROLE=worker
      Copy to Clipboard
  2. OpenShift Butane 구성 버전의 환경 변수를 설정합니다. 이 변수는 OpenShift 클러스터의 메이저 및 마이너 버전입니다. 예를 들면 4.12.0,4.13.0 또는 4.14.0 입니다.

    $ VERSION=4.12.0
    Copy to Clipboard
  3. NODE_ROLE 노드에 99-podman-fuse 라는 드롭인 CRI-O 구성 파일을 생성하는 MachineConfig 리소스를 생성합니다. 이 구성 파일을 사용하면 특정 Pod에 대해 가능한 /dev/fuse 장치에 액세스할 수 있습니다.

    cat << EOF | butane | oc apply -f -
    variant: openshift
    version: ${VERSION}
    metadata:
      labels:
        machineconfiguration.openshift.io/role: ${NODE_ROLE}
      name: 99-podman-dev-fuse-${NODE_ROLE}
    storage:
      files:
      - path: /etc/crio/crio.conf.d/99-podman-fuse 
    1
    
        mode: 0644
        overwrite: true
        contents: 
    2
    
          inline: |
            [crio.runtime.workloads.podman-fuse] 
    3
    
            activation_annotation = "io.openshift.podman-fuse" 
    4
    
            allowed_annotations = [
              "io.kubernetes.cri-o.Devices" 
    5
    
            ]
            [crio.runtime]
            allowed_devices = ["/dev/fuse"] 
    6
    
    EOF
    Copy to Clipboard
    1
    CRI-O에 대한 새로운 드롭인 구성 파일의 절대 파일 경로입니다.
    2
    새 드롭인 구성 파일의 내용입니다.
    3
    podman-fuse 워크로드를 정의합니다.
    4
    podman-fuse 워크로드 설정을 활성화하는 pod 주석입니다.
    5
    podman-fuse 워크로드에서 처리할 수 있는 주석 목록입니다.
    6
    사용자가 io.kubernetes.cri-o.Devices 주석으로 지정할 수 있는 호스트의 장치 목록입니다.
  4. MachineConfig 리소스를 적용하면 변경 사항이 적용되면 작업자 역할이 있는 각 노드에 대해 예약이 일시적으로 비활성화됩니다. 노드 상태를 확인합니다.

    $ oc get nodes
    Copy to Clipboard

    출력 예:

    NAME                           STATUS                     ROLES    AGE   VERSION
    ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.27.9
    ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.27.9
    ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.27.9
    ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.27.9
    ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.27.9
    ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.27.9
    Copy to Clipboard
  5. 작업자 역할의 모든 노드의 상태가 Ready 이면 다음 주석이 있는 모든 Pod에서/dev/fuse 를 사용할 수 있습니다.

    io.openshift.podman-fuse: ''
    io.kubernetes.cri-o.Devices: /dev/fuse
    Copy to Clipboard

검증 단계

  1. 작업자 역할이 있는 노드의 이름을 가져옵니다.

    $ oc get nodes
    Copy to Clipboard
  2. 작업자 노드에 대한 oc 디버그 세션을 엽니다.

    $ oc debug node/<nodename>
    Copy to Clipboard
  3. 99-podman-fuse 라는 새 CRI-O 구성 파일이 있는지 확인합니다.

    sh-4.4# stat /host/etc/crio/crio.conf.d/99-podman-fuse
    Copy to Clipboard
4.12.1.1. 작업 공간 내에서 Podman 및 Buildah에 fuse-overlayfs 사용

사용자는 https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.18/html-single/user_guide/index#end-user-guide:using-the-fuse-overlay-storage-driver 에 따라 Podman 및 Buildah의 fuse-overlayfs 스토리지 드라이버를 사용하도록 기존 작업 공간을 업데이트할 수 있습니다.

4.12.2. 모든 작업 공간에 fuse-overlayfs 활성화

해당 컨테이너를 사용하는 모든 작업 공간에 fuse-overlayfs를 사용하도록 작업 공간의 컨테이너 진입점 스크립트 구성에 대해 알아봅니다.

UDI(Universal Developer Image)에는 기본적으로 필요한 구성이 이미 포함되어 있습니다. 그러나 Podman 5.x로 인해 사용자 지정 이미지를 사용하는 경우 현재 사용자가 /home/user/.config 폴더를 소유해야 하는 경우 스크립트를 수동으로 구성해야 합니다.

사전 요구 사항

프로세스

  1. CheCluster 사용자 정의 리소스의 spec.devEnvironments.workspacesPodAnnotations 필드에 필요한 주석을 설정합니다.

    kind: CheCluster
    apiVersion: org.eclipse.che/v2
    spec:
      devEnvironments:
        workspacesPodAnnotations:
          io.kubernetes.cri-o.Devices: /dev/fuse
    Copy to Clipboard
    참고

    OpenShift 버전 4.14 이하의 경우 io.openshift.podman-fuse: "" 주석도 필요합니다.

  2. 선택 사항: 작업 공간 컨테이너에 사용자 지정 이미지를 사용하는 경우 /home/user/.config 폴더를 생성하고 진입점을 통해 런타임에서 storage.conf 파일을 구성합니다. 이렇게 하려면 이미지를 빌드하기 전에 작업 공간 컨테이너 이미지의 진입점 스크립트에 다음을 추가합니다. 진입점에 /home/user/.config 폴더를 생성하면 이미지 빌드 시 알 수 없는 현재 사용자가 폴더를 소유하게 됩니다.

    # Configure container builds to use vfs or fuse-overlayfs
    if [ ! -d "${HOME}/.config/containers" ]; then
      mkdir -p ${HOME}/.config/containers
      if [ -c "/dev/fuse" ] && [ -f "/usr/bin/fuse-overlayfs" ]; then
        (echo '[storage]';echo 'driver = "overlay"';echo '[storage.options.overlay]';echo 'mount_program = "/usr/bin/fuse-overlayfs"') > ${HOME}/.config/containers/storage.conf
      else
        (echo '[storage]';echo 'driver = "vfs"') > "${HOME}"/.config/containers/storage.conf
      fi
    fi
    Copy to Clipboard

    이렇게 하면 /home/user/.config 가 아직 존재하지 않는 경우 폴더가 생성되어 사용자가 소유합니다. 예를 들어 /home/user/.config 가 영구 볼륨에 저장된 경우 이미 존재할 수 있습니다.

  3. 작업 영역을 시작하고 /home/user/.config 의 소유자가 user 인지 확인합니다.

    $ ls -la /home/user
    Copy to Clipboard

    출력 예:

    ...
    drwxrwsr-x.  3 user 1000660000   24 Dec 24 15:40 .config
    Copy to Clipboard
  4. 스토리지 드라이버가 오버레이 인지 확인합니다.

    $ podman info | grep overlay
    Copy to Clipboard

    출력 예:

    graphDriverName: overlay
      overlay.mount_program:
        Executable: /usr/bin/fuse-overlayfs
        Package: fuse-overlayfs-1.14-1.el9.x86_64
          fuse-overlayfs: version 1.13-dev
      Backing Filesystem: overlayfs
    Copy to Clipboard
    참고

    기존 작업 공간에 대해 다음 오류가 발생할 수 있습니다.

    ERRO[0000] User-selected graph driver "overlay" overwritten by graph driver "vfs" from database - delete libpod local files ("/home/user/.local/share/containers/storage") to resolve.  May prevent use of images created by other tools
    Copy to Clipboard

    이 경우 오류 메시지에 언급된 libpod 로컬 파일을 삭제합니다.

5장. IDE 확장 관리

IDE는 확장 또는 플러그인을 사용하여 기능을 확장하며 확장 기능을 관리하는 메커니즘은 IDE 간에 다릅니다.

5.1. Microsoft Visual Studio Code 확장 - 오픈 소스

확장을 관리하기 위해 이 IDE 는 다음 Open VSX 레지스트리 인스턴스 중 하나를 사용합니다.

  • Air-gapped, 오프라인 및 프록시 제한 환경을 지원하기 위해 OpenShift Dev Spaces의 plugin-registry 포드에서 실행되는 Open VSX 레지스트리의 임베디드 인스턴스입니다. 임베디드 Open VSX 레지스트리에는 open-vsx.org 에 게시된 확장의 하위 집합만 포함되어 있습니다. 이 하위 집합을 사용자 지정할 수 있습니다.
  • 인터넷을 통해 액세스하는 공개 open-vsx.org 레지스트리입니다.
  • OpenShift Dev Spaces 작업 공간 포드에서 액세스할 수 있는 네트워크에 배포된 독립 실행형 Open VSX 레지스트리 인스턴스입니다.

기본값은 Open VSX 레지스트리의 포함된 인스턴스입니다.

5.1.1. Open VSX 레지스트리 인스턴스 선택

기본값은 Open VSX 레지스트리의 포함된 인스턴스입니다.

기본 Open VSX 레지스트리 인스턴스가 필요한 경우 다음 인스턴스 중 하나를 선택할 수 있습니다.

  • https://open-vsx.org 에서 인터넷에 액세스해야 하는 Open VSX 레지스트리 인스턴스입니다.
  • OpenShift Dev Spaces 작업 공간 포드에서 액세스할 수 있는 네트워크에 배포된 독립 실행형 Open VSX 레지스트리 인스턴스입니다.

프로세스

  • CheCluster 사용자 정의 리소스에서 openVSXURL 값을 편집합니다.

    spec:
      components:
        pluginRegistry:
          openVSXURL: "<url_of_an_open_vsx_registry_instance>" 
    1
    Copy to Clipboard
    1
    예: openVSXURL: "https://open-vsx.org".
    중요
    • https://open-vsx.org 를 사용하는 것은 인터넷과 격리된 Air-gapped 환경에서 권장되지 않습니다. 악성 코드 제거의 위험을 줄이고 코드에 대한 무단 액세스는 큐레이트된 확장 세트와 함께 내장되거나 자체 호스팅되는 Open VSX 레지스트리를 사용합니다.
    • plugin-registry pod에서 포함된 Open VSX 레지스트리 인스턴스를 선택하려면 openVSXURL: '' 를 사용합니다. 포함된 확장 목록을 사용자 지정할 수 있습니다.
    • 또한 독립 실행형 Open VSX 레지스트리 인스턴스의 URL에서 openVSXURL 을 가리킬 수 있으며 프록시에 의해 차단되지 않은 경우 해당 URL을 조직의 클러스터 내에서 액세스할 수 있습니다.

5.1.2. 임베디드 Open VSX 레지스트리 인스턴스에서 확장 기능 추가 또는 제거

포함된 Open VSX 레지스트리 인스턴스에서 확장을 추가하거나 제거할 수 있습니다. 그러면 조직의 작업 공간에 사용할 수 있는 Open VSX 레지스트리의 사용자 지정 빌드가 생성됩니다.

작은 정보

OpenShift Dev Spaces 업데이트 후 최신 보안 수정 사항을 얻으려면 최신 태그 또는 SHA를 기반으로 컨테이너를 다시 빌드합니다.

프로세스

  1. 선택한 각 확장의 게시자 및 확장 이름을 가져옵니다.

    1. Open VSX 레지스트리 웹 사이트에서 확장을 찾고 확장 프로그램 목록 페이지 및 확장 프로그램의 URL을 복사합니다.
    2. 복사한 URL에서 <publisher > 및 <extension> 이름을 추출합니다.

      https://open-vsx.org/extension/<publisher>/<name>
      Copy to Clipboard
      작은 정보

      확장 기능을 Microsoft Visual Studio Marketplace 에서만 사용할 수 있지만 Open VSX 에서는 사용할 수 없는 경우 확장 게시자에 이러한 지침에 따라 open-vsx.org에도 게시하도록 요청할 수 있습니다.If the extension is only available from Microsoft Visual Studio Marketplace , but not Open VSX , you can also ask the extension publisher to also publish it on open-vsx.org according to these instructions. https://github.com/marketplace/actions/publish-vs-code-extension

      확장 게시자를 사용할 수 없거나 open-vsx.org 에 확장을 게시하지 않으려는 경우 확장 기능에 해당하는 Open VSX가 없는 경우 Open VSX 팀에 문제를 보고하는 것이 좋습니다.

  2. 사용자 정의 플러그인 레지스트리 이미지를 빌드하고 CheCluster 사용자 정의 리소스를 업데이트합니다.

    작은 정보
    • 빌드 프로세스 중에 각 확장은 OpenShift Dev Spaces에서 사용되는 Visual Studio Code 버전과의 호환성을 확인합니다.
    1. OpenShift Dev Spaces 인스턴스 사용:

      중요

      IBM Power(ppc64le) 및 IBM Z(s390x)의 경우 사용자 정의 플러그인 레지스트리가 해당 아키텍처에 로컬로 빌드될 것으로 예상됩니다.

      1. 관리자로 OpenShift Dev Spaces 인스턴스에 로그인합니다.

Red Hat Registry 서비스 계정을 생성하고 사용자 이름과 토큰을 복사합니다.

  1. 플러그인 레지스트리 리포지토리 를 사용하여 작업 영역을 시작합니다.
  2. 터미널을 열고 OpenShift Dev Spaces 버전(예: devspaces-3.15-rhel-8)에 해당하는 Git 태그를 확인합니다.

    git checkout devspaces-$PRODUCT_VERSION-rhel-8
    Copy to Clipboard
  3. openvsx-sync.json 파일을 열고 확장을 추가하거나 제거합니다.
  4. 1을 실행합니다. 작업 공간의 registry.redhat.io 작업에 로그인합니다(Terminal → Run Task…​ → devfile → 1. registry.redhat.io에 로그인하고 registry.redhat.io 에 로그인합니다.
  5. 2를 실행합니다. 작업 공간에 사용자 지정 플러그인 레지스트리 작업을 빌드하고 게시합니다(Terminal → Run Task…​ → devfile → 2. 사용자 지정 플러그인 레지스트리 빌드 및 게시).
  6. 3을 실행합니다. 작업 영역에서 사용자 정의 플러그인 레지스트리 작업을 사용하도록 Che를 구성합니다(Terminal → Run Task…​ → devfile → 3). 사용자 지정 플러그인 레지스트리를 사용하도록 Che를 구성합니다.

    1. Linux 운영 체제 사용:

      작은 정보
      • podman 및 NodeJS 버전 18.20.3 이상이 시스템에 설치되어 있어야 합니다.
  7. Dev Spaces 리포지토리를 다운로드하거나 분기하고 복제합니다.
git clone https://github.com/redhat-developer/devspaces.git
Copy to Clipboard

+

  1. 플러그인 레지스트리 하위 모듈로 이동합니다.
cd devspaces/dependencies/che-plugin-registry/
Copy to Clipboard

+

  1. OpenShift Dev Spaces 버전에 해당하는 태그를 체크아웃합니다(예: devspaces-3.15-rhel-8).

    git checkout devspaces-$PRODUCT_VERSION-rhel-8
    Copy to Clipboard
  2. Red Hat Registry 서비스 계정을 생성하고 사용자 이름과 토큰을 복사합니다.
  3. registry.redhat.io 에 로그인 :

    podman login registry.redhat.io
    Copy to Clipboard
  4. 추가 또는 제거해야 하는 각 확장에 대해 openvsx-sync.json 파일을 편집합니다.

    • 확장을 추가하려면 openvsx-sync.json 파일에 게시자, 이름 및 확장 버전을 추가합니다.
    • 확장을 제거하려면 openvsx-sync.json 파일에서 게시자, 이름 및 확장 버전을 제거합니다.
    • 다음 JSON 구문을 사용합니다.

          {
              "id": "<publisher>.<name>",
              "version": "<extension_version>"
          }
      Copy to Clipboard
      작은 정보
      • 조직에서 내부 용도로만 사용되는 확장 프로그램 또는 closed-source 확장이 있는 경우 사용자 정의 플러그인 레지스트리 컨테이너에 액세스할 수 있는 URL을 사용하여 .vsix 파일에서 직접 확장을 추가할 수 있습니다.

            {
                "id": "<publisher>.<name>",
                "download": "<url_to_download_vsix_file>",
                "version": "<extension_version>"
            }
        Copy to Clipboard
      • 리소스를 사용하기 전에 Microsoft Visual Studio Marketplace 에 대한 사용 약관 을 읽으십시오.
  5. 플러그인 레지스트리 컨테이너 이미지를 빌드하고 quay.io 와 같은 컨테이너 레지스트리에 게시합니다.

    1. $ ./build.sh -o <username> -r quay.io -t custom
      Copy to Clipboard
    2. $ podman push quay.io/<username/plugin_registry:custom>
      Copy to Clipboard
  6. 조직의 클러스터에서 CheCluster 사용자 지정 리소스를 편집하여 (예: quay.io) 이미지를 가리키고 변경 사항을 저장합니다.

    spec:
      components:
        pluginRegistry:
          deployment:
            containers:
              - image: quay.io/<username/plugin_registry:custom>
          openVSXURL: ''
    Copy to Clipboard

검증

  1. plugin-registry pod가 다시 시작되어 실행 중인지 확인합니다.
  2. 작업 영역을 다시 시작하고 작업 공간 IDE의 확장 보기에서 사용 가능한 확장을 확인합니다.

5.2. VSX 레지스트리 URL 열기

확장을 검색하고 설치하기 위해 Microsoft Visual Studio Code - 오픈 소스 편집기는 포함된 Open VSX 레지스트리 인스턴스를 사용합니다. 또한 포함된 항목이 아닌 다른 Open VSX 레지스트리 인스턴스를 사용하도록 OpenShift Dev Spaces를 구성할 수도 있습니다.

프로세스

  • CheCluster 사용자 정의 리소스 spec.components.pluginRegistry.openVSXURL 필드에서 Open VSX 레지스트리 인스턴스의 URL을 설정합니다.

    spec:
       components:
    # [...]
         pluginRegistry:
           openVSXURL: <your_open_vsx_registy>
    # [...]
    Copy to Clipboard
    주의

    전용 Microsoft 사용 약관 으로 인해 Red Hat OpenShift Dev Spaces에서Visual Studio Code Marketplace 를 지원하지 않습니다.

6장. Visual Studio Code 구성 - 오픈 소스("코드 - OSS")

Visual Studio Code - 오픈 소스("Code - OSS")를 구성하는 방법을 알아봅니다.

6.1. 단일 및 다중 루트 작업 공간 구성

다중 루트 작업 공간 기능을 사용하면 동일한 작업 공간에 여러 프로젝트 폴더를 사용할 수 있습니다. 이 기능은 제품 문서 및 제품 코드 리포지토리와 같은 여러 관련 프로젝트에서 한 번에 작업할 때 유용합니다.

작은 정보

작업 공간 파일을 더 잘 이해하고 작성할 수 있는 VS Code "workspace" 를 참조하십시오.

참고

기본적으로 작업 공간은 다중 루트 모드에서 열리도록 설정됩니다.

작업 공간이 시작되면 /projects/.code-workspace 작업 공간이 생성됩니다. 작업 공간 파일에는 devfile에 설명된 모든 프로젝트가 포함됩니다.

{
	"folders": [
		{
			"name": "project-1",
			"path": "/projects/project-1"
		},
		{
			"name": "project-2",
			"path": "/projects/project-2"
		}
	]
}
Copy to Clipboard

작업 공간 파일이 이미 있으면 업데이트되고 누락된 모든 프로젝트가 devfile에서 가져옵니다. devfile에서 프로젝트를 제거하면 작업 공간 파일에 남아 있습니다.

기본 동작을 변경하고 자체 작업 공간 파일을 제공하거나 단일 루트 작업 공간으로 전환할 수 있습니다.

프로세스

  • 자체 작업 공간 파일을 제공합니다.

    • .code-workspace 라는 작업 공간 파일을 리포지토리의 루트에 배치합니다. 작업 영역을 만든 후 Visual Studio Code - Open Source("Code - OSS")는 작업 공간 파일을 그대로 사용합니다.

      {
      	"folders": [
      		{
      			"name": "project-name",
      			"path": "."
      		}
      	]
      }
      Copy to Clipboard
      중요

      작업 공간 파일을 만들 때는 주의하십시오. 오류가 발생하면 대신 빈 Visual Studio Code - 오픈 소스("Code - OSS")가 열립니다.

      중요

      여러 프로젝트가 있는 경우 작업 공간 파일은 첫 번째 프로젝트에서 가져옵니다. 첫 번째 프로젝트에 작업 공간 파일이 없으면 새 파일이 생성되어 /projects 디렉터리에 배치됩니다.

  • 대체 작업 공간 파일을 지정합니다.

    • devfile에 VSCODE_DEFAULT_WORKSPACE 환경 변수를 정의하고 작업 공간 파일의 올바른 위치를 지정합니다.

         env:
           - name: VSCODE_DEFAULT_WORKSPACE
             value: "/projects/project-name/workspace-file"
      Copy to Clipboard
  • 단일 루트 모드에서 작업 공간을 엽니다.

    • VSCODE_DEFAULT_WORKSPACE 환경 변수를 정의하고 root로 설정합니다.

         env:
           - name: VSCODE_DEFAULT_WORKSPACE
             value: "/"
      Copy to Clipboard

6.2. Microsoft Visual Studio Code에 대한 신뢰할 수 있는 확장 구성

Microsoft Visual Studio Code의 product.json 파일에서 trustedExtensionAuthAccess 필드를 사용하여 인증 토큰에 액세스하는 데 신뢰할 수 있는 확장을 지정할 수 있습니다.

	"trustedExtensionAuthAccess": [
		"<publisher1>.<extension1>",
		"<publisher2>.<extension2>"
	]
Copy to Clipboard

이는 GitHub, Microsoft 또는 OAuth가 필요한 기타 서비스와 같은 서비스에 액세스해야 하는 확장 기능이 있는 경우 특히 유용합니다. 이 필드에 확장 ID를 추가하면 이러한 토큰에 액세스할 수 있는 권한을 부여합니다.

devfile 또는 ConfigMap에서 변수를 정의할 수 있습니다. 필요에 더 적합한 옵션을 선택합니다. ConfigMap을 사용하면 변수가 모든 작업 공간에 전파되며 사용 중인 devfile마다 변수를 추가할 필요가 없습니다.

주의

trustedExtensionAuthAccess 필드를 잘못 사용하는 경우 보안 위험이 발생할 수 있으므로 주의하십시오. 신뢰할 수 있는 확장에만 액세스 권한을 부여합니다.

프로세스

Microsoft Visual Studio Code 편집기는 che-code 이미지 내에 번들되므로 작업 공간이 시작될 때 product.json 파일만 변경할 수 있습니다.

  1. VSCODE_TRUSTED_EXTENSIONS 환경 변수를 정의합니다. devfile.yaml에서 변수를 정의하거나 변수를 사용하여 ConfigMap을 마운트하는 중에서 선택합니다.

    1. devfile.yaml에서 VSCODE_TRUSTED_EXTENSIONS 환경 변수를 정의합니다.

         env:
           - name: VSCODE_TRUSTED_EXTENSIONS
             value: "<publisher1>.<extension1>,<publisher2>.<extension2>"
      Copy to Clipboard
    2. VSCODE_TRUSTED_EXTENSIONS 환경 변수를 사용하여 ConfigMap을 마운트합니다.

         kind: ConfigMap
         apiVersion: v1
         metadata:
           name: trusted-extensions
           labels:
             controller.devfile.io/mount-to-devworkspace: 'true'
             controller.devfile.io/watch-configmap: 'true'
           annotations:
             controller.devfile.io/mount-as: env
         data:
           VSCODE_TRUSTED_EXTENSIONS: '<publisher1>.<extension1>,<publisher2>.<extension2>'
      Copy to Clipboard

검증

  • 변수 값은 작업 영역 시작 시 구문 분석되고 해당 trustedExtensionAuthAccess 섹션이 product.json 에 추가됩니다.

6.3. 기본 확장 구성

기본 확장은 확장 프로그램 바이너리 .vsix 파일 경로를 DEFAULT_EXTENSIONS 환경 변수에 배치하여 지정된 사전 설치된 확장 집합입니다.

시작 후 편집기는 이 환경 변수를 확인하고 지정된 경우 확장의 경로를 가져와서 사용자를 방해하지 않고 백그라운드에 설치합니다.

기본 확장 구성은 편집기 수준에서 .vsix 확장을 설치하는 데 유용합니다.

참고

여러 개의 확장 기능을 지정하려면 해당 확장을 together으로 구분합니다.

  DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
Copy to Clipboard

DEFAULT_EXTENSIONS 환경 변수를 정의하는 방법을 알아보려면 작업 공간에 .vsix 파일을 추가하는 여러 예제를 참조하십시오.

기본 .vsix 확장을 작업 공간에 포함하는 세 가지 다른 방법이 있습니다.

  • 확장 바이너리를 소스 리포지토리에 넣습니다.
  • devfile postStart 이벤트를 사용하여 네트워크에서 확장 바이너리를 가져옵니다.
  • che-code 이미지에 확장의 .vsix 바이너리를 포함합니다.

확장 바이너리를 소스 리포지토리에 배치

확장 바이너리를 Git 리포지토리에 배치하고 devfile에서 환경 변수를 정의하는 것이 작업 공간에 기본 확장 기능을 추가하는 가장 쉬운 방법입니다. 리포지토리 루트에 extension.vsix 파일이 있는 경우 툴링 컨테이너에 DEFAULT_EXTENSIONS 를 설정할 수 있습니다.

프로세스

  • 다음 예와 같이 .devfile.yaml 에서 DEFAULT_EXTENSIONS 를 지정합니다.

    schemaVersion: 2.3.0
    metadata:
      generateName: example-project
    components:
      - name: tools
        container:
          image: quay.io/devfile/universal-developer-image:ubi8-latest
          env:
            - name: 'DEFAULT_EXTENSIONS'
              value: '/projects/example-project/extension.vsix'
    Copy to Clipboard

devfile postStart 이벤트를 사용하여 네트워크에서 확장 바이너리 가져오기

cURL 또는 GNU Wget을 사용하여 작업 공간에 확장을 다운로드할 수 있습니다. 이를 위해서는 다음이 필요합니다.

  • workpace에 확장을 다운로드하려면 devfile 명령을 지정합니다.
  • postStart 이벤트를 추가하여 작업 공간 시작 시 명령을 실행합니다.
  • devfile에서 DEFAULT_EXTENSIONS 환경 변수를 정의합니다.

프로세스

  • 다음 예에 표시된 값을 devfile에 추가합니다.

    schemaVersion: 2.3.0
    metadata:
      generateName: example-project
    components:
      - name: tools
        container:
          image: quay.io/devfile/universal-developer-image:ubi8-latest
          env:
            - name: DEFAULT_EXTENSIONS
              value: '/tmp/extension-1.vsix;/tmp/extension-2.vsix'
    
    commands:
      - id: add-default-extensions
        exec:
          # name of the tooling container
          component: tools
          # download several extensions using curl
          commandLine: |
            curl https://.../extension-1.vsix --location -o /tmp/extension-1.vsix
            curl https://.../extension-2.vsix --location -o /tmp/extension-2.vsix
    
    events:
      postStart:
        - add-default-extensions
    Copy to Clipboard
    주의

    경우에 따라 curl은 .gzip 압축 파일을 다운로드할 수 있습니다. 이로 인해 확장 기능을 설치할 수 없습니다. 이 문제를 해결하려면 파일을 .vsix.gz 파일로 저장한 다음 gunzip 으로 압축을 풉니다. 이렇게 하면 .vsix.gz 파일이 압축 해제된 .vsix 파일로 대체됩니다.

    curl https://some-extension-url --location -o /tmp/extension.vsix.gz
    gunzip /tmp/extension.vsix.gz
    Copy to Clipboard

che-code 이미지에 확장 .vsix 바이너리 포함

편집기 이미지에 번들된 기본 확장과 ConfigMap에 정의된 DEFAULT_EXTENSIONS 환경 변수를 사용하면 devfile을 변경하지 않고 기본 확장을 적용할 수 있습니다.

다음 단계에 따라 편집기 이미지에 필요한 확장을 추가합니다.

프로세스

  • 디렉토리를 만들고 이 디렉토리에 선택한 .vsix 확장을 배치합니다.
  • 다음 콘텐츠를 사용하여 Dockerfile을 생성합니다.

    # inherit che-incubator/che-code:latest
    FROM quay.io/che-incubator/che-code:latest
    USER 0
    
    # copy all .vsix files to /default-extensions directory
    RUN mkdir --mode=775 /default-extensions
    COPY --chmod=755 *.vsix /default-extensions/
    
    # add instruction to the script to copy default extensions to the working container
    RUN echo "cp -r /default-extensions /checode/" >> /entrypoint-init-container.sh
    Copy to Clipboard
  • 이미지를 빌드한 다음 레지스트리로 푸시합니다.

    $ docker build -t yourname/che-code:next .
    $ docker push yourname/che-code:next
    Copy to Clipboard
  • 새 ConfigMap을 사용자 프로젝트에 추가하고 DEFAULT_EXTENSIONS 환경 변수를 정의하고 확장에 대한 절대 경로를 지정합니다. 이 ConfigMap은 환경 변수를 사용자 프로젝트의 모든 작업 공간으로 설정합니다.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: vscode-default-extensions
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
      annotations:
        controller.devfile.io/mount-as: env
    data:
      DEFAULT_EXTENSIONS: '/checode/default-extensions/extension1.vsix;/checode/default-extensions/extension2.vsix'
    Copy to Clipboard
  • yourname/che-code:next 이미지를 사용하여 작업 영역을 생성합니다. 먼저 대시보드를 열고 왼쪽의 Create Workspace 탭으로 이동합니다.

    1. 편집기 선택기 섹션에서 편집기 정의 사용 드롭다운을 확장하고 편집기 URI를 편집기 이미지로 설정합니다.
    2. 샘플을 클릭하거나 Git 리포지토리 URL을 사용하여 작업 영역을 생성합니다.

7장. Dev Spaces 서버 API 사용

OpenShift Dev Spaces 서버 워크로드를 관리하려면 Swagger 웹 사용자 인터페이스를 사용하여 OpenShift Dev Spaces 서버 API를 탐색합니다.

프로세스

  • Swagger API 웹 사용자 인터페이스( https:// <openshift_dev_spaces_fqdn> /swagger )로 이동합니다.

추가 리소스

8장. Dev Spaces 업그레이드

이 장에서는 CodeReady Workspaces 3.1에서 OpenShift Dev Spaces 3.1로 업그레이드하는 방법을 설명합니다.

8.1. chectl 관리 툴 업그레이드

이 섹션에서는 dsc 관리 도구를 업그레이드하는 방법을 설명합니다.

8.2. 업데이트 승인 전략 지정

Red Hat OpenShift Dev Spaces Operator는 다음 두 가지 업그레이드 전략을 지원합니다.

자동
Operator는 새 업데이트가 제공되면 설치합니다.
Manual
새 업데이트는 설치를 시작하기 전에 수동으로 승인해야 합니다.

OpenShift 웹 콘솔을 사용하여 Red Hat OpenShift Dev Spaces Operator에 대한 업데이트 승인 전략을 지정할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자의 OpenShift 웹 콘솔 세션입니다. 웹 콘솔 액세스를 참조하십시오.
  • Red Hat Ecosystem Catalog를 사용하여 설치한 OpenShift Dev Spaces 인스턴스.

프로세스

  1. OpenShift 웹 콘솔에서 Operator 설치된 Operator로 이동합니다.
  2. 설치된 Operator 목록에서 Red Hat OpenShift Dev Spaces 를 클릭합니다.
  3. 서브스크립션 탭으로 이동합니다.
  4. 자동 또는 수동으로 업데이트 승인 전략을 구성합니다.

8.3. OpenShift 웹 콘솔을 사용하여 Dev Spaces 업그레이드

OpenShift 웹 콘솔의 Red Hat Ecosystem Catalog에서 Red Hat OpenShift Dev Spaces Operator를 사용하여 이전 마이너 버전에서 업그레이드를 수동으로 승인할 수 있습니다.

사전 요구 사항

프로세스

검증 단계

  1. OpenShift Dev Spaces 인스턴스로 이동합니다.
  2. 3.18 버전 번호는 페이지 하단에 표시됩니다.

8.4. CLI 관리 툴을 사용하여 Dev Spaces 업그레이드

이 섹션에서는 CLI 관리 툴을 사용하여 이전 마이너 버전에서 업그레이드하는 방법을 설명합니다.

사전 요구 사항

  • OpenShift의 관리 계정.
  • openshift-devspaces OpenShift 프로젝트에서 동일한 OpenShift 인스턴스에서 CLI 관리 툴을 사용하여 설치된 CodeReady Workspaces의 이전 마이너 버전의 실행 중인 인스턴스입니다.
  • OpenShift Dev Spaces 버전 3.18용 DSC. 2.2절. “dsc 관리 툴 설치” 을 참조하십시오.

프로세스

  1. 실행 중인 모든 CodeReady Workspaces 3.1 작업 공간에 대해 변경 사항을 저장하고 Git 리포지토리로 내보냅니다.
  2. CodeReady Workspaces 3.1 인스턴스에서 모든 작업 공간을 종료합니다.
  3. OpenShift Dev Spaces 업그레이드:

    $ dsc server:update -n openshift-devspaces
    Copy to Clipboard
    참고

    느린 시스템 또는 인터넷 연결의 경우 --k8spodwaittimeout=1800000 플래그 옵션을 추가하여 Pod 시간 초과 기간을 1800000ms 이상으로 확장합니다.

검증 단계

  1. OpenShift Dev Spaces 인스턴스로 이동합니다.
  2. 3.18 버전 번호는 페이지 하단에 표시됩니다.

8.5. 제한된 환경에서 Dev Spaces 업그레이드

이 섹션에서는 Red Hat OpenShift Dev Spaces를 업그레이드하고 제한된 환경에서 CLI 관리 툴을 사용하여 마이너 버전 업데이트를 수행하는 방법을 설명합니다.

사전 요구 사항

프로세스

  1. 미러링 스크립트를 다운로드하여 실행하여 사용자 정의 Operator 카탈로그를 설치하고 관련 이미지( prepare-restricted-environment.sh )를 미러링합니다.

    $ bash prepare-restricted-environment.sh \
      --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.17\
      --devworkspace_operator_version "v0.32.0" \
      --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.17" \
      --prod_operator_package_name "devspaces" \
      --prod_operator_bundle_name "devspacesoperator" \
      --prod_operator_version "v3.18.0" \
      --my_registry "<my_registry>" 
    1
    Copy to Clipboard
    1
    이미지를 미러링할 프라이빗 Docker 레지스트리
  2. CodeReady Workspaces 3.1 인스턴스에서 실행 중인 모든 작업 영역에서 변경 사항을 저장하고 Git 리포지토리로 내보냅니다.
  3. CodeReady Workspaces 3.1 인스턴스에서 모든 작업 공간을 중지합니다.
  4. 다음 명령을 실행합니다.

    $ dsc server:update --che-operator-image="$TAG" -n openshift-devspaces --k8spodwaittimeout=1800000
    Copy to Clipboard

검증 단계

  1. OpenShift Dev Spaces 인스턴스로 이동합니다.
  2. 3.18 버전 번호는 페이지 하단에 표시됩니다.

8.6. OpenShift에서 Dev Workspace Operator 복구

OLM 재시작 또는 클러스터 업그레이드와 같은 특정 조건에서 OpenShift Dev Spaces용 Dev Spaces Operator는 클러스터에 이미 존재하는 경우에도 Dev Workspace Operator를 자동으로 설치할 수 있습니다. 이 경우 다음과 같이 OpenShift에서 Dev Workspace Operator를 복구할 수 있습니다.

사전 요구 사항

  • 대상 OpenShift 클러스터에 대한 클러스터 관리자로서의 활성 oc 세션. CLI 시작하기를 참조하십시오.
  • OpenShift 웹 콘솔의 설치된 Operator 페이지에는 Dev Workspace Operator에 대한 여러 항목 또는 ReplacingPending (보류 중)에 있는 하나의 항목이 표시됩니다.

프로세스

  1. 실패한 Pod가 포함된 devworkspace-controller 네임스페이스를 삭제합니다.
  2. 변환 전략을 None 으로 설정하고 전체 Webhook 섹션을 제거하여 DevWorkspaceDevWorkspaceTemplate CRD(Custom Resource Definitions)를 업데이트합니다.

    spec:
      ...
      conversion:
        strategy: None
    status:
    ...
    Copy to Clipboard
    작은 정보

    AdministrationCustomResourceDefinitions 에서 DevWorkspace 를 검색하여 OpenShift 웹 콘솔의 관리자 화면에서 DevWorkspace 및 DevWorkspaceTemplate CRD를 찾고 편집할 수 있습니다.

    참고

    DevWorkspaceOperatorConfigDevWorkspaceRouting CRD에는 기본적으로 변환 전략이 None 으로 설정되어 있습니다.

  3. Dev Workspace Operator 서브스크립션을 제거합니다.

    $ oc delete sub devworkspace-operator \
    -n openshift-operators 
    1
    Copy to Clipboard
    1
    OpenShift-operators 또는 Dev Workspace Operator가 설치된 OpenShift 프로젝트입니다.
  4. Dev Workspace Operator CSV를 < devworkspace_operator.vX.Y.Z> 형식으로 가져옵니다.

    $ oc get csv | grep devworkspace
    Copy to Clipboard
  5. 각 Dev Workspace Operator CSV를 제거합니다.

    $ oc delete csv <devworkspace_operator.vX.Y.Z> \
    -n openshift-operators 
    1
    Copy to Clipboard
    1
    OpenShift-operators 또는 Dev Workspace Operator가 설치된 OpenShift 프로젝트입니다.
  6. Dev Workspace Operator 서브스크립션을 다시 생성합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: devworkspace-operator
      namespace: openshift-operators
    spec:
      channel: fast
      name: devworkspace-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      installPlanApproval: Automatic 
    1
    
      startingCSV: devworkspace-operator.v0.32.0
    EOF
    Copy to Clipboard
    1
    자동 또는 수동.
    중요

    installPlanApproval: Manual 의 경우 OpenShift 웹 콘솔의 관리자 화면에서 OperatorInstalled Operators 로 이동하여 Dev Workspace Operator:Upgrade availableInstallPlan Approve.

  7. OpenShift 웹 콘솔의 관리자 화면에서 Operator 설치된Operator 로 이동하여 Dev Workspace Operator성공 상태를 확인합니다.

9장. Dev Spaces 설치 제거

주의

OpenShift Dev Spaces를 설치 제거하면 모든 OpenShift Dev Spaces 관련 사용자 데이터가 제거됩니다!

oc 를 사용하여 OpenShift Dev Spaces 인스턴스를 설치 제거합니다.

사전 요구 사항

프로세스

  • OpenShift Dev Spaces 인스턴스를 제거합니다.

    $ dsc server:delete
    Copy to Clipboard
작은 정보

--delete-namespace 옵션은 OpenShift Dev Spaces 네임스페이스를 제거합니다.

--delete-all 옵션은 Dev Workspace Operator 및 관련 리소스를 제거합니다.

법적 공지

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat