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


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

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

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

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

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

프로세스

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

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

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

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

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

참고

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

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

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

프로세스

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

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

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

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

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

사전 요구 사항

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

프로세스

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

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

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

    spec:
      devEnvironments:
        trustedCerts:
          gitTrustedCertsConfigMapName: che-git-self-signed-cert

검증 단계

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

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

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

3.5.4. 작업 공간 nodeSelector 구성

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

프로세스

  1. NodeSelector 사용

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

    spec:
      devEnvironments:
        nodeSelector:
          key: value

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

  2. Taints 및 Tolerations 사용

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

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

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

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

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

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

3.5.5. 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>
    # [...]

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

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

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

프로세스

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

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

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

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: user-settings-xml
      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>
  2. 아래 Secret 을 생성하여 모든 사용자 네임스페이스에 복제합니다. 구성 가능성을 개선하기 위해 추가 라벨 및 주석을 추가하여 보안 을 사용자 지정할 수 있습니다. 기타 가능한 라벨 및 주석은 자동 마운트 볼륨, configmaps 및 시크릿 을 참조하십시오.

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

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

    kind: Secret
    apiVersion: v1
    metadata:
      name: user-certificates
      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: |
        ...
    참고

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

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

    kind: Secret
    apiVersion: v1
    metadata:
      name: user-env
      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
  3. 아래의 PersistentVolumeClaim 을 생성하여 모든 사용자 네임스페이스에 복제합니다.

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

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

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

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

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: 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
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.