관리 가이드
Red Hat OpenShift Dev Spaces 3.18 관리
초록
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
devEnvironments:
defaultNamespace:
autoProvision: false
이 설정을 사용하면 클러스터 관리자가 각 사용자에 대한 프로비저닝을 제어하고 리소스 제한 및 할당량을 포함하여 다양한 설정을 명시적으로 구성할 수 있는 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이 생성됩니다.
네임스페이스에 사용할 수 있는 권한을 사용자에게 부여할 수 있는 모든 리소스 및 작업은 아래에 나열되어 있습니다.
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
networking:
auth:
advancedAuthorization:
allowUsers:
- user-a
- user-b
denyUsers:
- user-c
allowGroups:
- openshift-group-a
- openshift-group-b
denyGroups:
- openshift-group-c
denyUsers
및 denyGroup
카테고리의 사용자는 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 컨테이너 보안 컨텍스트 사양에 SETGID
및 SETUID
기능을 추가합니다.
"spec": { "containers": [ "securityContext": { "allowPrivilegeEscalation": true, "capabilities": { "add": ["SETGID", "SETUID"], "drop": ["ALL","KILL","MKNOD"] }, "readOnlyRootFilesystem": false, "runAsNonRoot": true, "runAsUser": 1001110000 } ] }
"spec": {
"containers": [
"securityContext": {
"allowPrivilegeEscalation": true,
"capabilities": {
"add": ["SETGID", "SETUID"],
"drop": ["ALL","KILL","MKNOD"]
},
"readOnlyRootFilesystem": false,
"runAsNonRoot": true,
"runAsUser": 1001110000
}
]
}
이를 통해 사용자가 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
spec:
devEnvironments:
disableContainerBuildCapabilities: true
리소스 할당량 및 제한 범위
리소스 할당량 및 제한 범위는 클러스터 내에서 잘못된 행위자 및 리소스 오용을 방지하는 데 사용할 수 있는 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 서버를 수행할 수 있습니다.
사전 요구 사항
Linux 또는 macOS.
참고Windows에
dsc
를 설치하려면 다음 페이지를 참조하십시오.
프로세스
-
https://developers.redhat.com/products/openshift-dev-spaces/download 에서
$HOME
과 같은 디렉터리로 아카이브를 다운로드합니다. -
아카이브에서
tar xvzf
를 실행하여/dsc
디렉터리를 추출합니다. -
추출된
/dsc/bin
하위 디렉터리를$PATH
에 추가합니다.
검증
dsc
를 실행하여 이에 대한 정보를 봅니다.dsc
$ dsc
Copy to Clipboard Copied!
추가 리소스
2.3. 아키텍처
그림 2.1. Dev Workspace Operator를 사용한 고급 OpenShift Dev Spaces 아키텍처

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와 상호 작용

추가 리소스
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 게이트웨이와 다른 구성 요소 간의 상호 작용

추가 리소스
2.3.1.4. 사용자 대시보드
사용자 대시보드는 Red Hat OpenShift Dev Spaces의 방문 페이지입니다. OpenShift Dev Spaces 사용자는 사용자 대시보드를 검색하여 작업 공간에 액세스하고 관리합니다. 이는 React 애플리케이션입니다. OpenShift Dev Spaces 배포는 devspaces-dashboard
Deployment에서 시작합니다.
액세스할 수 있어야 합니다.
- 2.3.1.5절. “dev Spaces 서버”
- 2.3.1.6절. “플러그인 레지스트리”
- OpenShift API
그림 2.4. 다른 구성 요소와 사용자 대시보드 상호 작용

사용자가 사용자 대시보드를 요청하여 작업 영역을 시작할 때 사용자 대시보드는 이러한 작업 시퀀스를 실행합니다.
- 리포지토리 URL을 2.3.1.5절. “dev Spaces 서버” 로 전송하고 사용자가 원격 devfile에서 작업 공간을 생성할 때 반환되는 devfile이 필요합니다.
- 작업 공간을 설명하는 devfile을 읽습니다.
- 2.3.1.6절. “플러그인 레지스트리” 에서 추가 메타데이터를 수집합니다.
- 정보를 Dev Workspace 사용자 정의 리소스로 변환합니다.
- OpenShift API를 사용하여 사용자 프로젝트에서 Dev Workspace 사용자 지정 리소스를 생성합니다.
- Dev Workspace 사용자 정의 리소스 상태를 감시합니다.
- 사용자를 실행 중인 작업 공간 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 다른 구성 요소와의 서버 상호 작용

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 작업 공간 구성 요소

