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
カスタムリソースの設定」 を参照してください。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
のコンテンツへのシンボリックリンクが追加されます。その結果、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 で実行されます。