This documentation is for a release that is no longer maintained
See documentation for the latest supported version.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: 10GiCopy to Clipboard Copied! Toggle word wrap Toggle overflow per-workspace: 5Gi
per-workspace: 5GiCopy 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 のコンテンツへのシンボリックリンクが追加されます。その結果、persistUserHome 機能は、ツールイメージの /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 で実行されます。