다이어그램에는 실행 중인 작업 공간이 하나씩 있습니다.
2.4. Dev Spaces 리소스 요구 사항 계산
OpenShift Dev Spaces Operator, Dev Workspace Controller 및 사용자 작업 공간은 Pod 세트로 구성됩니다. Pod는 CPU 및 메모리 제한 및 요청의 리소스 소비에 기여합니다.
devfile 예제에 대한 다음 링크는 업스트림 커뮤니티의 자료를 가리키는 포인터입니다. 이 자료에서는 사용 가능한 최신 콘텐츠와 최신 모범 사례를 나타냅니다. 이러한 팁은 Red Hat의 QE 부서에 의해 아직 진행되지 않았으며 다양한 사용자 그룹에서는 아직 검증되지 않았습니다. 이 정보를 신중하게 사용하십시오. '프로덕션' 용도 대신 교육 및 '개발' 목적에 가장 적합합니다.
프로세스
개발 환경을 정의하는 데 사용되는 devfile에 따라 달라지는 작업 공간 리소스 요구 사항을 식별합니다. 여기에는 devfile의 구성 요소 섹션에 명시적으로 지정된 작업 공간
구성 요소를
식별하는 작업이 포함됩니다.다음은 다음 구성 요소가 있는 devfile의 예입니다.
예 2.1.
툴
devfile의
툴
구성 요소는 다음 요청 및 제한을 정의합니다.memoryLimit: 6G memoryRequest: 512M cpuRequest: 1000m cpuLimit: 4000m
memoryLimit: 6G memoryRequest: 512M cpuRequest: 1000m cpuLimit: 4000m
Copy to Clipboard Copied! 작업 영역을 시작하는 동안 내부
che-gateway
컨테이너는 다음 요청 및 제한을 사용하여 암시적으로 프로비저닝됩니다.memoryLimit: 256M memoryRequest: 64M cpuRequest: 50m cpuLimit: 500m
memoryLimit: 256M memoryRequest: 64M cpuRequest: 50m cpuLimit: 500m
Copy to Clipboard Copied!
각 작업 공간에 필요한 리소스 합계를 계산합니다. 여러 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
- 모든 사용자가 동시에 실행할 것으로 예상되는 작업 공간 수와 작업 공간당 계산된 리소스를 곱합니다.
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를 설치할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. OpenShift CLI 시작하기를 참조하십시오. -
DSC
. 2.2절. “dsc 관리 툴 설치” 을 참조하십시오.
프로세스
선택 사항: 이전에 이 OpenShift 클러스터에 OpenShift Dev Spaces를 배포한 경우 이전 OpenShift Dev Spaces 인스턴스가 제거되었는지 확인합니다.
dsc server:delete
$ dsc server:delete
Copy to Clipboard Copied! OpenShift Dev Spaces 인스턴스를 생성합니다.
dsc server:deploy --platform openshift
$ dsc server:deploy --platform openshift
Copy to Clipboard Copied!
검증 단계
OpenShift Dev Spaces 인스턴스 상태를 확인합니다.
dsc server:status
$ dsc server:status
Copy to Clipboard Copied! OpenShift Dev Spaces 클러스터 인스턴스로 이동합니다.
dsc dashboard:open
$ dsc dashboard:open
Copy to Clipboard Copied!
3.1.3. 웹 콘솔을 사용하여 OpenShift에 Dev Spaces 설치
명령줄에 OpenShift Dev Spaces를 설치하는 데 문제가 있는 경우 OpenShift 웹 콘솔을 통해 설치할 수 있습니다.
사전 요구 사항
- 클러스터 관리자의 OpenShift 웹 콘솔 세션입니다. 웹 콘솔 액세스를 참조하십시오.
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. OpenShift CLI 시작하기를 참조하십시오. - 동일한 OpenShift 클러스터에 반복 설치의 경우 9장. Dev Spaces 설치 제거 에 따라 이전 OpenShift Dev Spaces 인스턴스를 설치 제거했습니다.
프로세스
-
OpenShift 웹 콘솔의 관리자 보기에서 Operator → OperatorHub 로 이동하여
Red Hat OpenShift Dev Spaces
를 검색합니다. 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가 동일한 네임스페이스에 설치되어 있어야 합니다.
다음과 같이 OpenShift에서
openshift-devspaces
프로젝트를 생성합니다.oc create namespace openshift-devspaces
oc create namespace openshift-devspaces
Copy to Clipboard Copied! - Operator → 설치된 Operator → Red Hat OpenShift Dev Spaces 인스턴스 사양 → CheCluster → YAML 보기로 이동합니다.
-
YAML 보기에서
namespace: openshift-operators
를namespace: openshift-devspaces
로 바꿉니다. 생성을 선택합니다.
작은 정보설치된 Operator에서 애플리케이션 생성 을 참조하십시오.
검증
- Red Hat OpenShift Dev Spaces 인스턴스 사양에서 devspaces 로 이동하여 세부 정보 탭을 시작합니다.
- Message 에서 None 이 있는지 확인합니다. 즉, 오류가 없음을 의미합니다.
- Red Hat OpenShift Dev Spaces URL 에서 OpenShift Dev Spaces 인스턴스의 URL이 표시될 때까지 기다린 다음 URL을 열어 OpenShift Dev Spaces 대시보드를 확인합니다.
- 리소스 탭에서 OpenShift Dev Spaces 배포의 리소스와 해당 상태를 확인합니다.
3.1.4. 제한된 환경에서 Dev Spaces 설치
제한된 네트워크에서 작동하는 OpenShift 클러스터에서는 공용 리소스를 사용할 수 없습니다.
그러나 OpenShift Dev Spaces 및 실행 중인 작업 공간을 배포하려면 다음과 같은 공용 리소스가 필요합니다.
- Operator 카탈로그
- 컨테이너 이미지
- 샘플 프로젝트
이러한 리소스를 사용할 수 있도록 하려면 OpenShift 클러스터에서 액세스할 수 있는 레지스트리의 사본으로 교체할 수 있습니다.
사전 요구 사항
- OpenShift 클러스터에는 최소 64GB의 디스크 공간이 있습니다.
- OpenShift 클러스터는 제한된 네트워크에서 작동할 준비가 되어 있습니다. 제한된 네트워크에서 연결이 끊긴 설치 미러링 및 Operator Lifecycle Manager 사용을 참조하십시오.
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. OpenShift CLI 시작하기를 참조하십시오. -
registry.redhat.io
Red Hat Ecosystem Catalog에 대한 활성 oc
-
opm
.opm
CLI 설치를 참조하십시오. -
jq
.jq
다운로드를 참조하십시오. -
podman
. Podman 설치 지침을 참조하십시오. -
Skopeo
버전 1.6 이상. Skopeo 설치를 참조하십시오. -
프라이빗 Docker 레지스트리에 대한 관리자 액세스 권한이 있는 활성
skopeo
세션입니다. 레지스트리에 인증하고 연결이 끊긴 설치의 이미지 미러링. -
OpenShift Dev Spaces 버전 3.18용 DSC.
2.2절. “dsc 관리 툴 설치”을 참조하십시오.
프로세스
미러링 스크립트를 다운로드하여 실행하여 사용자 정의 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>"
$ 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 Copied! - 1
- 이미지를 미러링할 프라이빗 Docker 레지스트리
이전 단계에서
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
$ 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 Copied! - OpenShift Dev Spaces 네임스페이스에서 사용자 프로젝트의 모든 Pod로 들어오는 트래픽을 허용합니다. 4.8.1절. “네트워크 정책 구성” 을 참조하십시오.
3.1.4.1. Ansible 샘플 설정
제한된 환경에서 Ansible 샘플을 사용하려면 다음 단계를 따르십시오.
사전 요구 사항
- Microsoft Visual Studio Code - 오픈 소스 IDE
- 64비트 x86 시스템.
프로세스
다음 이미지를 미러링합니다.
ghcr.io/ansible/ansible-devspaces@sha256:a28fa23d254ff1b3ae10b95a0812132148f141bda4516661e40d0c49c4ace200 registry.access.redhat.com/ubi8/python-39@sha256:301fec66443f80c3cc507ccaf72319052db5a1dc56deb55c8f169011d4bbaacb
ghcr.io/ansible/ansible-devspaces@sha256:a28fa23d254ff1b3ae10b95a0812132148f141bda4516661e40d0c49c4ace200 registry.access.redhat.com/ubi8/python-39@sha256:301fec66443f80c3cc507ccaf72319052db5a1dc56deb55c8f169011d4bbaacb
Copy to Clipboard Copied! 다음 도메인에 대한 액세스를 허용하도록 클러스터 프록시를 구성합니다.
.ansible.com .ansible-galaxy-ng.s3.dualstack.us-east-1.amazonaws.com
.ansible.com .ansible-galaxy-ng.s3.dualstack.us-east-1.amazonaws.com
Copy to Clipboard Copied!
다음 IDE 및 CPU 아키텍처에 대한 지원은 향후 릴리스에 대해 계획되어 있습니다.
IDE
- CryostatBrains IntelliJ IDEA Community Edition 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 인스턴스 사양 → devspaces → Red Hat OpenShift Dev Spaces URL 로 이동합니다.
사전 요구 사항
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. OpenShift CLI 시작하기를 참조하십시오.
프로세스
다음 명령을 실행합니다.
oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.status.cheURL}'
oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.status.cheURL}'
Copy to Clipboard Copied!
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"]
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"]
추가 리소스
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"]
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"]
추가 리소스
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 서버 구성 요소의 기본 속성 구성
-
cheServer
구성 요소 섹션에서 적절한 수정 사항을 사용하여CheCluster
사용자 정의 리소스 YAML 파일을 적용합니다. -
Operator는
che
ConfigMap
을 생성합니다. -
OpenShift는
ConfigMap
의 변경 사항을 감지하고 OpenShift Dev Spaces 포드를 다시 시작합니다.
추가 리소스
4.1.1. dsc를 사용하여 설치 중에 CheCluster
사용자 정의 리소스 구성
적절한 구성으로 OpenShift Dev Spaces를 배포하려면 OpenShift Dev Spaces를 설치하는 동안 CheCluster
사용자 정의 리소스 YAML 파일을 편집합니다. 그렇지 않으면 OpenShift Dev Spaces 배포는 Operator에서 매개변수화된 기본 구성을 사용합니다.
사전 요구 사항
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오. -
DSC
. 2.2절. “dsc 관리 툴 설치” 을 참조하십시오.
프로세스
구성할
CheCluster
사용자 정의 리소스의 하위 집합이 포함된che-operator-cr-patch.yaml
YAML 파일을 생성합니다.spec: <component>: <property_to_configure>: <value>
spec: <component>: <property_to_configure>: <value>
Copy to Clipboard Copied! OpenShift Dev Spaces를 배포하고
che-operator-cr-patch.yaml
파일에 설명된 변경 사항을 적용합니다.dsc server:deploy \ --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml \ --platform <chosen_platform>
$ dsc server:deploy \ --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml \ --platform <chosen_platform>
Copy to Clipboard Copied!
검증
구성된 속성의 값을 확인합니다.
oc get configmap che -o jsonpath='{.data.<configured_property>}' \ -n openshift-devspaces
$ oc get configmap che -o jsonpath='{.data.<configured_property>}' \ -n openshift-devspaces
Copy to Clipboard Copied!
4.1.2. CLI를 사용하여 CheCluster 사용자 정의 리소스 구성
OpenShift Dev Spaces의 실행 중인 인스턴스를 구성하려면 CheCluster
사용자 정의 리소스 YAML 파일을 편집합니다.
사전 요구 사항
- OpenShift에서 OpenShift Dev Spaces의 인스턴스입니다.
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
클러스터에서 CheCluster 사용자 정의 리소스를 편집합니다.
oc edit checluster/devspaces -n openshift-devspaces
$ oc edit checluster/devspaces -n openshift-devspaces
Copy to Clipboard Copied! - 파일을 저장하고 종료하여 변경 사항을 적용합니다.
검증
구성된 속성의 값을 확인합니다.
oc get configmap che -o jsonpath='{.data.<configured_property>}' \ -n openshift-devspaces
$ oc get configmap che -o jsonpath='{.data.<configured_property>}' \ -n openshift-devspaces
Copy to Clipboard Copied!
4.1.3. CheCluster
사용자 정의 리소스 필드 참조
이 섹션에서는 CheCluster
사용자 정의 리소스를 사용자 정의하는 데 사용할 수 있는 모든 필드에 대해 설명합니다.
-
예 4.2. “
CheCluster
사용자 정의 리소스 최소 예.” 표 4.10. “OpenShift Dev Spaces 구성 요소 구성.”
표 4.13. “OpenShift Dev Spaces 설치에서 사용하는 플러그인 레지스트리 구성 요소와 관련된 구성 설정”
표 4.15. “OpenShift Dev Spaces 설치에서 사용하는 Devfile 레지스트리 구성 요소와 관련된 구성 설정”
표 4.17. “OpenShift Dev Spaces 설치에서 사용하는 대시보드 구성 요소와 관련된 구성 설정입니다.”
- 표 4.19. “Kubernetes 이미지 가져오기 구성 요소 구성입니다.”
- 표 4.20. “OpenShift Dev Spaces 서버 지표 구성 요소 구성 요소.”
- 표 4.29. “OpenShift Dev Spaces 이미지를 저장하는 대체 레지스트리 구성.”
-
표 4.36. “
CheCluster
사용자 정의 리소스상태는 OpenShift Dev Spaces 설치의 관찰 상태를
정의합니다.”
예 4.2. CheCluster
사용자 정의 리소스 최소 예.
apiVersion: org.eclipse.che/v2 kind: CheCluster metadata: name: devspaces namespace: openshift-devspaces spec: components: {} devEnvironments: {} networking: {}
apiVersion: org.eclipse.che/v2
kind: CheCluster
metadata:
name: devspaces
namespace: openshift-devspaces
spec:
components: {}
devEnvironments: {}
networking: {}
속성 | 설명 | 기본 |
---|---|---|
allowedSources | AllowedSources는 작업 공간을 시작할 수 있는 허용된 소스를 정의합니다. | |
containerBuildConfiguration | 컨테이너 빌드 구성. | |
defaultComponents | DevWorkspaces에 적용되는 기본 구성 요소입니다. 이러한 기본 구성 요소는 구성 요소가 포함되지 않은 Devfile 때 사용해야 합니다. | |
defaultEditor |
를 사용하여 만들 작업 공간에 대한 기본 편집기입니다. 플러그인 ID 또는 URI일 수 있습니다. 플러그인 ID에는 | |
defaultNamespace | 사용자의 기본 네임스페이스. | { "autoProvision": true, "template": "<username>-che"} |
defaultPlugins | DevWorkspaces에 적용되는 기본 플러그인입니다. | |
deploymentStrategy |
DeploymentStrategy는 기존 작업 공간 Pod를 새로 교체하는 데 사용할 배포 전략을 정의합니다. 사용 가능한 배포 계층은 | |
disableContainerBuildCapabilities |
컨테이너 빌드 기능을 비활성화합니다. | |
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에 대한 추가 주석을 정의합니다. |
속성 | 설명 | 기본 |
---|---|---|
autoProvision | 가 사용자 네임스페이스를 자동으로 생성할 수 있는지 여부를 나타냅니다. false로 설정하면 클러스터 관리자가 사용자 네임스페이스를 미리 생성해야 합니다. | true |
템플릿 |
사용자 네임스페이스를 사전에 생성하지 않으면 이 필드는 첫 번째 작업 공간을 시작할 때 생성된 Kubernetes 네임스페이스를 정의합니다. < | "<username>-che" |
속성 | 설명 | 기본 |
---|---|---|
편집기 |
기본 플러그인을 지정할 편집기 ID입니다. 플러그인 ID에는 | |
plugins | 지정된 편집기의 기본 플러그인 URI입니다. |
속성 | 설명 | 기본 |
---|---|---|
env | 컨테이너에서 설정할 환경 변수 목록입니다. | |
image | 컨테이너 이미지. Operator에서 제공하는 기본 컨테이너 이미지를 사용하도록 생략하거나 비워 둡니다. | |
imagePullPolicy |
이미지 가져오기 정책. 기본값은 | |
name | 컨테이너 이름. | |
resources | 이 컨테이너에 필요한 컴퓨팅 리소스입니다. |
속성 | 설명 | 기본 |
---|---|---|
perUserStrategyPvcConfig |
| |
perWorkspaceStrategyPvcConfig |
| |
pvcStrategy |
OpenShift Dev Spaces 서버의 영구 볼륨 클레임 전략입니다. 지원되는 전략은 | "per-user" |
속성 | 설명 | 기본 |
---|---|---|
claimSize | 영구 볼륨 클레임 크기. 클레임 크기를 업데이트하려면 크기 조정을 지원해야 하는 스토리지 클래스입니다. | |
storageClass | 영구 볼륨 클레임의 스토리지 클래스입니다. 생략하거나 비워 두면 기본 스토리지 클래스가 사용됩니다. |
속성 | 설명 | 기본 |
---|---|---|
claimSize | 영구 볼륨 클레임 크기. 클레임 크기를 업데이트하려면 크기 조정을 지원해야 하는 스토리지 클래스입니다. | |
storageClass | 영구 볼륨 클레임의 스토리지 클래스입니다. 생략하거나 비워 두면 기본 스토리지 클래스가 사용됩니다. |
속성 | 설명 | 기본 |
---|---|---|
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에는 |
속성 | 설명 | 기본 |
---|---|---|
openShiftSecurityContextConstraint | 컨테이너를 빌드하는 OpenShift 보안 컨텍스트 제약 조건입니다. | "container-build" |
속성 | 설명 | 기본 |
---|---|---|
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 설치에서 사용하는 플러그인 레지스트리와 관련된 구성 설정 |
속성 | 설명 | 기본 |
---|---|---|
Clusterroles |
OpenShift Dev Spaces ServiceAccount에 할당된 추가 ClusterRoles. 각 역할에는 | |
debug | OpenShift Dev Spaces 서버의 디버그 모드를 활성화합니다. | false |
배포 | 배포 덮어쓰기 옵션. | |
extraProperties |
| |
logLevel |
OpenShift Dev Spaces 서버의 로그 수준: | "INFO" |
proxy | Kubernetes 클러스터의 프록시 서버 설정 OpenShift 클러스터에 추가 구성이 필요하지 않습니다. OpenShift 클러스터에 대한 이러한 설정을 지정하면 OpenShift 프록시 구성을 덮어씁니다. |
속성 | 설명 | 기본 |
---|---|---|
credentialsSecretName |
프록시 서버의 | |
nonProxyHosts |
프록시를 바이패스하여 직접 연결할 수 있는 호스트 목록입니다. 와일드카드 도메인을 사용하여 | |
port | 프록시 서버 포트. | |
url |
프록시 서버의 URL(protocol+hostname)입니다. 프록시 구성이 필요한 경우에만 사용합니다. Operator는 OpenShift 클러스터 전체 프록시 구성을 준수하여 사용자 정의 리소스에서 |
속성 | 설명 | 기본 |
---|---|---|
배포 | 배포 덮어쓰기 옵션. | |
disableInternalRegistry | 내부 플러그인 레지스트리를 비활성화합니다. | |
externalPluginRegistries | 외부 플러그인 레지스트리. | |
openVSXURL | VSX 레지스트리 URL을 엽니다. 포함된 인스턴스를 생략하면 사용됩니다. |
속성 | 설명 | 기본 |
---|---|---|
url | 플러그인 레지스트리의 공용 URL입니다. |
속성 | 설명 | 기본 |
---|---|---|
배포 | 더 이상 사용되지 않는 배포 덮어쓰기 옵션 | |
disableInternalRegistry | 내부 devfile 레지스트리를 비활성화합니다. | |
externalDevfileRegistries | 즉시 사용 가능한 샘플 devfile을 제공하는 외부 devfile 레지스트리입니다. |
속성 | 설명 | 기본 |
---|---|---|
url | 즉시 사용할 수 있는 devfile 샘플에 서비스를 제공하는 devfile 레지스트리의 공개 기관. |
속성 | 설명 | 기본 |
---|---|---|
브랜딩 | 대시보드 브랜딩 리소스. | |
배포 | 배포 덮어쓰기 옵션. | |
headerMessage | 대시보드 헤더 메시지. | |
logLevel | 대시보드의 로그 수준입니다. | "ERROR" |
속성 | 설명 | 기본 |
---|---|---|
표시 | 메시지를 표시하도록 대시보드에 지시합니다. | |
text | 사용자 대시보드에 경고 메시지가 표시됩니다. |
속성 | 설명 | 기본 |
---|---|---|
enable |
커뮤니티 지원 Kubernetes Image Puller Operator를 설치하고 구성합니다. 사양을 제공하지 않고 값을 | |
spec | CheCluster에서 이미지 풀러를 구성하는 Kubernetes 이미지 Puller 사양입니다. |
속성 | 설명 | 기본 |
---|---|---|
enable |
OpenShift Dev Spaces 서버 엔드포인트에 대한 | true |
속성 | 설명 | 기본 |
---|---|---|
azure | 사용자가 Azure DevOps Service(dev.azure.com)에서 호스팅되는 리포지토리를 사용할 수 있습니다. | |
Bitbucket | 사용자가 Bitbucket(bitbucket.org 또는 자체 호스팅)에서 호스팅되는 리포지토리를 사용할 수 있습니다. | |
github | 사용자가 GitHub에서 호스팅되는 리포지토리(github.com 또는 GitHub Enterprise)로 작업할 수 있습니다. | |
gitlab | 사용자가 GitLab(gitlab.com 또는 자체 호스팅)에서 호스팅되는 리포지토리를 사용할 수 있습니다. |
속성 | 설명 | 기본 |
---|---|---|
disableSubdomainIsolation |
하위 도메인 격리를 비활성화합니다. 더 이상 사용되지 않는 | |
endpoint |
GitHub 서버 엔드 포인트 URL. 더 이상 사용되지 않는 | |
secretName | base64로 인코딩된 GitHub OAuth 클라이언트 ID 및 GitHub OAuth 클라이언트 시크릿이 포함된 Kubernetes 시크릿입니다. 자세한 내용은 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-github/. |
속성 | 설명 | 기본 |
---|---|---|
endpoint |
GitLab 서버 엔드 포인트 URL. 더 이상 사용되지 않는 | |
secretName | base64로 인코딩된 GitHub 애플리케이션 ID 및 GitLab Application Client 시크릿이 포함된 Kubernetes 시크릿입니다. 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-gitlab/. |
속성 | 설명 | 기본 |
---|---|---|
endpoint |
Bitbucket 서버 끝점 URL. 더 이상 사용되지 않는 | |
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/. |
속성 | 설명 | 기본 |
---|---|---|
secretName | base64로 인코딩된 Azure DevOps 서비스 애플리케이션 ID 및 클라이언트 시크릿이 포함된 Kubernetes 시크릿입니다. 다음 페이지를 참조하십시오. https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-microsoft-azure-devops-services |
속성 | 설명 | 기본 |
---|---|---|
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 클러스터 리소스의 이름입니다. 클래스 이름이 | |
labels | Ingress(OpenShift 플랫폼의 경로)에 설정할 레이블을 정의합니다. | |
tlsSecretName |
Ingress TLS 종료를 설정하는 데 사용되는 시크릿의 이름입니다. 필드가 빈 문자열인 경우 기본 클러스터 인증서가 사용됩니다. 시크릿에는 |
속성 | 설명 | 기본 |
---|---|---|
advancedAuthorization |
사전 인증 설정 Che에 액세스할 수 있는 사용자 및 그룹을 결정합니다. 사용자가 | |
gateway | 게이트웨이 설정. | { "configLabels": { "app": "che", "component": "che-gateway-config" }} |
identityProviderURL | ID 공급자 서버의 공용 URL입니다. | |
identityToken |
업스트림으로 전달할 ID 토큰입니다. | |
oAuthAccessTokenInactivityTimeoutSeconds |
OpenShift 측에 ID 페더레이션을 설정하는 데 사용되는 OpenShift | |
oAuthAccessTokenMaxAgeSeconds |
OpenShift 측에 ID 페더레이션을 설정하는 데 사용되는 OpenShift | |
oAuthClientName |
OpenShift 측에 ID 페더레이션을 설정하는 데 사용되는 OpenShift | |
oAuthScope | 액세스 토큰 범위. 이 필드는 Kubernetes용으로 만든 OpenShift Dev Spaces 설치에만 해당하며 OpenShift에서만 무시됩니다. | |
oAuthSecret |
OpenShift 측에 ID 페더레이션을 설정하는 데 사용되는 OpenShift |
속성 | 설명 | 기본 |
---|---|---|
configLabels | 게이트웨이 구성 레이블입니다. | { "app": "che", "component": "che-gateway-config"} |
배포 |
배포 덮어쓰기 옵션. 게이트웨이 배포는 여러 컨테이너로 구성되므로, 구성에서 이름별로 구분해야 합니다. - | |
kubeRbacProxy | OpenShift Dev Spaces 게이트웨이 Pod 내에서 kube-rbac-proxy 구성 | |
oAuthProxy | OpenShift Dev Spaces 게이트웨이 포드 내에서 oauth-proxy 구성 | |
traefik | OpenShift Dev Spaces 게이트웨이 포드 내에서 Restoreefik 구성 |
속성 | 설명 | 기본 |
---|---|---|
hostname | 이미지를 가져올 대체 컨테이너 레지스트리의 선택적 호스트 이름 또는 URL입니다. 이 값은 OpenShift Dev Spaces 배포와 관련된 모든 기본 컨테이너 이미지에 정의된 컨테이너 레지스트리 호스트 이름을 재정의합니다. 이는 제한된 환경에 OpenShift Dev Space를 설치하는 데 특히 유용합니다. | |
조직 | 이미지를 가져올 대체 레지스트리의 선택적 리포지토리 이름입니다. 이 값은 OpenShift Dev Spaces 배포와 관련된 모든 기본 컨테이너 이미지에 정의된 컨테이너 레지스트리 조직을 재정의합니다. 이는 제한된 환경에 OpenShift Dev Space를 설치하는 데 특히 유용합니다. |
속성 | 설명 | 기본 |
---|---|---|
컨테이너 | Pod에 속하는 컨테이너 목록입니다. | |
nodeSelector | 노드 선택기는 Pod를 실행할 수 있는 노드를 제한합니다. | |
securityContext | Pod를 사용하여 실행해야 하는 보안 옵션입니다. | |
허용 오차 | Pod를 실행할 수 있는 구성 요소 Pod 제한의 Pod 허용 오차입니다. |
속성 | 설명 | 기본 |
---|---|---|
env | 컨테이너에서 설정할 환경 변수 목록입니다. | |
image | 컨테이너 이미지. Operator에서 제공하는 기본 컨테이너 이미지를 사용하도록 생략하거나 비워 둡니다. | |
imagePullPolicy |
이미지 가져오기 정책. 기본값은 | |
name | 컨테이너 이름. | |
resources | 이 컨테이너에 필요한 컴퓨팅 리소스입니다. |
속성 | 설명 | 기본 |
---|---|---|
limits | 허용되는 최대 컴퓨팅 리소스 양을 설명합니다. | |
요청 | 필요한 최소 컴퓨팅 리소스 양을 설명합니다. |
속성 | 설명 | 기본 |
---|---|---|
cpu |
CPU(코어)입니다. (500m = .5 cores) 값을 지정하지 않으면 구성 요소에 따라 기본값이 설정됩니다. value가 | |
메모리 |
메모리(바이트)입니다. (500GI = 500GiB = 500 * 1024 * 1024 * 1024) 값을 지정하지 않으면 구성 요소에 따라 기본값이 설정됩니다. value가 |
속성 | 설명 | 기본 |
---|---|---|
cpu |
CPU(코어)입니다. (500m = .5 cores) 값을 지정하지 않으면 구성 요소에 따라 기본값이 설정됩니다. value가 | |
메모리 |
메모리(바이트)입니다. (500GI = 500GiB = 500 * 1024 * 1024 * 1024) 값을 지정하지 않으면 구성 요소에 따라 기본값이 설정됩니다. value가 |
속성 | 설명 | 기본 |
---|---|---|
fsGroup |
Pod의 모든 컨테이너에 적용되는 특수 추가 그룹입니다. 기본값은 | |
runAsUser |
컨테이너 프로세스의 진입점을 실행하는 UID입니다. 기본값은 |
속성 | 설명 | 기본 |
---|---|---|
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에서 작업 공간을 시작할 때 필요한 프로젝트를 생성하는 데 사용하는 프로젝트 이름 템플릿을 구성할 수 있습니다.
유효한 프로젝트 이름 템플릿은 다음과 같은 규칙을 따릅니다.
-
<
;username>
또는 <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_>
spec: components: devEnvironments: defaultNamespace: template: <workspace_namespace_template_>
Copy to Clipboard Copied! 예 4.3. 사용자 작업 공간 프로젝트 이름 템플릿 예
사용자 작업 공간 프로젝트 이름 템플릿 결과 프로젝트 예 <username>-devspaces
(기본값)user1-devspaces
<userid>-namespace
cge1egvsb2nhba-namespace-ul1411
<userid>-aka-<username>-namespace
cgezegvsb2nhba-aka-user1-namespace-6m2w2b
4.2.2. 사전 프로비저닝 프로젝트
자동 프로비저닝을 사용하는 대신 작업 공간 프로젝트를 사전에 프로비저닝할 수 있습니다. 각 사용자에 대해 절차를 반복합니다.
프로세스
CheCluster
수준에서 자동 네임스페이스 프로비저닝을 비활성화합니다.devEnvironments: defaultNamespace: autoProvision: false
devEnvironments: defaultNamespace: autoProvision: false
Copy to Clipboard Copied! 다음 라벨 및 주석을 사용하여 < username > 사용자에 대한 <project_name > 프로젝트를 생성합니다.
kind: Namespace apiVersion: v1 metadata: name: <project_name> labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-namespace annotations: che.eclipse.org/username: <username>
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 Copied! - 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가 변경 사항을 즉시 되돌립니다.
프로세스
아래
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: ...
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 Copied! 예 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>
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 Copied! 아래
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: ...
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 Copied! 예 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: | ...
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 Copied! 참고작업 영역 시작 시
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
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 Copied! 아래의
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: ...
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 Copied! 예 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
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 Copied! 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
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 Copied! 매개변수는
선택 사항이며 사용할 수 있는 매개변수를 정의합니다. 현재PROJECT_NAME
및PROJECT_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
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 Copied! 참고템플릿 Kubernetes 리소스 생성은 OpenShift에서만 지원됩니다.
-
추가 리소스
- https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.18/html-single/user_guide/index#end-user-guide:mounting-configmaps
- https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.18/html-single/user_guide/index#end-user-guide:mounting-secrets
- https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.18/html-single/user_guide/index#end-user-guide:requesting-persistent-storage-for-workspaces
- 볼륨, configmaps 및 secret 자동 마운트
-
템플릿에
대한 OpenShift API 참조 - 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의 실행 중인 인스턴스.
프로세스
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 ...
apiVersion: v1
kind: Secret
metadata:
name: custom-settings
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-secret
...
또는
apiVersion: v1 kind: ConfigMap metadata: name: custom-settings labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-configmap ...
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-settings
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
...
주석 값을 구성합니다. 주석은 지정된 오브젝트가 파일로 마운트되었음을 나타냅니다.
-
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 ...
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
...
또는
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 ...
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
...
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>
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>
또는
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>
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>
그러면 ca.crt
라는 파일이 OpenShift Dev Spaces 컨테이너의 /data
경로에 마운트됩니다.
OpenShift Dev Spaces 컨테이너를 변경하려면 Secret 또는 ConfigMap 오브젝트를 완전히 다시 생성합니다.
4.3.1.2. OpenShift Dev Spaces 컨테이너에 하위 경로로 시크릿 또는 ConfigMap 마운트
사전 요구 사항
- Red Hat OpenShift Dev Spaces의 실행 중인 인스턴스.
프로세스
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 ...
apiVersion: v1
kind: Secret
metadata:
name: custom-settings
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-secret
...
또는
apiVersion: v1 kind: ConfigMap metadata: name: custom-settings labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-configmap ...
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-settings
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
...
주석 값을 구성합니다. 주석은 지정된 오브젝트가 하위 경로로 마운트되었음을 나타냅니다.
-
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 ...
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
...
또는
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 ...
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
...
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>
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>
또는
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>
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>
그러면 ca.crt
라는 파일이 OpenShift Dev Spaces 컨테이너의 /data
경로에 마운트됩니다.
OpenShift Dev Spaces 컨테이너를 변경하려면 Secret 또는 ConfigMap 오브젝트를 완전히 다시 생성합니다.
4.3.1.3. OpenShift Dev Spaces 컨테이너에 환경 변수로 시크릿 또는 ConfigMap 마운트
사전 요구 사항
- Red Hat OpenShift Dev Spaces의 실행 중인 인스턴스.
프로세스
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 ...
apiVersion: v1
kind: Secret
metadata:
name: custom-settings
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-secret
...
또는
apiVersion: v1 kind: ConfigMap metadata: name: custom-settings labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-configmap ...
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-settings
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
...
주석 값을 구성합니다. 주석은 지정된 오브젝트가 환경 변수로 마운트되었음을 나타냅니다.
-
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
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
또는
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
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
그러면 다음 두 가지 환경 변수가 생성됩니다.
-
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>
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>
또는
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>
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>
그러면 다음 두 가지 환경 변수가 생성됩니다.
-
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
apiVersion: org.eclipse.che/v2 kind: CheCluster spec: components: cheServer: extraProperties: CHE_LOGS_APPENDERS_IMPL: json
Copy to Clipboard Copied!
이전 버전의 OpenShift Dev Spaces Operator에는 이 역할을 수행하기 위해 custom
이라는 ConfigMap이 있었습니다. OpenShift Dev Spaces Operator에서 사용자 지정 이름으로 configMap
을 찾으면
필드에 포함된 데이터를 추가하고 OpenShift Dev Spaces를 재배포하고 custom
CheProperties사용자 정의
configMap
을 삭제합니다.
4.4. 자동 스케일링 구성
Red Hat OpenShift Dev Spaces 자동 스케일링의 다양한 측면에 대해 알아보십시오.
4.4.1. Red Hat OpenShift Dev Spaces 컨테이너의 복제본 수 구성
Kubernetes HorizontalPodAutoscaler
(HPA)를 사용하여 OpenShift Dev Spaces 피연산자의 복제본 수를 구성하려면 배포에 대한 HPA
리소스를 정의할 수 있습니다. HPA
는 지정된 메트릭을 기반으로 복제본 수를 동적으로 조정합니다.
프로세스
대상 지표와 원하는 복제본 수를 지정하여 배포에 대한
HPA
리소스를 생성합니다.apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: scaler namespace: openshift-devspaces spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: <deployment_name> ...
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 Copied! - 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
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
이 예에서 HPA는 최소 2개의 복제본, 최대 5개의 복제본 및 CPU 사용률을 기반으로 하는 스케일링을 사용하여 devspace라는 배포를 대상으로 합니다.
추가 리소스
4.4.2. 머신 자동 스케일링 구성
리소스 요구 사항에 따라 노드 수를 조정하도록 클러스터를 구성한 경우 OpenShift Dev Spaces 작업 공간의 원활한 작동을 유지하기 위해 추가 구성이 필요합니다.
자동 스케일러가 노드를 추가하고 제거할 때 작업 공간을 특별히 고려해야 합니다.
자동 스케일러에서 새 노드를 추가하면 노드 프로비저닝이 완료될 때까지 작업 공간 시작 시간이 평상보다 오래 걸릴 수 있습니다.
반대로 노드를 제거하면 작업 공간을 사용하는 동안 중단을 방지하고 저장된 데이터가 손실될 가능성이 있는 자동 스케일러에서 작업 공간 Pod를 실행하는 노드를 제거할 수 없습니다.
4.4.2.1. 자동 스케일러가 새 노드를 추가하는 경우
새 노드를 추가하는 동안 적절한 작업 공간을 시작하도록 OpenShift Dev Spaces 설치를 구성해야 합니다.
프로세스
CheCluster 사용자 지정 리소스에서 자동 스케일러가 새 노드를 프로비저닝할 때 적절한 작업 공간 시작을 허용하도록 다음 필드를 설정합니다.
spec: devEnvironments: startTimeoutSeconds: 600 ignoredUnrecoverableEvents: - FailedScheduling
spec: devEnvironments: startTimeoutSeconds: 600
1 ignoredUnrecoverableEvents:
2 - FailedScheduling
Copy to Clipboard Copied!
4.4.2.2. 자동 스케일러가 노드를 제거하는 경우
자동 스케일러가 노드를 제거해야 할 때 작업 공간 Pod가 제거되지 않도록 하려면 모든 작업 공간 Pod에 "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
주석을 추가합니다.
프로세스
CheCluster 사용자 정의 리소스에서
spec.devEnvironments.workspacesPodAnnotations
필드에cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
주석을 추가합니다.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 Copied!
검증 단계
작업 영역을 시작하고 작업 공간 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}'
$ oc get pod <workspace_pod_name> -o jsonpath='{.metadata.annotations.cluster-autoscaler\.kubernetes\.io/safe-to-evict}' false
Copy to Clipboard Copied!
4.5. 전역적으로 작업 공간 구성
이 섹션에서는 관리자가 전역적으로 작업 공간을 구성할 수 있는 방법에 대해 설명합니다.
4.5.1. 사용자가 유지할 수 있는 작업 공간 수 제한
기본적으로 사용자는 대시보드에 무제한의 작업 공간을 유지할 수 있지만 이 수를 제한하여 클러스터의 수요를 줄일 수 있습니다.
이 구성은 CheCluster
사용자 정의 리소스의 일부입니다.
spec: devEnvironments: maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>
spec:
devEnvironments:
maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>
- 1
- 사용자당 최대 작업 공간 수를 설정합니다. 기본값
-1
을 사용하면 사용자가 무제한의 작업 공간을 유지할 수 있습니다. 양의 정수를 사용하여 사용자당 최대 작업 공간 수를 설정합니다.
프로세스
OpenShift Dev Spaces 네임스페이스의 이름을 가져옵니다. 기본값은
openshift-devspaces
입니다.oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
$ oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
Copy to Clipboard Copied! maxNumberOfWorkspacesPerUser
를 구성합니다.oc patch checluster/devspaces -n openshift-devspaces \ --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'
$ oc patch checluster/devspaces -n openshift-devspaces \
1 --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'
2 Copy to Clipboard Copied!
4.5.2. 모든 사용자가 동시에 실행할 수 있는 작업 공간 수 제한
기본적으로 모든 사용자는 무제한 작업 공간을 실행할 수 있습니다. 모든 사용자가 동시에 실행할 수 있는 작업 공간 수를 제한할 수 있습니다. 이 구성은 CheCluster
사용자 정의 리소스의 일부입니다.
spec: devEnvironments: maxNumberOfRunningWorkspacesPerCluster: <running_workspaces_limit>
spec:
devEnvironments:
maxNumberOfRunningWorkspacesPerCluster: <running_workspaces_limit>
- 1
- 전체 Kubernetes 클러스터에서 동시에 실행 중인 최대 작업 공간 수입니다. 이는 시스템의 모든 사용자에게 적용됩니다. 값을 -1로 설정하면 실행 중인 작업 공간 수에 제한이 없음을 의미합니다.
프로세스
maxNumberOfRunningWorkspacesPerCluster
를 구성합니다.oc patch checluster/devspaces -n openshift-devspaces \ --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerCluster": <running_workspaces_limit>}}}'
oc patch checluster/devspaces -n openshift-devspaces \ --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerCluster": <running_workspaces_limit>}}}'
1 Copy to Clipboard Copied! - 1
- <
running_workspaces_limit> 값을
선택합니다.
4.5.3. 사용자가 여러 작업 공간을 동시에 실행 가능
기본적으로 사용자는 한 번에 하나의 작업 공간만 실행할 수 있습니다. 사용자가 여러 작업 공간을 동시에 실행할 수 있습니다.
기본 스토리지 방법을 사용하는 경우 Pod가 다중 노드 클러스터의 노드에 분산되는 경우 사용자가 동시에 작업 공간을 실행할 때 문제가 발생할 수 있습니다. 사용자별 공통
스토리지 전략에서 작업별
스토리지 전략으로 전환하거나 임시
스토리지 유형을 사용하면 이러한 문제를 방지하거나 해결할 수 있습니다.
이 구성은 CheCluster
사용자 정의 리소스의 일부입니다.
spec: devEnvironments: maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
spec:
devEnvironments:
maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
- 1
- 사용자당 동시에 실행 중인 최대 작업 공간 수를 설정합니다.
-1
값을 사용하면 사용자가 무제한의 작업 공간을 실행할 수 있습니다. 기본값은1
입니다.
프로세스
OpenShift Dev Spaces 네임스페이스의 이름을 가져옵니다. 기본값은
openshift-devspaces
입니다.oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
$ oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
Copy to Clipboard Copied! maxNumberOfRunningWorkspacesPerUser
를 구성합니다.oc patch checluster/devspaces -n openshift-devspaces \ --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerUser": <running_workspaces_limit>}}}'
$ oc patch checluster/devspaces -n openshift-devspaces \
1 --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerUser": <running_workspaces_limit>}}}'
2 Copy to Clipboard Copied!
4.5.4. 자체 서명된 인증서가 있는 Git
자체 서명된 인증서를 사용하는 Git 공급자의 작업을 지원하도록 OpenShift Dev Spaces를 구성할 수 있습니다.
사전 요구 사항
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. OpenShift CLI 시작하기를 참조하십시오. - Git 버전 2 이상
프로세스
Git 서버에 대한 세부 정보를 사용하여 새 ConfigMap 을 생성합니다.
oc create configmap che-git-self-signed-cert \ --from-file=ca.crt=<path_to_certificate> \ --from-literal=githost=<git_server_url> -n openshift-devspaces
$ 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 Copied! - 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 인증서를 포함해야 합니다.
ConfigMap에 필요한 라벨을 추가합니다.
oc label configmap che-git-self-signed-cert \ app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
$ oc label configmap che-git-self-signed-cert \ app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
Copy to Clipboard Copied! Git 리포지토리에 자체 서명된 인증서를 사용하도록 OpenShift Dev Spaces 피연산자를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.
spec: devEnvironments: trustedCerts: gitTrustedCertsConfigMapName: che-git-self-signed-cert
spec: devEnvironments: trustedCerts: gitTrustedCertsConfigMapName: che-git-self-signed-cert
Copy to Clipboard Copied!
검증 단계
새 작업 공간을 만들고 시작합니다. 작업 영역에서 사용하는 모든 컨테이너는 자체 서명된 인증서가 있는 파일이 포함된 특수 볼륨을 마운트합니다. 컨테이너의
/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
[http "https://10.33.177.118:3000"] sslCAInfo = /etc/config/che-git-tls-creds/certificate
Copy to Clipboard Copied!
4.5.5. 작업 공간 nodeSelector 구성
이 섹션에서는 OpenShift Dev Spaces 작업 공간의 Pod에 nodeSelector
를 구성하는 방법을 설명합니다.
프로세스
NodeSelector 사용
OpenShift Dev Spaces는
CheCluster
사용자 정의 리소스를 사용하여nodeSelector
를 구성합니다.spec: devEnvironments: nodeSelector: key: value
spec: devEnvironments: nodeSelector: key: value
Copy to Clipboard Copied! 이 섹션에는 nodeSelector 규칙을 형성하려면 각 노드 라벨 에 대한
키=값
쌍 세트가 포함되어야 합니다.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
spec: devEnvironments: tolerations: - effect: NoSchedule key: key value: value operator: Equal
Copy to Clipboard Copied!
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를 시작할 수 있습니다.
허용되는 소스를 구성합니다.
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ -p \ '{ "spec": { "devEnvironments": { "allowedSources": { "urls": ["url_1", "url_2"] } } } }'
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ -p \ '{ "spec": { "devEnvironments": { "allowedSources": { "urls": ["url_1", "url_2"]
1 } } } }'
Copy to Clipboard Copied! - 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 작업 공간이 시작될 때 이미 사용 가능하므로 작업 공간 시작 시간이 단축됩니다.
Kubernetes 이미지 가져오기 설치
Kubernetes 이미지 가져오기 구성
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
사용자 정의 리소스를 통해 구성할 수 없습니다.
사전 요구 사항
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. OpenShift CLI 시작하기를 참조하십시오.
프로세스
- doc에 따라 가져올 관련 컨테이너 이미지 목록을 수집합니다. 4.6.3절. “Kubernetes Image Puller의 기본 이미지 목록 검색”
메모리 요청 및 제한 매개 변수를 정의하여 가져온 컨테이너와 플랫폼에 충분한 메모리가 있는지 확인합니다.
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)
(memory limit) * (number of images) * (number of nodes in the cluster)
Copy to Clipboard Copied! 컨테이너 메모리 제한
20Mi
를 사용하여 20개의 노드에서 5개의 이미지를 가져오려면2000Mi
의 메모리가 필요합니다.이미지 Puller 리포지토리를 복제하고 OpenShift 템플릿이 포함된 디렉터리에 가져옵니다.
git clone https://github.com/che-incubator/kubernetes-image-puller cd kubernetes-image-puller/deploy/openshift
git clone https://github.com/che-incubator/kubernetes-image-puller cd kubernetes-image-puller/deploy/openshift
Copy to Clipboard Copied! 다음 매개변수를 사용하여
app.yaml
,configmap.yaml
및serviceaccount.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
이미지 가져오기를 호스팅할 OpenShift 프로젝트를 생성합니다.
oc new-project <k8s-image-puller>
oc new-project <k8s-image-puller>
Copy to Clipboard Copied! 템플릿을 처리하고 적용하여 가져오기를 설치합니다.
oc process -f serviceaccount.yaml | oc apply -f - oc process -f configmap.yaml | oc apply -f - oc process -f app.yaml | oc apply -f -
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 Copied!
검증 단계
< kubernetes-image-puller > 배포 및 < kubernetes-image-puller > DaemonSet이 있는지 확인합니다. DaemonSet에는 클러스터의 각 노드에 대한 Pod가 있어야 합니다.
oc get deployment,daemonset,pod --namespace <k8s-image-puller>
oc get deployment,daemonset,pod --namespace <k8s-image-puller>
Copy to Clipboard Copied! < kubernetes-image-puller >
ConfigMap
의 값을 확인합니다.oc get configmap <kubernetes-image-puller> --output yaml
oc get configmap <kubernetes-image-puller> --output yaml
Copy to Clipboard Copied!
4.6.1.3. 웹 콘솔을 사용하여 OpenShift에 이미지 Puller 설치
OpenShift 웹 콘솔을 사용하여 OpenShift에 커뮤니티 지원 Kubernetes Image Puller Operator를 설치할 수 있습니다.
사전 요구 사항
- 클러스터 관리자의 OpenShift 웹 콘솔 세션입니다. 웹 콘솔 액세스를 참조하십시오.
프로세스
- 커뮤니티 지원 Kubernetes Image Puller Operator를 설치합니다. 웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.
-
커뮤니티 지원 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 시작하기를 참조하십시오.
프로세스
OpenShift Dev Spaces 이미지를 사전 가져오도록 이미지 Puller를 구성합니다.
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ --patch '{ "spec": { "components": { "imagePuller": { "enable": true } } } }'
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ --patch '{ "spec": { "components": { "imagePuller": { "enable": true } } } }'
Copy to Clipboard Copied!
4.6.2.3. 사용자 정의 이미지를 사전 가져오도록 이미지 가져오기 구성
사용자 정의 이미지를 사전 가져오도록 Kubernetes 이미지 가져오기를 구성할 수 있습니다.
사전 요구 사항
- 조직의 OpenShift Dev Spaces 인스턴스가 Kubernetes 클러스터에 설치되어 실행 중입니다.
- 이미지 Puller는 Kubernetes 클러스터에 설치됩니다.
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
사용자 지정 이미지를 사전 가져오도록 이미지 가져오기를 구성합니다.
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" } } } } }'
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 Copied! - 1
- 이미지--------------------
4.6.2.4. 추가 이미지를 사전 가져오도록 이미지 가져오기 구성
추가 OpenShift Dev Spaces 이미지를 미리 가져오도록 Kubernetes 이미지 가져오기를 구성할 수 있습니다.
사전 요구 사항
- 조직의 OpenShift Dev Spaces 인스턴스가 Kubernetes 클러스터에 설치되어 실행 중입니다.
- 이미지 Puller는 Kubernetes 클러스터에 설치됩니다.
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
k8s-image-puller
네임스페이스를 생성합니다.oc create namespace k8s-image-puller
oc create namespace k8s-image-puller
Copy to Clipboard Copied! 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__" EOF
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 Copied! - 1
- 이미지--------------------
4.6.3. Kubernetes Image Puller의 기본 이미지 목록 검색
Kubernetes Image Puller에서 사용하는 기본 이미지 목록을 검색하는 방법을 알아봅니다. 이 기능은 이러한 이미지의 하위 집합만 미리 사용하도록 이미지 Puller를 검토 및 구성하려는 관리자에게 유용할 수 있습니다.
사전 요구 사항
- 조직의 OpenShift Dev Spaces 인스턴스가 Kubernetes 클러스터에 설치되어 실행 중입니다.
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
OpenShift Dev Spaces Operator가 배포된 네임스페이스를 찾습니다.
OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
Copy to Clipboard Copied! Image Puller에서 사전 가져올 수 있는 이미지를 확인합니다.
oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- cat /tmp/external_images.txt
oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- cat /tmp/external_images.txt
Copy to Clipboard Copied!
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 서버에 배포합니다.CheCluster
사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.spec: devEnvironments: defaultPlugins: - editor: eclipse/che-theia/next plugins: - 'https://your-web-server/plugin.yaml'
spec: devEnvironments: defaultPlugins: - editor: eclipse/che-theia/next
1 plugins:
2 - 'https://your-web-server/plugin.yaml'
Copy to Clipboard Copied!
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 원격 분석 시스템을 확장하여 사용자 지정 백엔드와 통신하는 데 필요한 단계를 설명합니다.
- 이벤트를 수신하는 서버 프로세스 생성
- OpenShift Dev Spaces 라이브러리를 확장하여 이벤트를 서버로 보내는 백엔드를 생성합니다.
- 컨테이너에 Telemetry 백엔드 패키징 및 이미지 레지스트리에 배포
- 백엔드용 플러그인 추가 및 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) }
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)
}
이 코드를 기반으로 컨테이너 이미지를 생성하고 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
$ 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
manifest_with_ingress.yaml
및 manifest_with_route
둘 다 배포 및 서비스에 대한 정의가 포함되어 있습니다. 전자는 Kubernetes 인그레스도 정의하고 후자는 OpenShift 경로를 정의합니다.
매니페스트 파일에서 내보낸 이미지와 일치하도록 이미지
및 호스트
필드와 OpenShift 클러스터의 공용 호스트 이름을 바꿉니다. 그런 다음 실행합니다.
kubectl apply -f manifest_with_[ingress|route].yaml -n openshift-devspaces
$ kubectl apply -f manifest_with_[ingress|route].yaml -n openshift-devspaces
4.7.2.3. 백엔드 프로젝트 생성
개발 시 신속한 피드백을 받으려면 Dev Workspace 내에서 개발을 수행하는 것이 좋습니다. 이렇게 하면 클러스터에서 애플리케이션을 실행하고 프런트 엔드 Telemetry 플러그인에서 이벤트를 수신할 수 있습니다.
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
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 Copied! -
src/main/java/mygroup
및src/test/java/mygroup
아래에 있는 파일을 제거합니다. -
최신 버전 및
backend-base
의 Maven 좌표는 GitHub 패키지를 참조하십시오. 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>
<!-- 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 Copied! -
GitHub 패키지에서
org.eclipse.che.incubator.workspace-telemetry:backend-base
종속성을 다운로드할 수 있는read:packages
권한으로 개인 액세스 토큰을 생성합니다. ~/.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>
<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 Copied!
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") Optional<String> welcomeMessage; }
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")
Optional<String> welcomeMessage;
}
- 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( (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); } @Override public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) { } @Override public void onActivity() {} }
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(
(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);
}
@Override
public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) { }
@Override
public void onActivity() {}
}
org.my.group.AnalyticsManager
및 org.my.group.MainConfiguration
은 대체 빈이므로 src/main/resources/application.properties
의 quarkus.arc.selected-alternatives
속성을 사용하여 지정합니다.
예 4.26. application.properties
quarkus.arc.selected-alternatives=MainConfiguration,AnalyticsManager
quarkus.arc.selected-alternatives=MainConfiguration,AnalyticsManager
4.7.2.5. Dev Workspace 내에서 애플리케이션 실행
Dev Workspace에서
DEVWORKSPACE_TELEMETRY_BACKEND_PORT
환경 변수를 설정합니다. 여기서 값은4167
로 설정됩니다.spec: template: attributes: workspaceEnv: - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT value: '4167'
spec: template: attributes: workspaceEnv: - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT value: '4167'
Copy to Clipboard Copied! - Red Hat OpenShift Dev Spaces 대시보드에서 Dev Workspace를 다시 시작합니다.
Dev Workspace의 터미널 창에서 다음 명령을 실행하여 애플리케이션을 시작합니다.
--settings
플래그를 사용하여 GitHub 액세스 토큰이 포함된settings.xml
파일의 위치에 대한 경로를 지정합니다.mvn --settings=settings.xml quarkus:dev -Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}
$ mvn --settings=settings.xml quarkus:dev -Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}
Copy to Clipboard Copied! 이제 애플리케이션은 프런트 엔드 플러그인에서 포트
4167
을 통해 원격 분석 이벤트를 수신합니다.
검증 단계
다음 출력이 기록되었는지 확인합니다.
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]
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 Copied! AnalyticsManager
의onEvent()
메서드가 프런트 엔드 플러그인에서 이벤트를 수신하는지 확인하려면 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
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 Copied!
4.7.2.6. isEnabled()
구현
예제의 목적을 위해 이 메서드는 호출될 때마다 항상 true
를 반환합니다.
예 4.27. AnalyticsManager.java
@Override public boolean isEnabled() { return true; }
@Override
public boolean isEnabled() {
return true;
}
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 클러스터의 수신 도메인 이름입니다.
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") @Consumes(MediaType.APPLICATION_JSON) Response sendEvent(Map<String, Object> payload); }
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 Copied! - 1
POST
요청을 할 끝점입니다.
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
org.my.group.TelemetryService/mp-rest/url=http://little-telemetry-server-che.apps-crc.testing
Copy to Clipboard Copied! TelemetryService
를AnalyticsManager
에 삽입하고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); }
@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 Copied! 그러면 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) {}
@Override
public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) {}
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); } }
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);
}
}
4.7.2.10. destroy()
구현
destroy()
가 호출되면 WORKSPACE_STOPPED
이벤트를 전송하고 연결 풀과 같은 모든 리소스를 종료합니다.
예 4.33. AnalyticsManager.java
@Override public void destroy() { onEvent(WORKSPACE_STOPPED, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties); }
@Override
public void destroy() {
onEvent(WORKSPACE_STOPPED, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties);
}
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"]
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"]
이미지를 빌드하려면 다음을 실행합니다.
mvn package && \ podman build -f src/main/docker/Dockerfile.jvm -t image:tag .
mvn package && \
podman build -f src/main/docker/Dockerfile.jvm -t image:tag .
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}"]
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}"]
이미지를 빌드하려면 다음을 실행합니다.
mvn package -Pnative -Dquarkus.native.container-build=true && \ podman build -f src/main/docker/Dockerfile.native -t image:tag .
mvn package -Pnative -Dquarkus.native.container-build=true && \
podman build -f src/main/docker/Dockerfile.native -t image:tag .
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 env: - name: WELCOME_MESSAGE value: 'hello world!'
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
env:
- name: WELCOME_MESSAGE
value: 'hello world!'
- 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
$ oc create configmap --from-file=plugin.yaml -n openshift-devspaces telemetry-plugin-yaml
배포, 서비스 및 웹 서버를 노출하는 경로를 생성합니다. 배포는 이 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
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
oc apply -f manifest.yaml
$ oc apply -f manifest.yaml
검증 단계
배포가 시작되면 웹 서버에서
plugin.yaml
을 사용할 수 있는지 확인합니다.curl apache-che.apps-crc.testing/plugin.yaml
$ curl apache-che.apps-crc.testing/plugin.yaml
Copy to Clipboard Copied!
4.7.2.13. Dev Workspace에서 Telemetry 플러그인 지정
기존 Dev Workspace의
components
필드에 다음을 추가합니다.components: ... - name: telemetry-plugin plugin: uri: http://apache-che.apps-crc.testing/plugin.yaml
components: ... - name: telemetry-plugin plugin: uri: http://apache-che.apps-crc.testing/plugin.yaml
Copy to Clipboard Copied! - OpenShift Dev Spaces 대시보드에서 Dev Workspace를 시작합니다.
검증 단계
원격 분석 플러그인 컨테이너가 Dev Workspace Pod에서 실행 중인지 확인합니다. 여기에서는 편집기 내에서 Workspace 보기를 확인하여 확인합니다.
- 편집기 내에서 파일을 편집하고 예제 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 plugins: - 'http://apache-che.apps-crc.testing/plugin.yaml'
spec: devEnvironments: defaultPlugins: - editor: eclipse/che-theia/next
1 plugins:
2 - 'http://apache-che.apps-crc.testing/plugin.yaml'
Copy to Clipboard Copied!
검증 단계
- Red Hat OpenShift Dev Spaces 대시보드에서 새 또는 기존 Dev Workspace를 시작합니다.
- 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>"
spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "<key1=value1,key2=value2>"
1 Copy to Clipboard Copied! - 1
- 쉼표로 구분된 키-값 쌍 목록입니다. 여기서 키는 OpenShift Dev Spaces 서버 로그 출력에 표시된 대로 로거의 이름이며 값은 필요한 로그 수준입니다.
예 4.38.
WorkspaceManager
의 디버그 모드 구성spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "org.eclipse.che.api.workspace.server.WorkspaceManager=DEBUG"
spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "org.eclipse.che.api.workspace.server.WorkspaceManager=DEBUG"
Copy to Clipboard Copied!
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"
spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "che.infra.request-logging=TRACE"
Copy to Clipboard Copied!
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/
dsc server:logs -d /home/user/che-logs/
Copy to Clipboard Copied! 실행하면
dsc server:logs
가 로그 파일을 저장할 디렉터리를 지정하는 콘솔에 메시지를 출력합니다.Red Hat OpenShift Dev Spaces logs will be available in '/tmp/chectl-logs/1648575098344'
Red Hat OpenShift Dev Spaces logs will be available in '/tmp/chectl-logs/1648575098344'
Copy to Clipboard Copied! 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
dsc server:logs -n my-namespace
Copy to Clipboard Copied! 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
에 지표를 노출합니다. 이는 기본적으로 사전 구성되어 있습니다.
프로세스
Dev Workspace Operator 지표 서비스를 감지하기 위한 ServiceMonitor를 생성합니다.
예 4.39. ServiceMonitor
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: devworkspace-controller namespace: openshift-devspaces spec: endpoints: - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token interval: 10s port: metrics scheme: https tlsConfig: insecureSkipVerify: true namespaceSelector: matchNames: - openshift-operators selector: matchLabels: app.kubernetes.io/name: devworkspace-controller
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 Copied! 클러스터 내 Prometheus 인스턴스에서 OpenShift Dev Spaces 네임스페이스에서 ServiceMonitor를 감지할 수 있습니다. 기본 OpenShift Dev Spaces 네임스페이스는
openshift-devspaces
입니다.oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
$ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
Copy to Clipboard Copied!
검증
- OpenShift Dev Spaces를 새로 설치하려면 대시보드에서 OpenShift Dev Spaces 작업 공간을 생성하여 지표를 생성합니다.
- OpenShift 웹 콘솔의 관리자 보기에서 모니터링 → 메트릭 으로 이동합니다.
PromQL 쿼리를 실행하여 메트릭을 사용할 수 있는지 확인합니다. 예를 들어
devworkspace_started_total
을 입력하고 쿼리 실행을 클릭합니다.더 많은 메트릭은 4.7.3.2절. “dev Workspace별 메트릭” 에서 참조하십시오.
누락된 메트릭을 해결하려면 가능한 RBAC 관련 오류에 대한 Prometheus 컨테이너 로그를 확인합니다.
Prometheus Pod의 이름을 가져옵니다.
$ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
$ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
Copy to Clipboard Copied! 이전 단계의 Prometheus Pod에서 Prometheus 컨테이너 로그의 마지막 20행을 출력합니다.
$ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
$ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
Copy to Clipboard Copied!
추가 리소스
4.7.3.2. dev Workspace별 메트릭
다음 표에서는 devworkspace-controller-metrics
서비스에서 노출하는 Dev Workspace별 메트릭을 설명합니다.
이름 | 유형 | 설명 | 라벨 |
---|---|---|---|
| 카운터 | Dev Workspace 시작 이벤트 수입니다. |
|
| 카운터 |
|
|
| 카운터 | 실패한 Dev Workspace 수입니다. |
|
| 히스토그램 | Dev Workspace를 시작하는 데 걸린 총 시간(초)입니다. |
|
이름 | 설명 | 값 |
---|---|---|
|
Dev Workspace의 |
|
|
Dev Workspace의 |
|
| 작업 공간 시작 실패 이유 |
|
이름 | 설명 |
---|---|
| Dev Workspace를 생성하는 데 사용되는 잘못된 devfile으로 인한 시작 실패. |
|
다음과 같은 오류로 인해 시작 실패: |
| 알 수 없는 실패 이유 |
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을 생성하고 필요한 레이블을 적용합니다.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
$ 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 Copied! 참고이전 명령에는 업스트림 커뮤니티의 자료에 대한 링크가 포함되어 있습니다. 이 자료에서는 사용 가능한 최신 콘텐츠와 최신 모범 사례를 나타냅니다. 이러한 팁은 Red Hat의 QE 부서에 의해 아직 진행되지 않았으며 다양한 사용자 그룹에서는 아직 검증되지 않았습니다. 이 정보를 신중하게 사용하십시오.
oc label configmap grafana-dashboard-dwo console.openshift.io/dashboard=true -n openshift-config-managed
$ oc label configmap grafana-dashboard-dwo console.openshift.io/dashboard=true -n openshift-config-managed
Copy to Clipboard Copied! 참고대시보드 정의는 Grafana 6.x 대시보드를 기반으로 합니다. OpenShift 웹 콘솔에서 모든 Grafana 6.x 대시보드 기능이 지원되는 것은 아닙니다.
검증 단계
- OpenShift 웹 콘솔의 관리자 보기에서 모니터링 → 대시보드 로 이동합니다.
- 대시보드 → 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 패널

