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 Workspace Operator」 は、永続ボリューム要求を作成します。
OpenShift Dev Spaces PVC のストレージクラス機能を使用するには、OpenShift Dev Spaces 設定でストレージクラス名を定義します。
手順
CheCluster カスタムリソース定義を使用してストレージクラスを定義します。
ストレージクラス名を定義します。
CheClusterカスタムリソースを設定し、OpenShift Dev Spaces をインストールします。「dsc を使用したインストール時にCheClusterカスタムリソースの設定」 を参照してください。spec: devEnvironments: storage: perUserStrategyPvcConfig: claimSize: <claim_size>1 storageClass: <storage_class_name>2 perWorkspaceStrategyPvcConfig: claimSize: <claim_size>3 storageClass: <storage_class_name>4 pvcStrategy: <pvc_strategy>5
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'
- 1
- 利用可能なストレージストラテジーは、
per-user、per-workspaceおよびephemeralです。
4.9.3. ストレージサイズの設定 リンクのコピーリンクがクリップボードにコピーされました!
永続ボリューム要求 (PVC) サイズは、per-user または per-workspace のストレージストラテジーを使用して設定できます。CheCluster カスタムリソースの PVC サイズを Kubernetes リソース数量 の形式で指定する必要があります。利用可能なストレージストラテジーの詳細は、こちらのページ を参照してください。
デフォルトの永続ボリューム要求サイズ:
per-user: 10Giper-workspace: 5Gi
手順
-
Che Cluster カスタムリソースで、必要なストレージストラテジーの適切な
claimSizeフィールドを設定します。
-
このフィールドは、インストール時に設定できます。「dsc を使用したインストール時に
CheClusterカスタムリソースの設定」 を参照してください。 - このフィールドは、コマンドラインで更新できます。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。
spec:
devEnvironments:
storage:
pvc:
pvcStrategy: '<strategy_name>'
perUserStrategyPvcConfig:
claimSize: <resource_quantity>
perWorkspaceStrategyPvcConfig:
claimSize: <resource_quantity>
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
上記のコマンドにより、/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
これは、/home/tooling のファイルが persistUserHome 機能を使用していなくても /home/user からアクセスできるように Dockerfile で実行されます。