Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

このコンテンツは選択した言語では利用できません。

Chapter 7. Configure server components

Mount OpenShift Secrets and ConfigMaps into OpenShift Dev Spaces containers to provide configuration files, credentials, and environment variables without modifying container images.

You can mount Secrets and ConfigMaps as files, as subpath volumes, or as environment variables. Each method requires specific annotations and labels on the OpenShift resource.

7.1. Mount a Secret or a ConfigMap as a file
リンクのコピー

Mount an OpenShift Secret or a ConfigMap as a file into an OpenShift Dev Spaces container to provide configuration files, certificates, or credentials without embedding them in the container image.

Prerequisites

  • You have a running instance of Red Hat OpenShift Dev Spaces.

Procedure

  1. Create a new OpenShift Secret or a ConfigMap in the OpenShift project where OpenShift Dev Spaces is deployed with the required labels: 

    apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
...

    where:

    kind
    Secret for a Secret or ConfigMap for a ConfigMap.
    <DEPLOYMENT_NAME>
    Target deployment: devspaces, devspaces-dashboard, devfile-registry, or plugin-registry.
    <OBJECT_KIND>
    secret for a Secret or configmap for a ConfigMap.

  2. Configure the annotation values. Annotations must indicate that the given object is mounted as a file:

    • che.eclipse.org/mount-as: file - Mounts an object as a file.

    • che.eclipse.org/mount-path: <TARGET_PATH> - To provide a required mount path.

      For a 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
...

      For a 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
...

  3. Add data items to the object. Each item name must match the desired file name mounted into the container.

    For a Secret: 

    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>

    For a ConfigMap: 

    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>

Verification

  • Verify that the file is mounted in the target container: 

    oc exec -n openshift-devspaces deploy/<DEPLOYMENT_NAME> -- ls <TARGET_PATH>/<FILE_NAME>

    Each data item name in the object corresponds to a file name at the mount path. For example, a data item named ca.crt with a mount path of /data results in a file at /data/ca.crt.

    Important

    If you update the Secret or ConfigMap data, re-create the object entirely to make the changes visible in the OpenShift Dev Spaces container.

7.2. Mount a Secret or a ConfigMap as a subPath
リンクのコピー

Mount an OpenShift Secret or a ConfigMap as a subPath to add individual files to a target directory without replacing existing contents. Use a subPath mount when the target directory already contains files that must be preserved.

Prerequisites

  • You have a running instance of Red Hat OpenShift Dev Spaces.

Procedure

  1. Create a new OpenShift Secret or a ConfigMap in the OpenShift project where OpenShift Dev Spaces is deployed with the required labels: 

    apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
...

    where:

    kind
    Secret for a Secret or ConfigMap for a ConfigMap.
    <DEPLOYMENT_NAME>
    Target deployment: devspaces, devspaces-dashboard, devfile-registry, or plugin-registry.
    <OBJECT_KIND>
    secret for a Secret or configmap for a ConfigMap.

  2. Configure the annotation values. Annotations must indicate that the given object is mounted as a subPath:

    • che.eclipse.org/mount-as: subpath - Mounts an object as a subPath.

    • che.eclipse.org/mount-path: <TARGET_PATH> - To provide a required mount path.

      For a 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
...

      For a 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
...

  3. Add data items to the object. Each item name must match the file name mounted into the container.

    For a Secret: 

    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>

    For a ConfigMap: 

    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>

Verification

  • Verify that the file is mounted in the target container: 

    oc exec -n openshift-devspaces deploy/<DEPLOYMENT_NAME> -- ls <TARGET_PATH>/<FILE_NAME>

    Each data item name in the object corresponds to a file name at the mount path. For example, a data item named ca.crt with a mount path of /data results in a file at /data/ca.crt.

    Important

    If you update the Secret or ConfigMap data, re-create the object entirely to make the changes visible in the OpenShift Dev Spaces container.

7.3. Mount a Secret or a ConfigMap as an environment variable
リンクのコピー

Mount an OpenShift Secret or a ConfigMap as an environment variable in an OpenShift Dev Spaces container. This injects configuration values such as credentials, API keys, or feature flags without modifying the container image.

Prerequisites

  • You have a running instance of Red Hat OpenShift Dev Spaces.

Procedure

  1. Create a new OpenShift Secret or a ConfigMap in the OpenShift project where OpenShift Dev Spaces is deployed with the required labels: 

    apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
...

    where:

    kind
    Secret for a Secret or ConfigMap for a ConfigMap.
    <DEPLOYMENT_NAME>
    Target deployment: devspaces, devspaces-dashboard, devfile-registry, or plugin-registry.
    <OBJECT_KIND>
    secret for a Secret or configmap for a ConfigMap.

  2. Configure the annotation values. Annotations must indicate that the given object is mounted as an environment variable:

    • che.eclipse.org/mount-as: env - Mounts an object as an environment variable.

    • che.eclipse.org/env-name: <FOO_ENV> - Provides the environment variable name, which is required to mount an object key value.

      For a Secret: 

      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
stringData:
  mykey: myvalue

      For a ConfigMap: 

      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

  3. If the object provides more than one data item, provide the environment variable name for each data key by using the che.eclipse.org/<key>_env-name annotation format.

    For a Secret: 

    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>

    For a ConfigMap: 

    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>

    The maximum length of annotation names in an OpenShift object is 63 characters, where 9 characters are reserved for a prefix that ends with /. This restricts the maximum length of the key that can be used for the object.

Verification

  • Verify that the environment variable is set in the target container: 

    oc exec -n openshift-devspaces deploy/<DEPLOYMENT_NAME> -- env | grep <ENV_NAME>

    For a single-key object, both the env-name value and the data key name become environment variables. For a multi-key object, only the per-key env-name values are provisioned.

    Important

    If you update the Secret or ConfigMap data, re-create the object entirely to make the changes visible in the OpenShift Dev Spaces container.

7.4. Advanced configuration options for OpenShift Dev Spaces server
リンクのコピー

Advanced configuration of the OpenShift Dev Spaces server allows you to set environment variables or override properties that are not exposed through the standard CheCluster Custom Resource fields.

Advanced configuration is necessary to:

  • Add environment variables not automatically generated by the Operator from the standard CheCluster Custom Resource fields.
  • Override the properties automatically generated by the Operator from the standard CheCluster Custom Resource fields.

The customCheProperties field, part of the CheCluster Custom Resource server settings, contains a map of additional environment variables to apply to the OpenShift Dev Spaces server component.

7.4.1. Override the default memory limit for workspaces
リンクのコピー

  • Configure the CheCluster Custom Resource. 

    apiVersion: org.eclipse.che/v2
kind: CheCluster
spec:
  components:
    cheServer:
      extraProperties:
        CHE_LOGS_APPENDERS_IMPL: json
Note

Previous versions of the OpenShift Dev Spaces Operator had a ConfigMap named custom to fulfill this role. If the OpenShift Dev Spaces Operator finds a configMap with the name custom, it adds the data into the customCheProperties field. The Operator then redeploys OpenShift Dev Spaces and deletes the custom configMap.

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る