- 평균 작업 공간 시작 시간
- 평균 작업 공간 시작 기간입니다.
- Workspace 시작
- 성공 및 실패한 작업 공간 시작 수입니다.
- dev Workspace 성공 및 실패
- 성공적인 Dev Workspace 시작과 실패한 Dev Workspace 시작 간의 비교입니다.
- dev Workspace 실패율
- 실패한 작업 공간 시작 수와 총 작업 공간 시작 수 간의 비율입니다.
- dev Workspace 시작 실패 이유
작업 영역 시작 실패의 배포를 표시하는 원형 차트입니다.
-
BadRequest
-
InfrastructureFailure
-
알 수 없음
-
4.7.3.4.2. Operator 지표
Operator별 지표가 Operator 지표 패널에 표시됩니다.
그림 4.2. Operator 지표 패널

- 이동 중 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 지표를 노출합니다. 이 동작을 구성할 수 있습니다.
프로세스
CheCluster
사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.spec: components: metrics: enable: <boolean>
spec: components: metrics: enable: <boolean>
1 Copy to Clipboard Copied! - 1
true
to enable,false
를 비활성화합니다.
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 메트릭 활성화 및 노출을 참조하십시오.
프로세스
OpenShift Dev Spaces JVM 메트릭 서비스를 감지하기 위한 ServiceMonitor를 생성합니다.
예 4.40. ServiceMonitor
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: che-host namespace: openshift-devspaces spec: endpoints: - interval: 10s port: metrics scheme: http namespaceSelector: matchNames: - openshift-devspaces selector: matchLabels: app.kubernetes.io/name: devspaces
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 Copied! Prometheus가 메트릭을 볼 수 있도록 Role 및 RoleBinding을 생성합니다.
예 4.41. Role
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: prometheus-k8s namespace: openshift-devspaces rules: - verbs: - get - list - watch apiGroups: - '' resources: - services - endpoints - pods
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 Copied! - 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 subjects: - kind: ServiceAccount name: prometheus-k8s namespace: openshift-monitoring roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: prometheus-k8s
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 Copied! - 1
- OpenShift Dev Spaces 네임스페이스입니다. 기본값은
openshift-devspaces
입니다.
클러스터 내 Prometheus 인스턴스에서 OpenShift Dev Spaces 네임스페이스에서 ServiceMonitor를 감지할 수 있습니다. 기본 OpenShift Dev Spaces 네임스페이스는
openshift-devspaces
입니다.oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
$ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
Copy to Clipboard Copied!
검증
- OpenShift 웹 콘솔의 관리자 보기에서 모니터링 → 메트릭 으로 이동합니다.
-
PromQL 쿼리를 실행하여 메트릭을 사용할 수 있는지 확인합니다. 예를 들어
process_uptime_seconds{job="che-host"}
를 입력하고 Run queries 를 클릭합니다.
누락된 메트릭을 해결하려면 가능한 RBAC 관련 오류에 대한 Prometheus 컨테이너 로그를 확인합니다.
Prometheus Pod의 이름을 가져옵니다.
$ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
$ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
Copy to Clipboard Copied! 이전 단계의 Prometheus Pod에서 Prometheus 컨테이너 로그의 마지막 20행을 출력합니다.
$ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
$ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
Copy to Clipboard Copied!
4.7.4.3. OpenShift 웹 콘솔 대시보드에서 OpenShift Dev Spaces Server 보기
OpenShift Dev Spaces Server JVM 지표를 수집하도록 클러스터 내 Prometheus 인스턴스를 구성한 후 OpenShift 웹 콘솔의 관리자 화면에서 사용자 정의 대시보드에서 메트릭을 볼 수 있습니다.
사전 요구 사항
- 조직의 OpenShift Dev Spaces 인스턴스가 Red Hat OpenShift에서 설치 및 실행됩니다.
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오. - 클러스터 내 Prometheus 인스턴스는 지표를 수집하고 있습니다. 4.7.4.2절. “Prometheus를 사용하여 OpenShift Dev Spaces Server 지표 수집”을 참조하십시오.
프로세스
openshift-config-managed
프로젝트에서 대시보드 정의에 대한 ConfigMap을 생성하고 필요한 레이블을 적용합니다.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
$ 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 Copied! 참고이전 명령에는 업스트림 커뮤니티의 자료에 대한 링크가 포함되어 있습니다. 이 자료에서는 사용 가능한 최신 콘텐츠와 최신 모범 사례를 나타냅니다. 이러한 팁은 Red Hat의 QE 부서에 의해 아직 진행되지 않았으며 다양한 사용자 그룹에서는 아직 검증되지 않았습니다. 이 정보를 신중하게 사용하십시오.
oc label configmap grafana-dashboard-devspaces-server console.openshift.io/dashboard=true -n openshift-config-managed
$ oc label configmap grafana-dashboard-devspaces-server console.openshift.io/dashboard=true -n openshift-config-managed
Copy to Clipboard Copied! 참고대시보드 정의는 Grafana 6.x 대시보드를 기반으로 합니다. OpenShift 웹 콘솔에서 모든 Grafana 6.x 대시보드 기능이 지원되는 것은 아닙니다.
검증 단계
- OpenShift 웹 콘솔의 관리자 보기에서 모니터링 → 대시보드 로 이동합니다.
Dashboard → Dev Workspace Operator 로 이동하여 대시보드 패널에 데이터가 포함되어 있는지 확인합니다.
그림 4.3. 빠른 사실
그림 4.4. JVM 메모리
그림 4.5. JVM Misc
그림 4.6. JVM 메모리 풀(heap)
그림 4.7. JVM 메모리 풀(Non-Heap)
그림 4.8. 가비지 컬렉션
그림 4.9. 클래스 로드
그림 4.10. 버퍼 풀
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 podSelector: {} policyTypes: - Ingress
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 Copied! OPTIONAL: 네트워크 정책으로 다중 테넌트 격리 구성을 적용한 경우
allow-from-openshift-apiserver
및allow-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 spec: podSelector: matchLabels: app.kubernetes.io/name: devworkspace-webhook-server ingress: - from: - podSelector: {} namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-apiserver policyTypes: - Ingress
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 Copied! 예 4.45.
allow-from-workspaces-namespaces.yaml
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-workspaces-namespaces namespace: openshift-devspaces spec: podSelector: {} ingress: - from: - podSelector: {} namespaceSelector: matchLabels: app.kubernetes.io/component: workspaces-namespace policyTypes: - Ingress
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 Copied! - 4.2절. “프로젝트 구성”
- 네트워크 격리
- 네트워크 정책으로 다중 테넌트 격리 구성
4.8.2. Dev Spaces 호스트 이름 구성
다음 절차에서는 사용자 지정 호스트 이름을 사용하도록 OpenShift Dev Space를 구성하는 방법을 설명합니다.
사전 요구 사항
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오. - 인증서 및 개인 키 파일이 생성됩니다.
개인 키 및 인증서 쌍을 생성하려면 다른 OpenShift Dev Spaces 호스트에 대해 동일한 CA(인증 기관)를 사용해야 합니다.
DNS 공급자에게 클러스터 인그레스에 대한 사용자 지정 호스트 이름을 가리키도록 요청합니다.
프로세스
OpenShift Dev Spaces용 프로젝트를 사전 생성합니다.
oc create project openshift-devspaces
$ oc create project openshift-devspaces
Copy to Clipboard Copied! TLS 시크릿을 생성합니다.
oc create secret TLS <tls_secret_name> \ --key <key_file> \ --cert <cert_file> \ -n openshift-devspaces
$ oc create secret TLS <tls_secret_name> \
1 --key <key_file> \
2 --cert <cert_file> \
3 -n openshift-devspaces
Copy to Clipboard Copied! 보안에 필요한 레이블을 추가합니다.
oc label secret <tls_secret_name> \ app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
$ oc label secret <tls_secret_name> \
1 app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
Copy to Clipboard Copied! - 1
- TLS 시크릿 이름
CheCluster
사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.spec: networking: hostname: <hostname> tlsSecretName: <secret>
spec: networking: hostname: <hostname>
1 tlsSecretName: <secret>
2 Copy to Clipboard Copied! - 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 인증서를 자동으로 삽입합니다.
사전 요구 사항
프로세스
모든 CA 체인 PEM 파일을
custom-ca-certificates.pem
파일에 연결하고 Java 신뢰 저장소와 호환되지 않는 반환 문자를 제거합니다.cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem
$ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem
Copy to Clipboard Copied! 필요한 TLS 인증서를 사용하여
custom-ca-certificates
ConfigMap을 생성합니다.oc create configmap custom-ca-certificates \ --from-file=custom-ca-certificates.pem \ --namespace=openshift-devspaces
$ oc create configmap custom-ca-certificates \ --from-file=custom-ca-certificates.pem \ --namespace=openshift-devspaces
Copy to Clipboard Copied! 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
$ 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 Copied! - 이전에 배포되지 않은 경우 OpenShift Dev Spaces를 배포합니다. 그렇지 않으면 OpenShift Dev Spaces 구성 요소 롤아웃이 완료될 때까지 기다립니다.
- 변경 사항을 적용하려면 실행 중인 작업 공간을 다시 시작합니다.
검증 단계
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
$ 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 Copied! OpenShift Dev Spaces 서버 로그에서 가져온 인증서 수가 null이 아닌지 확인합니다.
oc logs deploy/devspaces --namespace=openshift-devspaces \ | grep tls-ca-bundle.pem
$ oc logs deploy/devspaces --namespace=openshift-devspaces \ | grep tls-ca-bundle.pem
Copy to Clipboard Copied! - 작업 공간을 시작하고, 생성된 프로젝트 이름(< workspace_namespace >)을 가져오고, 작업 공간이 시작될 때까지 기다립니다.
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}'
$ oc get configmap che-trusted-ca-certs \ --namespace=<workspace_namespace> \ --output='jsonpath={.data.tls-ca-bundle\.pem}'
Copy to Clipboard Copied! 작업 공간 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
$ 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 Copied! 작업 공간 Pod 이름 < workspace_pod_name >을 가져옵니다.
oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].metadata.name}' \
$ oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].metadata.name}' \
Copy to Clipboard Copied! 작업 공간 컨테이너에 사용자 정의 CA 인증서가 있는지 확인합니다. 이 명령은 OpenShift Dev Spaces CA 번들 인증서를 PEM 형식으로 반환합니다.
oc exec <workspace_pod_name> \ --namespace=<workspace_namespace> \ -- cat /public-certs/tls-ca-bundle.pem
$ oc exec <workspace_pod_name> \ --namespace=<workspace_namespace> \ -- cat /public-certs/tls-ca-bundle.pem
Copy to Clipboard Copied!
추가 리소스
4.8.4. 레이블 및 주석 추가
4.8.4.1. 라우터 공유에서 작동하도록 OpenShift 경로 구성
OpenShift 경로의 레이블, 주석 및 도메인이 라우터 분할에서 작동하도록 구성할 수 있습니다.
사전 요구 사항
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. OpenShift CLI 시작하기를 참조하십시오. -
DSC
. 2.2절. “dsc 관리 툴 설치” 을 참조하십시오.
프로세스
CheCluster
사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.spec: networking: labels: <labels> domain: <domain> annotations: <annotations>
spec: networking: labels: <labels>
1 domain: <domain>
2 annotations: <annotations>
3 Copy to Clipboard Copied!
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 사용자 정의 리소스 정의를 사용하여 스토리지 클래스를 정의합니다.
스토리지 클래스 이름을 정의합니다.
CheCluster
사용자 정의 리소스를 구성하고 OpenShift Dev Spaces를 설치합니다. 4.1.1절. “dsc를 사용하여 설치 중에CheCluster
사용자 정의 리소스 구성”을 참조하십시오.spec: devEnvironments: storage: perUserStrategyPvcConfig: claimSize: <claim_size> storageClass: <storage_class_name> perWorkspaceStrategyPvcConfig: claimSize: <claim_size> storageClass: <storage_class_name> pvcStrategy: <pvc_strategy>
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 Copied!
4.9.2. 스토리지 전략 구성
OpenShift Dev Spaces는 스토리지 전략을 선택하여 작업 공간에 영구 스토리지 또는 비영구 스토리지를 제공하도록 구성할 수 있습니다. 선택한 스토리지 전략은 기본적으로 새로 생성된 모든 작업 공간에 적용됩니다. 사용자는 devfile 의 작업 공간 또는 URL 매개변수를 통해 기본이 아닌 스토리지 전략을 선택할 수 있습니다.
사용 가능한 스토리지 전략:
-
사용자별: 사용자가
생성한 모든 작업 공간에 단일 PVC를 사용합니다. -
작업별
: 각 작업 공간에는 자체 PVC가 제공됩니다. -
ephemeral
: 비영구 스토리지; 작업 영역을 중지하면 로컬 변경 사항이 손실됩니다.
OpenShift Dev Spaces에 사용되는 기본 스토리지 전략은 사용자당
입니다.
프로세스
-
Che Cluster 사용자 정의 리소스의
pvcStrategy
필드를사용자당
,Workspace별
또는임시
로 설정합니다.
-
설치 시 이 필드를 설정할 수 있습니다. 4.1.1절. “dsc를 사용하여 설치 중에
CheCluster
사용자 정의 리소스 구성”을 참조하십시오. - 이 필드는 명령줄에서 업데이트할 수 있습니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.
spec: devEnvironments: storage: pvc: pvcStrategy: 'per-user'
spec:
devEnvironments:
storage:
pvc:
pvcStrategy: 'per-user'
- 1
- 사용 가능한 스토리지 전략은
사용자당
,작업당
및임시
입니다.
4.9.3. 스토리지 크기 구성
사용자 또는
스토리지 전략을 사용하여 PVC(영구 볼륨 클레임) 크기를 구성할 수 있습니다. 작업
별CheCluster
사용자 정의 리소스에서 PVC 크기를 Kubernetes 리소스 수량 의 형식으로 지정해야 합니다. 사용 가능한 스토리지 전략에 대한 자세한 내용은 이 페이지를 참조하십시오.
기본 영구 볼륨 클레임 크기:
per-user: 10Gi
per-user: 10Gi
Copy to Clipboard Copied! per-workspace: 5Gi
per-workspace: 5Gi
Copy to Clipboard Copied!
프로세스
-
Che Cluster 사용자 정의 리소스에서 원하는 스토리지 전략에 적절한
claimSize
필드를 설정합니다.
-
설치 시 이 필드를 설정할 수 있습니다. 4.1.1절. “dsc를 사용하여 설치 중에
CheCluster
사용자 정의 리소스 구성”을 참조하십시오. - 이 필드는 명령줄에서 업데이트할 수 있습니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.
spec: devEnvironments: storage: pvc: pvcStrategy: '<strategy_name>' perUserStrategyPvcConfig: claimSize: <resource_quantity> perWorkspaceStrategyPvcConfig: claimSize: <resource_quantity>
spec:
devEnvironments:
storage:
pvc:
pvcStrategy: '<strategy_name>'
perUserStrategyPvcConfig:
claimSize: <resource_quantity>
perWorkspaceStrategyPvcConfig:
claimSize: <resource_quantity>
4.9.4. 영구 사용자 홈
Red Hat OpenShift Dev Spaces는 각 비임스페이스 작업 공간을 사용하여 작업 공간 재시작 시 /home/user
디렉토리를 유지할 수 있는 영구적인 홈 디렉터리 기능을 제공합니다. spec.devEnvironments.persistUserhome.enabled
를 true
로 설정하여 CheCluster에서 이 기능을 활성화할 수 있습니다.
새로 시작된 작업 공간의 경우 이 기능은 툴 컨테이너의 /home/user
경로에 마운트된 PVC를 생성합니다. 이 문서에서는 devfile의 첫 번째 컨테이너를 참조하는 데 "tools 컨테이너"가 사용됩니다. 이 컨테이너는 기본적으로 프로젝트 소스 코드가 포함된 컨테이너입니다.
PVC가 처음 마운트되면 영구 볼륨의 콘텐츠가 비어 있으므로 /home/user
디렉터리 콘텐츠로 채워야 합니다.
기본적으로 persistUserhome 기능은
이라는 새 작업 공간 Pod마다 init 컨테이너를 생성합니다. 이 init 컨테이너는 툴 컨테이너 이미지로 생성되며 init
-persistent-homestow
명령을 실행하여 영구 볼륨에 심볼릭 링크를 생성하여 /home/user
디렉터리를 채웁니다.
.viminfo
및 .bashrc
파일과 같이 /home/user
디렉터리에 심볼릭 링크할 수 없는 파일의 경우 stow
대신 cp
를 사용합니다.
stow
명령의 주요 기능은 다음을 실행하는 것입니다.
stow -t /home/user/ -d /home/tooling/ --no-folding
stow -t /home/user/ -d /home/tooling/ --no-folding
위의 명령은 /home/tooling에 있는 파일 및 디렉토리에 대한 /home/user
에 대한 심볼릭 링크를 만듭니다. 이렇게 하면 영구 볼륨이 /home/tooling
의 콘텐츠에 대한 심볼릭 링크로 채워집니다. 결과적으로 persistentUserHome
기능은 툴링 이미지에 /home/user/
콘텐츠가 /home/tooling
내에 있을 것으로 예상합니다.
예를 들어 툴 컨테이너 이미지에 .config 및
디렉터리에 파일이 포함된 경우 stow는 다음과 같은 방식으로 영구 볼륨에 심볼릭 링크를 생성합니다.
.config
-folder /another-file
과 같은 홈/tooling
그림 4.11. persistUserhome이 활성화된 툴
컨테이너

