4.5. 전역적으로 작업 공간 구성
이 섹션에서는 관리자가 전역적으로 작업 공간을 구성할 수 있는 방법에 대해 설명합니다.
4.5.1. 사용자가 유지할 수 있는 작업 공간 수 제한 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 사용자는 대시보드에 무제한의 작업 공간을 유지할 수 있지만 이 수를 제한하여 클러스터의 수요를 줄일 수 있습니다.
이 구성은 CheCluster 사용자 정의 리소스의 일부입니다.
spec:
devEnvironments:
maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>
- 1
- 사용자당 최대 작업 공간 수를 설정합니다. 기본값
-1을 사용하면 사용자가 무제한의 작업 공간을 유지할 수 있습니다. 양의 정수를 사용하여 사용자당 최대 작업 공간 수를 설정합니다.
프로세스
OpenShift Dev Spaces 네임스페이스의 이름을 가져옵니다. 기본값은
openshift-devspaces입니다.$ oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"maxNumberOfWorkspacesPerUser를 구성합니다.$ oc patch checluster/devspaces -n openshift-devspaces \1 --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'2
4.5.2. 모든 사용자가 동시에 실행할 수 있는 작업 공간 수 제한 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 모든 사용자는 무제한 작업 공간을 실행할 수 있습니다. 모든 사용자가 동시에 실행할 수 있는 작업 공간 수를 제한할 수 있습니다. 이 구성은 CheCluster 사용자 정의 리소스의 일부입니다.
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>}}}'1 - 1
- <
running_workspaces_limit> 값을선택합니다.
4.5.3. 사용자가 여러 작업 공간을 동시에 실행 가능 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 사용자는 한 번에 하나의 작업 공간만 실행할 수 있습니다. 사용자가 여러 작업 공간을 동시에 실행할 수 있습니다.
기본 스토리지 방법을 사용하는 경우 Pod가 다중 노드 클러스터의 노드에 분산되는 경우 사용자가 동시에 작업 공간을 실행할 때 문제가 발생할 수 있습니다. 사용자별 공통 스토리지 전략에서 작업별 스토리지 전략으로 전환하거나 임시 스토리지 유형을 사용하면 이러한 문제를 방지하거나 해결할 수 있습니다.
이 구성은 CheCluster 사용자 정의 리소스의 일부입니다.
spec:
devEnvironments:
maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
- 1
- 사용자당 동시에 실행 중인 최대 작업 공간 수를 설정합니다.
-1값을 사용하면 사용자가 무제한의 작업 공간을 실행할 수 있습니다. 기본값은1입니다.
프로세스
OpenShift Dev Spaces 네임스페이스의 이름을 가져옵니다. 기본값은
openshift-devspaces입니다.$ oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"maxNumberOfRunningWorkspacesPerUser를 구성합니다.$ oc patch checluster/devspaces -n openshift-devspaces \1 --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerUser": <running_workspaces_limit>}}}'2
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> \1 --from-literal=githost=<git_server_url> -n openshift-devspaces2 - 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-devspacesGit 리포지토리에 자체 서명된 인증서를 사용하도록 OpenShift Dev Spaces 피연산자를 구성합니다. 4.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.
spec: devEnvironments: trustedCerts: gitTrustedCertsConfigMapName: che-git-self-signed-cert
검증 단계
새 작업 공간을 만들고 시작합니다. 작업 영역에서 사용하는 모든 컨테이너는 자체 서명된 인증서가 있는 파일이 포함된 특수 볼륨을 마운트합니다. 컨테이너의
/etc/gitconfig파일에는 Git 서버 호스트(URL) 및http섹션의 인증서 경로에 대한 정보가 포함되어 있습니다( git-config에 대한 Git 문서 참조).예 4.22.
/etc/gitconfig파일의 내용[http "https://10.33.177.118:3000"] sslCAInfo = /etc/config/che-git-tls-creds/certificate
4.5.5. 작업 공간 nodeSelector 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 OpenShift Dev Spaces 작업 공간의 Pod에 nodeSelector 를 구성하는 방법을 설명합니다.
프로세스
NodeSelector 사용
OpenShift Dev Spaces는
CheCluster사용자 정의 리소스를 사용하여nodeSelector를 구성합니다.spec: devEnvironments: nodeSelector: key: value이 섹션에는 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
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"]1 } } } }'- 1
- 클라우드 개발 환경(CDE)을 시작하기 위해 승인된 URL의 배열입니다. CDE는 이러한 URL에서만 시작할 수 있습니다. 와일드카드
*는 URL에서 지원됩니다. 예를 들어https://example.com/*에서는example.com내의 모든 경로에서 CDE를 시작할 수 있습니다.