This documentation is for a release that is no longer maintained
See documentation for the latest supported version.管理ガイド
Red Hat OpenShift Dev Spaces 3.18 の管理
概要
第1章 セキュリティーのベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
より回復力のある開発環境を促進するのに役立つ Red Hat OpenShift Dev Spaces の主なベストプラクティスを概説します。
Red Hat OpenShift Dev Spaces は OpenShift 上で実行され、プラットフォームおよび、そのプラットフォーム上で機能する製品の基盤を提供します。OpenShift のドキュメントは、セキュリティ強化の第一歩となります。
OpenShift でのプロジェクト分離
OpenShift では、プロジェクトの分離は Kubernetes の namespace の分離に似ていますが、プロジェクトの概念を通じて実現されます。OpenShift のプロジェクトは、クラスター内のさまざまなアプリケーション、チーム、またはワークロード間の分離と連携を提供する最上位の組織単位です。
デフォルトでは、OpenShift Dev Spaces は各ユーザーに対して一意の <username>-devspaces
プロジェクトをプロビジョニングします。または、クラスター管理者は、OpenShift レベルでプロジェクトのセルフプロビジョニングを無効にし、CheCluster カスタムリソースで namespace の自動プロビジョニングをオフにすることもできます。
devEnvironments: defaultNamespace: autoProvision: false
devEnvironments:
defaultNamespace:
autoProvision: false
この設定では、OpenShift Dev Spaces に対して適切なアクセスを柔軟に選び提供できます。クラスター管理者は、各ユーザーのプロビジョニングを制御し、リソース制限やクォータを含むさまざまな設定を明示的に設定できます。プロジェクトプロビジョニングの詳細は、「プロジェクトの事前プロビジョニング」 を参照してください。
ロールベースアクセス制御 (RBAC)
デフォルトでは、OpenShift Dev Spaces Operator は以下の ClusterRole を作成します。
-
<namespace>-cheworkspaces-clusterrole
-
<namespace>-cheworkspaces-devworkspace-clusterrole
<namespace>
接頭辞は、Red Hat OpenShift Dev Spaces CheCluster CR が配置されているプロジェクト名に対応します。
ユーザーが初めて Red Hat OpenShift Dev Spaces にアクセスすると、対応する RoleBinding が <username>-devspaces
プロジェクトに作成されます。
ユーザーに namespace で使用する権限を付与できるすべてのリソースとアクションが以下にリストされています。
リソース | アクション |
---|---|
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" |
events | "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" |
apps/deployments | "get", "list", "watch", "create", "patch", "delete" |
apps/replicasets | "get", "list", "patch", "delete" |
namespace | "get", "list" |
projects | "get" |
devworkspace | "get", "create", "delete", "list", "update", "patch", "watch" |
devworkspacetemplates | "get", "create", "delete", "list", "update", "patch", "watch" |
各ユーザーには自分の namespace への権限のみが付与され、他のユーザーのリソースにアクセスできません。クラスター管理者は、ユーザーに追加の権限を追加できます。デフォルトで付与された権限を削除しないでください。
Red Hat OpenShift Dev Spaces ユーザー向けのクラスターロールの設定については 製品ドキュメント を参照してください。
ロールベースのアクセス制御の詳細は、OpenShift のドキュメント を参照してください。
開発環境の分離
開発環境の分離は、OpenShift プロジェクトを使用して実装されます。すべての開発者は、プロジェクトを 1 つ所有し、そのプロジェクトで以下の某ジェクトが作成および管理されます。
- IDE サーバーを含む Cloud Development Environment (CDE) Pod。
- Git トークン、SSH キー、Kubernetes トークンなどの開発者認証情報を含むシークレット。
- Git 名やメールなど、開発者固有の設定を持つ ConfigMap。
- CDE Pod が停止している場合でも、ソースコードなどのデータを保持するボリューム。
namespace 内のリソースへのアクセスは、その namespace を所有する開発者に制限する必要があります。別の開発者に読み取りアクセス権を付与することは、開発者の認証情報を共有することと同じなので、避けるべきです。
強化された認可
巨大なモノリス OpenShift クラスターを持つ代わりに、インフラストラクチャーを複数の「目的に合った」クラスターに分割することが現在の傾向として挙げられます。ただし、管理者はきめ細かいアクセスを提供して、特定の機能を特定のユーザーに制限する場合があります。
目的に適合した OpenShift クラスターとは、特定のユースケースまたはワークロードの要件と「目的に合った」特別に設計および設定されたクラスターを指します。管理するワークロードの特性に基づいて、パフォーマンス、リソース使用率、その他の要素を最適化するように調整されます。Red Hat OpenShift Dev Spaces の場合、このタイプのクラスターをプロビジョニングすることを推奨します。
この目的のために、さまざまなグループやユーザーに対するきめ細かなアクセス設定に使用できるオプションのプロパティーが、CheCluster カスタムリソースで利用できます。
-
allowUsers
-
allowGroups
-
denyUsers
-
denyGroups
以下は、アクセス設定の例です。
denyUsers
および denyGroup
カテゴリーのユーザーは Red Hat OpenShift Dev Spaces を使用できず、ユーザーダッシュボードにアクセスしようとすると警告が表示されます。
認証
認証された OpenShift ユーザーのみが Red Hat OpenShift Dev Spaces にアクセスできます。ゲートウェイ Pod は、ロールベースのアクセス制御 (RBAC) サブシステムを使用して、開発者がクラウド開発環境 (CDE) にアクセスする権限があるかどうかを判断します。
CDE Gateway コンテナーは、開発者の Kubernetes ロールをチェックします。ロールによって CDE Pod へのアクセスが許可されている場合は、開発環境への接続が許可されます。デフォルトでは、namespace の所有者だけが CDE Pod にアクセスできます。
namespace 内のリソースへのアクセスは、その namespace を所有する開発者に制限する必要があります。別の開発者に 読み取り
アクセス権を付与することは、開発者の認証情報を共有することと同じなので、避けるべきです。
セキュリティーコンテキストとセキュリティーコンテキストの制約
Red Hat OpenShift Dev Spaces は、CDE Pod コンテナーのセキュリティーコンテキストの仕様に SETGID
および SETUID
機能を追加します。
これにより、ユーザーは CDE 内からコンテナーイメージを構築することができます。
デフォルトでは、Red Hat OpenShift Dev Spaces は、ユーザーに特定の SecurityContextConstraint
(SCC) を割り当て、ユーザーがそのような機能を持つ Pod を起動できるようにします。この SCC は、デフォルトの restricted
SCC と比較してユーザーに多くの機能を付与しますが、anyuid
SCC と比較すると機能は少なくなります。このデフォルトの SCC は、OpenShift Dev Spaces namespace に事前に作成され、container-build
という名前が付けられています。
CheCluster カスタムリソースで次のプロパティーを設定すると、ユーザーに追加の機能と SCC が割り当てられなくなります。
spec: devEnvironments: disableContainerBuildCapabilities: true
spec:
devEnvironments:
disableContainerBuildCapabilities: true
リソースの割り当てと制限範囲
リソースクォータと制限範囲は、クラスター内での不正なアクターやリソースの乱用を防ぐために使用できる Kubernetes の機能です。具体的には、Pod とコンテナーのリソース消費制約を設定できます。リソースクォータと制限範囲を組み合わせて、プロジェクト固有のポリシーを適用し、不正なアクターが過剰なリソースを消費するのを防ぐことができます。
これらのメカニズムは、OpenShift クラスター内のリソース管理、安定性、公平性の向上に貢献します。リソースクォータ と 制限範囲 の詳細は、OpenShift のドキュメントを参照してください。
非接続環境
エアギャップされた、OpenShift の非接続クラスターとは、インターネットや外部ネットワークから分離された OpenShift クラスターを指します。この分離は、機密性の高いシステムや重要なシステムを潜在的なサイバー脅威から保護するというセキュリティー上の理由で行われることが多いです。エアギャップ環境では、クラスターは外部リポジトリーまたはレジストリーにアクセスしてコンテナーイメージ、更新、または依存関係をダウンロードできません。
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 拡張機能の管理の詳細は、公式ドキュメント を参照してください。
追加の拡張機能をインストールすると、潜在的なリスクが増大します。これらのリスクを最小限に抑えるには、信頼できるソースからの拡張機能のみをインストールし、定期的に更新するようにしてください。
シークレット
ユーザーの namespace に Kubernetes シークレットとして保存されている機密データ (Personal Access Token (PAT)、SSH 鍵など) を保持します。
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 管理ツールのインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Dev Spaces コマンドライン管理ツールである dsc
は、Microsoft Windows、Apple MacOS、および Linux にインストールできます。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! Toggle word wrap Toggle overflow
関連情報
2.3. アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
図2.1 Dev Workspace Operator を使用した高度な OpenShift Dev Spaces アーキテクチャー
OpenShift Dev Spaces は、3 つのコンポーネントのグループで実行されます。
- OpenShift Dev Spaces サーバーコンポーネント
- ユーザープロジェクトおよびワークスペースの管理。主な設定要素はユーザーダッシュボードで、ユーザーはここから自分のワークスペースを制御します。
- Dev ワークスペースの演算子
-
User ワークスペースの実行に必要な OpenShift オブジェクトを作成し、制御します。
Pod
、Services
、およびPersistentVolumes
が含まれます。 - User ワークスペース
- コンテナーベースの開発環境、IDE を含みます。
これらの OpenShift の機能のロールは中心的なものです。
- Dev ワークスペースのカスタムリソース
- ユーザーワークスペースを表す有効な OpenShift オブジェクト。OpenShift Dev Spaces で操作します。3 つのグループのコンポーネントのコミュニケーションチャンネルとなります。
- OpenShift のロールベースアクセスコントロール (RBAC)
- すべてのリソースへのアクセスを制御します。
2.3.1. サーバーコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces サーバーコンポーネントにより、マルチテナンシーとワークスペースの管理が確保されます。
図2.2 Dev Workspace Operator と対話する OpenShift Dev Spaces サーバーコンポーネント
2.3.1.1. Dev Spaces オペレーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces Operator は、OpenShift Dev Spaces サーバーコンポーネントの完全なライフサイクル管理を行います。これには、以下が含まれます。
CheCluster
カスタムリソース定義 (CRD)-
CheCluster
OpenShift オブジェクトを定義します。 - OpenShift Dev Spaces コントローラー
- Pod、サービス、永続ボリュームなどの OpenShift Dev Space インスタンスを実行するために必要な OpenShift オブジェクトを作成し、制御します。
CheCluster
カスタムリソース (CR)OpenShift Dev Spaces Operator を持つクラスターでは、
CheCluster
カスタムリソース (CR) を作成できます。OpenShift Dev Spaces オペレーターは、この OpenShift Dev Spaces インスタンス上で OpenShift Dev Spaces サーバーコンポーネントの完全なライフサイクル管理を行います。
2.3.1.2. Dev ワークスペースの演算子 リンクのコピーリンクがクリップボードにコピーされました!
Dev Workspace 演算子は、OpenShift を拡張して Dev Workspace のサポートを提供します。これには、以下が含まれます。
- Dev Workspace のカスタムリソース定義
- Devfile v2 仕様から Dev Workspace OpenShift オブジェクトを定義します。
- Dev Workspace コントローラー
- Pod、サービス、永続ボリュームなど、Dev Workspace の実行に必要な OpenShift オブジェクトを作成して制御します。
- Dev Workspace カスタムリソース
- Dev Workspace 演算子があるクラスターでは、Dev Workspace カスタムリソース (CR) を作成することができます。Dev Workspace CR は、Devfile を OpenShift で表現したものです。OpenShift クラスター内の User ワークスペースを定義します。
関連情報
2.3.1.3. ゲートウェイ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces ゲートウェイには、以下のロールがあります。
- 要求をルーティングする。Traefik を使用します。
- OpenID Connect(OIDC) でユーザーを認証する。OpenShift OAuth2 プロキシー を使用します。
- OpenShift ロールベースのアクセス制御 (RBAC) ポリシーを適用して、OpenShift Dev Spaces リソースへのアクセスを制御します。`kube-rbac-proxy` を使用します。
OpenShift Dev Spaces Operator はこれを che-gateway
Deployment として管理します。
以下へのアクセスを制御します。
図2.3 OpenShift Dev Spaces ゲートウェイと他のコンポーネントとの対話
関連情報
2.3.1.4. ユーザーダッシュボード リンクのコピーリンクがクリップボードにコピーされました!
ユーザーダッシュボードは、Red Hat OpenShift Dev Spaces のランディングページです。OpenShift Dev Spaces ユーザーは、ユーザーダッシュボードを参照してワークスペースにアクセスし、管理します。これは React のアプリケーションです。OpenShift Dev Spaces デプロイメントは、devspaces-dashboard
Deployment で起動します。
以下へのアクセス権が必要です。
- 「Dev Spaces サーバー」
- 「プラグインレジストリー」
- OpenShift API
図2.4 User ダッシュボードと他のコンポーネントとの対話
ユーザーがユーザーダッシュボードにワークスペースの起動を要求すると、ユーザーダッシュボードはこの一連のアクションを実行します。
- リポジトリー URL を 「Dev Spaces サーバー」 に送信し、ユーザーがリモート devfile からワークスペースを作成する際に devfile が返されることを想定します。
- ワークスペースを記述した devfile を読み込みます。
- 「プラグインレジストリー」 から追加のメタデータを収集します。
- その情報を Dev Workspace Custom Resource に変換します。
- OpenShift API を使用して、ユーザープロジェクトに Dev Workspace Custom Resource を作成します。
- Dev Workspace Custom Resource のステータスを監視します。
- 実行中のワークスペース IDE にユーザーをリダイレクトします。
2.3.1.5. Dev Spaces サーバー リンクのコピーリンクがクリップボードにコピーされました!
関連情報
OpenShift Dev Spaces サーバーの主な機能は次のとおりです。
- ユーザーネームスペースの作成
- ユーザーネームスペースに必要なシークレットと config map のプロビジョニング
- Git サービスプロバイダーとの統合による devfile の取得および認証
OpenShift Dev Spaces サーバーは、HTTP REST API を公開する Java Web サービスで、以下へのアクセスが必要です。
- Git サービスプロバイダー
- OpenShift API
図2.5 OpenShift Dev Spaces サーバーと他のコンポーネントとの対話
2.3.1.6. プラグインレジストリー リンクのコピーリンクがクリップボードにコピーされました!
各 OpenShift Dev Spaces ワークスペースは、特定のエディターと関連する拡張機能のセットを使用して起動します。OpenShift Dev Spaces のプラグインレジストリーは、使用可能なエディターとエディター拡張機能のリストを提供するものです。各エディターや拡張機能は、Devfile v2 に記載されています。
「ユーザーダッシュボード」 は、レジストリーの内容を読み取っています。
図2.6 他のコンポーネントとのプラグインレジストリーの相互作用
2.3.2. User ワークスペース リンクのコピーリンクがクリップボードにコピーされました!
図2.7 User ワークスペースと他のコンポーネントとの対話
User ワークスペースは、コンテナー内で動作する Web IDE です。
User ワークスペースは、Web アプリケーションです。コンテナー内で動作するマイクロサービスで構成されており、ブラウザー上で動作する最新の IDE のすべてのサービスを提供します。
- Editor
- 言語オートコンプリート
- 言語サーバー
- デバッグツール
- プラグイン
- アプリケーションのランタイム
ワークスペースは、ワークスペースコンテナーと有効なプラグイン、および関連する OpenShift コンポーネントを含む 1 つの OpenShift Deployment です。
- コンテナー
- ConfigMap
- サービス
- Endpoints
- Ingress またはルート
- シークレット
- 永続ボリューム (PV)
OpenShift Dev Spaces ワークスペースには、OpenShift 永続ボリューム (PV) で永続化されるプロジェクトのソースコードが含まれます。マイクロサービスは、この共有ディレクトリーに読み書き可能なアクセス権があります。
devfile v2 形式を使用して、OpenShift Dev Spaces ワークスペースのツールおよびランタイムアプリケーションを指定します。
以下の図は、OpenShift Dev Spaces ワークスペースとそのコンポーネントを実行する 1 つを示しています。
図2.8 OpenShift Dev Spaces ワークスペースコンポーネント
この図では、実行中のワークスペースが 1 つあります。
2.4. Dev Spaces リソース要件の計算 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces Operator、Dev Workspace Controller、およびユーザーワークスペースは Pod のセットで構成されます。Pod は、CPU とメモリーの制限と要求のリソース消費に影響します。
example devfile への次のリンクは、上流コミュニティーからの資料へのポインターです。この資料は、利用可能な最新のコンテンツと最新のベストプラクティスを表しています。これらのヒントは Red Hat の QE 部門によってまだ精査されておらず、広範なユーザーグループによってまだ証明されていません。この情報は慎重に使用してください。'実稼働' 目的ではなく、教育および '開発' 目的で使用するのが最適です。
手順
開発環境の定義に使用される devfile に依存するワークスペースのリソース要件を特定します。これには、devfile の
components
セクションで明示的に指定されたワークスペースコンポーネントの識別が含まれます。以下は、次のコンポーネントを含む devfile の例 です。
例2.1
tools
devfile の
tools
コンポーネントは、以下の要求および制限を定義します。memoryLimit: 6G memoryRequest: 512M cpuRequest: 1000m cpuLimit: 4000m
memoryLimit: 6G memoryRequest: 512M cpuRequest: 1000m cpuLimit: 4000m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワークスペースの起動中、内部
che-gateway
コンテナーには次のリクエストと制限が暗黙的にプロビジョニングされます。memoryLimit: 256M memoryRequest: 64M cpuRequest: 50m cpuLimit: 500m
memoryLimit: 256M memoryRequest: 64M cpuRequest: 50m cpuLimit: 500m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
各ワークスペースに必要なリソースの合計を計算します。複数の devfile を使用する場合は、予想されるすべての devfile に対してこの計算を繰り返します。
例2.2 前の手順の example devfile のワークスペース要件
Expand 目的 Pod コンテナー名 メモリー制限 メモリーリクエスト CPU limit CPU request 開発者ツール
workspace
tools
6 GiB
512 MiB
4000 m
1000 m
OpenShift Dev Spaces ゲートウェイ
workspace
che-gateway
256 MiB
64 MiB
500 m
50 m
合計
6.3 GiB
576 MiB
4500 m
1050 m
- ワークスペースごとに計算されたリソースに、すべてのユーザーが同時に実行すると予想されるワークスペースの数を掛けます。
OpenShift Dev Spaces Operator、オペランド、および Dev Workspace Controller の要件の合計を計算します。
Expand 表2.1 OpenShift Dev Spaces Operator、オペランド、および Dev Workspace Controller のデフォルト要件 目的 Pod の名前 コンテナー名 メモリー制限 メモリーリクエスト CPU limit CPU request OpenShift Dev Spaces 演算子
devspaces-operator
devspaces-operator
256 MiB
64 MiB
500 m
100 m
OpenShift Dev Spaces Server
devspaces
devspaces-server
1 GiB
512 MiB
1000 m
100 m
OpenShift Dev Spaces Dashboard
devspaces-dashboard
devspaces-dashboard
256 MiB
32 MiB
500 m
100 m
OpenShift Dev Spaces Gateway
devspaces-gateway
traefik
4 GiB
128 MiB
1000 m
100 m
OpenShift Dev Spaces Gateway
devspaces-gateway
configbump
256 MiB
64 MiB
500 m
50 m
OpenShift Dev Spaces Gateway
devspaces-gateway
oauth-proxy
512 MiB
64 MiB
500 m
100 m
OpenShift Dev Spaces Gateway
devspaces-gateway
kube-rbac-proxy
512 MiB
64 MiB
500 m
100 m
devfile レジストリー
devfile-registry
devfile-registry
256 MiB
32 MiB
500 m
100 m
プラグインレジストリー
plugin-registry
plugin-registry
256 MiB
32 MiB
500 m
100 m
Dev Workspace Controller Manager
devworkspace-controller-manager
devworkspace-controller
1 GiB
100 MiB
1000 m
250 m
Dev Workspace Controller Manager
devworkspace-controller-manager
kube-rbac-proxy
該当なし
該当なし
該当なし
該当なし
Dev Workspace Webhook Server
devworkspace-webhook-server
webhook-server
300 MiB
20 MiB
200 m
100 m
Dev Workspace Operator Catalog
devworkspace-operator-catalog
registry-server
該当なし
50 MiB
該当なし
10 m
Dev Workspace Webhook Server
devworkspace-webhook-server
webhook-server
300 MiB
20 MiB
200 m
100 m
Dev Workspace Webhook Server
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 のインスタンスは、クラスターごとに 1 つだけデプロイできます。
3.1. クラウドでの Dev Spaces のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Dev Spaces をクラウドでデプロイして実行します。
前提条件
- OpenShift Dev Spaces をデプロイする OpenShift クラスター。
-
dsc
: Red Hat OpenShift Dev Spaces のコマンドラインツール。「dsc 管理ツールのインストール」 を参照してください。
3.1.1. クラウドでの OpenShift Dev Spaces のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
dsc
ツールを使用してクラウドで OpenShift Dev Spaces Server を起動するには、以下の手順に従ってください。
3.1.2. CLI を使用した OpenShift への Dev Spaces のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces を OpenShift にインストールできます。
前提条件
- OpenShift Container Platform
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。OpenShift CLI のスタートガイド を参照してください。 -
dsc
。「dsc 管理ツールのインストール」 を参照してください。
手順
オプション: この OpenShift クラスターに OpenShift Dev Spaces をデプロイした場合は、以前の OpenShift Dev Spaces インスタンスが削除されていることを確認してください。
dsc server:delete
$ dsc server:delete
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Dev Spaces インスタンスを作成します。
dsc server:deploy --platform openshift
$ dsc server:deploy --platform openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証手順
OpenShift Dev Spaces インスタンスのステータスを確認します。
dsc server:status
$ dsc server:status
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Dev Spaces クラスターインスタンスに移動します。
dsc dashboard:open
$ dsc dashboard:open
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.3. Web コンソールを使用した OpenShift への Dev Spaces のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインで OpenShift Dev Spaces をインストール できない場合は、OpenShift Web コンソールからインストールできます。
前提条件
- クラスター管理者による OpenShift Web コンソールセッション。Web コンソールへのアクセス を参照してください。
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。OpenShift CLI のスタートガイド を参照してください。 - 同じ OpenShift クラスターに繰り返しインストールする場合は、9章Dev Spaces のアンインストール に従って、以前の OpenShift Dev Spaces インスタンスをアンインストールしました。
手順
-
OpenShift Web コンソールの 管理者 ビューで、Operators → OperatorHub に移動し、
Red Hat OpenShift Dev Spaces
を検索します。 Red Hat OpenShift Dev Spaces Operator をインストールします。
ヒントWeb コンソールを使用した OperatorHub からのインストール を参照してください。
ImportantRed Hat OpenShift Dev Spaces Operator は、Dev Workspace Operator に依存します。Red Hat OpenShift Dev Spaces Operator を手動でデフォルト以外の namespace にインストールする場合は、Dev Workspace Operator も同じ namespace にインストールされていることを確認してください。これは、Operator Lifecycle Manager が、Red Hat OpenShift Dev Spaces Operator namespace 内の依存関係として Dev Workspace Operator をインストールしようとすることから、Dev Spaces Operator が別の namespace にインストールされている場合は、Dev Workspace Operator は 2 つの競合するインストールとなる可能性があるため、確認が必要となります。
クラスターに Web Terminal Operator をオンボードする場合は、両方とも Dev Workspace Operator に依存しているため、Red Hat OpenShift Dev Spaces Operator と同じインストール namespace を使用するようにしてください。Web Terminal Operator、Red Hat OpenShift Dev Spaces Operator、および Dev Workspace Operator は、同じ namespace にインストールする必要があります。
次のように、OpenShift で
openshift-devspaces
プロジェクトを作成します。oc create namespace openshift-devspaces
oc create namespace openshift-devspaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Operators → Installed Operators → Red Hat OpenShift Dev Spaces インスタンスの仕様 → Create CheCluster → YAML view に移動します。
-
YAML view で、
namespace: openshift-operators
をnamespace: openshift-devspaces
に置き換えます。 Create を選択します。
ヒントインストールされた Operator からのアプリケーションの作成 を参照してください。
検証
- Red Hat OpenShift Dev Spaces インスタンスの仕様 で、devspaces に移動し、Details タブに移動します。
- Message の下に None があることを確認します。これはエラーがないことを意味します。
- Red Hat OpenShift Dev Spaces URL で、OpenShift Dev Spaces インスタンスの URL が表示されるまで待ち、URL を開いて OpenShift Dev Spaces ダッシュボードを確認します。
- Resources タブで、OpenShift Dev Spaces デプロイメントのリソースとそのステータスを表示します。
3.1.4. 制限された環境での Dev Spaces のインストール リンクのコピーリンクがクリップボードにコピーされました!
制限されたネットワークで動作する OpenShift クラスターでは、パブリックリソースは利用できません。
ただし、OpenShift Dev Spaces をデプロイしてワークスペースを実行するには、以下のパブリックリソースが必要です。
- Operator カタログ
- コンテナーイメージ
- サンプルプロジェクト
これらのリソースを使用可能にするには、OpenShift クラスターからアクセス可能なレジストリー内のそれらのコピーに置き換えます。
前提条件
- OpenShift クラスターに、少なくとも 64 GB のディスクスペースがある。
- OpenShift クラスターは、制限されたネットワーク上で動作する準備ができている。非接続インストールミラーリングについて および ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。OpenShift CLI のスタートガイド を参照してください。 -
registry.redhat.io
Red Hat エコシステムカタログへのアクティブなoc
レジストリーセッション。Red Hat Container Registry authentication を参照してください。
-
opm
。opm
CLI のインストール を参照してください。 -
jq
。Downloadingjq
を参照してください。 -
podman
。Podman Installation Instructions を参照してください。 -
skopeo
バージョン 1.6 以降。Installing Skopeo を参照してください。 -
プライベート Docker レジストリーへの管理アクセス権を持つアクティブな
skopeo
セッション。レジストリーへの認証 および 非接続インストールのイメージのミラーリング を参照してください。 -
OpenShift Dev Spaces バージョン 3.18 の
dsc
。「dsc 管理ツールのインストール」を参照してください。
手順
ミラーリングスクリプトをダウンロードして実行し、カスタム Operator カタログをインストールし、関連するイメージをミラーリングします (prepare-restricted-environment.sh)。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- イメージがミラーリングされるプライベート Docker レジストリー
前の手順で
で che-operator-cr-patch.yaml
に指定した設定で OpenShift Dev Spaces をインストールします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Dev Spaces namespace からユーザープロジェクト内のすべての Pod への受信トラフィックを許可します。「ネットワークポリシーの設定」 を参照してください。
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! Toggle word wrap Toggle overflow 以下のドメインへのアクセスを許可するようにクラスタープロキシーを設定します。
.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! Toggle word wrap Toggle overflow
以下の IDE および CPU アーキテクチャーのサポートは、今後のリリースで計画されています。
IDE
- JetBrains IntelliJ IDEA Community Edition IDE (テクノロジープレビュー)
CPU アーキテクチャー
- IBM Power (ppc64le)
- IBM Z (s390x)
3.2. 完全修飾ドメイン名 (FQDN) の検索 リンクのコピーリンクがクリップボードにコピーされました!
組織の OpenShift Dev Spaces インスタンスの完全修飾ドメイン名 (FQDN) は、コマンドラインまたは OpenShift Web コンソールで取得できます。
次のように、OpenShift Web コンソールの Administrator ビューで、組織の OpenShift Dev Spaces インスタンスの FQDN を見つけることができます。Operators → Installed Operators → Red Hat OpenShift Dev Spaces instance Specification → 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! Toggle word wrap Toggle overflow
3.3. Dev Spaces をインストールするためのパーミッション リンクのコピーリンクがクリップボードにコピーされました!
さまざまな Kubernetes クラスターに Red Hat OpenShift Dev Spaces をインストールするために必要なパーミッションを説明します。
3.3.1. CLI を使用して OpenShift に Dev Spaces をインストールするためのパーミッション リンクのコピーリンクがクリップボードにコピーされました!
以下は、dsc を使用して OpenShift クラスターに OpenShift Dev Space をインストールするために必要な最小限のパーミッションセットです。
3.3.2. Web コンソールを使用して OpenShift に Dev Spaces をインストールするためのパーミッション リンクのコピーリンクがクリップボードにコピーされました!
以下は、Web コンソールを使用して OpenShift クラスターに OpenShift Dev Spaces をインストールするために必要な最小限のパーミッションのセットです。
第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
、dashboard
および imagePuller
) を設定するセクションが含まれています。
Red Hat OpenShift Dev Spaces Operator は、CheCluster
カスタムリソースを OpenShift Dev Spaces インストールの各コンポーネントで使用できる config map に変換します。
OpenShift プラットフォームは、設定を各コンポーネントに適用し、必要な Pod を作成します。OpenShift がコンポーネントの設定で変更を検知すると、Pod を適宜再起動します。
例4.1 OpenShift Dev Spaces サーバーコンポーネントの主なプロパティーの設定
-
cheServer
コンポーネントセクションで適切な変更を加えたCheCluster
カスタムリソース YAML ファイルを適用します。 -
Operator は、
che
ConfigMap
を生成します。 -
OpenShift は
ConfigMap
の変更を検出し、OpenShift Dev Spaces Pod の再起動をトリガーします。
関連情報
4.1.1. dsc を使用したインストール時に CheCluster カスタムリソースの設定 リンクのコピーリンクがクリップボードにコピーされました!
適切な設定で OpenShift Dev Space をデプロイするには、OpenShift Dev Space のインストール時に CheCluster
カスタムリソース YAML ファイルを編集します。それ以外の場合は、OpenShift Dev Spaces デプロイメントは Operator で設定されたデフォルト設定パラメーターを使用します。
前提条件
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。 -
dsc
。「dsc 管理ツールのインストール」 を参照してください。
手順
設定する
CheCluster
カスタムリソースのサブセットを含むche-operator-cr-patch.yaml
YAML ファイルを作成します。spec: <component>: <property_to_configure>: <value>
spec: <component>: <property_to_configure>: <value>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow
検証
設定されたプロパティーの値を確認します。
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! Toggle word wrap Toggle overflow
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! Toggle word wrap Toggle overflow - ファイルを保存して閉じ、変更を適用します。
検証
設定されたプロパティーの値を確認します。
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! Toggle word wrap Toggle overflow
4.1.3. CheCluster カスタムリソースフィールドの参照 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、CheCluster
カスタムリソースのカスタマイズに使用できるすべてのフィールドを説明します。
例4.2 最小の CheCluster
カスタムリソースの例。
プロパティー | 説明 | デフォルト |
---|---|---|
allowedSources | allowedSources は、ワークスペースを起動できる許可されたソースを定義します。 | |
containerBuildConfiguration | コンテナーのビルド設定。 | |
defaultComponents | DevWorkspaces に適用されるデフォルトコンポーネント。デフォルトコンポーネントは、Devfile にコンポーネントが含まれていない場合に使用します。 | |
defaultEditor |
一緒に作成するワークスペースのデフォルトエディター。プラグイン ID または URI を指定できます。プラグイン ID は | |
defaultNamespace | ユーザーのデフォルトの namespace。 | { "autoProvision": true, "template": "<username>-che"} |
defaultPlugins | DevWorkspaces に適用されるデフォルトのプラグイン。 | |
deploymentStrategy |
DeploymentStrategy は、既存のワークスペース Pod を新しい Pod に置き換えるために使用するデプロイメントストラテジーを定義します。利用可能なデプロイメントは | |
disableContainerBuildCapabilities |
コンテナービルド機能を無効にします。 | |
gatewayContainer | GatewayContainer の設定。 | |
ignoredUnrecoverableEvents | IgnoredUnrecoverableEvents は、起動中のワークスペースを失敗させるかどうかを決定するときに無視する必要がある Kubernetes イベント名のリストを定義します。一時的なクラスターの問題によって誤検知がトリガーされている場合 (たとえば、クラスターで 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 |
security | ワークスペースのセキュリティー設定。 | |
serviceAccount | ワークスペースの開始時に DevWorkspace オペレーターが使用する ServiceAccount。 | |
serviceAccountTokens | 投影されたボリュームとしてワークスペース Pod にマウントされる ServiceAccount トークンのリスト。 | |
startTimeoutSeconds | StartTimeoutSeconds は、ワークスペースが自動的に失敗するまでの開始にかかる最大期間 (秒単位) を決定します。指定しない場合、デフォルト値の 300 秒 (5 分) が使用されます。 | 300 |
storage | ワークスペースの永続ストレージ。 | { "pvcStrategy": "per-user"} |
tolerations | ワークスペース Pod の Pod 許容範囲によって、ワークスペース Pod を実行できる場所が制限されます。 | |
trustedCerts | 信頼できる証明書の設定。 | |
user | ユーザー設定 | |
workspacesPodAnnotations | WorkspacesPodAnnotations は、ワークスペース Pod の追加のアノテーションを定義します。 |
プロパティー | 説明 | デフォルト |
---|---|---|
autoProvision | ユーザー namespace の自動作成を許可するかどうかを示します。false に設定すると、クラスター管理者がユーザー namespace を事前に作成する必要があります。 | true |
template |
ユーザー namespace を事前に作成しない場合には、このフィールドは最初のワークスペースの起動時に作成される Kubernetes namespace を定義します。che-workspace-<username> など、 | "<username>-che" |
プロパティー | 説明 | デフォルト |
---|---|---|
editor |
デフォルトのプラグインを指定するエディター ID。プラグイン ID は | |
plugins | 指定されたエディターのデフォルトのプラグイン URI。 |
プロパティー | 説明 | デフォルト |
---|---|---|
env | コンテナーに設定する環境変数のリスト。 | |
image | コンテナーイメージ。Operator によって提供されるデフォルトのコンテナーイメージを使用するには、これを省略するか、空のままにします。 | |
imagePullPolicy |
イメージプルポリシーデフォルト値は、 | |
name | コンテナー名 | |
resources | このコンテナーに必要なコンピューティングリソース。 |
プロパティー | 説明 | デフォルト |
---|---|---|
perUserStrategyPvcConfig |
| |
perWorkspaceStrategyPvcConfig |
| |
pvcStrategy |
OpenShift Dev Spaces サーバーの永続ボリューム要求ストラテジー。サポートされているストラテジーは、 | "per-user" |
プロパティー | 説明 | デフォルト |
---|---|---|
claimSize | Persistent Volume Claim のサイズ。要求サイズを更新するには、要求サイズをプロビジョニングするストレージクラスがサイズ変更をサポートしている必要があります。 | |
storageClass | Persistent Volume Claim のストレージクラス。省略されるか、空のままの場合は、デフォルトのストレージクラスが使用されます。 |
プロパティー | 説明 | デフォルト |
---|---|---|
claimSize | Persistent Volume Claim のサイズ。要求サイズを更新するには、要求サイズをプロビジョニングするストレージクラスがサイズ変更をサポートしている必要があります。 | |
storageClass | Persistent Volume Claim のストレージクラス。省略されるか、空のままの場合は、デフォルトのストレージクラスが使用されます。 |
プロパティー | 説明 | デフォルト |
---|---|---|
disableWorkspaceCaBundleMount | デフォルトでは、Operator は 2 つのロケーション ('/public-certs' と '/etc/pki/ca-trust/extracted/pem') で、CA 証明書バンドルを含む 'ca-certs-merged' ConfigMap をユーザーのワークスペースに作成し、マウントします。'/etc/pki/ca-trust/extracted/pem' ディレクトリーは、システムが Red Hat で信頼できる認証局 (CentOS、Fedora など) に展開した CA 証明書を保存する場所です。このオプションは、引き続き '/public-certs' にマウントしながら、CA バンドルを '/etc/pki/ca-trust/extracted/pem' ディレクトリーにマウントすることを無効にします。 | |
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"} |
dashboard | OpenShift Dev Spaces インストールで使用されるダッシュボードに関連する設定。 | |
devWorkspace | DevWorkspace Operator の設定。 | |
devfileRegistry | OpenShift Dev Spaces インストールで使用される devfile レジストリーに関連する設定。 | |
imagePuller | Kubernetes Image Puller の設定。 | |
metrics | OpenShift Dev Spaces サーバーのメトリック設定。 | { "enable": true} |
pluginRegistry | OpenShift Dev Spaces インストールで使用されるプラグインレジストリーに関連する設定。 |
プロパティー | 説明 | デフォルト |
---|---|---|
clusterRoles |
OpenShift Dev Spaces ServiceAccount に割り当てられた追加の ClusterRoles。各ロールには、 | |
debug | OpenShift Dev Spaces サーバーのデバッグモードを有効にします。 | false |
deployment | デプロイメントオーバーライドオプション。 | |
extraProperties |
| |
logLevel |
OpenShift Dev Spaces サーバーのログレベル: | "INFO" |
proxy | Kubernetes クラスターのプロキシーサーバー設定。OpenShift クラスターに追加の設定は必要ありません。これらの設定を OpenShift クラスターに指定することで、OpenShift プロキシー設定をオーバーライドします。 |
プロパティー | 説明 | デフォルト |
---|---|---|
credentialsSecretName |
プロキシーサーバーの | |
nonProxyHosts |
プロキシーをバイパスして直接アクセスできるホストのリスト。ワイルドカードドメインを指定するには、次の形式 | |
ポート | プロキシーサーバーポート。 | |
url |
プロキシーサーバーの URL (プロトコル + ホスト名)。プロキシー設定が必要な場合にのみ使用してください。Operator は OpenShift クラスター全体のプロキシー設定を尊重し、カスタムリソースで |
プロパティー | 説明 | デフォルト |
---|---|---|
deployment | デプロイメントオーバーライドオプション。 | |
disableInternalRegistry | 内部プラグインレジストリーを無効にします。 | |
externalPluginRegistries | 外部プラグインレジストリー。 | |
openVSXURL | VSX レジストリー URL を開きます。省略した場合は、埋め込みインスタンスが使用されます。 |
プロパティー | 説明 | デフォルト |
---|---|---|
url | プラグインレジストリーのパブリック URL。 |
プロパティー | 説明 | デフォルト |
---|---|---|
deployment | 非推奨のデプロイメントオーバーライドオプション。 | |
disableInternalRegistry | 内部 devfile レジストリーを無効にします。 | |
externalDevfileRegistries | サンプルのすぐに使用できる devfile を提供する外部 devfile レジストリー。 |
プロパティー | 説明 | デフォルト |
---|---|---|
url | すぐに使用できるサンプルの devfile を提供する devfile レジストリーのパブリック UR。 |
プロパティー | 説明 | デフォルト |
---|---|---|
branding | Dashboard のブランディングリソース | |
deployment | デプロイメントオーバーライドオプション。 | |
headerMessage | ダッシュボードのヘッダーメッセージ。 | |
logLevel | ダッシュボードのログレベル。 | "ERROR" |
プロパティー | 説明 | デフォルト |
---|---|---|
表示 | ダッシュボードにメッセージを表示するように指示します。 | |
text | ユーザーダッシュボードに表示される警告メッセージ。 |
プロパティー | 説明 | デフォルト |
---|---|---|
enable |
コミュニティーでサポートされている Kubernetes Image Puller Operator をインストールして設定します。仕様を指定せずに値を | |
spec | CheCluster で Image Puller を設定するための Kubernetes Image 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 | Kubernetes シークレット。Base64 でエンコードされた GitHub OAuth クライアント ID と GitHub OAuth クライアントシークレットが含まれます。詳細は、https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-github/ を参照してください。 |
プロパティー | 説明 | デフォルト |
---|---|---|
endpoint |
GitLab サーバーのエンドポイント URL。 | |
secretName | Kubernetes シークレット。Base64 でエンコードされた GitHub アプリケーション ID と GitLab アプリケーションクライアントシークレットが含まれます。https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-gitlab/ を参照してください。 |
プロパティー | 説明 | デフォルト |
---|---|---|
endpoint |
Bitbucket サーバーのエンドポイント URL。 | |
secretName | Kubernetes シークレット。Base64 でエンコードされた Bitbucket OAuth 1.0 または OAuth 2.0 データが含まれます。詳細は、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 | Kubernetes シークレット。Base64 でエンコードされた Azure DevOps Service アプリケーション ID とクライアントシークレットが含まれます。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 が作成される namespace です。ラベルと組み合わせて、デフォルト以外の Ingress Controller によって提供されるルートを作成します。Kubernetes クラスターの場合、グローバル Ingress ドメインが含まれます。デフォルト値はありません。指定する必要があります。 | |
hostname | インストールされた OpenShift Dev Spaces サーバーのパブリックホスト名。 | |
ingressClassName |
IngressClassName は、IngressClass クラスターリソースの名前です。クラス名が | |
labels | Ingress (OpenShift プラットフォームのルート) に設定されるラベルを定義します。 | |
tlsSecretName |
Ingress TLS ターミネーションのセットアップに使用されるシークレットの名前。フィールドが空の文字列の場合、デフォルトのクラスター証明書が使用されます。シークレットには、 |
プロパティー | 説明 | デフォルト |
---|---|---|
advancedAuthorization |
高度な承認設定。Che へのアクセスを許可するユーザーとグループを決定します。ユーザーは、 | |
gateway | ゲートウェイ設定。 | { "configLabels": { "app": "che", "component": "che-gateway-config" }} |
identityProviderURL | アイデンティティープロバイダーサーバーの公開 URL。 | |
identityToken |
アップストリームに渡される ID トークン。サポートされるトークンには、 | |
oAuthAccessTokenInactivityTimeoutSeconds |
OpenShift 側で ID フェデレーションをセットアップするために使用される OpenShift | |
oAuthAccessTokenMaxAgeSeconds |
OpenShift 側で ID フェデレーションをセットアップするために使用される OpenShift | |
oAuthClientName |
OpenShift 側でアイデンティティーフェデレーションを設定するために使用される OpenShift | |
oAuthScope | アクセストークンのスコープ。このフィールドは、Kubernetes 専用に作成された OpenShift Dev Spaces インストールに固有であり、OpenShift では無視されます。 | |
oAuthSecret |
OpenShift 側でアイデンティティーフェデレーションを設定するために使用される OpenShift |
プロパティー | 説明 | デフォルト |
---|---|---|
configLabels | ゲートウェイ設定ラベル。 | { "app": "che", "component": "che-gateway-config"} |
deployment |
デプロイメントオーバーライドオプション。ゲートウェイのデプロイメントは複数のコンテナーで構成されているため、設定では次の名前で区別する必要があります。 | |
kubeRbacProxy | OpenShift Dev Spaces ゲートウェイ Pod 内の kube-rbac-proxy の設定。 | |
oAuthProxy | OpenShift Dev Spaces ゲートウェイ Pod 内の oauth-proxy の設定。 | |
traefik | OpenShift Dev Spaces ゲートウェイ Pod 内の Traefik の設定。 |
プロパティー | 説明 | デフォルト |
---|---|---|
hostname | イメージのプルに使用する別のコンテナーレジストリーの任意のホスト名または URL。この値は、OpenShift Dev Spaces デプロイメントに含まれるすべてのデフォルトのコンテナーイメージで定義されたコンテナーレジストリーのホスト名をオーバーライドします。これは、制限された環境で OpenShift Dev Spaces をインストールする場合にとくに役立ちます。 | |
organization | イメージのプルに使用する別のレジストリーのオプションのリポジトリー名。この値は、OpenShift Dev Spaces デプロイメントに含まれるすべてのデフォルトのコンテナーイメージで定義されたコンテナーレジストリー組織をオーバーライドします。これは、制限された環境で OpenShift Dev Spaces をインストールする場合にとくに役立ちます。 |
プロパティー | 説明 | デフォルト |
---|---|---|
containers | Pod に属するコンテナーのリスト。 | |
nodeSelector | ノードセレクターは、Pod を実行できるノードを制限します。 | |
securityContext | Pod を実行する必要があるセキュリティーオプション。 | |
tolerations | コンポーネント Pod の Pod toleration は、Pod を実行できる場所を制限します。 |
プロパティー | 説明 | デフォルト |
---|---|---|
env | コンテナーに設定する環境変数のリスト。 | |
image | コンテナーイメージ。Operator によって提供されるデフォルトのコンテナーイメージを使用するには、これを省略するか、空のままにします。 | |
imagePullPolicy |
イメージプルポリシーデフォルト値は、 | |
name | コンテナー名 | |
resources | このコンテナーに必要なコンピューティングリソース。 |
プロパティー | 説明 | デフォルト |
---|---|---|
limits | 許可されるコンピューティングリソースの最大量を説明します。 | |
request | 必要なコンピューティングリソースの最小量を説明します。 |
プロパティー | 説明 | デフォルト |
---|---|---|
cpu |
CPU、コア単位。(500m = 0.5 コア) 値が指定されていない場合は、コンポーネントに応じてデフォルト値が設定されます。値が | |
memory |
メモリー (バイト単位)。(500Gi = 500GiB = 500 * 1024 * 1024 * 1024) 値が指定されていない場合は、コンポーネントに応じてデフォルト値が設定されます。値が |
プロパティー | 説明 | デフォルト |
---|---|---|
cpu |
CPU、コア単位。(500m = 0.5 コア) 値が指定されていない場合は、コンポーネントに応じてデフォルト値が設定されます。値が | |
memory |
メモリー (バイト単位)。(500Gi = 500GiB = 500 * 1024 * 1024 * 1024) 値が指定されていない場合は、コンポーネントに応じてデフォルト値が設定されます。値が |
プロパティー | 説明 | デフォルト |
---|---|---|
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 で実行している場合は、ルートの自動的に解決されたベースドメインです。 |
4.2. プロジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces は、ユーザーごとに、プロジェクト内のワークスペースを分離します。OpenShift Dev Spaces は、ラベルとアノテーションの存在によってユーザープロジェクトを識別します。ワークスペースを起動する際に必要なプロジェクトが存在しない場合、OpenShift Dev Spaces はテンプレート名を使用してプロジェクトを作成します。
OpenShift Dev Spaces の動作は、次の方法で変更できます。
4.2.1. プロジェクト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces がワークスペース起動時に必要なプロジェクトを作成するために使用するプロジェクト名テンプレートを設定できます。
有効なプロジェクト名テンプレートは、次の規則に従います。
-
<username>
または<userid>
プレースホルダーは必須です。 -
ユーザー名と ID に無効な文字を含めることはできません。ユーザー名または ID のフォーマットが OpenShift オブジェクトの命名規則と互換性がない場合、OpenShift Dev Spaces は、互換性のない文字を
-
記号に置き換えてユーザー名や ID を有効な名前に変更します。 -
OpenShift Dev Spaces は、
<userid>
プレースホルダーを 14 文字の文字列と判断し、ID が衝突しないようにランダムな 6 文字の接尾辞を追加します。結果は、再利用のためにユーザー設定に保存されます。 - Kubernetes は、プロジェクト名の長さを 63 文字に制限しています。
- OpenShift は、長さをさらに 49 文字に制限しています。
手順
CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。spec: components: devEnvironments: defaultNamespace: template: <workspace_namespace_template_>
spec: components: devEnvironments: defaultNamespace: template: <workspace_namespace_template_>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.3 ユーザーワークスペースプロジェクト名テンプレートの例
Expand ユーザーワークスペースプロジェクト名テンプレート 結果のプロジェクト例 <username>-devspaces
(デフォルト)user1-devspaces
<userid>-namespace
cge1egvsb2nhba-namespace-ul1411
<userid>-aka-<username>-namespace
cgezegvsb2nhba-aka-user1-namespace-6m2w2b
4.2.2. プロジェクトの事前プロビジョニング リンクのコピーリンクがクリップボードにコピーされました!
自動プロビジョニングに依存するのではなく、ワークスペースプロジェクトを事前にプロビジョニングできます。ユーザーごとに手順を繰り返します。
手順
CheCluster
レベルでの自動 namespace プロビジョニングを無効にします。devEnvironments: defaultNamespace: autoProvision: false
devEnvironments: defaultNamespace: autoProvision: false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のラベルとアノテーションを使用して、<username> ユーザーの <project_name> プロジェクトを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 選択したプロジェクト名を使用します。
4.2.3. ユーザー namespace の設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、OpenShift Dev Spaces を使用して ConfigMaps
、Secrets
、PersistentVolumeClaim
、およびその他の Kubernetes オブジェクトを openshift-devspaces
namespace から多数のユーザー固有の namespace にレプリケートするプロセスを説明します。OpenShift Dev Spaces は、共有認証情報、設定ファイル、証明書などの重要な設定データのユーザー namespace への同期を自動化します。
openshift-devspaces namespace の Kubernetes リソースに変更を加えると、OpenShift Dev Spaces はすべてのユーザー namespace にわたって変更を直ちに複製します。逆に、Kubernetes リソースがユーザー namespace で変更されると、OpenShift Dev Spaces は変更を直ちに元に戻します。
手順
以下の
ConfigMap
を作成して、すべてのユーザー namespace に複製します。設定可能性を高めるために、追加のラベルとアノテーションを追加してConfigMap
をカスタマイズできます。その他の可能なラベルとアノテーションは、ボリューム、configmap、シークレットの自動マウント を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.4 ユーザーワークスペースに
settings.xml
ファイルをマウントCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
Secret
を作成して、それをすべてのユーザー namespace に複製します。設定可能性を高めるために、追加のラベルとアノテーションを追加してSecret
をカスタマイズできます。その他の可能なラベルとアノテーションは、ボリューム、configmap、シークレットの自動マウント を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.5 ユーザーワークスペースに証明書をマウントする
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ワークスペースの起動時に
update-ca-trust
コマンドを実行して証明書をインポートします。これは手動で実行することも、devfile のpostStart
イベントにこのコマンドを追加することで実行することもできます。devfile でのイベントバインディングの追加 を参照してください。例4.6 環境変数をユーザーワークスペースにマウントする
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
PersistentVolumeClaim
を作成して、それをすべてのユーザー namespace に複製します。設定可能性を高めるために、追加のラベルとアノテーションを追加して
PersistentVolumeClaim
をカスタマイズできます。その他の可能なラベルとアノテーションは、ボリューム、configmap、シークレットの自動マウント を参照してください。PersistentVolumeClaim
を変更するには、一度削除し、openshift-devspaces namespace に新しいものを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.7
PersistentVolumeClaim
をユーザーワークスペースにマウントCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Kubernetes Engine を利用するには、
Template
オブジェクトを作成して、各ユーザー namespace 間でテンプレート内に定義されたすべてのリソースをレプリケートできます。前述の
ConfigMap
、Secret
、およびPersistentVolumeClaim
とは別に、Template
オブジェクトには以下を含むことができます。-
LimitRange
-
NetworkPolicy
-
ResourceQuota
-
ロール
RoleBinding
Copy to Clipboard Copied! Toggle word wrap Toggle overflow parameters
はオプションであり、使用可能なパラメーターを定義します。現時点では、PROJECT_NAME
およびPROJECT_ADMIN_USER
のみがサポートされています。PROJECT_NAME
は OpenShift Dev Spaces namespace の名前で、PROJECT_ADMIN_USER
は namespace の OpenShift Dev Spaces ユーザーです。オブジェクトの namespace 名は、同期中にユーザーの namespace 名に置き換えられます。
例4.8 Kubernetes リソースをユーザー namespace にレプリケートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Template Kubernetes リソースの作成は、OpenShift でのみサポートされます。
-
関連情報
- https://access.redhat.com/documentation/ja-jp/red_hat_openshift_dev_spaces/3.18/html-single/user_guide/index#end-user-guide:mounting-configmaps
- https://access.redhat.com/documentation/ja-jp/red_hat_openshift_dev_spaces/3.18/html-single/user_guide/index#end-user-guide:mounting-secrets
- https://access.redhat.com/documentation/ja-jp/red_hat_openshift_dev_spaces/3.18/html-single/user_guide/index#end-user-guide:requesting-persistent-storage-for-workspaces
- ボリューム、configmaps、シークレットの自動マウント
-
Template
の OpenShift API リファレンス - OpenShift プロジェクト作成の設定
4.3. サーバーコンポーネントの設定 リンクのコピーリンクがクリップボードにコピーされました!
4.3.1. シークレットまたは ConfigMap をファイルまたは環境変数としての Red Hat OpenShift Dev Spaces コンテナーへのマウント リンクのコピーリンクがクリップボードにコピーされました!
シークレットは、以下のような機密データを格納する OpenShift オブジェクトです。
- ユーザー名
- パスワード
- 認証トークン
(暗号化された形式)。
ユーザーは、機密データを含む OpenShift シークレットまたは設定を含む ConfigMap を、OpenShift Dev Spaces 管理コンテナーに次のようにマウントできます。
- ファイル
- 環境変数
マウントプロセスでは、標準の OpenShift マウントメカニズムを使用しますが、追加のアノテーションとラベル付けが必要です。
4.3.1.1. シークレットまたは ConfigMap を OpenShift Dev Spaces コンテナーにファイルとしてマウントする リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Red Hat OpenShift Dev Spaces の実行中のインスタンス
手順
OpenShift Dev Spaces がデプロイされている OpenShift プロジェクトに新しい OpenShift シークレットまたは ConfigMap を作成します。作成される予定のオブジェクトのラベルは、ラベルのセットと一致する必要があります。
-
app.kubernetes.io/part-of: che.eclipse.org
-
app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
<DEPLOYMENT_NAME>
には、以下のデプロイメントのいずれかを使用します。-
devspaces-dashboard
-
devfile-registry
-
plugin-registry
devspaces
および
-
<jasper_KIND>
は以下のいずれかになります。secret
あるいは、以下のような場合もあります。
-
configmap
-
例4.9 以下に例を示します。
あるいは、以下のような場合もあります。
アノテーションの値を設定します。アノテーションは、指定されたオブジェクトがファイルとしてマウントされていることを示す必要があります。
-
che.eclipse.org/mount-as: file
- オブジェクトをファイルとしてマウントするように指定します。 -
che.eclipse.org/mount-path: <TARGET_PATH>
- 必要なマウントパスを指定します。
-
例4.10 以下に例を示します。
あるいは、以下のような場合もあります。
OpenShift オブジェクトには複数の項目が含まれる可能性があり、その名前はコンテナーにマウントされる必要なファイル名と一致する必要があります。
例4.11 以下に例を示します。
あるいは、以下のような場合もあります。
これにより、ca.crt
という名前のファイルが OpenShift Dev Spaces コンテナーの /data
パスにマウントされます。
OpenShift Dev Spaces コンテナーでの変更を表示するには、シークレットまたは ConfigMap オブジェクト全体を再作成します。
4.3.1.2. シークレットまたは ConfigMap を subPath として OpenShift Dev Spaces コンテナーにマウントする リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Red Hat OpenShift Dev Spaces の実行中のインスタンス
手順
OpenShift Dev Spaces がデプロイされている OpenShift プロジェクトに新しい OpenShift シークレットまたは ConfigMap を作成します。作成される予定のオブジェクトのラベルは、ラベルのセットと一致する必要があります。
-
app.kubernetes.io/part-of: che.eclipse.org
-
app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
<DEPLOYMENT_NAME>
には、以下のデプロイメントのいずれかを使用します。-
devspaces-dashboard
-
devfile-registry
-
plugin-registry
devspaces
および
-
<jasper_KIND>
は以下のいずれかになります。secret
あるいは、以下のような場合もあります。
-
configmap
-
例4.12 以下に例を示します。
あるいは、以下のような場合もあります。
アノテーションの値を設定します。アノテーションは、指定されたオブジェクトが subPath としてマウントされていることを示す必要があります。
-
che.eclipse.org/mount-as: subpath
- オブジェクトが subPath としてマウントされていることを示します。 -
che.eclipse.org/mount-path: <TARGET_PATH>
- 必要なマウントパスを指定します。
-
例4.13 以下に例を示します。
あるいは、以下のような場合もあります。
OpenShift オブジェクトには、コンテナーにマウントされたファイル名と名前が一致する必要がある複数の項目を含めることができます。
例4.14 以下に例を示します。
あるいは、以下のような場合もあります。
これにより、ca.crt
という名前のファイルが OpenShift Dev Spaces コンテナーの /data
パスにマウントされます。
OpenShift Dev Spaces コンテナーでの変更を表示するには、シークレットまたは ConfigMap オブジェクト全体を再作成します。
4.3.1.3. シークレットまたは ConfigMap を環境変数として OpenShift Dev Spaces コンテナーにマウントする リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Red Hat OpenShift Dev Spaces の実行中のインスタンス
手順
OpenShift Dev Spaces がデプロイされている OpenShift プロジェクトに新しい OpenShift シークレットまたは ConfigMap を作成します。作成される予定のオブジェクトのラベルは、ラベルのセットと一致する必要があります。
-
app.kubernetes.io/part-of: che.eclipse.org
-
app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
<DEPLOYMENT_NAME>
には、以下のデプロイメントのいずれかを使用します。-
devspaces-dashboard
-
devfile-registry
-
plugin-registry
devspaces
および
-
<jasper_KIND>
は以下のいずれかになります。secret
あるいは、以下のような場合もあります。
-
configmap
-
例4.15 以下に例を示します。
あるいは、以下のような場合もあります。
アノテーションの値を設定します。アノテーションは、指定されたオブジェクトが環境変数としてマウントされていることを示す必要があります。
-
che.eclipse.org/mount-as: env
-: オブジェクトを環境変数としてマウントするように指定します。 -
che.eclipse.org/env-name: <FOOO_ENV>
: オブジェクトキー値のマウントに必要な環境変数名を指定します。
-
例4.16 以下に例を示します。
あるいは、以下のような場合もあります。
これにより、2 つの環境変数が
-
FOO_ENV
-
myvalue
OpenShift Dev Spaces コンテナーにプロビジョニングされている。
オブジェクトに複数のデータ項目がある場合、環境変数の名前は以下のようにそれぞれのデータキーに指定される必要があります。
例4.17 以下に例を示します。
あるいは、以下のような場合もあります。
これにより、2 つの環境変数が
-
FOO_ENV
-
OTHER_ENV
OpenShift Dev Spaces コンテナーにプロビジョニングされている。
OpenShift シークレットのアノテーション名の最大長さは 63 文字です。ここで、9 文字は、/
で終わる接頭辞用に予約されます。これは、オブジェクトに使用できるキーの最大長さの制限として機能します。
OpenShift Dev Spaces コンテナーでの変更を表示するには、シークレットまたは ConfigMap オブジェクト全体を再作成します。
4.3.2. Dev Spaces サーバーの高度な設定オプション リンクのコピーリンクがクリップボードにコピーされました!
以下のセクションでは、OpenShift Dev Spaces サーバーコンポーネントの詳細なデプロイメントおよび設定方法を説明します。
4.3.2.1. OpenShift Dev Spaces サーバーの詳細設定について リンクのコピーリンクがクリップボードにコピーされました!
以下のセクションでは、OpenShift Dev Spaces サーバーコンポーネントの詳細な設定方法を説明します。
詳細設定は以下を実行するために必要です。
-
標準の
CheCluster
カスタムリソースフィールドから Operator によって自動的に生成されない環境変数を追加します。 -
標準の
CheCluster
カスタムリソースフィールドから Operator によって自動的に生成されるプロパティーを上書きします。
CheCluster
Custom Resource server
設定の一部である customCheProperties
フィールドには、OpenShift Dev Spaces サーバーコンポーネントに適用する追加の環境変数のマップが含まれます。
例4.18 ワークスペースのデフォルトのメモリー制限の上書き
CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OpenShift Dev Spaces Operator の以前のバージョンには、このロールを果たすために custom
という名前の ConfigMap がありました。OpenShift Dev Spaces オペレーターが custom
という名前の configMap
を見つけると、それに含まれるデータを customCheProperties
フィールドに追加し、OpenShift Dev Spaces を再デプロイして、カスタム
configMap
を削除します。
4.4. 自動スケーリングの設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Dev Spaces の自動スケーリングのさまざまな側面を説明します。
4.4.1. Red Hat OpenShift Dev Spaces コンテナーのレプリカ数の設定 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes HorizontalPodAutoscaler
(HPA) を使用して OpenShift Dev Spaces オペランドのレプリカの数を設定するには、デプロイメント用の HPA
リソースを定義します。HPA
は指定されたメトリクスに基づいてレプリカの数を動的に調整します。
手順
ターゲットメトリクスと必要なレプリカ数を指定して、デプロイメント用の
HPA
リソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<deployment_name>
には、以下のデプロイメントのいずれかに対応します。-
devspaces
-
che-gateway
-
devspaces-dashboard
-
plugin-registry
-
devfile-registry
-
例4.19 devspaces デプロイメント用の HorizontalPodAutoscaler
を作成する
この例では、HPA は devspaces という名前のデプロイメントをターゲットにしており、レプリカは最小 2 つ、最大 5 つで、CPU 使用率に基づいてスケーリングされます。
4.4.2. マシンの自動スケーリングの設定 リンクのコピーリンクがクリップボードにコピーされました!
リソースのニーズに応じてノードの数を調整するようにクラスターを設定した場合は、OpenShift Dev Spaces ワークスペースのシームレスな操作を維持するために追加の設定が必要です。
Autoscaler がノードを追加および削除する場合、ワークスペースには特別な考慮が必要です。
autoscaler によって新しいノードが追加されている場合、ノードのプロビジョニングが完了するまで、ワークスペースの起動に通常よりも時間がかかることがあります。
逆に、ノードが削除される場合、ワークスペースの使用中に中断が発生し、保存されていないデータが失われる可能性を回避するために、ワークスペース Pod を実行しているノードは Autoscaler によって削除されないことが理想的です。
4.4.2.1. Autoscaler が新しいノードを追加する場合 リンクのコピーリンクがクリップボードにコピーされました!
新しいノードが追加されている間にワークスペースが適切に起動するようにするには、OpenShift Dev Spaces インストールに追加の設定を行う必要があります。
手順
CheCluster カスタムリソースで、Autoscaler が新しいノードをプロビジョニングするときにワークスペースが適切に起動できるように、次のフィールドを設定します。
spec: devEnvironments: startTimeoutSeconds: 600 ignoredUnrecoverableEvents: - FailedScheduling
spec: devEnvironments: startTimeoutSeconds: 600
1 ignoredUnrecoverableEvents:
2 - FailedScheduling
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.2.2. Autoscaler がノードを削除する場合 リンクのコピーリンクがクリップボードにコピーされました!
Autoscaler がノードを削除する必要がある場合にワークスペース Pod が削除されないようにするには、すべてのワークスペース Pod に "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
アノテーションを追加します。
手順
CheCluster カスタムリソースで、
cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
アノテーションをspec.devEnvironments.workspacesPodAnnotations
フィールドに追加します。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! Toggle word wrap Toggle overflow
検証手順
ワークスペースを起動し、ワークスペース 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! Toggle word wrap Toggle overflow
4.5. ワークスペースのグローバル設定 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、管理者がワークスペースをグローバルに設定する方法を説明します。
4.5.1. ユーザーが保持できるワークスペースの数を制限する リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、ユーザーはダッシュボードに無制限の数のワークスペースを保持できますが、この数を制限してクラスターの需要を減らすことができます。
この設定は、CheCluster
カスタムリソースの一部です。
spec: devEnvironments: maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>
spec:
devEnvironments:
maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>
- 1
- ユーザーごとのワークスペースの最大数を設定します。デフォルト値
-1
では、ユーザーは無制限の数のワークスペースを保持できます。ユーザーごとのワークスペースの最大数を設定するには、正の整数を使用します。
手順
OpenShift Dev Spaces namespace の名前を取得します。デフォルトは
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! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow
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! Toggle word wrap Toggle overflow - 1
<running_workspaces_limit>
の値を選択します。
4.5.3. ユーザーが複数のワークスペースを同時に実行できるようにする リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、ユーザーは一度に 1 つのワークスペースしか実行できません。ユーザーが複数のワークスペースを同時に実行できるようにすることができます。
デフォルトのストレージ方法を使用している際、マルチノードクラスター内のノード全体に Pod が分散されている場合は、ワークスペースを同時に実行すると問題が発生する可能性があります。ユーザーごとの common
ストレージストラテジーから per-workspace
ストレージストラテジーに切り替えるか、ephemeral
ストレージタイプを使用すると、これらの問題を回避または解決できます。
この設定は、CheCluster
カスタムリソースの一部です。
spec: devEnvironments: maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
spec:
devEnvironments:
maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
- 1
- ユーザーごとに同時に実行されるワークスペースの最大数を設定します。値
-1
を指定すると、ユーザーはワークスペースを無制限に実行できます。デフォルト値は1
です。
手順
OpenShift Dev Spaces namespace の名前を取得します。デフォルトは
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! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow
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! Toggle word wrap Toggle overflow - 1
- 自己署名証明書へのパス。
- 2
- Git サーバーの URL を指定するオプションのパラメーター (例:
https://git.example.com:8443
)。省略すると、自己署名証明書が HTTPS 経由のすべてのリポジトリーに使用されます。
注記-
証明書ファイルは、通常、以下のような Base64 ASCII ファイルとして保存されます。
.pem
,.crt
,.ca-bundle
.証明書ファイルを保持するすべてのConfigMap
はバイナリーデータ証明書ではなく Base64 ASCII 証明書を使用する必要があります。 -
証明書の信頼チェーンが必要です。
ca.crt
が認証局 (CA) によって署名されている場合は、CA 証明書がca.crt
ファイルに含まれている必要があります。
必要なラベルを 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! Toggle word wrap Toggle overflow Git リポジトリーに自己署名証明書を使用するように OpenShift Dev Spaces オペランドを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。
spec: devEnvironments: trustedCerts: gitTrustedCertsConfigMapName: che-git-self-signed-cert
spec: devEnvironments: trustedCerts: gitTrustedCertsConfigMapName: che-git-self-signed-cert
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証手順
新規ワークスペースを作成および開始します。ワークスペースによって使用されるすべてのコンテナーは、自己署名証明書のあるファイルを含む特殊なボリュームをマウントします。コンテナーの
/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! Toggle word wrap Toggle overflow
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! Toggle word wrap Toggle overflow このセクションには、nodeSelector ルールを形成するために、各 ノードラベル の
key=value
ペアのセットが含まれている必要があります。テイントおよび容認の使用
これは
nodeSelector
とは逆の働きをします。Pod がスケジュールされるノードを指定する代わりに、Pod がスケジュールされないノードを指定します。詳細は、https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration を参照してください。OpenShift Dev Spaces は、
CheCluster
カスタムリソースを使用してtolerations
を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
nodeSelector
は、OpenShift Dev Spaces のインストール時に設定する必要があります。これにより、既存のワークスペース PVC および Pod が異なるゾーンにスケジュールされることによってボリュームのアフィニティーの競合が生じ、既存のワークスペースが実行できなくなることを防ぐことができます。
大規模なマルチゾーンクラスターの異なるゾーンに Pod および PVC がスケジュールされないようにするには、PVC の作成プロセスを調整する追加の StorageClass
オブジェクトを作成します (allowedTopologies
フィールドに注目してください)。
CheCluster
カスタムリソースを通じて、新しく作成された StorageClass
の名前を OpenShift Dev Spaces に渡します。詳細は、「ストレージクラスの設定」 を参照してください。
4.5.6. クラウド開発環境に許可される URL の設定 リンクのコピーリンクがクリップボードにコピーされました!
許可された URL は、クラウド開発環境 (CDE) の開始を保護する上で重要な役割を果たし、認可されたソースからのみ起動できるようにします。*
などのワイルドカードサポートを利用することで、組織は柔軟な URL パターンを実装し、ドメイン内のさまざまなパス間で動的でセキュアな CDE の開始を可能にします。
許可されたソースを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラウド開発環境 (CDE) を起動するための認可された URL の配列。CDE は、これらの URL からのみ開始できます。ワイルドカード
*
は URL でサポートされます。たとえば、https://example.com/*
は、example.com
内の任意のパスから CDE を開始できるよう許可します。
4.6. ワークスペースの起動を迅速化するイメージのキャッシュ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces ワークスペースの起動時間のパフォーマンスを改善するには、Image Puller を使用して OpenShift クラスターのイメージの事前プルに使用できる OpenShift Dev Spaces に依存しないコンポーネントを使用します。
Image Puller は、関連する OpenShift Dev Spaces ワークスペースイメージを各ノードで事前にプルするように設定できる DaemonSet を作成する追加の OpenShift デプロイメントです。これらのイメージは、OpenShift Dev Spaces ワークスペースの起動時にすでに利用可能なため、ワークスペースの開始時間が改善されています。
Kubernetes Image Puller のインストール
Kubernetes Image Puller の設定
4.6.1. Kubernetes Image Puller のインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の手順に従って、さまざまなユースケース用に Kubernetes Image Puller をインストールします。
4.6.1.1. Kubernetes Image Puller のインストール リンクのコピーリンクがクリップボードにコピーされました!
4.6.1.2. CLI を使用した OpenShift への Image Puller のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift oc
管理ツールを使用して、OpenShift に Kubernetes Image Puller をインストールできます。
ImagePuller が oc
CLI でインストールされている場合は、CheCluster
カスタムリソースを介して設定することができません。
前提条件
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。OpenShift CLI のスタートガイド を参照してください。
手順
- ドキュメントに従って、プルする関連コンテナーイメージのリストを収集します。「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! Toggle word wrap Toggle overflow コンテナーのメモリー制限が
20Mi
の 20 ノードで 5 つのイメージをプルする場合、2000Mi
のメモリーが必要です。Image 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! Toggle word wrap Toggle overflow 以下のパラメーターを使用して、
app.yaml
、configmap.yaml
およびserviceaccount.yaml
OpenShift テンプレートを設定します。Expand 表4.37 app.yaml の Image 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
Expand 表4.38 configmap.yaml の Image 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
の値"{}"
Expand 表4.39 serviceaccount.yaml の Image Puller OpenShift テンプレートパラメーター 値 使用方法 デフォルト SERVICEACCOUNT_NAME
デプロイメントで作成され、使用される ServiceAccount の名前
kubernetes-image-puller
KIP_IMAGE
スリープバイナリーのコピー元である Image Puller イメージ
registry.redhat.io/devspaces/imagepuller-rhel8:latest
Image Puller をホストする OpenShift プロジェクトを作成します。
oc new-project <k8s-image-puller>
oc new-project <k8s-image-puller>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow テンプレートを処理してから適用し、Puller をインストールします。
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! Toggle word wrap Toggle overflow
検証手順
<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! Toggle word wrap Toggle overflow <kubernetes-image-puller>
ConfigMap
の値を確認します。oc get configmap <kubernetes-image-puller> --output yaml
oc get configmap <kubernetes-image-puller> --output yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.1.3. Web コンソールを使用した OpenShift への Image Puller のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Web コンソールを使用して、コミュニティーでサポートされている Kubernetes Image Puller Operator を OpenShift にインストールできます。
前提条件
- クラスター管理者による OpenShift Web コンソールセッション。Web コンソールへのアクセス を参照してください。
手順
- コミュニティーでサポートされている Kubernetes Image Puller Operator をインストールします。Web コンソールを使用した OperatorHub からのインストール を参照してください。
-
コミュニティーでサポートされている Kubernetes Image Puller Operator から
KubernetesImagePuller
オペランドを作成します。インストールされた Operator からのアプリケーションの作成 を参照してください。
4.6.2. Kubernetes Image Puller の設定 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、さまざまなユースケースで Kubernetes Image Puller を設定する手順を説明します。
4.6.2.1. Kubernetes Image Puller の設定 リンクのコピーリンクがクリップボードにコピーされました!
4.6.2.2. デフォルトの Dev Spaces イメージを事前にプルするように Image Puller の設定 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes Image Puller を設定して、デフォルトの OpenShift Dev Spaces イメージを事前にプルできます。Red Hat OpenShift Dev Spaces Operator は、事前にプルするイメージのリストを制御し、OpenShift Dev Spaces のアップグレード時にそれらを自動的に更新します。
前提条件
- 組織の OpenShift Dev Spaces インスタンスが Kubernetes クラスターにインストールされ、実行されている。
- Image Puller が Kubernetes クラスターにインストールされている。
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
OpenShift Dev Spaces イメージを事前にプルするように Image Puller を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.2.3. カスタムイメージを事前にプルするための Image Puller の設定 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes Image Puller を設定して、カスタムイメージを事前にプルすることができます。
前提条件
- 組織の OpenShift Dev Spaces インスタンスが Kubernetes クラスターにインストールされ、実行されている。
- Image Puller が Kubernetes クラスターにインストールされている。
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
カスタムイメージを事前にプルするように Image Puller を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- セミコロンで区切られたイメージのリスト
4.6.2.4. 追加のイメージを事前にプルするための Image Puller の設定 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes Image Puller を設定して、追加の OpenShift Dev Spaces イメージを事前にプルできます。
前提条件
- 組織の OpenShift Dev Spaces インスタンスが Kubernetes クラスターにインストールされ、実行されている。
- Image Puller が Kubernetes クラスターにインストールされている。
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
k8s-image-puller
namespace を作成します。oc create namespace k8s-image-puller
oc create namespace k8s-image-puller
Copy to Clipboard Copied! Toggle word wrap Toggle overflow KubernetesImagePuller
カスタムリソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- セミコロンで区切られたイメージのリスト
4.6.3. Kubernetes Image Puller のデフォルトイメージリストの取得 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes Image Puller で使用されるデフォルトのイメージリストを取得する方法を説明します。これは、Image Puller を確認して、事前にこれらのイメージのサブセットのみを使用するように設定する管理者に役立ちます。
前提条件
- 組織の OpenShift Dev Spaces インスタンスが Kubernetes クラスターにインストールされ、実行されている。
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
OpenShift Dev Spaces Operator がデプロイされている namespace を見つけます。
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! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow
4.7. 可観測性の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces 可観測性機能を設定するには、以下を参照してください。
4.7.1. Woopra telemetry プラグイン リンクのコピーリンクがクリップボードにコピーされました!
Woopra Telemetry プラグイン は、Telemetry を Red Hat OpenShift Dev Spaces インストールから Segment および Woopra に送信するためにビルドされたプラグインです。このプラグインは、Red Hat がホストする Eclipse Che で使用されますが、Red Hat OpenShift Dev Spaces デプロイメントではこのプラグインを利用できます。有効な Woopra ドメインおよびセグメント書き込みキー以外の依存関係はありません。プラグインである plugin.yaml の devfile v2 には、プラグインに渡すことのできる 4 つの環境変数があります。
-
WOOPRA_DOMAIN
- イベントの送信先となる Woopra ドメイン。 -
SEGMENT_WRITE_KEY
- セグメントおよび Woopra にイベントを送信するための書き込みキー。 -
WOOPRA_DOMAIN_ENDPOINT
- Woopra ドメインを直接渡さない場合、プラグインは Woopra ドメインを返す指定の HTTP エンドポイントからこれを取得します。 -
SEGMENT_WRITE_KEY_ENDPOINT
- セグメント書き込みキーを直接渡さない場合、プラグインはセグメント書き込みキーを返す指定された HTTP エンドポイントからこれを取得します。
Red Hat OpenShift Dev Spaces インストールで Woopra プラグインを有効にするには、以下を実行します。
手順
plugin.yaml
devfile v2 ファイルを、環境変数が正しく設定された HTTP サーバーにデプロイします。CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.2. Telemetry プラグインの作成 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、AbstractAnalyticsManager
を拡張し、以下のメソッドを実装する AnalyticsManager
クラスを作成する方法を説明します。
-
isEnabled()
: Telemetry バックエンドが正しく機能しているかどうかを判断します。これは、常にtrue
を返すか、接続プロパティーがない場合にfalse
を返すなど、より複雑なチェックがあることを意味します。 -
destroy()
: Telemetry バックエンドをシャットダウンする前に実行されるクリーンアップ方法。このメソッドは、WORKSPACE_STOPPED
イベントを送信します。 -
onActivity()
- 特定のユーザーに対して一部のアクティビティーが依然として実行されていることを通知します。これは主にWORKSPACE_INACTIVE
イベントを送信するために使用されます。 -
onEvent()
- Telemetry イベントをWORKSPACE_USED
またはWORKSPACE_STARTED
などの Telemetry サーバーに送信します。 -
increaseDuration()
- 短時間に多くのイベントを送信するのではなく、現在のイベントの期間を長くします。
次のセクションでは、以下を説明します。
- Telemetry サーバーを作成してイベントを標準出力にエコーします。
- OpenShift Dev Spaces Telemetry クライアントを拡張して、ユーザーのカスタムバックエンドを実装します。
-
カスタムバックエンドの Dev Workspace プラグインを表す
plugin.yaml
ファイルを作成します。 -
CheCluster
カスタムリソースからworkspacesDefaultPlugins
属性を設定して、カスタムプラグインの場所を OpenShift Dev Spaces に指定します。
4.7.2.1. スタートガイド リンクのコピーリンクがクリップボードにコピーされました!
以下では、OpenShift Dev Spaces Telemetry システムを拡張してカスタムバックエンドと通信するために必要な手順を説明します。
- イベントを受信するサーバープロセスの作成
- イベントをサーバーに送信するバックエンドを作成する OpenShift Dev Spaces ライブラリーの拡張
- コンテナーでの Telemetry バックエンドのパッケージ化およびイメージレジストリーへのデプロイ
- バックエンドのプラグインを追加し、OpenShift Dev Space に Dev Workspaces にプラグインを読み込むよう指示
Telemetry バックエンドの最終的な例は、こちら を参照してください。
4.7.2.2. イベントを受信するサーバーの作成 リンクのコピーリンクがクリップボードにコピーされました!
この例は、Telemetry プラグインからイベントを受信し、標準出力に書き込むサーバーを作成する方法を示しています。
実稼働環境のユースケースでは、独自の Telemetry サーバーを作成するのではなく、サードパーティーの Telemetry システム (Segment、Woopra など) との統合を検討してください。この場合、プロバイダーの API を使用してイベントをカスタムバックエンドからシステムに送信します。
以下の Go コードは、ポート 8080
でサーバーを起動し、イベントを標準出力に書き込みます。
例4.21 main.go
このコードに基づいてコンテナーイメージを作成し、これを OpenShift の openshift-devspaces
プロジェクトでデプロイメントとして公開します。サンプル Telemetry サーバーのコードは telemetry-server-example で利用できます。Telemetry サーバーをデプロイするには、リポジトリーのクローンを作成し、コンテナーをビルドします。
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
の両方には、Deployment およびサービスの定義が含まれます。また、前者は Kubernetes Ingress も定義しますが、後者は OpenShift Route を定義します。
マニフェストファイルで、プッシュした image
に一致する image および host
フィールドと、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! Toggle word wrap Toggle overflow -
src/main/java/mygroup
とsrc/test/java/mygroup
の下にあるファイルを削除します。 -
backend-base
の最新バージョンおよび Maven コーディネートは、GitHub パッケージ を参照してください。 以下の依存関係を
pom.xml
に追加します。例4.22
pom.xml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
read:packages
パーミッションでパーソナルアクセストークンを作成し、GitHub パッケージ からorg.eclipse.che.incubator.workspace-telemetry:backend-base
依存関係をダウンロードします。 GitHub ユーザー名、パーソナルアクセストークン、
che-incubator
リポジトリーの詳細を~/.m2/settings.xml
ファイルに追加します。例4.23
settings.xml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.2.4. AnalyticsManager の具体的な実装の作成および特殊なロジックの追加 リンクのコピーリンクがクリップボードにコピーされました!
src/main/java/mygroup
の下に、プロジェクトに 2 つのファイルを作成します。
-
MainConfiguration.java
-AnalyticsManager
に提供される設定が含まれます。 -
AnalyticsManager.java
: Telemetry システム固有のロジックが含まれます。
例4.24 MainConfiguration.java
- 1
- MicroProfile 設定アノテーションは、
welcome.message
設定を注入するために使用されます。
バックエンドに固有の設定プロパティーを設定する方法の詳細は、Quarkus 設定リファレンスガイド を参照してください。
例4.25 AnalyticsManager.java
org.my.group.AnalyticsManager
と org.my.group.MainConfiguration
は代替の Bean であるため、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
に設定されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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! Toggle word wrap Toggle overflow アプリケーションは、フロントエンドプラグインからポート
4167
を使用して Telemetry イベントを受け取るようになりました。
検証手順
以下の出力がログに記録されていることを確認します。
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! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow
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()
は、バックエンドが受信したイベントを Telemetry システムに送信します。サンプルアプリケーションでは、HTTP POST ペイロードを Telemetry サーバーから /event
エンドポイントに送信します。
4.7.2.7.1. サンプル Telemetry サーバーへの POST 要求の送信 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、Telemetry サーバーアプリケーションは http://little-telemetry-server-che.apps-crc.testing
の URL で OpenShift にデプロイされます。ここで、apps-crc.testing
は OpenShift クラスターの Ingress ドメイン名です。
TelemetryService.java
を作成して RESTEasy REST Client を設定します。例4.28
TelemetryService.java
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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! Toggle word wrap Toggle overflow TelemetryService
をAnalyticsManager
に注入し、onEvent()
でPOST
リクエストを送信します。例4.30
AnalyticsManager.java
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、HTTP 要求が Telemetry サーバーに送信され、短期間同じイベントが自動的に遅延します。デフォルトの期間は 1500 ミリ秒です。
4.7.2.8. increaseDuration() の実装 リンクのコピーリンクがクリップボードにコピーされました!
多くの Telemetry システムはイベント期間を認識します。AbstractAnalyticsManager
は、同じ期間内で発生する同様のイベントを 1 つのイベントにマージします。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
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);
}
「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
イメージをビルドするには、以下を実行します。
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
イメージをビルドするには、以下を実行します。
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 documentation を参照してください。
例4.36 plugin.yaml
- 1
- 「Quarkus アプリケーションのパッケージ化」 からビルドされたコンテナーイメージを指定します。
- 2
- Example 4 から
welcome.message
オプションの設定プロパティーの値を設定します。
通常、ユーザーはこのファイルを企業 Web サーバーにデプロイします。このガイドでは、OpenShift で Apache Web サーバーを作成し、そこでプラグインをホストする方法を説明します。
新規 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
Web サーバーを公開するためにデプロイメント、サービス、およびルートを作成します。デプロイメントはこの ConfigMap
オブジェクトを参照し、これを /var/www/html
ディレクトリーに配置します。
例4.37 manifest.yaml
oc apply -f manifest.yaml
$ oc apply -f manifest.yaml
検証手順
デプロイメントが開始されたら、Web サーバーで
plugin.yaml
が利用できることを確認します。curl apache-che.apps-crc.testing/plugin.yaml
$ curl apache-che.apps-crc.testing/plugin.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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! Toggle word wrap Toggle overflow - OpenShift Dev Spaces ダッシュボードから Dev Workspace を起動します。
検証手順
Telemetry-plug-in コンテナーが Dev Workspace Pod で稼働していることを確認します。ここでは、これはエディターで Workspace ビューをチェックして検証されます。
- エディター内のファイルを編集し、Telemetry サーバーのログのサンプルでイベントを確認します。
4.7.2.14. すべての Dev Workspaces の Telemetry プラグインの適用 リンクのコピーリンクがクリップボードにコピーされました!
Telemetry プラグインをデフォルトのプラグインとして設定します。デフォルトのプラグインは、新規および既存の Dev Workspaces の Dev Workspace の起動に適用されます。
CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証手順
- Red Hat OpenShift Dev Spaces ダッシュボードから新規または既存の Dev Workspace を起動します。
- 「Dev Workspace での Telemetry プラグインの指定」 の検証手順に従って、Telemetry プラグインが機能していることを確認します。
4.7.2.15. サーバーロギングの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces サーバーで利用可能な個別のロガーのログレベルを微調整できます。
OpenShift Dev Spaces サーバー全体のログレベルは、Operator の cheLogLevel
設定プロパティーを使用してグローバルに設定されます。「CheCluster
カスタムリソースフィールドの参照」 を参照してください。Operator によって管理されないインストールでグローバルログレベルを設定するには、che
ConfigMap で CHE_LOG_LEVEL
環境変数を指定します。
CHE_LOGGER_CONFIG
環境変数を使用して、OpenShift Dev Spaces サーバーの個々のロガーのログレベルを設定することができます。
4.7.2.15.1. ログレベルの設定 リンクのコピーリンクがクリップボードにコピーされました!
手順
CheCluster
カスタムリソースを設定します。「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! Toggle word wrap Toggle overflow - 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! Toggle word wrap Toggle overflow
4.7.2.15.2. ロガーの命名 リンクのコピーリンクがクリップボードにコピーされました!
ロガーの名前は、それらのロガーを使用する内部サーバークラスのクラス名に従います。
4.7.2.15.3. HTTP トラフィックのロギング リンクのコピーリンクがクリップボードにコピーされました!
手順
OpenShift Dev Spaces サーバーと Kubernetes または OpenShift クラスターの API サーバー間の HTTP トラフィックをログに記録するには、
CheCluster
カスタムリソースを設定します。「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! Toggle word wrap Toggle overflow
4.7.2.16. dsc を使用したログの収集 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Dev Spaces のインストールは、OpenShift クラスターで実行されている複数のコンテナーで構成されます。実行中の各コンテナーからログを手動で収集できますが、dsc
はプロセスを自動化するコマンドを提供します。
以下のコマンドを使用すると、dsc
ツールを使用して OpenShift クラスターから Red Hat OpenShift Dev Spaces ログを収集します。
dsc server: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! Toggle word wrap Toggle overflow 実行すると、
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! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow dsc server:deploy
-
ログは、
dsc
を使用してインストール時に OpenShift Dev Spaces のインストール時に自動的に収集されます。dsc server:logs
と同様に、ディレクトリーのログは-d
パラメーターを使用して指定できます。
関連情報
4.7.3. Dev Workspace Operator のモニタリング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift クラスター内監視スタックを設定して、Dev Workspace Operator によって公開されるメトリックを取得できます。
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 を作成します。
クラスター内の Prometheus インスタンスが OpenShift Dev Spaces namespace 内の ServiceMonitor を検出できるようにします。デフォルトの OpenShift Dev Spaces の namespace は
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! Toggle word wrap Toggle overflow
検証
- OpenShift Dev Spaces を新規インストールする場合は、ダッシュボードから OpenShift Dev Spaces ワークスペースを作成してメトリックを生成します。
- OpenShift Web コンソールの Administrator ビューで、Observe → Metrics に移動します。
PromQL クエリーを実行して、メトリックが利用可能であることを確認します。たとえば、
devworkspace_started_total
を入力し、Run queries をクリックします。その他のメトリクスは、「Dev Workspace 固有のメトリック」 を参照してください。
不足しているメトリクスのトラブルシューティングを行うには、Prometheus コンテナーログで RBAC 関連のエラーを確認します。
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! Toggle word wrap Toggle overflow 前のステップの 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! Toggle word wrap Toggle overflow
4.7.3.2. Dev Workspace 固有のメトリック リンクのコピーリンクがクリップボードにコピーされました!
次の表は、devworkspace-controller-metrics
サービスによって公開される Dev Workspace 固有のメトリックを説明しています。
名前 | 型 | 説明 | ラベル |
---|---|---|---|
| カウンター | Dev Workspace の開始イベントの数。 |
|
| カウンター |
|
|
| カウンター | 失敗した Dev Workspaces の数。 |
|
| ヒストグラム | Dev Workspace の起動にかかった総時間 (秒)。 |
|
名前 | 説明 | 値 |
---|---|---|
|
Dev Workspace の |
|
|
Dev Workspace の |
|
| ワークスペースの起動失敗の理由です。 |
|
名前 | 説明 |
---|---|
| Dev Workspace の作成に使用された devfile が無効であるため、起動に失敗しました。 |
|
|
| 不明な失敗理由。 |
4.7.3.3. OpenShift Web コンソールダッシュボードからの Dev Workspace Operator メトリックの表示 リンクのコピーリンクがクリップボードにコピーされました!
Dev Workspace Operator メトリックを収集するようにクラスター内 Prometheus インスタンスを設定した後、OpenShift Web コンソールの Administrator パースペクティブのカスタムダッシュボードにメトリックを表示できます。
前提条件
- OpenShift Dev Spaces の組織インスタンスが Red Hat OpenShift にインストールされ、実行されています。
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。 - クラスター内の Prometheus インスタンスはメトリックを収集しています。「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! Toggle word wrap Toggle overflow 注記前のコマンドには、アップストリームコミュニティーからの資料へのリンクが含まれています。この資料は、利用可能な最新のコンテンツと最新のベストプラクティスを表しています。これらのヒントは 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! Toggle word wrap Toggle overflow 注記ダッシュボード定義は、Grafana 6.x ダッシュボードに基づいています。すべての Grafana 6.x ダッシュボード機能が OpenShift Web コンソールでサポートされているわけではありません。
検証手順
- OpenShift Web コンソールの Administrator ビューで、Observe → Dashboards に移動します。
- Dashboard → Che Server JVM に移動し、ダッシュボードパネルにデータが含まれていることを確認します。
4.7.3.4. 開発ワークスペースオペレーター用のダッシュボード リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Web コンソールのカスタムダッシュボードは Grafana 6.x に基づいており、Dev Workspace Operator からの次のメトリックを表示します。
Grafana 6.x ダッシュボードのすべての機能が OpenShift Web コンソールダッシュボードとしてサポートされているわけではありません。
4.7.3.4.1. Dev Workspace メトリック リンクのコピーリンクがクリップボードにコピーされました!
開発ワークスペース固有のメトリックは、Dev Workspace Metrics パネルに表示されます。
図4.1 Dev Workspace Metrics パネル
- ワークスペースの平均起動時間
- ワークスペースの平均起動時間。
- ワークスペースの起動
- ワークスペースの起動の成功と失敗の回数。
- 開発ワークスペースの成功と失敗
- Dev Workspace の起動の成功と失敗の比較。
- Dev Workspace の失敗率
- ワークスペースの起動失敗回数と総起動回数の比率。
- Dev Workspace 起動失敗の理由
ワークスペース起動失敗の分布を表示する円グラフ:
-
BadRequest
-
InfrastructureFailure
-
Unknown
-
4.7.3.4.2. Operator メトリクス リンクのコピーリンクがクリップボードにコピーされました!
Operator 固有のメトリクスは Operator Metrics パネルに表示されます。
図4.2 Operator Metrics パネル
- 進行中の Webhook
- さまざまな Webhook リクエストの数の比較。
- 作業キューの深さ
- 作業キューにある調整リクエストの数。
- メモリー
- Dev Workspace コントローラーと Dev Workspace Webhook サーバーのメモリー使用状況。
- 1 秒あたりの平均調整数 (DWO)
- Dev Workspace コントローラーの 1 秒あたりの平均調整回数。
4.7.4. Dev Spaces サーバーの監視 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces サーバーの JVM メモリーやクラスローディングなどの JVM メトリックを公開するように OpenShift Dev Spaces を設定できます。
4.7.4.1. OpenShift Dev Spaces サーバーメトリックの有効化と公開 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces は、che-host
サービスのポート 8087
で JVM メトリックを公開します。この動作を設定できます。
手順
CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。spec: components: metrics: enable: <boolean>
spec: components: metrics: enable: <boolean>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 有効にするには
true
、無効にするにはfalse
。
4.7.4.2. Prometheus を使用した OpenShift Dev Spaces メトリックの収集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内 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 を作成します。
Prometheus がメトリックを表示できるようにするには、Role と RoleBinding を作成します。
例4.41 ロール
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenShift Dev Spaces namespace。デフォルトは
openshift-devspaces
です。
例4.42 RoleBinding
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenShift Dev Spaces namespace。デフォルトは
openshift-devspaces
です。
クラスター内の Prometheus インスタンスが OpenShift Dev Spaces namespace 内の ServiceMonitor を検出できるようにします。デフォルトの OpenShift Dev Spaces の namespace は
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! Toggle word wrap Toggle overflow
検証
- OpenShift Web コンソールの Administrator ビューで、Observe → Metrics に移動します。
-
PromQL クエリーを実行して、メトリックが利用可能であることを確認します。たとえば、
process_uptime_seconds{job="che-host"}
と入力し、Run queries をクリックします。
不足しているメトリクスのトラブルシューティングを行うには、Prometheus コンテナーログで RBAC 関連のエラーを確認します。
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! Toggle word wrap Toggle overflow 前のステップの 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! Toggle word wrap Toggle overflow
4.7.4.3. OpenShift Web コンソールダッシュボードからの OpenShift Dev Spaces Server の表示 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces Server JVM メトリックを収集するようにクラスター内 Prometheus インスタンスを設定した後、OpenShift Web コンソールの Administrator パースペクティブのカスタムダッシュボードにメトリックを表示できます。
前提条件
- OpenShift Dev Spaces の組織インスタンスが Red Hat OpenShift にインストールされ、実行されています。
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。 - クラスター内の Prometheus インスタンスはメトリックを収集しています。「Prometheus を使用した OpenShift Dev Spaces メトリックの収集」 を参照してください。
手順
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! Toggle word wrap Toggle overflow 注記前のコマンドには、アップストリームコミュニティーからの資料へのリンクが含まれています。この資料は、利用可能な最新のコンテンツと最新のベストプラクティスを表しています。これらのヒントは 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! Toggle word wrap Toggle overflow 注記ダッシュボード定義は、Grafana 6.x ダッシュボードに基づいています。すべての Grafana 6.x ダッシュボード機能が OpenShift Web コンソールでサポートされているわけではありません。
検証手順
- OpenShift Web コンソールの Administrator ビューで、Observe → Dashboards に移動します。
Dashboard → Dev Workspace Operator に移動し、ダッシュボードパネルにデータが含まれていることを確認します。
図4.3 クイックファクト
図4.4 JVM メモリー
図4.5 JVM Misc
図4.6 JVM メモリープール (ヒープ)
図4.7 JVM メモリープール (非ヒープ)
図4.8 ガベージコレクション
図4.9 クラスローディング
図4.10 バッファープール
4.8. ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
4.8.1. ネットワークポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、OpenShift クラスター内のすべての Pod は、異なる namespace にある場合でも相互に通信できます。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 namespace からユーザープロジェクト内のすべての Pod への受信トラフィックを許可します。オプション: ネットワークポリシーによるマルチテナント分離の設定 を適用した場合は、
allow-from-openshift-apiserver
およびallow-from-workspaces-namespaces
NetworkPolicies もopenshift-devspaces
に適用する必要があります。allow-from-openshift-apiserver
NetworkPolicy は、openshift-apiserver
namespace からdevworkspace-webhook-server
への受信トラフィックを許可し、Webhook を有効にします。allow-from-workspaces-namespaces
NetworkPolicy は、各ユーザープロジェクトからche-gateway
Pod への受信トラフィックを許可します。例4.44
allow-from-openshift-apiserver.yaml
- 「プロジェクトの設定」
- ネットワーク分離
- ネットワークポリシーを使用したマルチテナント分離の設定
4.8.2. Dev Spaces ホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、カスタムホスト名を使用するように OpenShift Dev Space を設定する方法を説明します。
前提条件
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。 - 証明書とプライベートキーファイルが生成されます。
秘密鍵と証明書のペアを生成するには、他の OpenShift Dev Spaces ホストと同じ認証局 (CA) を使用する必要があります。
DNS プロバイダーに対し、カスタムホスト名をクラスター Ingress を参照するよう要求します。
手順
OpenShift Dev Spaces のプロジェクトを作成します。
oc create project openshift-devspaces
$ oc create project openshift-devspaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TLS Secret を作成します。
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! Toggle word wrap Toggle overflow シークレットに必要なラベルを追加します。
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! Toggle word wrap Toggle overflow - 1
- TLS Secret 名
CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。spec: networking: hostname: <hostname> tlsSecretName: <secret>
spec: networking: hostname: <hostname>
1 tlsSecretName: <secret>
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Dev Spaces がすでにデプロイされている場合は、すべての OpenShift Dev Spaces コンポーネントのロールアウトが完了するまで待ちます。
4.8.3. 信頼されていない TLS 証明書を Dev Spaces にインポートする リンクのコピーリンクがクリップボードにコピーされました!
外部サービスとの OpenShift Dev Spaces コンポーネントの通信は、TLS で暗号化されます。信頼できる認証局 (CA) によって署名された TLS 証明書が必要です。したがって、以下のような外部サービスで使用されていて、信頼されていない CA チェーンをすべて OpenShift Dev Spaces にインポートする必要があります。
- プロキシー
- ID プロバイダー (OIDC)
- ソースコードリポジトリープロバイダー (Git)
OpenShift Dev Spaces は、OpenShift Dev Spaces プロジェクトのラベル付き ConfigMaps を TLS 証明書のソースとして使用します。ConfigMaps には、それぞれ任意の数の証明書と、任意の数の鍵を指定できます。Operator は、すべての ConfigMaps を ca-certs-merged
という単一の ConfigMaps にマージし、これを OpenShift Dev Spaces サーバー、ダッシュボード、およびワークスペース Pod にボリュームとしてマウントします。デフォルトでは、Operator は ca-certs-merged
ConfigMap を 2 つのロケーション (/public-certs
と /etc/pki/ca-trust/extracted/pem
) でユーザーのワークスペースにマウントします。/etc/pki/ca-trust/extracted/pem
ディレクトリーは、システムが、Red Hat で信頼できる認証局 (CentOS、Fedora など) に展開した CA 証明書を保存する場所です。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! Toggle word wrap Toggle overflow 必要な 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! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow - 以前にデプロイされていない場合は、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! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow - ワークスペースを起動し、ワークスペースが作成されたプロジェクト名 (<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! Toggle word wrap Toggle overflow ワークスペース 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! Toggle word wrap Toggle overflow ワークスペース 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! Toggle word wrap Toggle overflow ワークスペースコンテナーにカスタム 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! Toggle word wrap Toggle overflow
関連情報
4.8.4. ラベルとアノテーションの追加 リンクのコピーリンクがクリップボードにコピーされました!
4.8.4.1. ルーターのシャード化と連携するように OpenShift ルートを設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Route が ルーターのシャード化 と連携するようにラベル、アノテーション、およびドメインを設定できます。
前提条件
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。OpenShift CLI のスタートガイド を参照してください。 -
dsc
。「dsc 管理ツールのインストール」 を参照してください。
手順
CheCluster
カスタムリソースを設定します。「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! Toggle word wrap Toggle overflow
4.9. ストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces は Network File System (NFS) プロトコルをサポートしていません。
4.9.1. ストレージクラスの設定 リンクのコピーリンクがクリップボードにコピーされました!
設定されたインフラストラクチャーストレージを使用するように OpenShift Dev Spaces を設定するには、ストレージクラスを使用して OpenShift Dev Spaces をインストールします。これは、デフォルト以外のプロビジョナーによって提供される永続ボリュームをバインドする場合に特に便利です。
OpenShift Dev Spaces には、データを保存するために永続ボリュームを必要とするコンポーネントが 1 つあります。
-
OpenShift Dev Spaces ワークスペース。OpenShift Dev Spaces ワークスペースは、
/projects
ボリュームなどのボリュームを使用してソースコードを保存します。
OpenShift Dev Spaces ワークスペースソースコードは、ワークスペースが一時的ではない場合にのみ永続ボリュームに保存されます。
永続ボリューム要求のファクト:
- OpenShift Dev Spaces は、インフラストラクチャーに永続ボリュームを作成しません。
- OpenShift Dev Spaces は、永続ボリュームクレーム (PVC) を使用して永続ボリュームをマウントします。
「Dev ワークスペースの演算子」 は、永続ボリューム要求を作成します。
OpenShift Dev Spaces PVC のストレージクラス機能を使用するには、OpenShift Dev Spaces 設定でストレージクラス名を定義します。
手順
CheCluster カスタムリソース定義を使用してストレージクラスを定義します。
ストレージクラス名を定義します。
CheCluster
カスタムリソースを設定し、OpenShift Dev Spaces をインストールします。「dsc を使用したインストール時にCheCluster
カスタムリソースの設定」 を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.2. ストレージストラテジーの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces は、ストレージストラテジーを選択することで、ワークスペースに永続ストレージまたは非永続ストレージを提供するように設定できます。選択したストレージストラテジーは、デフォルトで新しく作成されたすべてのワークスペースに適用されます。ユーザーは、devfile または URL パラメーター を通じて、ワークスペースのデフォルト以外のストレージストラテジーを選択できます。
利用可能なストレージストラテジー:
-
per-user
: ユーザーによって作成されたすべてのワークスペースに単一の PVC を使用します。 -
per-workspace
: 各ワークスペースには独自の PVC が付与されます。 -
ephemeral
: 非永続ストレージ。ワークスペースが停止すると、ローカルの変更は失われます。
OpenShift Dev Spaces で使用されるデフォルトのストレージストラテジーは per-user
です。
手順
-
Che Cluster カスタムリソースの
pvcStrategy
フィールドを、per-user
、per-workspace
またはephemeral
に設定します。
-
このフィールドは、インストール時に設定できます。「dsc を使用したインストール時に
CheCluster
カスタムリソースの設定」 を参照してください。 - このフィールドは、コマンドラインで更新できます。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。
spec: devEnvironments: storage: pvc: pvcStrategy: 'per-user'
spec:
devEnvironments:
storage:
pvc:
pvcStrategy: 'per-user'
- 1
- 利用可能なストレージストラテジーは、
per-user
、per-workspace
およびephemeral
です。
4.9.3. ストレージサイズの設定 リンクのコピーリンクがクリップボードにコピーされました!
永続ボリューム要求 (PVC) サイズは、per-user
または per-workspace
のストレージストラテジーを使用して設定できます。CheCluster
カスタムリソースの PVC サイズを Kubernetes リソース数量 の形式で指定する必要があります。利用可能なストレージストラテジーの詳細は、こちらのページ を参照してください。
デフォルトの永続ボリューム要求サイズ:
per-user: 10Gi
per-user: 10Gi
Copy to Clipboard Copied! Toggle word wrap Toggle overflow per-workspace: 5Gi
per-workspace: 5Gi
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
-
Che Cluster カスタムリソースで、必要なストレージストラテジーの適切な
claimSize
フィールドを設定します。
-
このフィールドは、インストール時に設定できます。「dsc を使用したインストール時に
CheCluster
カスタムリソースの設定」 を参照してください。 - このフィールドは、コマンドラインで更新できます。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。
4.9.4. 永続ホームディレクトリー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Dev Spaces は、非一時ワークスペースごとにワークスペースの再起動後も /home/user
ディレクトリーを維持できるようにする永続ホームディレクトリー機能を提供します。spec.devEnvironments.persistUserHome.enabled
を true
に設定して、CheCluster でこの機能を有効にできます。
新しく起動されたワークスペースでは、この機能により、tools コンテナーの /home/user
パスにマウントされる PVC が作成されます。このドキュメントでは、"tools コンテナー" を使用して devfile の最初のコンテナーを参照します。このコンテナーは、デフォルトでプロジェクトソースコードを含むコンテナーです。
PVC の初回マウント時に、永続ボリュームのコンテンツは空になるため、/home/user
ディレクトリーのコンテンツを設定する必要があります。
デフォルトでは、persistUserHome
機能は、init-persistent-home
という名前の新規ワークスペース Pod ごとに init コンテナーを作成します。この init コンテナーはツールコンテナーイメージと共に作成され、stow
コマンドを実行して永続ボリュームにシンボリックリンクを作成し、/home/user
ディレクトリーを設定します。
.viminfo
および .bashrc
ファイルなど、/home/user
ディレクトリーにシンボリックリンクができないファイルの場合は、stow
の代わりに cp
が使用されます。
stow
コマンドの主な機能は、以下を実行することです。
stow -t /home/user/ -d /home/tooling/ --no-folding
stow -t /home/user/ -d /home/tooling/ --no-folding
上記のコマンドは、/home/tooling にあるファイルおよびディレクトリーの /home/user
にシンボリックリンクを作成します。これにより、永続ボリュームに /home/tooling
のコンテンツへのシンボリックリンクが追加されます。その結果、persistentUserHome
機能は、ツールイメージに /home/user/
コンテンツが /home/tooling
内にあることを想定します。
たとえば、ツールコンテナーイメージに .config
および .config-folder/another-file
などの home/tooling
ディレクトリーのファイルが含まれている場合は、stow は次の方法で永続ボリュームにシンボリックリンクを作成します。
図4.11 persistUserHome
が有効になっているツールコンテナー
init コンテナーは、stow
コマンドの出力を /home/user/.stow.log
に書き込みます。永続ボリュームをワークスペースに初めてマウントしたときにのみ stow
を実行します。
stow
コマンドを使用して、永続ボリュームに /home/user
コンテンツを設定することには、主に 2 つの利点があります。
-
シンボリックリンクを作成する方が、
/home/user
ディレクトリーの内容を永続ボリュームにコピーするよりも高速で、ストレージの消費も少なくなります。言い換えれば、この場合の永続ボリュームには、実際のファイルではなくシンボリックリンクが含まれています。 -
ツールイメージが、既存のバイナリー、設定、およびファイルの新しいバージョンで更新されている場合、既存のシンボリックリンクは
/home/tooling
の新しいバージョンにすでにリンクされるため、init コンテナーは新しいバージョンをstow
する必要はありません。
ツールイメージが追加のバイナリーまたはファイルで更新されている場合、stow
コマンドは再度実行されないため、/home/user
ディレクトリーにシンボリックリンクされません。この場合は、/home/user/.stow_completed
ファイルを削除し、ワークスペースを再起動して stow
を再実行する必要があります。
persistUserHome
ツールのイメージ要件
persistUserHome
は、ワークスペースに使用されるツールイメージによって異なります。デフォルトでは、OpenShift Dev Spaces は、追加設定なしで persistUserHome
をサポートするサンプルワークスペースに Universal Developer Image (UDI) を使用します。
カスタムイメージを使用している場合は、persistUserHome
機能をサポートするために満たさなければならない 3 つの要件があります。
-
ツールイメージには
stow
バージョン >= 2.4.0 が含まれている必要がある。 -
$HOME
環境変数が/home/user
に設定されている。 -
tools イメージでは、
/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
これは、/home/tooling
のファイルが persistUserHome
機能を使用していなくても /home/user
からアクセスできるように Dockerfile で実行されます。
4.10. ダッシュボードの設定 リンクのコピーリンクがクリップボードにコピーされました!
4.10.1. 使用開始サンプルの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、カスタムサンプルを表示するように OpenShift Dev Spaces Dashboard を設定する方法を説明します。
前提条件
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
サンプル設定で JSON ファイルを作成します。ファイルにはオブジェクトの配列が含まれている必要があります。各オブジェクトはサンプルを表します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル設定で 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! Toggle word wrap Toggle overflow 必要なラベルを 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! Toggle word wrap Toggle overflow - OpenShift Dev Spaces Dashboard ページを更新して、新しいサンプルを表示します。
4.10.2. エディター定義の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces エディター定義の設定方法を説明します。
前提条件
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
エディター定義設定で
my-editor-definition-devfile.yaml
YAML ファイルを作成します。重要metadata.attributes
のpublisher
およびversion
の実際の値を指定してください。これらは、Publisher/name/version
形式のエディター名とともにエディター ID を構築するために使用されます。以下に、オプションの値も含め、サポートされている値を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow エディター定義コンテンツを使用して 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! Toggle word wrap Toggle overflow 必要なラベルを 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! Toggle word wrap Toggle overflow - OpenShift Dev Spaces ダッシュボードページを更新して、新しい利用可能なエディターを確認します。
4.10.2.1. エディター定義の取得 リンクのコピーリンクがクリップボードにコピーされました!
エディター定義は、次の URL から OpenShift Dev Spaces ダッシュボード API によっても提供されます。
https://<openshift_dev_spaces_fqdn>/dashboard/api/editors
「エディター定義の設定」 の例では、次の 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 のデフォルトエディター定義を設定する方法を説明します。
前提条件
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。 -
jq
。Downloadingjq
を参照してください。
手順
利用可能なエディターの 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! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow - 1
- ワークスペースを作成するためのデフォルトのエディターは、プラグイン ID または URI を使用して指定できます。プラグイン ID は
publisher/name/version
の形式に従う必要があります。最初の手順で使用可能なエディター ID を参照してください。
関連情報
- 「エディター定義の設定」
- 「エディター定義を非表示にする」
- {editor-definition-samples-link}
4.10.4. エディター定義を非表示にする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces エディター定義を非表示にする方法を説明します。これは、選択したエディターをダッシュボード UI から非表示にする場合に便利です。たとえば、IntelliJ IDEA Ultimate を非表示にして、Visual Studio Code - Open Source のみを表示させる場合に便利です。
前提条件
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。 -
jq
。Downloadingjq
を参照してください。
手順
OpenShift Dev Spaces Operator がデプロイされている namespace を見つけます。
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! Toggle word wrap Toggle overflow 利用可能なエディター定義ファイルを確認します。
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! Toggle word wrap Toggle overflow 出力は以下の例のようになります。
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! Toggle word wrap Toggle overflow 非表示にするエディター定義を選択します。たとえば、
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! Toggle word wrap Toggle overflow 非表示にするエディター定義の 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! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow Operator サブスクリプション名と namespace (存在する場合) を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 空のエディター定義を使用して Kubernetes リソースにパッチを適用し、ConfigMap をマウントします。パッチを適用するリソースは、Operator サブスクリプションの存在によって異なります。サブスクリプションが存在する場合は、サブスクリプションにパッチを適用する必要があります。サブスクリプションが存在しない場合は、Operator デプロイメントにパッチを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
- 「エディター定義の設定」
- 「デフォルトのエディター定義の設定」
- {editor-definition-samples-link}
4.10.5. OpenShift Eclipse Che ConsoleLink アイコンのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
この手順では、Red Hat OpenShift Dev Spaces ConsoleLink アイコンをカスタマイズする方法を説明します。
前提条件
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
シークレットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 行の折り返しが無効になっている Base64 エンコーディング。
- devspaces-dashboard のロールアウトが完了するまで待ちます。
4.11. ID および承認の管理 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift Dev Spaces の ID および承認の管理のさまざまな側面を説明します。
4.11.1. Git プロバイダーの OAuth の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Dev Spaces でワークスペースの起動時に Personal Access Token を強制的に更新する実験的な機能を有効にするには、カスタムリソース設定を次のように変更します。
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. Configuring OAuth 2.0 for GitHub リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが GitHub でホストされるリモート Git リポジトリーと連携できるようにするには、以下を実行します。
- GitHub OAuth アプリ (OAuth 2.0) をセットアップします。
- GitHub OAuth アプリケーションシークレットを適用します。
4.11.1.1.1. GitHub OAuth アプリケーションの設定 リンクのコピーリンクがクリップボードにコピーされました!
Set up a GitHub OAuth App using OAuth 2.0.
前提条件
- GitHub にログインしている。
手順
- https://github.com/settings/applications/new にアクセスします。
以下の値を設定します。
-
アプリケーション名:
<application name>
-
ホームページ URL:
https://<openshift_dev_spaces_fqdn>/
-
Authorization callback URL:
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
-
アプリケーション名:
- Register application をクリックします。
- Generate new client secret をクリックします。
- GitHub OAuth アプリケーションシークレットを適用する際に使用するために GitHub OAuth クライアント ID をコピーして保存します。
- GitHub OAuth アプリケーションシークレットを適用する際に使用するために GitHub OAuth クライアントシークレット をコピーして保存します。
4.11.1.1.2. GitHub OAuth アプリケーションシークレットの適用 リンクのコピーリンクがクリップボードにコピーされました!
GitHub OAuth App Secret を準備し、これを適用します。
前提条件
- GitHub OAuth アプリケーションのセットアップが完了します。
GitHub OAuth アプリケーションのセットアップ時に生成された以下の値が用意されています。
- GitHub OAuth Client ID
- GitHub OAuth Client Secret
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
Secret を準備します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenShift Dev Spaces namespace。デフォルトは
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! Toggle word wrap Toggle overflow - 出力に Secret が作成されたことを確認します。
別の GitHub プロバイダー用に OAuth 2.0 を設定するには、上記の手順を繰り返し、別の名前で 2 つ目の GitHub OAuth Secret を作成する必要があります。
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 にログインしている。
手順
- アバターをクリックして、 → の編集に移動します。
- Name に OpenShift Dev Spaces を入力します。
-
Redirect URI として
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
を入力します。 - Confidential および Expire access tokens のチェックボックスを選択します。
-
Scopes の下で、
api
、write_repository
、およびopenid
のチェックボックスにチェックを入れます。 - Save application をクリックします。
- GitLab-authorized アプリケーションシークレットを適用する際に使用するために GitLab アプリケーション ID をコピーして保存します。
- GitLab-authorized アプリケーションシークレットを適用する際に使用するために GitLab クライアントシークレット をコピーして保存します。
4.11.1.2.2. GitLab で承認されるアプリケーションシークレットの適用 リンクのコピーリンクがクリップボードにコピーされました!
GitLab で承認されるアプリケーションシークレットを準備し、これを適用します。
前提条件
- GitLab 認証アプリケーションの設定が完了します。
GitLab で承認されたアプリケーションのセットアップ時に生成された以下の値が用意されています。
- GitLab Application ID
- GitLab Client Secret
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
Secret を準備します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットを適用します。
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! Toggle word wrap Toggle overflow - 出力に Secret が作成されたことを確認します。
別の Gitlab プロバイダー用に OAuth 2.0 を設定するには、上記の手順を繰り返し、別の名前で 2 つ目の Gitlab OAuth Secret を作成する必要があります。
4.11.1.3. Bitbucket サーバーの OAuth 2.0 の設定 リンクのコピーリンクがクリップボードにコピーされました!
OAuth 2.0 を使用すると、ユーザーが Bitbucket Server でホストされているリモート Git リポジトリーを操作できるようになります。
- Bitbucket Server で OAuth 2.0 アプリケーションリンクをセットアップします。
- Bitbucket Server のアプリケーションリンクシークレットを適用します。
4.11.1.3.1. Bitbucket Server での OAuth 2.0 アプリケーションリンクのセットアップ リンクのコピーリンクがクリップボードにコピーされました!
Bitbucket Server で OAuth 2.0 アプリケーションリンクをセットアップします。
前提条件
- Bitbucket Server にログインしている。
手順
- Administration > Applications > Application links に移動します。
- Create link を選択します。
- External application および Incoming を選択します。
-
Redirect URL フィールドに
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
を入力します。 - Application permissions で Admin - Write チェックボックスを選択します。
- Save をクリックします。
- Bitbucket アプリケーションリンクのシークレットを適用する際に使用するために クライアント ID をコピーして保存します。
- Bitbucket アプリケーションリンクのシークレットを適用する際に使用するために、クライアントシークレット をコピーして保存します。
4.11.1.3.2. Bitbucket Server の OAuth 2.0 アプリケーションリンクシークレットの適用 リンクのコピーリンクがクリップボードにコピーされました!
Bitbucket Server の OAuth 2.0 アプリケーションリンクシークレットを準備して適用します。
前提条件
- アプリケーションリンクが Bitbucket Server にセットアップされている。
Bitbucket アプリケーションリンクのセットアップ時に生成された以下の値が用意されています。
- Bitbucket Client ID
- Bitbucket Client secret
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
Secret を準備します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットを適用します。
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! Toggle word wrap Toggle overflow - 出力に 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 Cloud で OAuth コンシューマーを設定する リンクのコピーリンクがクリップボードにコピーされました!
Bitbucket Cloud で OAuth 2.0 の OAuth コンシューマーをセットアップします。
前提条件
- Bitbucket Cloud にログインしている。
手順
- アバターをクリックして、All workspaces ページに移動します。
- ワークスペースを選択してクリックします。
- → → に移動します。
- Name に OpenShift Dev Spaces を入力します。
-
Callback URL として
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
と入力します。 - Permissions で、Account と Repositories のすべてのチェックボックスをオンにして、Save をクリックします。
- 追加されたコンシューマーを展開し、Bitbucket OAuth コンシューマーシークレットを適用する際に使用するために キー 値をコピーして保存します。
- Bitbucket OAuth コンシューマーシークレットを適用する際に使用するために シークレット 値をコピーして保存します。
4.11.1.4.2. Bitbucket Cloud に OAuth コンシューマーシークレットを適用する リンクのコピーリンクがクリップボードにコピーされました!
Bitbucket Cloud の OAuth コンシューマーシークレットを準備して適用します。
前提条件
- OAuth コンシューマーは Bitbucket Cloud でセットアップされます。
Bitbucket OAuth コンシューマーのセットアップ時に生成された次の値が準備されています。
- Bitbucket OAuth コンシューマーキー
- Bitbucket OAuth コンシューマーシークレット
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
Secret を準備します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットを適用します。
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! Toggle word wrap Toggle overflow - 出力に Secret が作成されたことを確認します。
4.11.1.5. Bitbucket サーバー向け OAuth 1.0 の設定 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが Bitbucket サーバーでホストされるリモート Git リポジトリーと連携できるようにするには、以下を実行します。
- Bitbucket Server でアプリケーションリンク (OAuth 1.0) を設定します。
- Bitbucket Server のアプリケーションリンクシークレットを適用します。
4.11.1.5.1. Bitbucket Server でのアプリケーションリンクの設定 リンクのコピーリンクがクリップボードにコピーされました!
Bitbucket Server で OAuth 1.0 のアプリケーションリンクをセットアップします。
前提条件
- Bitbucket Server にログインしている。
-
openssl
は、使用しているオペレーティングシステムにインストールされている。
手順
コマンドラインでコマンドを実行して、次の手順に必要なファイルを作成し、アプリケーションリンクシークレットを適用するときに使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - → に移動します。
-
URL フィールドに
https://<openshift_dev_spaces_fqdn>/
と入力し、Create new link をクリックします。 - 提供されたアプリケーション URL が一度リダイレクトされました で、この URL を使用する チェックボックスをオンにして、続行 をクリックします。
- Application Name に OpenShift Dev Spaces を入力します。
- Application Type として Generic Application を選択します。
- OpenShift Dev Spaces を Service Provider Name として入力します。
-
bitbucket-consumer-key
ファイルの内容を Consumer キー として貼り付けます。 -
bitbucket-shared-secret
ファイルの内容を Shared シークレット として貼り付けます。 -
リクエストトークンの URL として
<bitbucket_server_url>/plugins/servlet/oauth/request-token
と入力します。 -
アクセストークンの URL として
<bitbucket_server_url>/plugins/servlet/oauth/access-token
と入力します。 -
Authorize URL として
<bitbucket_server_url>/plugins/servlet/oauth/authorize
と入力します。 - 受信リンクの作成 チェックボックスをオンにして、続行 をクリックします。
-
bitbucket-consumer-key
ファイルの内容を Consumer Key として貼り付けます。 - コンシューマー名 として OpenShift Dev Spaces を入力します。
-
public-stripped.pub
ファイルの内容を 公開鍵 として貼り付け、Continue をクリックします。
4.11.1.5.2. Bitbucket Server 用にアプリケーションリンクシークレットを適用する リンクのコピーリンクがクリップボードにコピーされました!
Bitbucket Server のアプリケーションリンクシークレットを準備して適用します。
前提条件
- アプリケーションリンクが Bitbucket Server にセットアップされている。
アプリケーション連携の設定時に作成された以下のファイルが用意されています。
-
privatepkcs8-stripped.pem
-
bitbucket-consumer-key
-
bitbucket-shared-secret
-
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
Secret を準備します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットを適用します。
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! Toggle word wrap Toggle overflow - 出力に Secret が作成されたことを確認します。
4.11.1.6. Microsoft Azure DevOps サービス用の OAuth 2.0 の設定 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが Microsoft Azure Repos でホスティングされているリモート Git リポジトリーを操作できるようにするには:
- Microsoft Azure DevOps Services OAuth アプリケーション (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 にログインしています。
重要Third-party application access via OAuth
が、組織で有効になっています。Change application connection & security policies for your organization を参照してください。手順
- 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
-
会社名:
- Select Authorized scopes で、Code (read and write) を選択します。
- Create application をクリックします。
- Microsoft Azure DevOps Services OAuth アプリケーションシークレットを適用する際に使用するために アプリケーション ID をコピーして保存します。
- Show をクリックして、Client Secret を表示します。
- 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 Services OAuth アプリの設定時に生成された次の値が用意されています。
- アプリケーション ID
- Client Secret
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
Secret を準備します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットを適用します。
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! Toggle word wrap Toggle overflow - 出力に 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! Toggle word wrap Toggle overflow - 1
- 一意のリソース名。
OpenShift Dev Spaces Operator がデプロイされている namespace を見つけます。
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! Toggle word wrap Toggle overflow 必要なロールを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ロールを OpenShift Dev Spaces Operator に委譲します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ロールを
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! Toggle word wrap Toggle overflow ロールをユーザーに委譲するように 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! Toggle word wrap Toggle overflow - OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。
- ログアウトして、新しいロールを適用するようにユーザーに依頼します。
4.11.3. 高度な認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces へのアクセスを許可するユーザーとグループを決定できます。
前提条件
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。
OpenShift Dev Spaces へのアクセスをユーザーに許可するには、そのユーザーを allowUsers
リストに追加します。あるいは、ユーザーがメンバーとなっているグループを選択し、そのグループを allowGroups
リストに追加します。OpenShift Dev Spaces へのユーザーのアクセスを拒否するには、そのユーザーを denyUsers
リストに追加します。あるいは、ユーザーがメンバーとなっているグループを選択し、そのグループを denyGroups
リストに追加します。ユーザーが allow
と deny
の両方のリストに登録されている場合は、OpenShift Dev Spaces へのアクセスは拒否されます。
allowUsers
と allowGroups
が空の場合、deny
リストにあるユーザーを除くすべてのユーザーが OpenShift Dev Spaces へのアクセスを許可されます。denyUsers
と denyGroups
が空の場合、allow
リストのユーザーのみが OpenShift Dev Spaces へのアクセスを許可されます。
allow
と deny
リストの両方が空の場合、すべてのユーザーが OpenShift Dev Spaces にアクセスできます。
4.11.4. GDPR に準拠したユーザーデータの削除 リンクのコピーリンクがクリップボードにコピーされました!
個人データを消去する権利を個人に強制する General Data Protection Regulation (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! Toggle word wrap Toggle overflow - ユーザーエントリーを削除します。
ユーザーに関連するリソース (プロジェクト、ロール、サービスアカウントなど) がある場合は、ユーザーを削除する前に、まずそれらを削除する必要があります。
oc delete user <username>
$ oc delete user <username>
4.12. fuse-overlayfs の設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Universal Developer Image (UDI) には、ワークスペース内でコンテナーイメージをビルドおよびプッシュするために使用できる Podman と Buildah が含まれています。ただし、UDI の Podman と Buildah は、コピーオンライトのサポートを提供しない vfs
ストレージドライバーを使用するように設定されています。より効率的なイメージ管理を行うには、ルートレス環境でコピーオンライトをサポートする fuse-overlayfs ストレージドライバーを使用します。
OpenShift バージョン 4.15 より前のワークスペースで fuse-overlayfs を有効にするには、管理者はまず 「OpenShift バージョン 4.15 より前のバージョンへのアクセスを有効にする」 の手順でクラスター上の /dev/fuse
アクセスを有効にする必要があります。
OpenShift バージョン 4.15 以降では、/dev/fuse
デバイスがデフォルトで使用できるため、これは必要ありません。リリースノート を参照してください。
/dev/fuse
アクセスを有効にした後、fuse-overlayfs は次の 2 つの方法で有効にできます。
- クラスター内のすべてのユーザーワークスペースの場合、「すべてのワークスペースで fuse-overlayfs を有効にする」 を参照してください。
- 特定のユーザーに属するワークスペースの場合、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_dev_spaces/3.18/html-single/user_guide/index#end-user-guide:using-the-fuse-overlay-storage-driver を参照してください。
4.12.1. OpenShift バージョン 4.15 より前のバージョンへのアクセスを有効にする リンクのコピーリンクがクリップボードにコピーされました!
fuse-overlayfs を使用するには、まず /dev/fuse
をワークスペースコンテナーからアクセスできるようにする必要があります。
OpenShift バージョン 4.15 以降では、/dev/fuse
デバイスがデフォルトで使用できるため、この手順は必要ありません。リリースノート を参照してください。
OpenShift クラスター上で MachineConfig
リソースを作成することは、クラスターに高度なシステムレベルの変更を加えることになるため、潜在的に危険なタスクです。
詳細および考えられるリスクは、MachineConfig のドキュメント を参照してください。
前提条件
手順
OpenShift クラスターのタイプ (シングルノードクラスター、または個別のコントロールプレーンとワーカーノードを持つマルチノードクラスター) に基づいて環境変数を設定します。
シングルノードクラスターの場合は、次のように設定します。
NODE_ROLE=master
$ NODE_ROLE=master
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチノードクラスターの場合は、次のように設定します。
NODE_ROLE=worker
$ NODE_ROLE=worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OpenShift Butane 設定バージョンの環境変数を設定します。この変数は、OpenShift クラスターのメジャーバージョンとマイナーバージョンです。たとえば、
4.12.0
、4.13.0
、または4.14.0
です。VERSION=4.12.0
$ VERSION=4.12.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NODE_ROLE
ノードに99-podman-fuse
という名前のドロップイン CRI-O 設定ファイルを作成するMachineConfig
リソースを作成します。この設定ファイルにより、特定の Pod が/dev/fuse
デバイスにアクセスできるようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfig
リソースを適用した後、変更が適用されると、worker
ロールを持つ各ノードのスケジュール設定が一時的に無効になります。ノードのステータスを表示します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow worker
ロールを持つすべてのノードのステータスが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! Toggle word wrap Toggle overflow
検証手順
worker
ロールを持つノードの名前を取得します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノードへの
oc debug
セッションを開きます。oc debug node/<nodename>
$ oc debug node/<nodename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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! Toggle word wrap Toggle overflow
4.12.1.1. ワークスペース内で Podman と Buildah への fuse-overlayfs の使用 リンクのコピーリンクがクリップボードにコピーされました!
https://access.redhat.com/documentation/ja-jp/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 が使用されるようにする方法を説明します。
Universal Developer Image (UDI) には、必要な設定がデフォルトですでに含まれています。ただし、Podman 5.x では /home/user/.config
フォルダーを現在のユーザーが所有する必要があるため、カスタムイメージを使用する場合はスクリプトを手動で設定する必要があります。
前提条件
- OpenShift バージョンが 4.14 以前の場合は 「OpenShift バージョン 4.15 より前のバージョンへのアクセスを有効にする」セクションを完了した。
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。
手順
CheCluster カスタムリソースの
spec.devEnvironments.workspacesPodAnnotations
フィールドに必要なアノテーションを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift バージョン 4.14 以下の場合は、
io.openshift.podman-Fuse: ""
アノテーションも必要です。オプション: ワークスペースコンテナーにカスタムイメージを使用している場合は、
/home/user/.config
フォルダーを作成し、エントリーポイントを介して実行時にstorage.conf
ファイルを設定します。これを行うには、イメージをビルドする前に、ワークスペースコンテナーイメージのエントリーポイントスクリプトに次のコードを追加します。エントリーポイントに/home/user/.config
フォルダーを作成すると、フォルダーは現在のユーザーによって所有されることになりますが、これはイメージのビルド時にはわかりません。Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
/home/user/.config
がまだ存在しない場合は、フォルダーが作成され、所有者はuser
になります。たとえば、永続ボリュームに保存されている場合、/home/user/.config
がすでに存在している可能性があります。ワークスペースを起動し、
/home/user/.config
の所有者がuser
であることを確認します。ls -la /home/user
$ ls -la /home/user
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例:
... 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! Toggle word wrap Toggle overflow ストレージドライバーが
overlay
であることを確認します。podman info | grep overlay
$ podman info | grep overlay
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記既存のワークスペースで、次のエラーが発生する可能性があります。
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! Toggle word wrap Toggle overflow この場合、エラーメッセージに記載されているように libpod ローカルファイルを削除します。
第5章 IDE 拡張機能の管理 リンクのコピーリンクがクリップボードにコピーされました!
IDE は拡張機能またはプラグインを使用して機能を拡張します。拡張機能を管理するメカニズムは IDE によって異なります。
5.1. Microsoft Visual Studio Code の拡張機能 - オープンソース リンクのコピーリンクがクリップボードにコピーされました!
拡張機能を管理するために、この IDE は次の Open VSX レジストリーインスタンスのいずれかを使用します。
-
エアギャップ環境、オフライン環境、およびプロキシー制限環境をサポートする OpenShift Dev Spaces の
プラグインレジストリー
Pod で実行される Open VSX レジストリーの組み込みインスタンス。組み込みの Open VSX レジストリーには、open-vsx.org で公開されている拡張機能のサブセットのみが含まれています。このサブセットは カスタマイズ可能 です。 - インターネット経由でアクセスされるパブリック open-vsx.org レジストリー。
- OpenShift Dev Spaces ワークスペース Pod からアクセスできるネットワーク上にデプロイされるスタンドアロンの Open VSX レジストリーインスタンス。
デフォルトは、Open VSX レジストリーの埋め込みインスタンスです。
5.1.1. Open VSX レジストリーインスタンスの選択 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトは、Open VSX レジストリーの埋め込みインスタンスです。
デフォルトの Open VSX レジストリーインスタンスが必要なものではない場合は、次のいずれかのインスタンスを選択できます。
-
インターネットへのアクセスを必要とする、
https://open-vsx.org
の Open VSX レジストリーインスタンス。 - OpenShift Dev Spaces ワークスペース Pod からアクセスできるネットワーク上にデプロイされるスタンドアロンの 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! Toggle word wrap Toggle overflow - 1
- 例:
openVSXURL: "https://open-vsx.org"
重要- インターネットから隔離されているエアギャップ環境では https://open-vsx.org を使用することは推奨されません。マルウェア感染やコードへの不正アクセスのリスクを軽減するために、組み込みまたはセルフホスト型の Open VSX レジストリーを使用し、厳選された拡張機能セットを利用してください。
-
plugin-registry
Pod に組み込まれた Open VSX レジストリーインスタンスを選択するには、openVSXURL: ''
を使用します。含まれる拡張機能のリストをカスタマイズ できます。 -
また、その URL が組織のクラスター内からアクセス可能であり、プロキシーによってブロックされていない場合は、スタンドアロンの Open VSX レジストリーインスタンスの URL で
openVSXURL
を指すこともできます。
5.1.2. 組み込みの Open VSX レジストリーインスタンスでの拡張機能の追加または削除 リンクのコピーリンクがクリップボードにコピーされました!
埋め込まれた Open VSX レジストリーインスタンスの拡張機能を追加または削除できます。これにより、組織のワークスペースで使用できる Open VSX レジストリーのカスタムビルドが作成されます。
OpenShift Dev Spaces の更新後に最新のセキュリティー修正を取得するには、最新のタグまたは SHA に基づいてコンテナーを再構築します。
手順
選択した各拡張機能の発行元と名前を取得します。
- Open VSX レジストリー Web サイト で拡張機能を見つけて、拡張機能のリストページの URL と拡張機能のバージョンをコピーします。
コピーした URL から <publisher> と <extension> の名前を抽出します。
https://open-vsx.org/extension/<publisher>/<name>
https://open-vsx.org/extension/<publisher>/<name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒント拡張機能が Microsoft Visual Studio Marketplace からのみ入手可能で、Open VSX からは入手できない場合は、拡張機能の発行者に、これらの 手順 に従って open-vsx.org にも公開するように依頼できます。この GitHub アクション を使用する可能性があります。
拡張機能の発行者がいない場合や、または拡張機能を 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 Service Account を作成し、ユーザー名およびトークンをコピーします。
- plugin registry repository を使用してワークスペースを起動します。
ターミナルを開き、OpenShift Dev Spaces のバージョンに対応する Git タグ (例:
devspaces-3.15-rhel-8
) をチェックアウトします。git checkout devspaces-$PRODUCT_VERSION-rhel-8
git checkout devspaces-$PRODUCT_VERSION-rhel-8
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
openvsx-sync.json
ファイルを開き、拡張機能を追加または削除します。 -
ワークスペースの
1.Login to registry.redhat.io
タスクを実行し (Terminal → Run Task… → devfile → 1.Login to registry.redhat.io)、registry.redhat.io にログインします。 -
ワークスペースの
2.Build and Publish a Custom Plugin Registry
タスク (Terminal → Run Task… → devfile → 2.Build and Publish a Custom Plugin Registry) を実行します。 ワークスペースで
3.Configure Che to use the Custom Plugin Registry
タスク (Terminal → Run Task… → devfile → 3.Configure Che to use the Custom Plugin Registry) を実行します。Linux オペレーティングシステムを使用する場合:
ヒント- Podman および NodeJS バージョン 18.20.3 以降がシステムにインストールされている必要があります。
- Dev Spaces repository をダウンロードまたはフォークし、クローンを作成します。
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! Toggle word wrap Toggle overflow - 新しい Red Hat Registry Service Account を作成し、ユーザー名およびトークンをコピーします。
registry.redhat.io にログインします。
podman login registry.redhat.io
podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加または削除する必要がある拡張機能ごと に、
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! Toggle word wrap Toggle overflow ヒントクローズドソースの拡張機能または社内の内部使用のみを目的として開発された拡張機能がある場合は、カスタムプラグインレジストリーコンテナーにアクセスできる 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! Toggle word wrap Toggle overflow - リソースを使用する前に、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! Toggle word wrap Toggle overflow podman push quay.io/<username/plugin_registry:custom>
$ podman push quay.io/<username/plugin_registry:custom>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
イメージ (quay.io など) を指すように、社内のクラスター内の
CheCluster
カスタムリソースを編集し、変更を保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
-
plugin-registry
Pod が再始動して実行中であることを確認します。 - ワークスペースを再起動し、ワークスペース IDE の 拡張機能 ビューで使用可能な拡張機能を確認します。
5.2. Open VSX レジストリー URL リンクのコピーリンクがクリップボードにコピーされました!
拡張機能を検索およびインストールするために、Microsoft Visual Studio Code - Open Source エディターは組み込みの Open VSX レジストリーインスタンスを使用します。組み込みのレジストリーインスタンスではなく、別の Open VSX レジストリーインスタンスを使用するように OpenShift Dev Spaces を設定することもできます。
手順
CheCluster カスタムリソースの
spec.components.pluginRegistry.openVSXURL
フィールドに Open VSX レジストリーインスタンスの URL を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告Microsoft の専用の 使用条件 により、Visual Studio Code Marketplace は Red Hat OpenShift Dev Spaces ではサポートされていません。
第6章 Visual Studio Code - Open Source ("Code - OSS") の設定 リンクのコピーリンクがクリップボードにコピーされました!
Visual Studio Code - Open Source ("Code - OSS") を設定する方法を学習します。
6.1. 単一ルートおよびマルチルートワークスペースの設定 リンクのコピーリンクがクリップボードにコピーされました!
マルチルートワークスペース機能を使用すると、同じワークスペース内で複数のプロジェクトフォルダーを操作できます。これは、製品ドキュメントや製品コードリポジトリーなど、複数の関連プロジェクトを同時に作業する場合に便利です。
ワークスペースファイルをよりよく理解して作成するには、What is a VS Code "workspace" を参照してください。
ワークスペースは、デフォルトでマルチルートモードで開くように設定されています。
ワークスペースが起動すると、/projects/.code-workspace
ワークスペースファイルが生成されます。ワークスペースファイルには、devfile に記述されているすべてのプロジェクトが含まれます。
ワークスペースファイルがすでに存在する場合は更新され、不足しているプロジェクトはすべて devfile から取得されます。devfile からプロジェクトを削除すると、ワークスペースファイルに残ります。
デフォルトの動作を変更して独自のワークスペースファイルを提供したり、単一ルートワークスペースに切り替えたりできます。
手順
独自のワークスペースファイルを提供します。
.code-workspace
という名前のワークスペースファイルをリポジトリーのルートに配置します。ワークスペースの作成後、Visual Studio Code - Open Source ("Code - OSS") はワークスペースファイルをそのまま使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要ワークスペースファイルを作成するときは注意してください。エラーが発生した場合は、代わりに空の Visual Studio Code - Open Source ("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! Toggle word wrap Toggle overflow
ワークスペースをシングルルートモードで開きます。
VSCODE_DEFAULT_WORKSPACE 環境変数を定義し、ルートに設定します。
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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! Toggle word wrap Toggle overflow VSCODE_TRUSTED_EXTENSIONS 環境変数を使用して ConfigMap をマウントします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
-
変数の値はワークスペースの起動時に解析され、対応する
trustedExtensionAuthAccess
セクションがproduct.json
に追加されます。
6.3. デフォルトの拡張機能の設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの拡張機能は、プリインストールされた拡張機能のセットです。これは、拡張機能のバイナリー .vsix
ファイルのパスを DEFAULT_EXTENSIONS 環境変数に設定することで指定されます。
起動後、エディターはこの環境変数を確認し、指定されていれば拡張機能のパスを取得し、ユーザーの作業を妨げることなくバックグラウンドでインストールします。
デフォルトの拡張機能の設定は、エディターレベルで .vsix 拡張機能をインストールする場合に便利です。
複数の拡張機能を指定する場合は、セミコロンで区切ります。
DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
DEFAULT_EXTENSIONS 環境変数を定義する方法について、.vsix
ファイルをワークスペースに追加する複数の例を交えて説明します。
デフォルトの .vsix
拡張機能をワークスペースに組み込むには、次の 3 つの方法があります。
- 拡張機能のバイナリーをソースリポジトリーに配置します。
-
devfile の
postStart
イベントを使用して、ネットワークから拡張機能のバイナリーを取得します。 -
拡張機能の
.vsix
バイナリーをche-code
イメージに追加します。
拡張機能のバイナリーをソースリポジトリーに配置する
拡張バイナリーを Git リポジトリーに配置し、devfile で環境変数を定義するのが、デフォルトの拡張機能をワークスペースに追加する最も簡単な方法です。extension.vsix
ファイルがリポジトリーのルートに存在する場合は、ツールコンテナーに DEFAULT_EXTENSIONS を設定できます。
手順
以下の例のように、
.devfile.yaml
で DEFAULT_EXTENSIONS を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
devfile の postStart イベントを使用してネットワークから拡張機能のバイナリーを取得する
cURL または GNU Wget を使用して、拡張機能をワークスペースにダウンロードできます。そのためには、以下を行う必要があります。
- 拡張機能をワークスペースにダウンロードするための devfile コマンドを指定する
-
postStart
イベントを追加して、ワークスペースの起動時にコマンドを実行する - devfile で DEFAULT_EXTENSIONS 環境変数を定義する
手順
以下の例に示されている値を devfile に追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告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! Toggle word wrap Toggle overflow
che-code
イメージに拡張機能の .vsix
バイナリーを追加する
エディターイメージにバンドルされているデフォルトの拡張機能と、ConfigMap で定義した DEFAULT_EXTENSIONS 環境変数を使用すると、devfile を変更せずにデフォルトの拡張機能を適用できます。
以下の手順に従って、必要な拡張機能をエディターイメージに追加します。
手順
-
ディレクトリーを作成し、選択した
.vsix
拡張機能をこのディレクトリーに配置します。 以下の内容で Dockerfile を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージをビルドし、これをレジストリーにプッシュします。
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! Toggle word wrap Toggle overflow 新しい ConfigMap をユーザーのプロジェクトに追加し、DEFAULT_EXTENSIONS 環境変数を定義して、拡張機能の絶対パスを指定します。この ConfigMap は、環境変数をユーザーのプロジェクトのすべてのワークスペースに設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow yourname/che-code:next
イメージを使用してワークスペースを作成します。まず、ダッシュボードを開き、左側の Create Workspace タブに移動します。- Editor Selector セクションで、Use an Editor Definition ドロップダウンを展開し、エディターの URI を Editor Image に設定します。
- サンプルをクリックするか、Git リポジトリー URL を使用してワークスペースを作成します。
第7章 Dev Spaces サーバー API の使用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces サーバーのワークロードを管理するには、Swagger Web ユーザーインターフェイスを使用して OpenShift Dev Spaces サーバー API をナビゲートします。
手順
-
Swagger API Web ユーザーインターフェイス:
https://<openshift_dev_spaces_fqdn>/swagger
に移動します。
関連情報
第8章 Dev Spaces のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
この章では、CodeReady Workspaces 3.1 から OpenShift Dev Spaces 3.18 にアップグレードする方法を説明します。
8.1. chectl 管理ツールのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、dsc
管理ツールをアップグレードする方法を説明します。
8.2. 更新承認ストラテジーの指定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Dev Spaces Operator は、2 つのアップグレードストラテジーをサポートしています。
自動
- Operator は、新しい更新が利用可能になったときにそれらをインストールします。
Manual
- インストールを開始する前に、新しい更新を手動で承認する必要があります。
OpenShift Web コンソールを使用して、Red Hat OpenShift Dev Spaces Operator の更新承認ストラテジーを指定できます。
前提条件
- クラスター管理者による OpenShift Web コンソールセッション。Web コンソールへのアクセス を参照してください。
- Red Hat エコシステムカタログを使用してインストールされた OpenShift Dev Spaces のインスタンス。
手順
- OpenShift Web コンソールで、 → に移動します。
- インストールされているオペレーターのリストで Red Hat OpenShift Dev Spaces をクリックします。
- Subscription タブに移動します。
-
更新承認 ストラテジーを
Automatic
またはManual
に設定します。
関連情報
8.3. OpenShift Web コンソールを使用した Dev Spaces のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Web コンソールの Red Hat エコシステムカタログにある Red Hat OpenShift Dev Spaces Operator を使用して、以前のマイナーバージョンからのアップグレードを手動で承認できます。
前提条件
- クラスター管理者による OpenShift Web コンソールセッション。Web コンソールへのアクセス を参照してください。
- Red Hat エコシステムカタログを使用してインストールされた OpenShift Dev Spaces のインスタンス。
-
サブスクリプションの承認ストラテジーは
Manual
になります。「更新承認ストラテジーの指定」 を参照してください。
手順
- 保留中の Red Hat OpenShift Dev Spaces Operator のアップグレードを手動で承認します。保留中の Operator アップグレードの手動による承認 を参照してください。
検証手順
- OpenShift Dev Spaces インスタンスに移動します。
- 3.18 バージョン番号はページの下部に表示されます。
8.4. CLI 管理ツールを使用した Dev Spaces のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、CLI 管理ツールを使用して以前のマイナーバージョンからアップグレードする方法を説明します。
前提条件
- OpenShift の管理者アカウント。
-
以前のマイナーバージョンの CodeReady Workspaces の実行中のインスタンス。これは
openshift-devspaces
OpenShift プロジェクトの同じ OpenShift インスタンス上で CLI 管理ツールを使用してインストールします。 -
OpenShift Dev Spaces バージョン 3.18 の
dsc
。「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! Toggle word wrap Toggle overflow 注記低速なシステムまたはインターネット接続の場合は、
--k8spodwaittimeout=1800000
フラグオプションを追加して、Pod のタイムアウト期間を 1800000 ms 以上に拡張します。
検証手順
- OpenShift Dev Spaces インスタンスに移動します。
- 3.18 バージョン番号はページの下部に表示されます。
8.5. 制限された環境での Dev Spaces のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat OpenShift Dev Spaces をアップグレードして、制限された環境で CLI 管理ツールを使用してマイナーバージョンの更新を実行する方法を説明します。
前提条件
-
OpenShift Dev Spaces インスタンスは、
openshift-devspaces
プロジェクトのdsc --installer operator
メソッドを使用して OpenShift にインストールされている。「制限された環境での Dev Spaces のインストール」 を参照してください。
- OpenShift クラスターに、少なくとも 64 GB のディスクスペースがある。
- OpenShift クラスターは、制限されたネットワーク上で動作する準備ができている。非接続インストールミラーリングについて および ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。OpenShift CLI のスタートガイド を参照してください。 -
registry.redhat.io
Red Hat エコシステムカタログへのアクティブなoc
レジストリーセッション。Red Hat Container Registry authentication を参照してください。
-
opm
。opm
CLI のインストール を参照してください。 -
jq
。Downloadingjq
を参照してください。 -
podman
。Podman Installation Instructions を参照してください。 -
skopeo
バージョン 1.6 以降。Installing Skopeo を参照してください。 -
プライベート Docker レジストリーへの管理アクセス権を持つアクティブな
skopeo
セッション。レジストリーへの認証 および 非接続インストールのイメージのミラーリング を参照してください。 -
OpenShift Dev Spaces バージョン 3.18 の
dsc
。「dsc 管理ツールのインストール」を参照してください。
手順
ミラーリングスクリプトをダウンロードして実行し、カスタム Operator カタログをインストールし、関連するイメージをミラーリングします (prepare-restricted-environment.sh)。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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! Toggle word wrap Toggle overflow
検証手順
- 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 Web コンソールの Installed Operators ページに、Dev Workspace Operator の複数のエントリーが表示されるか、1 つのエントリーが Replaceing と Pending のループに陥っています。
手順
-
失敗した Pod を含む
devworkspace-controller
namespace を削除します。 DevWorkspace
およびDevWorkspaceTemplate
カスタムリソース定義 (CRD) を更新するには、変換ストラテジーをNone
に設定し、webhook
セクション全体を削除します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントDevWorkspace
を検索することにより、OpenShift Web コンソールの Administrator パースペクティブで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! Toggle word wrap Toggle overflow - 1
openshift-operators
または Dev Workspace Operator がインストールされている OpenShift プロジェクト。
<devworkspace-operator.vX.Y.Z> 形式で Dev Workspace Operator CSV を取得します。
oc get csv | grep devworkspace
$ oc get csv | grep devworkspace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各 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! Toggle word wrap Toggle overflow - 1
openshift-operators
または Dev Workspace Operator がインストールされている OpenShift プロジェクト。
Dev Workspace Operator サブスクリプションを再作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Automatic
またはManual
。
重要installPlanApproval: Manual
の場合、OpenShift Web コンソールの Administrator パースペクティブで → に移動し、Dev Workspace Operator: → → に対して以下を選択します。- OpenShift Web コンソールの Administrator パースペクティブで、 → に移動し、Dev Workspace Operator の Succeeded ステータスを確認します。
第9章 Dev Spaces のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Dev Spaces をアンインストールすると、OpenShift Dev Spaces 関連のすべてのユーザーデータが削除されます。
oc
を使用して OpenShift Dev Spaces インスタンスをアンインストールします。
前提条件
-
dsc
。「dsc 管理ツールのインストール」 を参照してください。
手順
OpenShift Dev Spaces インスタンスを削除します。
dsc server:delete
$ dsc server:delete
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
--delete-namespace
オプションは、OpenShift Dev Spaces namespace を削除します。
--delete-all
オプションは、Dev Workspace Operator と関連リソースを削除します。