init 컨테이너는 stow
명령의 출력을 /home/user/.stow.log
에 쓰고 영구 볼륨이 작업 공간에 처음 마운트될 때만 stow
를 실행합니다.
stow
명령을 사용하여 영구 볼륨에서 /home/user
콘텐츠를 채우면 다음과 같은 두 가지 주요 이점이 있습니다.
-
심볼릭 링크를 만드는 것은 영구 볼륨에
/home/user
디렉터리 콘텐츠의 복사본을 생성하는 것보다 적은 스토리지를 사용하는 속도가 빠릅니다. 다르게 설정하기 위해 이 경우 영구 볼륨에는 실제 파일 자체가 아닌 심볼릭 링크가 포함되어 있습니다. -
툴 이미지가 최신 버전의 기존 바이너리, 구성 및 파일로 업데이트되면 기존 심볼릭 링크가 이미
/home/tooling
의 최신 버전에 연결되므로 init 컨테이너가 새 버전을 중단할 필요가 없습니다.
툴링 이미지가 추가 바이너리 또는 파일로 업데이트되면 stow
명령이 다시 실행되지 않기 때문에 /home/user
디렉터리에 심볼릭 링크되지 않습니다. 이 경우 사용자는 /home/user/.stow_completed
파일을 삭제하고 작업 공간을 다시 시작하여 stow
를 재실행해야 합니다.
persistUserhome
툴 이미지 요구 사항
persistUserhome
은 작업 공간에 사용되는 툴 이미지에 따라 다릅니다. 기본적으로 OpenShift Dev Spaces는 샘플 작업 공간에 UDI(Universal Developer Image)를 사용하며 이 이미지는 즉시 persistUser
home을 지원합니다.
사용자 지정 이미지를 사용하는 경우 persistUser
home 기능을 지원하기 위해 충족해야 하는 세 가지 요구 사항이 있습니다.
-
툴 이미지에
stow
버전 >= 2.4.0이 포함되어야 합니다. -
$HOME
환경 변수는/home/user
로 설정됩니다. -
툴 이미지에서
/home/user
콘텐츠를 포함하기 위한 디렉터리는/home/tooling
입니다.
요구 사항 3으로 인해 기본 UDI 이미지는 예를 들어 /home/user
콘텐츠를 /home/tooling
에 추가하고 실행합니다.
RUN stow -t /home/user/ -d /home/tooling/ --no-folding
RUN stow -t /home/user/ -d /home/tooling/ --no-folding
Dockerfile에서 /home/tooling
의 파일은 persistUserhome Home
기능을 사용하지 않는 경우에도 /home/user
에서 액세스할 수 있습니다.
4.10. 대시보드 구성
4.10.1. 시작하기 샘플 구성
다음 절차에서는 사용자 정의 샘플을 표시하도록 OpenShift Dev Spaces 대시보드를 구성하는 방법을 설명합니다.
사전 요구 사항
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
샘플 구성으로 JSON 파일을 생성합니다. 파일에는 각 오브젝트가 샘플을 나타내는 오브젝트 배열이 포함되어야 합니다.
cat > my-samples.json <<EOF [ { "displayName": "<display_name>", "description": "<description>", "tags": <tags>, "url": "<url>", "icon": { "base64data": "<base64data>", "mediatype": "<mediatype>" } } ] EOF
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 Copied! 샘플 구성을 사용하여 ConfigMap을 생성합니다.
oc create configmap getting-started-samples --from-file=my-samples.json -n openshift-devspaces
oc create configmap getting-started-samples --from-file=my-samples.json -n openshift-devspaces
Copy to Clipboard Copied! 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
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 Copied! - 새 샘플을 보려면 OpenShift Dev Spaces 대시보드 페이지를 새로 고칩니다.
4.10.2. 편집기 정의 구성
OpenShift Dev Spaces 편집기 정의를 구성하는 방법을 알아봅니다.
사전 요구 사항
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
편집기 정의 구성을 사용하여
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 &'
# 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 Copied! 편집기 정의 콘텐츠를 사용하여 ConfigMap을 생성합니다.
oc create configmap my-editor-definition --from-file=my-editor-definition-devfile.yaml -n openshift-devspaces
oc create configmap my-editor-definition --from-file=my-editor-definition-devfile.yaml -n openshift-devspaces
Copy to Clipboard Copied! ConfigMap에 필요한 라벨을 추가합니다.
oc label configmap my-editor-definition app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=editor-definition -n openshift-devspaces
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 Copied! - 사용 가능한 새 편집기를 보려면 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
추가 리소스
- devfile 문서
- {editor-definition-samples-link}
4.10.3. 기본 편집기 정의 구성
OpenShift Dev Spaces 기본 편집기 정의를 구성하는 방법을 알아봅니다.
프로세스
사용 가능한 편집기의 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)"'
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 Copied! defaultEditor
를 구성합니다.oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ -p '{"spec":{"devEnvironments":{"defaultEditor": "<default_editor>"}}}'
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ -p '{"spec":{"devEnvironments":{"defaultEditor": "<default_editor>"}}}'
1 Copy to Clipboard Copied! - 1
- 작업 영역을 생성하는 기본 편집기는 플러그인 ID 또는 URI를 사용하여 지정할 수 있습니다. 플러그인 ID는
publisher/name/version
형식을 따라야 합니다. 첫 번째 단계에서 사용 가능한 편집기 ID를 참조하십시오.
추가 리소스
- 4.10.2절. “편집기 정의 구성”
- 4.10.4절. “편집기 정의 숨기기”
- {editor-definition-samples-link}
4.10.4. 편집기 정의 숨기기
OpenShift Dev Spaces 편집기 정의를 숨기는 방법을 알아봅니다. 이 기능은 대시보드 UI에서 선택한 편집기를 숨기고, 예를 들어 IntelliJ IDEA Cryostat를 숨기고 Visual Studio Code - 오픈 소스만 표시하려는 경우에 유용합니다.
프로세스
OpenShift Dev Spaces Operator가 배포된 네임스페이스를 찾습니다.
OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
Copy to Clipboard Copied! 사용 가능한 편집기 정의 파일을 찾습니다.
oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- ls /tmp/editors-definitions
oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- ls /tmp/editors-definitions
Copy to Clipboard Copied! 출력은 다음 예와 유사해야 합니다.
che-code-insiders.yaml che-code-latest.yaml che-idea-latest.yaml che-idea-next.yaml
che-code-insiders.yaml che-code-latest.yaml che-idea-latest.yaml che-idea-next.yaml
Copy to Clipboard Copied! 숨길 편집기 정의를 선택합니다. 예를 들어
che-idea-next.yaml
편집기 정의를 숨기려면 편집기 정의 파일 이름을 설정합니다.CHE_EDITOR_CONCEAL_FILE_NAME=che-idea-next.yaml
CHE_EDITOR_CONCEAL_FILE_NAME=che-idea-next.yaml
Copy to Clipboard Copied! 숨겨진 편집기 정의의 ConfigMap 이름을 정의합니다.
CHE_EDITOR_CONCEAL_CONFIGMAP_NAME=che-conceal-$CHE_EDITOR_CONCEAL_FILE_NAME
CHE_EDITOR_CONCEAL_CONFIGMAP_NAME=che-conceal-$CHE_EDITOR_CONCEAL_FILE_NAME
Copy to Clipboard Copied! ConfigMap을 생성합니다.
oc create configmap $CHE_EDITOR_CONCEAL_CONFIGMAP_NAME \ --namespace $OPERATOR_NAMESPACE \ --from-literal=$CHE_EDITOR_CONCEAL_FILE_NAME=""
oc create configmap $CHE_EDITOR_CONCEAL_CONFIGMAP_NAME \ --namespace $OPERATOR_NAMESPACE \ --from-literal=$CHE_EDITOR_CONCEAL_FILE_NAME=""
Copy to Clipboard Copied! 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')
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 Copied! 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
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 Copied!
추가 리소스
- 4.10.2절. “편집기 정의 구성”
- 4.10.3절. “기본 편집기 정의 구성”
- {editor-definition-samples-link}
4.10.5. OpenShift Eclipse Che ConsoleLink 아이콘 사용자 정의
다음 절차에서는 Red Hat OpenShift Dev Spaces ConsoleLink 아이콘을 사용자 지정하는 방법을 설명합니다.
사전 요구 사항
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
보안을 생성합니다.
oc apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: devspaces-dashboard-customization namespace: openshift-devspaces annotations: che.eclipse.org/mount-as: subpath che.eclipse.org/mount-path: /public/dashboard/assets/branding labels: app.kubernetes.io/component: devspaces-dashboard-secret app.kubernetes.io/part-of: che.eclipse.org data: loader.svg: <Base64_encoded_content_of_the_image> type: Opaque EOF
oc apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: devspaces-dashboard-customization namespace: openshift-devspaces annotations: che.eclipse.org/mount-as: subpath che.eclipse.org/mount-path: /public/dashboard/assets/branding labels: app.kubernetes.io/component: devspaces-dashboard-secret app.kubernetes.io/part-of: che.eclipse.org data: loader.svg: <Base64_encoded_content_of_the_image>
1 type: Opaque EOF
Copy to Clipboard Copied! - 1
- 비활성화된 줄 래핑을 사용한 Base64 인코딩.
- devspaces-dashboard의 롤아웃이 완료될 때까지 기다립니다.
추가 리소스
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"
spec:
components:
cheServer:
extraProperties:
CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN: "true"
OpenShift Dev Spaces와 Git 공급자 간에 OAuth를 구성하여 사용자가 원격 Git 리포지토리에서 작업할 수 있습니다.
4.11.1.1. GitHub용 OAuth 2.0 구성
사용자가 GitHub에서 호스팅되는 원격 Git 리포지토리를 사용할 수 있도록 하려면 다음을 수행합니다.
- GitHub OAuth 앱(OAuth 2.0)을 설정합니다.
- GitHub OAuth 앱 시크릿을 적용합니다.
4.11.1.1.1. GitHub OAuth 앱 설정
OAuth 2.0을 사용하여 GitHub OAuth 앱을 설정합니다.
사전 요구 사항
- GitHub에 로그인되어 있습니다.
프로세스
- https://github.com/settings/applications/new 로 이동합니다.
다음 값을 입력합니다.
-
애플리케이션 이름: <
;애플리케이션 이름>
-
Homepage URL:
https://<openshift_dev_spaces_fqdn>/
-
Authorization callback URL:
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
-
애플리케이션 이름: <
- Register application을 클릭합니다.
- 새 클라이언트 시크릿 생성 을 클릭합니다.
- GitHub OAuth 앱 시크릿을 적용할 때 사용할 GitHub OAuth 클라이언트 ID 를 복사하고 저장합니다.
- 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 시작하기를 참조하십시오.
프로세스
보안을 준비합니다.
kind: Secret apiVersion: v1 metadata: name: github-oauth-config namespace: openshift-devspaces 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> che.eclipse.org/scm-github-disable-subdomain-isolation: 'false' type: Opaque stringData: id: <GitHub_OAuth_Client_ID> secret: <GitHub_OAuth_Client_Secret>
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 Copied! - 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 클라이언트 시크릿.
보안을 적용합니다.
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 출력에서 Secret이 생성되었는지 확인합니다.
다른 GitHub 공급자에 대해 OAuth 2.0을 구성하려면 위의 단계를 반복하고 다른 이름으로 두 번째 GitHub OAuth 시크릿을 생성해야 합니다.
4.11.1.2. GitLab에 대한 OAuth 2.0 구성
사용자가 GitLab 인스턴스를 사용하여 호스팅되는 원격 Git 리포지토리에서 작업할 수 있도록 하려면 다음을 수행합니다.
- GitLab 인증 애플리케이션(OAuth 2.0)을 설정합니다.
- GitLab 인증 애플리케이션 시크릿을 적용합니다.
4.11.1.2.1. GitLab 인증 애플리케이션 설정
OAuth 2.0을 사용하여 GitLab 인증 애플리케이션을 설정합니다.
사전 요구 사항
- GitLab에 로그인되어 있습니다.
프로세스
- avatar를 클릭하고 → 로 이동합니다.
- 이름으로 OpenShift Dev Spaces 를 입력합니다.
-
Redirect URI 로
https:// <openshift_dev_spaces_fqdn> /api/oauth/callback
을 입력합니다. - Confidential 및 Expire 액세스 토큰 확인란을 선택합니다.
-
Scopes 에서
api
,write_repository
,openid
체크박스를 선택합니다. - Save application 을 클릭합니다.
- GitLab 인증 애플리케이션 시크릿을 적용할 때 사용할 GitLab 애플리케이션 ID 를 복사하고 저장합니다.
- GitLab-authorized 애플리케이션 시크릿을 적용할 때 사용할 GitLab 클라이언트 시크릿을 복사하고 저장합니다.
추가 리소스
4.11.1.2.2. GitLab 인증 애플리케이션 시크릿 적용
GitLab 인증 애플리케이션 시크릿을 준비하고 적용합니다.
사전 요구 사항
- GitLab 인증 애플리케이션 설정이 완료되었습니다.
GitLab 인증 애플리케이션을 설정할 때 생성된 다음 값이 준비됩니다.
- GitLab Application ID
- GitLab 클라이언트 시크릿
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
보안을 준비합니다.
kind: Secret apiVersion: v1 metadata: name: gitlab-oauth-config namespace: openshift-devspaces 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> type: Opaque stringData: id: <GitLab_Application_ID> secret: <GitLab_Client_Secret>
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 Copied! 보안을 적용합니다.
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 출력에서 Secret이 생성되었는지 확인합니다.
다른 Gitlab 공급자에 대해 OAuth 2.0을 구성하려면 위의 단계를 반복하고 다른 이름으로 두 번째 Gitlab OAuth 시크릿을 생성해야 합니다.
4.11.1.3. Bitbucket 서버에 대한 OAuth 2.0 구성
OAuth 2.0을 사용하여 사용자가 Bitbucket 서버에서 호스팅되는 원격 Git 리포지토리로 작업할 수 있습니다.
- Bitbucket 서버에서 OAuth 2.0 애플리케이션 링크를 설정합니다.
- Bitbucket 서버에 대한 애플리케이션 링크 시크릿을 적용합니다.
4.11.1.3.1. Bitbucket 서버에서 OAuth 2.0 애플리케이션 링크 설정
Bitbucket 서버에서 OAuth 2.0 애플리케이션 링크를 설정합니다.
사전 요구 사항
- Bitbucket 서버에 로그인되어 있습니다.
프로세스
- Administration > Applications > Application links 로 이동합니다.
- 링크 생성을 선택합니다.
- 외부 애플리케이션 및 수신 을 선택합니다.
-
https:// <openshift_dev_spaces_fqdn> /api/oauth/callback
을 Redirect URL 필드에 입력합니다. - 애플리케이션 권한 에서 관리자 - 쓰기 확인란을 선택합니다.
- 저장을 클릭합니다.
- Bitbucket 애플리케이션 링크 시크릿을 적용할 때 사용할 클라이언트 ID 를 복사하고 저장합니다.
- Bitbucket 애플리케이션 링크 시크릿을 적용할 때 사용할 클라이언트 시크릿을 복사하고 저장합니다.
추가 리소스
4.11.1.3.2. Bitbucket 서버에 대한 OAuth 2.0 애플리케이션 링크 시크릿 적용
Bitbucket 서버에 대한 OAuth 2.0 애플리케이션 링크 시크릿을 준비하고 적용합니다.
사전 요구 사항
- 애플리케이션 링크는 Bitbucket 서버에 설정됩니다.
Bitbucket 애플리케이션 링크를 설정할 때 생성된 다음 값이 준비됩니다.
- Bitbucket 클라이언트 ID
- Bitbucket 클라이언트 시크릿
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
보안을 준비합니다.
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: <bitbucket_server_url> type: Opaque stringData: id: <Bitbucket_Client_ID> secret: <Bitbucket_Client_Secret>
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 che.eclipse.org/scm-server-endpoint: <bitbucket_server_url>
2 type: Opaque stringData: id: <Bitbucket_Client_ID>
3 secret: <Bitbucket_Client_Secret>
4 Copy to Clipboard Copied! 보안을 적용합니다.
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 출력에서 Secret이 생성되었는지 확인합니다.
4.11.1.4. Bitbucket Cloud에 대한 OAuth 2.0 구성
사용자가 Bitbucket Cloud에서 호스팅되는 원격 Git 리포지토리에서 작업할 수 있습니다.
- Bitbucket Cloud에서 OAuth 소비자(OAuth 2.0)를 설정합니다.
- Bitbucket Cloud에 OAuth 소비자 시크릿을 적용합니다.
4.11.1.4.1. Bitbucket 클라우드에서 OAuth 소비자 설정
Bitbucket Cloud에서 OAuth 2.0에 대한 OAuth 소비자를 설정합니다.
사전 요구 사항
- Bitbucket Cloud에 로그인되어 있습니다.
프로세스
- avatar를 클릭하고 모든 작업 공간 페이지로 이동합니다.
- 작업 영역을 선택하고 클릭합니다.
- → 로 이동합니다.
- 이름으로 OpenShift Dev Spaces 를 입력합니다.
-
콜백 URL 로
https:// <openshift_dev_spaces_fqdn> /api/oauth/callback
을 입력합니다. - 권한 에서 모든 계정 및 리포지토리 확인란을 선택하고 저장을 클릭합니다.
- 추가된 소비자를 확장한 다음 Bitbucket OAuth 소비자 시크릿을 적용할 때 사용할 Key 값을 복사하여 저장합니다.
- 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 시작하기를 참조하십시오.
프로세스
보안을 준비합니다.
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces 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> secret: <Bitbucket_Oauth_Consumer_Secret>
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 Copied! 보안을 적용합니다.
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 출력에서 Secret이 생성되었는지 확인합니다.
4.11.1.5. Bitbucket 서버에 대한 OAuth 1.0 구성
사용자가 Bitbucket 서버에서 호스팅되는 원격 Git 리포지토리에서 작업할 수 있도록 하려면 다음을 수행합니다.
- Bitbucket 서버에서 애플리케이션 링크(OAuth 1.0)를 설정합니다.
- Bitbucket 서버에 대한 애플리케이션 링크 시크릿을 적용합니다.
4.11.1.5.1. Bitbucket 서버에서 애플리케이션 링크 설정
Bitbucket 서버에서 OAuth 1.0에 대한 애플리케이션 링크를 설정합니다.
사전 요구 사항
- Bitbucket 서버에 로그인되어 있습니다.
-
OpenSSL
은 사용 중인 운영 체제에 설치되어 있습니다.
프로세스
명령줄에서 명령을 실행하여 애플리케이션 링크 시크릿을 적용할 때 다음 단계에 필요한 파일을 생성합니다.
openssl genrsa -out private.pem 2048 && \ openssl pkcs8 -topk8 -inform pem -outform pem -nocrypt -in private.pem -out privatepkcs8.pem && \ cat privatepkcs8.pem | sed 's/-----BEGIN PRIVATE KEY-----//g' | sed 's/-----END PRIVATE KEY-----//g' | tr -d '\n' > privatepkcs8-stripped.pem && \ openssl rsa -in private.pem -pubout > public.pub && \ cat public.pub | sed 's/-----BEGIN PUBLIC KEY-----//g' | sed 's/-----END PUBLIC KEY-----//g' | tr -d '\n' > public-stripped.pub && \ openssl rand -base64 24 > bitbucket-consumer-key && \ openssl rand -base64 24 > bitbucket-shared-secret
$ openssl genrsa -out private.pem 2048 && \ openssl pkcs8 -topk8 -inform pem -outform pem -nocrypt -in private.pem -out privatepkcs8.pem && \ cat privatepkcs8.pem | sed 's/-----BEGIN PRIVATE KEY-----//g' | sed 's/-----END PRIVATE KEY-----//g' | tr -d '\n' > privatepkcs8-stripped.pem && \ openssl rsa -in private.pem -pubout > public.pub && \ cat public.pub | sed 's/-----BEGIN PUBLIC KEY-----//g' | sed 's/-----END PUBLIC KEY-----//g' | tr -d '\n' > public-stripped.pub && \ openssl rand -base64 24 > bitbucket-consumer-key && \ openssl rand -base64 24 > bitbucket-shared-secret
Copy to Clipboard Copied! - → 로 이동합니다.
-
https:// <openshift_dev_spaces_fqdn> /
를 URL 필드에 입력하고 Create new link 를 클릭합니다. - 제공된 애플리케이션 URL이 한 번 리디렉션되었습니다. 이 URL 사용 확인란을 선택하고 Continue 를 클릭합니다.
- 애플리케이션 이름으로 OpenShift Dev Spaces 를 입력합니다.
- 애플리케이션 유형으로 일반 애플리케이션을 선택합니다.
- OpenShift Dev Spaces 를 서비스 공급자 이름으로 입력합니다.
-
bitbucket-consumer-key
파일의 내용을 Consumer 키로 붙여넣습니다. -
bitbucket-shared-secret
파일의 내용을 공유 시크릿으로 붙여넣습니다. -
요청
토큰 URL로 <bitbucket_server_url
> /plugins/servlet/oauth/request-token 을 입력합니다. -
액세스
토큰 URL로 <bitbucket_server_url> /plugins/servlet/oauth/access-token
을 입력합니다. -
승인
URL로 <bitbucket_server_url> /plugins/servlet/oauth/authorize
를 입력합니다. - Create incoming link 확인란을 선택하고 Continue 를 클릭합니다.
-
bitbucket-consumer-key
파일의 내용을 Consumer Key 로 붙여넣습니다. - 소비자 이름으로 OpenShift Dev Spaces 를 입력합니다.
-
public-stripped.pub
파일의 내용을 공개 키로 붙여넣고 Continue 를 클릭합니다.
추가 리소스
4.11.1.5.2. Bitbucket 서버에 대한 애플리케이션 링크 시크릿 적용
Bitbucket 서버에 대한 애플리케이션 링크 시크릿을 준비하고 적용합니다.
사전 요구 사항
- 애플리케이션 링크는 Bitbucket 서버에 설정됩니다.
애플리케이션 링크를 설정할 때 생성된 다음 파일이 준비됩니다.
-
privatepkcs8-stripped.pem
-
bitbucket-consumer-key
-
bitbucket-shared-secret
-
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
보안을 준비합니다.
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces labels: app.kubernetes.io/component: oauth-scm-configuration app.kubernetes.io/part-of: che.eclipse.org annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: <bitbucket_server_url> type: Opaque stringData: private.key: <Content_of_privatepkcs8-stripped.pem> consumer.key: <Content_of_bitbucket-consumer-key> shared_secret: <Content_of_bitbucket-shared-secret>
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces
1 labels: app.kubernetes.io/component: oauth-scm-configuration app.kubernetes.io/part-of: che.eclipse.org annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: <bitbucket_server_url>
2 type: Opaque stringData: private.key: <Content_of_privatepkcs8-stripped.pem>
3 consumer.key: <Content_of_bitbucket-consumer-key>
4 shared_secret: <Content_of_bitbucket-shared-secret>
5 Copy to Clipboard Copied! 보안을 적용합니다.
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 출력에서 Secret이 생성되었는지 확인합니다.
4.11.1.6. Microsoft Azure DevOps Services용 OAuth 2.0 구성
사용자가 Microsoft Azure Repos에서 호스팅되는 원격 Git 리포지토리에서 작업할 수 있도록 하려면 다음을 수행합니다.
- Microsoft Azure DevOps Services OAuth App(OAuth 2.0)을 설정합니다.
- 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를 통한 타사 애플리케이션 액세스
는 조직에 대해 활성화됩니다. 조직의 애플리케이션 연결 및 보안 정책 변경을 참조하십시오.프로세스
- https://app.vsaex.visualstudio.com/app/register/.
다음 값을 입력합니다.
-
회사 이름:
OpenShift Dev Spaces
-
애플리케이션 이름:
OpenShift Dev Spaces
-
Application website:
https://<openshift_dev_spaces_fqdn>/
-
Authorization callback URL:
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
-
회사 이름:
- 인증 범위 선택에서 코드(읽기 및 쓰기) 를 선택합니다.
- 애플리케이션 생성을 클릭합니다.
- Microsoft Azure DevOps Services OAuth 앱 시크릿을 적용할 때 사용할 앱 ID 를 복사하고 저장합니다.
- 표시 를 클릭하여 클라이언트 시크릿 을 표시합니다.
- 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 시작하기를 참조하십시오.
프로세스
보안을 준비합니다.
kind: Secret apiVersion: v1 metadata: name: azure-devops-oauth-config namespace: openshift-devspaces 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> secret: <Microsoft_Azure_DevOps_Services_OAuth_Client_Secret>
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 Copied! 보안을 적용합니다.
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 출력에서 Secret이 생성되었는지 확인합니다.
- OpenShift Dev Spaces 서버 구성 요소의 롤아웃이 완료될 때까지 기다립니다.
4.11.2. Dev Spaces 사용자에 대한 클러스터 역할 구성
해당 사용자에게 클러스터 역할을 추가하여 OpenShift Dev Spaces 사용자에게 더 많은 클러스터 권한을 부여할 수 있습니다.
사전 요구 사항
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
사용자 역할 이름을 정의합니다.
USER_ROLES=<name>
$ USER_ROLES=<name>
1 Copy to Clipboard Copied! - 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)
$ OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
Copy to Clipboard Copied! 필요한 역할을 생성합니다.
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> apiGroups: - <apiGroups> resources: - <resources> EOF
$ 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 Copied! 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
$ 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 Copied! che
서비스 계정에 역할을 위임하도록 OpenShift Dev Spaces Operator를 구성합니다.kubectl patch checluster devspaces \ --patch '{"spec": {"components": {"cheServer": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
$ kubectl patch checluster devspaces \ --patch '{"spec": {"components": {"cheServer": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
Copy to Clipboard Copied! 사용자에게 역할을 위임하도록 OpenShift Dev Spaces 서버를 구성합니다.
kubectl patch checluster devspaces \ --patch '{"spec": {"devEnvironments": {"user": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
$ kubectl patch checluster devspaces \ --patch '{"spec": {"devEnvironments": {"user": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
Copy to Clipboard Copied! - OpenShift Dev Spaces 서버 구성 요소의 롤아웃이 완료될 때까지 기다립니다.
- 사용자에게 로그아웃하고 로그인하여 새 역할을 적용하도록 요청합니다.
4.11.3. 고급 권한 부여 구성
OpenShift Dev Spaces에 액세스할 수 있는 사용자 및 그룹을 확인할 수 있습니다.
사전 요구 사항
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
CheCluster
사용자 정의 리소스를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.spec: networking: auth: advancedAuthorization: allowUsers: - <allow_users> allowGroups: - <allow_groups> denyUsers: - <deny_users> denyGroups: - <deny_groups>
spec: networking: auth: advancedAuthorization: allowUsers: - <allow_users>
1 allowGroups: - <allow_groups>
2 denyUsers: - <deny_users>
3 denyGroups: - <deny_groups>
4 Copy to Clipboard Copied! - OpenShift Dev Spaces 서버 구성 요소의 롤아웃이 완료될 때까지 기다립니다.
사용자가 OpenShift Dev Spaces에 액세스할 수 있도록 허용하려면 allowUsers
목록에 추가합니다. 또는 사용자가 멤버인 그룹을 선택하고 allowGroups
목록에 그룹을 추가합니다. OpenShift Dev Spaces에 대한 사용자 액세스를 거부하려면 denyUsers
목록에 추가합니다. 또는 사용자가 멤버인 그룹을 선택하고 denyGroups
목록에 그룹을 추가합니다. 사용자가 허용
및 거부
목록 모두에 있는 경우 OpenShift Dev Spaces에 대한 액세스가 거부됩니다.
allowUsers
및 allowGroups
가 비어 있으면 거부
목록에 있는 항목을 제외한 모든 사용자가 OpenShift Dev Spaces에 액세스할 수 있습니다. denyUsers
및 denyGroups
가 비어 있으면 허용
목록의 사용자만 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 시작하기를 참조하십시오.
프로세스
다음 명령을 사용하여 OpenShift 클러스터의 모든 사용자를 나열합니다.
oc get users
$ oc get users
Copy to Clipboard Copied! - 사용자 항목을 삭제합니다.
사용자에게 연결된 리소스(예: 프로젝트, 역할 또는 서비스 계정)가 있는 경우 사용자를 삭제하기 전에 먼저 해당 리소스를 삭제해야 합니다.
oc delete user <username>
$ oc delete user <username>
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를 활성화할 수 있습니다.
- 클러스터 내의 모든 사용자 작업 공간 4.12.2절. “모든 작업 공간에 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 을 참조하십시오.
4.12.1. 4.15 이전의 OpenShift 버전에 대한 액세스 활성화
fuse-overlayfs를 사용하려면 먼저 작업 공간 컨테이너에서 /dev/fuse
에 액세스할 수 있도록 해야 합니다.
/dev/fuse
장치를 기본적으로 사용할 수 있으므로 OpenShift 버전 4.15 이상에는 이 절차가 필요하지 않습니다. 릴리스 정보를 참조하십시오.
OpenShift 클러스터에서 MachineConfig
리소스를 생성하는 것은 클러스터에 대한 고급 시스템 수준의 변경을 수행하기 때문에 잠재적으로 위험한 작업입니다.
자세한 내용 및 가능한 위험은 MachineConfig 문서를 참조하십시오.
사전 요구 사항
프로세스
OpenShift 클러스터 유형(단일 노드 클러스터 또는 별도의 컨트롤 플레인 및 작업자 노드가 있는 다중 노드 클러스터)에 따라 환경 변수를 설정합니다.
단일 노드 클러스터의 경우 다음을 설정합니다.
NODE_ROLE=master
$ NODE_ROLE=master
Copy to Clipboard Copied! 다중 노드 클러스터의 경우 다음을 설정합니다.
NODE_ROLE=worker
$ NODE_ROLE=worker
Copy to Clipboard Copied!
OpenShift Butane 구성 버전의 환경 변수를 설정합니다. 이 변수는 OpenShift 클러스터의 메이저 및 마이너 버전입니다. 예를 들면
4.12.0
,4.13.0
또는4.14.0
입니다.VERSION=4.12.0
$ VERSION=4.12.0
Copy to Clipboard Copied! 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 mode: 0644 overwrite: true contents: inline: | [crio.runtime.workloads.podman-fuse] activation_annotation = "io.openshift.podman-fuse" allowed_annotations = [ "io.kubernetes.cri-o.Devices" ] [crio.runtime] allowed_devices = ["/dev/fuse"] EOF
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 Copied! MachineConfig
리소스를 적용하면 변경 사항이 적용되면작업자
역할이 있는 각 노드에 대해 예약이 일시적으로 비활성화됩니다. 노드 상태를 확인합니다.oc get nodes
$ oc get nodes
Copy to Clipboard Copied! 출력 예:
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
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 Copied! 작업자
역할의 모든 노드의 상태가Ready
이면 다음 주석이 있는 모든 Pod에서/dev/fuse
를 사용할 수 있습니다.io.openshift.podman-fuse: '' io.kubernetes.cri-o.Devices: /dev/fuse
io.openshift.podman-fuse: '' io.kubernetes.cri-o.Devices: /dev/fuse
Copy to Clipboard Copied!
검증 단계
작업자
역할이 있는 노드의 이름을 가져옵니다.oc get nodes
$ oc get nodes
Copy to Clipboard Copied! 작업자 노드에 대한
oc 디버그
세션을 엽니다.oc debug node/<nodename>
$ oc debug node/<nodename>
Copy to Clipboard Copied! 99-podman-fuse
라는 새 CRI-O 구성 파일이 있는지 확인합니다.stat /host/etc/crio/crio.conf.d/99-podman-fuse
sh-4.4# stat /host/etc/crio/crio.conf.d/99-podman-fuse
Copy to Clipboard Copied!
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
폴더를 소유해야 하는 경우 스크립트를 수동으로 구성해야 합니다.
사전 요구 사항
- OpenShift 버전 4.14 이하의 경우 4.12.1절. “4.15 이전의 OpenShift 버전에 대한 액세스 활성화” 섹션이 완료되었습니다.
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오.
프로세스
CheCluster 사용자 정의 리소스의
spec.devEnvironments.workspacesPodAnnotations
필드에 필요한 주석을 설정합니다.kind: CheCluster apiVersion: org.eclipse.che/v2 spec: devEnvironments: workspacesPodAnnotations: io.kubernetes.cri-o.Devices: /dev/fuse
kind: CheCluster apiVersion: org.eclipse.che/v2 spec: devEnvironments: workspacesPodAnnotations: io.kubernetes.cri-o.Devices: /dev/fuse
Copy to Clipboard Copied! 참고OpenShift 버전 4.14 이하의 경우
io.openshift.podman-fuse: ""
주석도 필요합니다.선택 사항: 작업 공간 컨테이너에 사용자 지정 이미지를 사용하는 경우
/home/user/.config
폴더를 생성하고 진입점을 통해 런타임에서storage.conf
파일을 구성합니다. 이렇게 하려면 이미지를 빌드하기 전에 작업 공간 컨테이너 이미지의 진입점 스크립트에 다음을 추가합니다. 진입점에/home/user/.config
폴더를 생성하면 이미지 빌드 시 알 수 없는 현재 사용자가 폴더를 소유하게 됩니다.Configure container builds to use vfs or fuse-overlayfs
# 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 Copied! 이렇게 하면
/home/user/.config
가 아직 존재하지 않는 경우 폴더가 생성되어사용자가
소유합니다. 예를 들어/home/user/.config
가 영구 볼륨에 저장된 경우 이미 존재할 수 있습니다.작업 영역을 시작하고
/home/user/.config
의 소유자가user
인지 확인합니다.ls -la /home/user
$ ls -la /home/user
Copy to Clipboard Copied! 출력 예:
... drwxrwsr-x. 3 user 1000660000 24 Dec 24 15:40 .config
... drwxrwsr-x. 3 user 1000660000 24 Dec 24 15:40 .config
Copy to Clipboard Copied! 스토리지 드라이버가
오버레이
인지 확인합니다.podman info | grep overlay
$ podman info | grep overlay
Copy to Clipboard Copied! 출력 예:
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
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 Copied! 참고기존 작업 공간에 대해 다음 오류가 발생할 수 있습니다.
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
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 Copied! 이 경우 오류 메시지에 언급된 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>"
spec: components: pluginRegistry: openVSXURL: "<url_of_an_open_vsx_registry_instance>"
1 Copy to Clipboard Copied! - 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를 기반으로 컨테이너를 다시 빌드합니다.
프로세스
선택한 각 확장의 게시자 및 확장 이름을 가져옵니다.
- Open VSX 레지스트리 웹 사이트에서 확장을 찾고 확장 프로그램 목록 페이지 및 확장 프로그램의 URL을 복사합니다.
복사한 URL에서 <publisher > 및 <extension> 이름을 추출합니다.
https://open-vsx.org/extension/<publisher>/<name>
https://open-vsx.org/extension/<publisher>/<name>
Copy to Clipboard Copied! 작은 정보확장 기능을 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 팀에 문제를 보고하는 것이 좋습니다.
사용자 정의 플러그인 레지스트리 이미지를 빌드하고 CheCluster 사용자 정의 리소스를 업데이트합니다.
작은 정보- 빌드 프로세스 중에 각 확장은 OpenShift Dev Spaces에서 사용되는 Visual Studio Code 버전과의 호환성을 확인합니다.
OpenShift Dev Spaces 인스턴스 사용:
중요IBM Power(
ppc64le
) 및 IBM Z(s390x
)의 경우 사용자 정의 플러그인 레지스트리가 해당 아키텍처에 로컬로 빌드될 것으로 예상됩니다.- 관리자로 OpenShift Dev Spaces 인스턴스에 로그인합니다.
새 Red Hat Registry 서비스 계정을 생성하고 사용자 이름과 토큰을 복사합니다.
- 플러그인 레지스트리 리포지토리 를 사용하여 작업 영역을 시작합니다.
터미널을 열고 OpenShift Dev Spaces 버전(예:
devspaces-3.15-rhel-8
)에 해당하는 Git 태그를 확인합니다.git checkout devspaces-$PRODUCT_VERSION-rhel-8
git checkout devspaces-$PRODUCT_VERSION-rhel-8
Copy to Clipboard Copied! -
openvsx-sync.json
파일을 열고 확장을 추가하거나 제거합니다. -
1을 실행합니다. 작업 공간의 registry.redhat.io
작업에 로그인합니다(Terminal → Run Task… → devfile → 1. registry.redhat.io에 로그인하고 registry.redhat.io 에 로그인합니다. -
2를 실행합니다. 작업 공간에 사용자 지정 플러그인 레지스트리
작업을 빌드하고 게시합니다(Terminal → Run Task… → devfile → 2. 사용자 지정 플러그인 레지스트리 빌드 및 게시). 3을 실행합니다. 작업 영역에서 사용자 정의 플러그인 레지스트리
작업을 사용하도록 Che를 구성합니다(Terminal → Run Task… → devfile → 3). 사용자 지정 플러그인 레지스트리를 사용하도록 Che를 구성합니다.Linux 운영 체제 사용:
작은 정보- podman 및 NodeJS 버전 18.20.3 이상이 시스템에 설치되어 있어야 합니다.
- Dev Spaces 리포지토리를 다운로드하거나 분기하고 복제합니다.
git clone https://github.com/redhat-developer/devspaces.git
git clone https://github.com/redhat-developer/devspaces.git
+
- 플러그인 레지스트리 하위 모듈로 이동합니다.
cd devspaces/dependencies/che-plugin-registry/
cd devspaces/dependencies/che-plugin-registry/
+
OpenShift Dev Spaces 버전에 해당하는 태그를 체크아웃합니다(예:
devspaces-3.15-rhel-8
).git checkout devspaces-$PRODUCT_VERSION-rhel-8
git checkout devspaces-$PRODUCT_VERSION-rhel-8
Copy to Clipboard Copied! - 새 Red Hat Registry 서비스 계정을 생성하고 사용자 이름과 토큰을 복사합니다.
registry.redhat.io 에 로그인 :
podman login registry.redhat.io
podman login registry.redhat.io
Copy to Clipboard Copied! 추가 또는 제거해야 하는 각 확장에 대해
openvsx-sync.json
파일을 편집합니다.-
확장을 추가하려면
openvsx-sync.json
파일에 게시자, 이름 및 확장 버전을 추가합니다. -
확장을 제거하려면
openvsx-sync.json
파일에서 게시자, 이름 및 확장 버전을 제거합니다. 다음 JSON 구문을 사용합니다.
{ "id": "<publisher>.<name>", "version": "<extension_version>" }
{ "id": "<publisher>.<name>", "version": "<extension_version>" }
Copy to Clipboard Copied! 작은 정보조직에서 내부 용도로만 사용되는 확장 프로그램 또는 closed-source 확장이 있는 경우 사용자 정의 플러그인 레지스트리 컨테이너에 액세스할 수 있는 URL을 사용하여
.vsix
파일에서 직접 확장을 추가할 수 있습니다.{ "id": "<publisher>.<name>", "download": "<url_to_download_vsix_file>", "version": "<extension_version>" }
{ "id": "<publisher>.<name>", "download": "<url_to_download_vsix_file>", "version": "<extension_version>" }
Copy to Clipboard Copied! - 리소스를 사용하기 전에 Microsoft Visual Studio Marketplace 에 대한 사용 약관 을 읽으십시오.
-
확장을 추가하려면
플러그인 레지스트리 컨테이너 이미지를 빌드하고 quay.io 와 같은 컨테이너 레지스트리에 게시합니다.
./build.sh -o <username> -r quay.io -t custom
$ ./build.sh -o <username> -r quay.io -t custom
Copy to Clipboard Copied! podman push quay.io/<username/plugin_registry:custom>
$ podman push quay.io/<username/plugin_registry:custom>
Copy to Clipboard Copied!
조직의 클러스터에서
CheCluster
사용자 지정 리소스를 편집하여 (예: quay.io) 이미지를 가리키고 변경 사항을 저장합니다.spec: components: pluginRegistry: deployment: containers: - image: quay.io/<username/plugin_registry:custom> openVSXURL: ''
spec: components: pluginRegistry: deployment: containers: - image: quay.io/<username/plugin_registry:custom> openVSXURL: ''
Copy to Clipboard Copied!
검증
-
plugin-registry
pod가 다시 시작되어 실행 중인지 확인합니다. - 작업 영역을 다시 시작하고 작업 공간 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> # [...]
spec: components: # [...] pluginRegistry: openVSXURL: <your_open_vsx_registy> # [...]
Copy to Clipboard Copied! 주의전용 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" } ] }
{
"folders": [
{
"name": "project-1",
"path": "/projects/project-1"
},
{
"name": "project-2",
"path": "/projects/project-2"
}
]
}
작업 공간 파일이 이미 있으면 업데이트되고 누락된 모든 프로젝트가 devfile에서 가져옵니다. devfile에서 프로젝트를 제거하면 작업 공간 파일에 남아 있습니다.
기본 동작을 변경하고 자체 작업 공간 파일을 제공하거나 단일 루트 작업 공간으로 전환할 수 있습니다.
프로세스
자체 작업 공간 파일을 제공합니다.
.code-workspace
라는 작업 공간 파일을 리포지토리의 루트에 배치합니다. 작업 영역을 만든 후 Visual Studio Code - Open Source("Code - OSS")는 작업 공간 파일을 그대로 사용합니다.{ "folders": [ { "name": "project-name", "path": "." } ] }
{ "folders": [ { "name": "project-name", "path": "." } ] }
Copy to Clipboard Copied! 중요작업 공간 파일을 만들 때는 주의하십시오. 오류가 발생하면 대신 빈 Visual Studio Code - 오픈 소스("Code - OSS")가 열립니다.
중요여러 프로젝트가 있는 경우 작업 공간 파일은 첫 번째 프로젝트에서 가져옵니다. 첫 번째 프로젝트에 작업 공간 파일이 없으면 새 파일이 생성되어
/projects
디렉터리에 배치됩니다.
대체 작업 공간 파일을 지정합니다.
devfile에 VSCODE_DEFAULT_WORKSPACE 환경 변수를 정의하고 작업 공간 파일의 올바른 위치를 지정합니다.
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/projects/project-name/workspace-file"
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/projects/project-name/workspace-file"
Copy to Clipboard Copied!
단일 루트 모드에서 작업 공간을 엽니다.
VSCODE_DEFAULT_WORKSPACE 환경 변수를 정의하고 root로 설정합니다.
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"
Copy to Clipboard Copied!
6.2. Microsoft Visual Studio Code에 대한 신뢰할 수 있는 확장 구성
Microsoft Visual Studio Code의 product.json
파일에서 trustedExtensionAuthAccess
필드를 사용하여 인증 토큰에 액세스하는 데 신뢰할 수 있는 확장을 지정할 수 있습니다.
"trustedExtensionAuthAccess": [ "<publisher1>.<extension1>", "<publisher2>.<extension2>" ]
"trustedExtensionAuthAccess": [
"<publisher1>.<extension1>",
"<publisher2>.<extension2>"
]
이는 GitHub, Microsoft 또는 OAuth가 필요한 기타 서비스와 같은 서비스에 액세스해야 하는 확장 기능이 있는 경우 특히 유용합니다. 이 필드에 확장 ID를 추가하면 이러한 토큰에 액세스할 수 있는 권한을 부여합니다.
devfile 또는 ConfigMap에서 변수를 정의할 수 있습니다. 필요에 더 적합한 옵션을 선택합니다. ConfigMap을 사용하면 변수가 모든 작업 공간에 전파되며 사용 중인 devfile마다 변수를 추가할 필요가 없습니다.
trustedExtensionAuthAccess
필드를 잘못 사용하는 경우 보안 위험이 발생할 수 있으므로 주의하십시오. 신뢰할 수 있는 확장에만 액세스 권한을 부여합니다.
Microsoft Visual Studio Code 편집기는 che-code
이미지 내에 번들되므로 작업 공간이 시작될 때 product.json
파일만 변경할 수 있습니다.
VSCODE_TRUSTED_EXTENSIONS 환경 변수를 정의합니다. devfile.yaml에서 변수를 정의하거나 변수를 사용하여 ConfigMap을 마운트하는 중에서 선택합니다.
devfile.yaml에서 VSCODE_TRUSTED_EXTENSIONS 환경 변수를 정의합니다.
env: - name: VSCODE_TRUSTED_EXTENSIONS value: "<publisher1>.<extension1>,<publisher2>.<extension2>"
env: - name: VSCODE_TRUSTED_EXTENSIONS value: "<publisher1>.<extension1>,<publisher2>.<extension2>"
Copy to Clipboard Copied! 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>'
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 Copied!
검증
-
변수 값은 작업 영역 시작 시 구문 분석되고 해당
trustedExtensionAuthAccess
섹션이product.json
에 추가됩니다.
6.3. 기본 확장 구성
기본 확장은 확장 프로그램 바이너리 .vsix
파일 경로를 DEFAULT_EXTENSIONS 환경 변수에 배치하여 지정된 사전 설치된 확장 집합입니다.
시작 후 편집기는 이 환경 변수를 확인하고 지정된 경우 확장의 경로를 가져와서 사용자를 방해하지 않고 백그라운드에 설치합니다.
기본 확장 구성은 편집기 수준에서 .vsix 확장을 설치하는 데 유용합니다.
여러 개의 확장 기능을 지정하려면 해당 확장을 together으로 구분합니다.
DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
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'
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 Copied!
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
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 Copied! 주의경우에 따라 curl은
.gzip
압축 파일을 다운로드할 수 있습니다. 이로 인해 확장 기능을 설치할 수 없습니다. 이 문제를 해결하려면 파일을 .vsix.gz 파일로 저장한 다음 gunzip 으로 압축을 풉니다. 이렇게 하면 .vsix.gz 파일이 압축 해제된 .vsix 파일로 대체됩니다.curl https://some-extension-url --location -o /tmp/extension.vsix.gz gunzip /tmp/extension.vsix.gz
curl https://some-extension-url --location -o /tmp/extension.vsix.gz gunzip /tmp/extension.vsix.gz
Copy to Clipboard Copied!
che-code
이미지에 확장 .vsix
바이너리 포함
편집기 이미지에 번들된 기본 확장과 ConfigMap에 정의된 DEFAULT_EXTENSIONS 환경 변수를 사용하면 devfile을 변경하지 않고 기본 확장을 적용할 수 있습니다.
다음 단계에 따라 편집기 이미지에 필요한 확장을 추가합니다.
프로세스
-
디렉토리를 만들고 이 디렉토리에 선택한
.vsix
확장을 배치합니다. 다음 콘텐츠를 사용하여 Dockerfile을 생성합니다.
inherit che-incubator/che-code:latest copy all .vsix files to /default-extensions directory add instruction to the script to copy default extensions to the working container
# 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 Copied! 이미지를 빌드한 다음 레지스트리로 푸시합니다.
docker build -t yourname/che-code:next . docker push yourname/che-code:next
$ docker build -t yourname/che-code:next . $ docker push yourname/che-code:next
Copy to Clipboard Copied! 새 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'
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 Copied! yourname/che-code:next
이미지를 사용하여 작업 영역을 생성합니다. 먼저 대시보드를 열고 왼쪽의 Create Workspace 탭으로 이동합니다.- 편집기 선택기 섹션에서 편집기 정의 사용 드롭다운을 확장하고 편집기 URI를 편집기 이미지로 설정합니다.
- 샘플을 클릭하거나 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 인스턴스.
프로세스
- OpenShift 웹 콘솔에서 .
- 설치된 Operator 목록에서 Red Hat OpenShift Dev Spaces 를 클릭합니다.
- 서브스크립션 탭으로 이동합니다.
-
자동
또는 수동으로 업데이트 승인 전략을구성합니다
.
추가 리소스
8.3. OpenShift 웹 콘솔을 사용하여 Dev Spaces 업그레이드
OpenShift 웹 콘솔의 Red Hat Ecosystem Catalog에서 Red Hat OpenShift Dev Spaces Operator를 사용하여 이전 마이너 버전에서 업그레이드를 수동으로 승인할 수 있습니다.
사전 요구 사항
- 클러스터 관리자의 OpenShift 웹 콘솔 세션입니다. 웹 콘솔 액세스를 참조하십시오.
- Red Hat Ecosystem Catalog를 사용하여 설치한 OpenShift Dev Spaces 인스턴스입니다.
-
서브스크립션의 승인 전략은
수동
입니다. 8.2절. “업데이트 승인 전략 지정”을 참조하십시오.
프로세스
- 보류 중인 Red Hat OpenShift Dev Spaces Operator 업그레이드를 수동으로 승인합니다. 보류 중인 Operator 업그레이드 수동 승인을 참조하십시오.
검증 단계
- OpenShift Dev Spaces 인스턴스로 이동합니다.
- 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 관리 툴 설치” 을 참조하십시오.
프로세스
- 실행 중인 모든 CodeReady Workspaces 3.1 작업 공간에 대해 변경 사항을 저장하고 Git 리포지토리로 내보냅니다.
- CodeReady Workspaces 3.1 인스턴스에서 모든 작업 공간을 종료합니다.
OpenShift Dev Spaces 업그레이드:
dsc server:update -n openshift-devspaces
$ dsc server:update -n openshift-devspaces
Copy to Clipboard Copied! 참고느린 시스템 또는 인터넷 연결의 경우
--k8spodwaittimeout=1800000
플래그 옵션을 추가하여 Pod 시간 초과 기간을 1800000ms 이상으로 확장합니다.
검증 단계
- OpenShift Dev Spaces 인스턴스로 이동합니다.
- 3.18 버전 번호는 페이지 하단에 표시됩니다.
8.5. 제한된 환경에서 Dev Spaces 업그레이드
이 섹션에서는 Red Hat OpenShift Dev Spaces를 업그레이드하고 제한된 환경에서 CLI 관리 툴을 사용하여 마이너 버전 업데이트를 수행하는 방법을 설명합니다.
사전 요구 사항
-
OpenShift Dev Spaces 인스턴스는
openshift-devspaces
프로젝트의dsc --installer operator
방법을 사용하여 OpenShift에 설치되었습니다. 3.1.4절. “제한된 환경에서 Dev Spaces 설치”을 참조하십시오.
- OpenShift 클러스터에는 최소 64GB의 디스크 공간이 있습니다.
- OpenShift 클러스터는 제한된 네트워크에서 작동할 준비가 되어 있습니다. 제한된 네트워크에서 연결이 끊긴 설치 미러링 및 Operator Lifecycle Manager 사용을 참조하십시오.
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. OpenShift CLI 시작하기를 참조하십시오. -
registry.redhat.io
Red Hat Ecosystem Catalog에 대한 활성 oc
-
opm
.opm
CLI 설치를 참조하십시오. -
jq
.jq
다운로드를 참조하십시오. -
podman
. Podman 설치 지침을 참조하십시오. -
Skopeo
버전 1.6 이상. Skopeo 설치를 참조하십시오. -
프라이빗 Docker 레지스트리에 대한 관리자 액세스 권한이 있는 활성
skopeo
세션입니다. 레지스트리에 인증하고 연결이 끊긴 설치의 이미지 미러링. -
OpenShift Dev Spaces 버전 3.18용 DSC.
2.2절. “dsc 관리 툴 설치”을 참조하십시오.
프로세스
미러링 스크립트를 다운로드하여 실행하여 사용자 정의 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>"
$ 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 Copied! - 1
- 이미지를 미러링할 프라이빗 Docker 레지스트리
- CodeReady Workspaces 3.1 인스턴스에서 실행 중인 모든 작업 영역에서 변경 사항을 저장하고 Git 리포지토리로 내보냅니다.
- CodeReady Workspaces 3.1 인스턴스에서 모든 작업 공간을 중지합니다.
다음 명령을 실행합니다.
dsc server:update --che-operator-image="$TAG" -n openshift-devspaces --k8spodwaittimeout=1800000
$ dsc server:update --che-operator-image="$TAG" -n openshift-devspaces --k8spodwaittimeout=1800000
Copy to Clipboard Copied!
검증 단계
- OpenShift Dev Spaces 인스턴스로 이동합니다.
- 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에 대한 여러 항목 또는 Replacing 및 Pending (보류 중)에 있는 하나의 항목이 표시됩니다.
프로세스
-
실패한 Pod가 포함된
devworkspace-controller
네임스페이스를 삭제합니다. 변환 전략을
None
으로 설정하고 전체Webhook
섹션을 제거하여DevWorkspace
및DevWorkspaceTemplate
CRD(Custom Resource Definitions)를 업데이트합니다.spec: ... conversion: strategy: None status: ...
spec: ... conversion: strategy: None status: ...
Copy to Clipboard Copied! 작은 정보DevWorkspace
DevWorkspaceTemplate
CRD를 찾고 편집할 수 있습니다.참고DevWorkspaceOperatorConfig
및DevWorkspaceRouting
CRD에는 기본적으로 변환 전략이None
으로 설정되어 있습니다.Dev Workspace Operator 서브스크립션을 제거합니다.
oc delete sub devworkspace-operator \ -n openshift-operators
$ oc delete sub devworkspace-operator \ -n openshift-operators
1 Copy to Clipboard Copied! - 1
OpenShift-operators
또는 Dev Workspace Operator가 설치된 OpenShift 프로젝트입니다.
Dev Workspace Operator CSV를 < devworkspace_operator.vX.Y.Z> 형식으로 가져옵니다.
oc get csv | grep devworkspace
$ oc get csv | grep devworkspace
Copy to Clipboard Copied! 각 Dev Workspace Operator CSV를 제거합니다.
oc delete csv <devworkspace_operator.vX.Y.Z> \ -n openshift-operators
$ oc delete csv <devworkspace_operator.vX.Y.Z> \ -n openshift-operators
1 Copy to Clipboard Copied! - 1
OpenShift-operators
또는 Dev Workspace Operator가 설치된 OpenShift 프로젝트입니다.
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 startingCSV: devworkspace-operator.v0.32.0 EOF
$ 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 Copied! - 1
자동
또는수동
.
중요installPlanApproval: Manual
의 경우 OpenShift 웹 콘솔의 관리자 화면에서 → 로 이동하여 Dev Workspace Operator: → .- OpenShift 웹 콘솔의 관리자 화면에서 로 이동하여 Dev Workspace Operator 의 성공 상태를 확인합니다.
9장. Dev Spaces 설치 제거
OpenShift Dev Spaces를 설치 제거하면 모든 OpenShift Dev Spaces 관련 사용자 데이터가 제거됩니다!
oc
를 사용하여 OpenShift Dev Spaces 인스턴스를 설치 제거합니다.
사전 요구 사항
-
DSC
. 2.2절. “dsc 관리 툴 설치” 을 참조하십시오.
프로세스
OpenShift Dev Spaces 인스턴스를 제거합니다.
dsc server:delete
$ dsc server:delete
Copy to Clipboard Copied!
--delete-namespace
옵션은 OpenShift Dev Spaces 네임스페이스를 제거합니다.
--delete-all
옵션은 Dev Workspace Operator 및 관련 리소스를 제거합니다.