ユーザーガイド


Red Hat OpenShift Dev Spaces 3.9

Red Hat OpenShift Dev Spaces 3.9 の使用

Robert Kratky

Fabrice Flore-Thébault

Red Hat Developer Group Documentation Team

概要

Red Hat OpenShift Dev Spaces を使用するユーザー向けの情報

第1章 Dev Spaces のスタートガイド

組織ですでに OpenShift Dev Spaces インスタンスを実行している場合は、新しいワークスペースを開始し、ワークスペースを管理し、ワークスペースから Git サーバーに対して自分自身を認証する方法を学習することで、新しいユーザーとして開始できます。

1.1. Git リポジトリー URL からのワークスペースの開始

OpenShift Dev Spaces を使用すると、ブラウザーで URL を使用して、Git リポジトリーのクローンを含む新しいワークスペースを開始できます。このようにして、GitHub、GitLab、Bitbucket、または Microsoft Azure DevOps サーバーインスタンスでホストされている Git リポジトリーのクローンを作成できます。

ヒント

OpenShift Dev Spaces ダッシュボードの Create Workspace ページにある Git Repository URL フィールドを使用して、Git リポジトリーの URL を入力し、新しいワークスペースを開始することもできます。

重要
  • GitHub、GiLab、Bitbucket、または Microsoft Azure DevOps 以外の Git サービスからの URL を使用してワークスペースを開始すると、失敗します。
  • SSH URL を使用して新しいワークスペースを開始する場合は、SSH キーを伝播する必要があります。詳細は、Git 操作に SSH キーを使用するための DevWorkspaces の設定 を参照してください。
  • SSH URL がプライベートリポジトリーを参照する場合は、devfile.yaml コンテンツを取得できるようにアクセストークンを適用する必要があります。これは、SCM 認証ページの受け入れ、または パーソナルアクセストークン 手順の実行のいずれかで実行できます。
重要

プライベートリポジトリーにアクセスできるように、パーソナルアクセストークンを設定します。「Git プロバイダーアクセストークンの使用」を参照してください。

前提条件

  • 組織に、OpenShift Dev Spaces の実行中のインスタンスがある。
  • 組織の OpenShift Dev Spaces インスタンスの FQDN URL はわかっています: https://<openshift_dev_spaces_fqdn>
  • オプション: Git サーバーへの認証 が設定されています。
  • Git リポジトリーのメンテナーは、devfile.yaml または .devfile.yaml ファイルを Git リポジトリーのルートディレクトリーに保持します。(代替ファイル名とファイルパスについては、「新しいワークスペースを開始するための URL の任意のパラメーター」 を参照してください。)

    ヒント

    devfile を含まない Git リポジトリーの URL を指定して、新しいワークスペースを開始することもできます。これにより、Universal Developer Image and with Microsoft Visual Studio Code - Open Source をワークスペース IDE として使用するワークスペースが作成されます。

手順

Git リポジトリーのクローンを使用して新しいワークスペースを開始するには、以下を行います。

  1. オプション: OpenShift Dev Spaces ダッシュボードページにアクセスして、組織の OpenShift Dev Spaces のインスタンスを認証します。
  2. URL にアクセスして、基本的な構文を使用して新しいワークスペースを開始します。

    https://<openshift_dev_spaces_fqdn>#<git_repository_url>
    ヒント

    この URL は、任意のパラメーターを使用して拡張できます。

    https://<openshift_dev_spaces_fqdn>#<git_repository_url>?<optional_parameters> 1
    ヒント

    Git+SSH URL を使用して、新しいワークスペースを開始できます。Git 操作に SSH キーを使用するための DevWorkspaces の設定 を参照してください。

    例1.1 新しいワークスペースを開始するための URL

    • https://<openshift_dev_spaces_fqdn>#https://github.com/che-samples/cpp-hello-world
    • https://<openshift_dev_spaces_fqdn>#git@github.com:che-samples/cpp-hello-world.git

    例1.2 GitHub インスタンスリポジトリーのクローンを使用して、新しいワークスペースを開始するための URL 構文

    • https://<openshift_dev_spaces_fqdn>#https://<github_host>/<user_or_org>/<repository> は、デフォルトブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#https://<github_host>/<user_or_org>/<repository>/tree/<branch_name> は、指定されたブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#https://<github_host>/<user_or_org>/<repository>/pull/<pull_request_id> は、プルリクエストのブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#git@<github_host>:<user_or_org>/<repository>.git は、Git+SSH URL から新しいワークスペースを開始します。

    例1.3 GitLab インスタンスリポジトリーのクローンを使用して、新しいワークスペースを開始するための URL 構文

    • https://<openshift_dev_spaces_fqdn>#https://<gitlab_host>/<user_or_org>/<repository> は、デフォルトブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#https://<gitlab_host>/<user_or_org>/<repository>/-/tree/<branch_name> は、指定されたブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#git@<gitlab_host>:<user_or_org>/<repository>.git は、Git+SSH URL から新しいワークスペースを開始します。

    例1.4 BitBucket Server リポジトリーのクローンを使用して新しいワークスペースを開始するための URL 構文

    • https://<openshift_dev_spaces_fqdn>#https://<bb_host>/scm/<project-key>/<repository>.git は、デフォルトブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#https://<bb_host>/users/<user_slug>/repos/<repository>/ は、リポジトリーがユーザープロファイルの下に作成された場合、デフォルトブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#https://<bb_host>/users/<user-slug>/repos/<repository>/browse?at=refs%2Fheads%2F<branch-name> は、指定されたブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#git@<bb_host>:<user_slug>/<repository>.git は、Git+SSH URL から新しいワークスペースを開始します。

    例1.5 Microsoft Azure DevOps Git リポジトリーのクローンを使用して新しいワークスペースを開始するための URL 構文

    • https://<openshift_dev_spaces_fqdn>#https://<organization>@dev.azure.com/<organization>/<project>/_git/<repository> は、デフォルトのブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#https://<organization>@dev.azure.com/<organization>/<project>/_git/<repository>?version=GB<branch> は、特定のブランチのクローンを使用して、新しいワークスペースを開始します。
    • https://<openshift_dev_spaces_fqdn>#git@ssh.dev.azure.com:v3/<organization>/<project>/<repository> は、Git+SSH URL から新しいワークスペースを開始します。

    ブラウザータブで新しいワークスペースを開始するための URL を入力すると、ワークスペース開始ページが表示されます。

    新しいワークスペースの準備ができると、ワークスペース IDE がブラウザータブにロードされます。

    Git リポジトリーのクローンは、新しいワークスペースのファイルシステムに存在します。

    ワークスペースには、次のような一意の URL があります: https://<openshift_dev_spaces_fqdn>/<user_name>/<unique_url>

1.1.1. 新しいワークスペースを開始するための URL の任意のパラメーター

新しいワークスペースを開始すると、OpenShift Dev Spaces は devfile の指示に従ってワークスペースを設定します。URL を使用して新しいワークスペースを開始する場合は、ワークスペースをさらに設定する任意のパラメーターを URL に追加できます。これらのパラメーターを使用して、ワークスペース IDE を指定し、複製ワークスペースを開始し、devfile ファイル名またはパスを指定できます。

1.1.1.1. URL パラメーターの連結

新しいワークスペースを開始するための URL は、次の URL 構文で & を使用することにより、複数の任意の URL パラメーターの連結をサポートします。

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?<url_parameter_1>&<url_parameter_2>&<url_parameter_3>

例1.6 Git リポジトリーの URL と任意の URL パラメーターを使用して新しいワークスペースを開始するための URL

ブラウザーの完全な URL:

https://<openshift_dev_spaces_fqdn>#https://github.com/che-samples/cpp-hello-world?new&che-editor=che-incubator/intellij-community/latest&devfilePath=tests/testdevfile.yaml

URL の部分の説明:

https://<openshift_dev_spaces_fqdn> 1
#https://github.com/che-samples/cpp-hello-world 2
?new&che-editor=che-incubator/intellij-community/latest&devfilePath=tests/testdevfile.yaml 3
1
OpenShift Dev Spaces URL
2
新しいワークスペースに複製される Git リポジトリーの URL。
3
連結された任意の URL パラメーター。
1.1.1.2. IDE の URL パラメーター

URL パラメーター che-editor= を使用して、ワークスペースの開始時にサポートされている IDE を指定できます。

ヒント

ソースコード Git リポジトリーで /.che/che-editor.yaml ファイルを追加または編集して、ワークスペース用に複製できない場合は、che-editor= パラメーターを使用します。

注記

che-editor= パラメーターは /.che/che-editor.yaml ファイルをオーバーライドします。

このパラメーターは、次の 2 種類の値を受け入れます。

  • che-editor=<editor_key>

    https://<openshift_dev_spaces_fqdn>#<git_repository_url>?che-editor=<editor_key>
    表1.1 サポートされている IDE の URL パラメーター <editor_key> の値
    IDE<editor_key>注記

    Microsoft Visual Studio Code - Open Source

    che-incubator/che-code/latest

    これは、URL パラメーターまたは che-editor.yaml が使用されていない場合に新しいワークスペースに読み込まれるデフォルトの IDE です。

    JetBrains IntelliJ IDEA コミュニティー版

    che-incubator/che-idea/latest

    テクノロジープレビュー。Dashboard を使用してこの IDE を選択します。

  • che-editor=<url_to_a_file>

    https://<openshift_dev_spaces_fqdn>#<git_repository_url>?che-editor=<url_to_a_file>1
    1
    devfile の内容 を含むファイルへの URL。
    ヒント
    • URL は、RAW ファイルの内容を指している必要があります。
    • このパラメーターを che-editor.yaml ファイルで使用するには、ファイルを別の名前またはパスでコピーし、ファイルから inline の行を削除します。
1.1.1.3. 重複するワークスペースを開始するための URL パラメーター

新しいワークスペースを開始するために URL にアクセスすると、devfile に従って、リンクされた Git リポジトリーのクローンを使用して新しいワークスペースが作成されます。

状況によっては、devfile とリンクされた Git リポジトリーに関して重複する複数のワークスペースが必要になる場合があります。これを行うには、同じ URL にアクセスして、URL パラメーターを使用して新しいワークスペースを開始します。

複製ワークスペースを開始するための URL パラメーターは new です。

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?new
注記

現在 URL の使用を開始したワークスペースがある場合、new URL パラメーターを指定せずに URL に再度アクセスすると、エラーメッセージが表示されます。

1.1.1.4. devfile ファイル名の URL パラメーター

新しいワークスペースを開始するために URL にアクセスすると、OpenShift Dev Spaces は、リンクされた Git リポジトリーで、ファイル名が .devfile.yaml または devfile.yaml の devfile を検索します。リンクされた Git リポジトリー内の devfile は、このファイル命名規則に従う必要があります。

状況によっては、devfile に別の型にはまらないファイル名を指定する必要がある場合があります。

devfile の型にはまらないファイル名を指定するための URL パラメーターは df=<filename>.yaml です。

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?df=<filename>.yaml 1
1
<filename>.yaml は、リンクされた Git リポジトリー内の devfile の型にはまらないファイル名です。
ヒント

df=<filename>.yaml パラメーターにも長いバージョン (devfilePath=<filename>.yaml) があります。

1.1.1.5. devfile ファイルパスの URL パラメーター

新しいワークスペースを開始するために URL にアクセスすると、OpenShift Dev Spaces は、リンクされた Git リポジトリーの root ディレクトリーで、ファイル名が .devfile.yaml または devfile.yaml の devfile を検索します。リンクされた Git リポジトリー内の devfile のファイルパスは、このパス規則に従う必要があります。

状況によっては、リンクされた Git リポジトリー内の devfile に別の型にはまらないファイルパスを指定する必要がある場合があります。

devfile の型にはまらないファイルパスを指定するための URL パラメーターは devfilePath=<relative_file_path> です。

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?devfilePath=<relative_file_path> 1
1
<relative_file_path> は、リンクされた Git リポジトリー内の devfile の型にはまらないファイルパスです。
1.1.1.6. ワークスペースストレージの URL パラメーター

新規ワークスペースを起動する URL にストレージタイプを指定する URL パラメーターが含まれていない場合、新規ワークスペースは一時ストレージまたは永続ストレージに作成されます。これは、CheCluster カスタムリソースのデフォルトストレージタイプとして定義されます。

ワークスペースのストレージタイプを指定する URL パラメーターは、storageType= <storage_type> です。

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?storageType=<storage_type> 1
1
使用できる <storage_type> の値:
  • ephemeral
  • per-user (永続)
  • per-workspace (永続)
ヒント

ephemeral または per-workspace ストレージタイプを使用すると、複数のワークスペースを同時に実行できますが、これはデフォルト per-user ストレージタイプでは不可能です。

1.1.1.7. 追加のリモートの URL パラメーター

新しいワークスペースを開始するための URL にアクセスすると、OpenShift Dev Spaces は origin リモートを、組織の OpenShift Dev Spaces インスタンスの FQDN URL の後に # で指定した Git リポジトリーになるように設定します。

ワークスペースの追加のリモートを複製および設定するための URL パラメーターは、remotes= です。

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?remotes={{<name_1>,<url_1>},{<name_2>,<url_2>},{<name_3>,<url_3>},...}
重要
  • 追加のリモートのいずれにも origin という名前を入力しない場合、<git_repository_url> からのリモートが複製され、デフォルトで origin という名前が付けられ、想定されるブランチが自動的にチェックアウトされます。
  • 追加のリモートの 1 つに名前 origin を入力すると、そのデフォルトブランチは自動的にチェックアウトされますが、<git_repository_url> からのリモートはワークスペース用に複製されません。
1.1.1.8. コンテナーイメージの URL パラメーター

次のシナリオでは、image パラメーターを使用して、コンテナーイメージへのカスタム参照を使用できます。

  • Git リポジトリーに devfile が含まれていないため、カスタムイメージを使用して新しいワークスペースを開始したい場合。
  • Git リポジトリーには devfile が含まれており、devfile の components セクションにリストされている最初のコンテナーイメージをオーバーライドしたい場合。

コンテナーイメージへのパスの URL パラメーターは image= です。

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?image=<container_image_url>

https://<openshift_dev_spaces_fqdn>#https://github.com/eclipse-che/che-docs?image=quay.io/devfile/universal-developer-image:ubi8-latest

1.2. raw devfile URL からワークスペースを起動する

OpenShift Dev Spaces を使用すると、ブラウザーで devfile URL を開いて、新しいワークスペースを起動できます。

ヒント

OpenShift Dev Spaces ダッシュボードの Create Workspace ページの Git Repo URL フィールドを使用して、devfile の URL を入力し、新しいワークスペースを開始できます。

重要

新しいワークスペースのファイルシステムで Git リポジトリーのクローンを開始するには、devfile にプロジェクト情報が含まれている必要があります。

https://devfile.io/docs/2.2.0/adding-projects を参照してください。

前提条件

  • 組織に、OpenShift Dev Spaces の実行中のインスタンスがある。
  • 組織の OpenShift Dev Spaces インスタンスの FQDN URL はわかっています: https://<openshift_dev_spaces_fqdn>

手順

devfile URL から新しいワークスペースを起動するには:

  1. オプション: OpenShift Dev Spaces ダッシュボードページにアクセスして、組織の OpenShift Dev Spaces のインスタンスを認証します。
  2. URL にアクセスし、基本構文を使用して パブリック リポジトリーから新しいワークスペースを開始します。

    https://<openshift_dev_spaces_fqdn>#<devfile_url>

    パーソナルアクセストークンを URL に渡して、プライベート リポジトリーから devfile にアクセスできます。

    https://<openshift_dev_spaces_fqdn>#https://<token>@<host>/<path_to_devfile> 1
    1
    Git プロバイダーの Web サイトで生成したパーソナルアクセストークン。

    これは、GitHub、GitLab、Bitbucket、Microsoft Azure、およびパーソナルアクセストークンをサポートするその他のプロバイダーで機能します。

    重要

    この場合、自動化された Git 認証情報インジェクションは機能しません。Git 認証情報を設定するには、パーソナルアクセストークンの設定 ガイドを使用します。

    ヒント

    この URL は、任意のパラメーターを使用して拡張できます。

    https://<openshift_dev_spaces_fqdn>#<devfile_url>?<optional_parameters> 1

    例1.7 パブリックリポジトリーから新しいワークスペースを開始するための URL

    https://<openshift_dev_spaces_fqdn>#https://raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml

    例1.8 プライベートリポジトリーから新しいワークスペースを開始するための URL

    https://<openshift_dev_spaces_fqdn>#https://<token>@raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml

    検証

    ブラウザータブで新しいワークスペースを開始するための URL を入力すると、ワークスペース開始ページが表示されます。新しいワークスペースの準備ができると、ワークスペース IDE がブラウザータブにロードされます。

    ワークスペースには、次のような一意の URL があります: https://<openshift_dev_spaces_fqdn>/<user_name>/<unique_url>

1.3. ワークスペースで実行できる基本的なアクション

OpenShift Dev Spaces ダッシュボードの Workspaces ページ (https://<openshift_dev_spaces_fqdn>/dashboard/#/workspaces) でワークスペースを管理し、現在の状態を確認します。

新しいワークスペースを開始した後、Workspaces ページで次のアクションを実行できます。

表1.2 ワークスペースで実行できる基本的なアクション
アクションワークスペースページの GUI ステップ

実行中のワークスペースを再度開く

開く をクリックします。

実行中のワークスペースを再起動する

> Restart Workspace に移動します。

実行中のワークスペースを停止する

> Stop Workspace に移動します。

停止したワークスペースを開始する

開く をクリックします。

ワークスペースを削除する

> Delete Workspace に移動します。

1.4. ワークスペースから Git サーバーへの認証

ワークスペースでは、リモートのプライベート Git リポジトリーのクローンを作成したり、リモートのパブリックまたはプライベート Git リポジトリーにプッシュしたりするなど、ユーザー認証を必要とする Git コマンドを実行できます。

ワークスペースから Git サーバーへのユーザー認証は、管理者によって設定されるか、場合によっては個々のユーザーによって設定されます。

第2章 チームワークフローでの Dev Spaces の使用

組織で OpenShift Dev Spaces を使用する利点について、以下の記事で説明します。

2.1. 初めて貢献する方のためのバッジ

初めての貢献者がプロジェクトでワークスペースを開始できるようにするには、OpenShift Dev Spaces インスタンスへのリンクを含むバッジを追加します。

図2.1 ファクトリーバッジ

手順

  1. OpenShift Dev Spaces URL (https://<openshift_dev_spaces_fqdn>) とリポジトリー URL (<your_repository_url>) を置き換えて、プロジェクトの README.md ファイルにリポジトリーへのリンクを追加します。

    [![Contribute](https://www.eclipse.org/che/contribute.svg)](https://<openshift_dev_spaces_fqdn>/#https://<your_repository_url>)
  2. Git プロバイダーの Web インターフェイスの README.md ファイルには、 ファクトリーバッジが表示されます。バッジをクリックして、OpenShift Dev Spaces インスタンスでプロジェクトを含むワークスペースを開きます。

2.2. プル要求およびマージ要求の確認

Red Hat OpenShift Dev Spaces ワークスペースには、プルリクエストとマージリクエストを最初から最後まで確認するために必要なすべてのツールが含まれています。OpenShift Dev Spaces リンクをクリックすると、Red Hat OpenShift DevSpaces でサポートされている Web IDE にアクセスでき、リンター、単体テスト、ビルドなどを実行できるすぐに使用できるワークスペースがあります。

前提条件

  • Git プロバイダーによってホストされているリポジトリーにアクセスできる。
  • OpenShift Dev Spaces インスタンスにアクセスできる。

手順

  1. 機能ブランチを開いて、OpenShift Dev Spaces で確認します。ブランチのクローンが、デバッグとテスト用のツールを備えたワークスペースで開きます。
  2. プルまたはマージ要求の変更を確認してください。
  3. 必要なデバッグおよびテストツールを実行します。

    • リンターを実行します。
    • ユニットテストを実行します。
    • ビルドを実行します。
    • アプリケーションを実行して問題を確認します。
  4. Git プロバイダーの UI に移動してコメントを残し、割り当てられたリクエストをプルまたはマージします。

検証

  • (オプション) リポジトリーのメインブランチを使用して 2 番目のワークスペースを開き、問題を再現します。

2.3. Web IDE GitHub アクションで試す

Try in Web IDE GitHub アクション を GitHub リポジトリーワークフローに追加すると、レビュー担当者は Red Hat がホストする Eclipse Che でプルリクエストを迅速にテストできます。このアクションは、プルリクエストイベントをリッスンし、コメント、ステータスチェック、またはその両方を作成してファクトリー URL を提供することでこれを実現します。このファクトリー URL は、Red Hat がホストする Eclipse Che のプルリクエストブランチから新しいワークスペースを作成します。

注記

Che ドキュメントリポジトリー (https://github.com/eclipse/che-docs) は、レビュー担当者がプルリクエストを迅速にテストする際にTry in Web IDE GitHub アクションが役立つ実際の例です。最近のプルリクエストに移動してファクトリー URL を開き、ワークフローを体験してください。

図2.2 Try in Web IDE GitHub アクションによって作成されたプルリクエストコメント。バッジをクリックすると、レビュー担当者がプルリクエストをテストするための新しいワークスペースが開きます。

test

図2.3 Try in Web IDE GitHub アクションによって作成されたプルリクエストステータスチェック。"Details" リンクをクリックすると、レビュー担当者がプルリクエストをテストするための新しいワークスペースが開きます。

test

2.3.1. GitHub リポジトリーワークフローへのアクションの追加

このセクションでは、Try in Web IDE GitHub アクションを GitHub リポジトリーワークフローに統合する方法について説明します。

前提条件

  • GitHub リポジトリー
  • GitHub リポジトリーのルートにある devfile。

手順

  1. GitHub リポジトリーに、.github/workflows ディレクトリーを作成します (まだ存在しない場合)。
  2. 以下の内容で、.github/workflows ディレクトリーに example.yml ファイルを作成します。

    例2.1 example.yml

    name: Try in Web IDE example
    
    on:
      pull_request_target:
        types: [opened]
    
    jobs:
      add-link:
        runs-on: ubuntu-20.04
        steps:
          - name: Web IDE Pull Request Check
            id: try-in-web-ide
            uses: redhat-actions/try-in-web-ide@v1
            with:
              # GitHub action inputs
    
              # required
              github_token: ${{ secrets.GITHUB_TOKEN }}
    
              # optional - defaults to true
              add_comment: true
    
              # optional - defaults to true
              add_status: true

    このコードスニペットは、redhat-actions/try-in-web-ide コミュニティーアクションの v1 バージョンを実行するジョブを使用して、Try in Web IDE example という名前のワークフローを作成します。ワークフローは、opened アクティビティータイプの pull_request_target イベント でトリガーされます。

  3. オプションで、on.pull_request_target.types フィールドからアクティビティータイプを設定し、ワークフローがトリガーされるタイミングをカスタマイズします。reopened および synchronize などのアクティビティータイプが役立つ場合があります。

    例2.2 opened および synchronize アクティビティータイプの両方でワークフローをトリガーする

    on:
      pull_request_target:
        types: [opened, synchronize]
  4. オプションで、example.yml 内で add_comment および add_status GitHub アクション入力を設定します。これらの入力は Try in Web IDE GitHub アクションに送信され、コメントとステータスチェックを行うかどうかをカスタマイズします。

2.3.2. devfile の指定

ファクトリー URL によって作成されるワークスペースの開発環境を定義するために、リポジトリーのルートディレクトリーに devfile を指定することが推奨されます。これにより、ワークスペースには、プラグイン、開発コマンド、その他の環境セットアップなど、ユーザーがプルリクエストを確認するために必要なものがすべて含まれています。

Che ドキュメントリポジトリーの devfile は、明確に定義された有効な devfile の例です。

第3章 ワークスペースコンポーネントのカスタマイズ

ワークスペースコンポーネントをカスタマイズするには:

第4章 Dev Spaces の devfile の概要

devfile は、開発環境のカスタマイズに使用される yaml テキストファイルです。それらを使用して、特定のニーズに合わせて devfile を設定し、カスタマイズされた devfile を複数のワークスペースで共有して、チーム全体で同一のユーザーエクスペリエンスと、ビルド、実行、およびデプロイの動作を保証します。

Devfile および Universal Developer Image

ワークスペースを開始するのに devfile は必要ありません。プロジェクトリポジトリーに devfile を含めない場合、Red Hat OpenShift Dev Spaces は Universal Developer Image (UDI) を含むデフォルトの devfile を自動的にロードします。

OpenShift Dev Spaces devfile レジストリー

OpenShift Dev Spaces devfile レジストリー には、さまざまな言語およびテクノロジー用のすぐに使用できる devfile が含まれています。

注記

レジストリーに含まれる Devfile は Red Hat OpenShift Dev Spaces に固有のものであり、テンプレートではなくサンプルとして扱う必要があります。サンプルに含まれる他のバージョンのコンポーネントと連携するには、更新が必要になる場合があります。

第5章 ワークスペースの IDE

5.1. サポートされている IDE

新しいワークスペースのデフォルトの IDE は、Microsoft Visual Studio Code - オープンソースです。または、サポートされている別の IDE を選択することもできます。

表5.1 サポートされている IDE
IDEid注記

Microsoft Visual Studio Code - Open Source

che-incubator/che-code/latest

これは、URL パラメーターまたは che-editor.yaml が使用されていない場合に新しいワークスペースに読み込まれるデフォルトの IDE です。

JetBrains IntelliJ IDEA コミュニティー版

che-incubator/che-idea/latest

テクノロジープレビュー。Dashboard を使用してこの IDE を選択します。

5.2. OpenShift Dev Spaces でのリポジトリーレベルの IDE 設定

プロジェクトのソースコードを含むリモート Git リポジトリーに IDE 設定ファイルを直接保存できます。このように、1 つの共通の IDE 設定が、そのリポジトリーのクローンを備えたすべての新しいワークスペースに適用されます。このような IDE 設定ファイルには、次のものが含まれる場合があります。

5.3. Microsoft Visual Studio Code - Open Source

Microsoft Visual Studio Code - オープンソース の OpenShift Dev Spaces ビルドは、新しいワークスペースのデフォルト IDE です。

ワークスペースの起動時に、Open VSX レジストリー から Microsoft Visual Studio Code エクステンションのインストールを自動化できます。ワークスペースの起動時の Microsoft Visual Studio Code 拡張機能のインストールの自動化 を参照してください。

ヒント
  • タスク を使用して、devfile.yaml で指定されたコマンドを見つけて実行します。
  • ステータスバーDev Spaces をクリックするか、コマンドパレット から見つけて、Dev Spaces コマンドを使用します。

    • Dev Spaces: ダッシュボードを開く
    • Dev Spaces: Open OpenShift Console
    • Dev Spaces: ワークスペースの停止
    • Dev Spaces: ワークスペースの再起動
    • Dev Spaces: ローカル devfile からのワークスペースの再起動
    • Dev Spaces: ドキュメントを開く
注記

この IDE では、ブランディングされたビルドでカスタマイズされたブランディングが表示される場合があります。

5.3.1. ワークスペースの起動時に、Microsoft Visual Studio Code 拡張機能のインストールを自動化する

Microsoft Visual Studio Code - オープンソース IDE で選択した拡張機能を自動的にインストールするには、プロジェクトのソースコードを含み、ワークスペースに複製されるリモート Git リポジトリーに extensions.json ファイルを追加します。

前提条件

手順

  1. 選択した各拡張機能の発行元と名前を取得します。

    1. Open VSX レジストリー Web サイト で拡張機能を見つけ、拡張機能のリストページの URL をコピーします。
    2. コピーした URL から <publisher><extension> の名前を抽出します。

      https://www.open-vsx.org/extension/<publisher>/<extension>
  2. リモート Git リポジトリーに .vscode/extensions.json ファイルを作成します。
  3. 次のように、<publisher><extension> の名前を extensions.json ファイルに追加します。

      {
        "recommendations": [
          "<publisher_A>.<extension_B>",
          "<publisher_C>.<extension_D>",
          "<publisher_E>.<extension_F>"
        ]
      }

検証

  1. 作成された extensions.json ファイルを含む リモート Git リポジトリーの URL を使用して、新しいワークスペースを開始 します。
  2. ワークスペースの IDE で、Ctrl+Shift+X を押すか、拡張機能 に移動して、ファイルにリストされている各拡張機能を見つけます。
  3. 拡張機能には、ラベル This extension is enabled globally が付いています。

5.4. 共通 IDE の定義

一方、「IDE の URL パラメーター」 を使用すると、サポートされている IDE を個人的に選択して、ワークスペースを起動できます。同じソースコード Git リポジトリーのすべてのワークスペースに同じ IDE を定義する方が便利な場合があります。これを行うには、che-editor.yaml ファイルを使用します。このファイルは、詳細な IDE 設定もサポートします。

ヒント

社内のワークスペースのほとんどまたはすべてを Microsoft Visual Studio Code - オープンソース以外の同じ IDE で起動する場合は、社内の OpenShift Dev Spaces インスタンスの管理者が、OpenShift Dev Spaces インスタンスレベルでサポートされている別の IDE をデフォルト IDE として指定することもできます。これは、CheCluster カスタムリソースの .spec.devEnvironments.defaultEditor で実行できます。

5.4.1. che-editor.yaml の設定

che-editor.yaml ファイルを使用すると、チームに共通のデフォルト IDE を設定し、プロジェクトのソースコードに最適な IDE を新しいコントリビューターに提供できます。社内の OpenShift Dev Spaces インスタンスのデフォルト IDE ではなく、特定のソースコード Git リポジトリーに別の IDE デフォルトを設定する必要がある場合は、che-editor.yaml ファイルを使用することもできます。

手順

  • プロジェクトソースコードのリモート Git リポジトリーに、関連するパラメーターを指定する行を含む /.che/che-editor.yaml ファイルを作成します。

検証

  1. Git リポジトリーのクローンを使用して、新しいワークスペースを開始します
  2. 指定された IDE が、起動したワークスペースのブラウザータブに読み込まれることを確認します。

5.4.2. che-editor.yaml のパラメーター

che-editor.yaml で IDE を選択する最も簡単な方法は、サポートされている IDE の表から IDE の ID を指定することです。

表5.2 サポートされている IDE
IDEid注記

Microsoft Visual Studio Code - Open Source

che-incubator/che-code/latest

これは、URL パラメーターまたは che-editor.yaml が使用されていない場合に新しいワークスペースに読み込まれるデフォルトの IDE です。

JetBrains IntelliJ IDEA コミュニティー版

che-incubator/che-idea/latest

テクノロジープレビュー。Dashboard を使用してこの IDE を選択します。

例5.1 id は、プラグインレジストリーから IDE を選択

id: che-incubator/che-idea/latest

id パラメーターを提供する代わりに、che-editor.yaml ファイルは別の che-editor.yaml ファイルの URL への 参照、またはプラグインレジストリーの外部にある IDE の inline 定義をサポートします。

例5.2 参照 は、リモート che-editor.yaml ファイルを参照

reference: https://<hostname_and_path_to_a_remote_file>/che-editor.yaml

例5.3 inline は、プラグインレジストリーなしでカスタマイズされた IDE の完全な定義を指定

inline:
  schemaVersion: 2.1.0
  metadata:
    name: JetBrains IntelliJ IDEA Community IDE
  components:
    - name: intellij
      container:
        image: 'quay.io/che-incubator/che-idea:next'
        volumeMounts:
          - name: projector-user
            path: /home/projector-user
        mountSources: true
        memoryLimit: 2048M
        memoryRequest: 32Mi
        cpuLimit: 1500m
        cpuRequest: 100m
        endpoints:
          - name: intellij
            attributes:
              type: main
              cookiesAuthEnabled: true
              urlRewriteSupported: true
              discoverable: false
              path: /?backgroundColor=434343&wss
            targetPort: 8887
            exposure: public
            secure: false
            protocol: https
      attributes: {}
    - name: projector-user
      volume: {}

より複雑なシナリオの場合に、che-editor.yaml ファイルは registryUrl および override パラメーターをサポートします。

例5.4 registryUrl は、デフォルトの OpenShift Dev Spaces プラグインレジストリーではなく、カスタムプラグインレジストリーを参照

id: <editor_id> 1
registryUrl: <url_of_custom_plugin_registry>
1
カスタムプラグインレジストリーの IDE の ID

例5.5 IDE の 1 つ以上の定義済みプロパティーのデフォルト値の override

... 1
override:
  containers:
    - name: che-idea
      memoryLimit: 1280Mi
      cpuLimit: 1510m
      cpuRequest: 102m
    ...
1
id:registryUrl:、または reference:

第6章 ワークスペースでのクレデンシャルと設定の使用

ワークスペースでクレデンシャルと設定を使用できます。

これを行うには、組織の OpenShift Dev Spaces インスタンスの OpenShift クラスター内の Dev Workspace コンテナーにクレデンシャルと設定をマウントします。

  • クレデンシャルと機密性の高い設定を Kubernetes シークレット としてマウントします。
  • 機密性のない設定を Kubernetes ConfigMaps としてマウントします。

クラスター内の Dev Workspace Pod が認証を必要とするコンテナーレジストリーにアクセスできるようにする必要がある場合は、Dev Workspace Pod の イメージプルシークレット を作成します。

マウントプロセスでは、標準の Kubernetes マウントメカニズムを使用し、既存のリソースに追加のラベルとアノテーションを適用する必要があります。新しいワークスペースを開始するとき、または既存のワークスペースを再起動するときに、リソースがマウントされます。

さまざまなコンポーネントの永続的なマウントポイントを作成できます。

6.1. シークレットのマウント

機密データをワークスペースにマウントするには、Kubernetes シークレットを使用します。

Kubernetes Secrets を使用すると、ユーザー名、パスワード、SSH キーペア、認証トークン (AWS など)、および機密性の高い設定をマウントできます。

組織の OpenShift Dev Spaces インスタンスの OpenShift クラスター内の Dev Workspace コンテナーに Kubernetes シークレットをマウントします。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。
  • ユーザープロジェクトですべての Dev Workspace コンテナーにマウントする新しいシークレットを作成するか、既存のシークレットを決定している。

手順

  1. Secret のマウントに必要なラベルを Secret に追加します。

    $ oc label secret <Secret_name> \
            controller.devfile.io/mount-to-devworkspace=true \
            controller.devfile.io/watch-secret=true
  2. オプション: アノテーションを使用して、シークレットのマウント方法を設定します。

    表6.1 オプションのアノテーション
    アノテーション説明

    controller.devfile.io/mount-path:

    マウントパスを指定します。

    デフォルトは /etc/secret/<Secret_name> です。

    controller.devfile.io/mount-as:

    リソースのマウント方法を指定します: filesubpath、または env

    デフォルトは file です。

    mount-as: file は、キーと値をマウントパス内のファイルとしてマウントします。

    mount-as: subpath は、サブパスボリュームマウントを使用して、マウントパス内のキーと値をマウントします。

    mount-as: env は、すべての Dev Workspace コンテナーに環境変数としてキーと値をマウントします。

例6.1 シークレットをファイルとしてマウント

apiVersion: v1
kind: Secret
metadata:
  name: mvn-settings-secret
  labels:
    controller.devfile.io/mount-to-devworkspace: 'true'
    controller.devfile.io/watch-secret: 'true'
  annotations:
    controller.devfile.io/mount-path: '/home/user/.m2'
data:
  settings.xml: <Base64_encoded_content>

ワークスペースを開始すると、/home/user/.m2/settings.xml ファイルが Dev Workspace コンテナーで使用可能になります。

Maven を使用すると、settings.xml ファイルのカスタムパスを設定できます。以下に例を示します。

$ mvn --settings /home/user/.m2/settings.xml clean install

6.1.1. イメージプルシークレットの作成

組織の OpenShift Dev Spaces インスタンスの OpenShift クラスター内の Dev Workspace Pod が、認証を必要とするコンテナーレジストリーにアクセスできるようにするには、イメージプルシークレットを作成します。

oc.dockercfg ファイル、または config.json ファイルを使用して、イメージプルシークレットを作成できます。

6.1.1.1. oc でシークレットをプルするイメージを作成する

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。

手順

  1. ユーザープロジェクトで、プライベートコンテナーレジストリーの詳細とクレデンシャルを使用してイメージプルシークレットを作成します。

    $ oc create secret docker-registry <Secret_name> \
        --docker-server=<registry_server> \
        --docker-username=<username> \
        --docker-password=<password> \
        --docker-email=<email_address>
  2. 次のラベルをイメージプルシークレットに追加します。

    $ oc label secret <Secret_name> controller.devfile.io/devworkspace_pullsecret=true controller.devfile.io/watch-secret=true
6.1.1.2. .dockercfg ファイルからイメージプルシークレットを作成する

プライベートコンテナーレジストリーのクレデンシャルを .dockercfg ファイルにすでに保存している場合は、そのファイルを使用してイメージプルシークレットを作成できます。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。
  • base64 コマンドラインツールは、使用しているオペレーティングシステムにインストールされている。

手順

  1. .dockercfg ファイルを Base64 にエンコードします。

    $ cat .dockercfg | base64 | tr -d '\n'
  2. ユーザープロジェクトに新しい OpenShift シークレットを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <Secret_name>
      labels:
        controller.devfile.io/devworkspace_pullsecret: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      .dockercfg: <Base64_content_of_.dockercfg>
    type: kubernetes.io/dockercfg
  3. シークレットを適用します。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
6.1.1.3. config.json ファイルからイメージプルシークレットを作成する

プライベートコンテナーレジストリーのクレデンシャルを $HOME/.docker/config.json ファイルにすでに保存している場合は、そのファイルを使用してイメージプルシークレットを作成できます。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。
  • base64 コマンドラインツールは、使用しているオペレーティングシステムにインストールされている。

手順

  1. $HOME/.docker/config.json ファイルを Base64 にエンコードします。

    $ cat config.json | base64 | tr -d '\n'
  2. ユーザープロジェクトに新しい OpenShift シークレットを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <Secret_name>
      labels:
        controller.devfile.io/devworkspace_pullsecret: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      .dockerconfigjson: <Base64_content_of_config.json>
    type: kubernetes.io/dockerconfigjson
  3. シークレットを適用します。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF

6.1.2. Git プロバイダーアクセストークンの使用

GitHub、GitLab、Bitbucket、または Microsoft Azure Repos の OAuth は、組織の OpenShift Dev Spaces インスタンスの 管理者が設定 する必要があります。管理者が OpenShift Dev Spaces ユーザー向けに設定できなかった場合、回避策はパーソナルアクセストークンを使用することです。パーソナルアクセストークンは、OpenShift Dev Spaces ダッシュボードの User Preferences ページ (https://<openshift_dev_spaces_fqdn>/dashboard/#/user-preferences?tab=personal-access-tokens) で設定するか、Kubernetes シークレットとして手動で適用できます。

アクセストークンを Secret としてマウントすると、OpenShift Dev Spaces サーバーは、リポジトリーの /.che および /.vscode フォルダーへのアクセスを含め、ワークスペースの作成中に複製されたリモートリポジトリーにアクセスできます。

組織の OpenShift Dev Spaces インスタンスの OpenShift クラスターのユーザープロジェクトにシークレットを適用します。

シークレットを適用した後、GitHub、GitLab、Bitbucket Server、または Microsoft Azure Repos でホスティングされているプライベート Git リポジトリーのクローンを使用して、ワークスペースを作成できます。

Git プロバイダーごとに複数のアクセストークンシークレットを作成および適用できます。これらの各 Secret をユーザープロジェクトに適用する必要があります。

前提条件

  • クラスターにログインしている。

    ヒント

    OpenShift では、oc コマンドラインツールを使用してクラスターにログインできます。

    $ oc login https://<openshift_dev_spaces_fqdn> --username=<my_user>

手順

  1. Git プロバイダーの Web サイトでアクセストークンを生成します。

    重要

    パーソナルアクセストークンは機密情報であるため、機密扱いにする必要があります。パスワードのように扱います。認証に問題がある場合は、正しいトークンを使用し、リポジトリーのクローンを作成するための適切なパーミッションがあることを確認してください。

    1. コンピューターのローカルでターミナルを開きます。
    2. パーソナルアクセストークンを使用して、git コマンドでリポジトリーのクローンを作成します。git コマンドの形式は、Git プロバイダーによって異なります。たとえば、GitHub のパーソナルアクセストークンの検証は、以下のコマンドを使用して実行できます。
    git clone https://<PAT>@github.com/username/repo.git

    <PAT> は、パーソナルアクセストークンに、username/repo は適切なリポジトリーパスに置き換えます。トークンが有効で、必要なパーミッションがある場合は、クローンプロセスが正常に実行されるはずです。それ以外の場合、これはパーソナルアクセストークンが正しくない、パーミッションが不十分である、またはその他の問題を示しています。

    重要

    GitHub Enterprise Cloud の場合は、トークンが 組織内での使用が許可されている ことを確認します。

  2. アクセストークンを Base64 にエンコードします。

    ヒント

    オペレーティングシステムに base64 コマンドラインツールがインストールされている場合は、次のコマンドラインを使用できます。

    $ echo -n '<your_access_token_string>' | base64

  3. Web ブラウザーで https://<openshift_dev_spaces_fqdn>/api/user/id に移動して、OpenShift Dev Spaces ユーザー ID を取得します。
  4. 新しい OpenShift シークレットを準備します。

    kind: Secret
    apiVersion: v1
    metadata:
      name: personal-access-token-<your_choice_of_name_for_this_token>
      labels:
        app.kubernetes.io/component: scm-personal-access-token
        app.kubernetes.io/part-of: che.eclipse.org
      annotations:
        che.eclipse.org/che-userid: <devspaces_user_id>1
        che.eclipse.org/scm-personal-access-token-name: <git_provider_name>2
        che.eclipse.org/scm-url: <git_provider_endpoint>3
        che.eclipse.org/scm-organization: <git_provider_organization>4
    data:
      token: <Base64_encoded_access_token>
    type: Opaque
    1
    OpenShift Dev Spaces ユーザー ID。
    2
    Git プロバイダー名: githubgitlabbitbucket-server、または azure-devops
    3
    Git プロバイダーの URL。
    4
    この行は、Git プロバイダーのユーザー組織である azure-devops のみに適用されます。
  5. https://<openshift_dev_spaces_fqdn>/api/kubernetes/namespace にアクセスして、OpenShift Dev Spaces ユーザー namespace を name として取得します。
  6. クラスター内の OpenShift Dev Spaces ユーザー namespace に切り替えます。

    ヒント

    OpenShift の場合:

    • oc コマンドラインツールは、クラスター内で現在使用している namespace を返すことができます。これを使用して、現在の namespace を確認できます。

      $ oc project

    • 必要に応じて、コマンドラインで OpenShift Dev Spaces ユーザー namespace に切り替えることができます。

      $ oc project <your_user_namespace>

  7. シークレットを適用します。

    ヒント

    OpenShift では、oc コマンドラインツールを使用できます。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_step_5>
    EOF

検証

  1. Git プロバイダーがホストする リモート Git リポジトリーの URL を使用して、新しいワークスペースを開始します
  2. 変更を加えて、ワークスペースからリモート Git リポジトリーにプッシュします。

6.2. ConfigMap のマウント

機密でない設定データをワークスペースにマウントするには、Kubernetes ConfigMaps を使用します。

Kubernetes ConfigMaps を使用すると、アプリケーションの設定値などの機密性の低いデータをマウントできます。

Kubernetes ConfigMaps を組織の OpenShift Dev Spaces インスタンスの OpenShift クラスター内の Dev Workspace コンテナーにマウントします。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。
  • ユーザープロジェクトで、新規の ConfigMap を作成するか、すべての Dev Workspace コンテナーにマウントする既存の ConfigMap を決定している。

手順

  1. ConfigMap のマウントに必要なラベルを ConfigMap に追加します。

    $ oc label configmap <ConfigMap_name> \
            controller.devfile.io/mount-to-devworkspace=true \
            controller.devfile.io/watch-configmap=true
  2. オプション: アノテーションを使用して、ConfigMap のマウント方法を設定します。

    表6.2 オプションのアノテーション
    アノテーション説明

    controller.devfile.io/mount-path:

    マウントパスを指定します。

    デフォルトは /etc/config/<ConfigMap_name> です。

    controller.devfile.io/mount-as:

    リソースのマウント方法を指定します: filesubpath、または env

    デフォルトは file です。

    mount-as:file は、キーと値をマウントパス内のファイルとしてマウントします。

    mount-as:subpath は、サブパスボリュームマウントを使用して、マウントパス内のキーと値をマウントします。

    mount-as:env は、すべての Dev Workspace コンテナーに環境変数としてキーと値をマウントします。

例6.2 ConfigMap を環境変数としてマウントする

kind: ConfigMap
apiVersion: v1
metadata:
  name: my-settings
  labels:
    controller.devfile.io/mount-to-devworkspace: 'true'
    controller.devfile.io/watch-configmap: 'true'
  annotations:
    controller.devfile.io/mount-as: env
data:
  <env_var_1>: <value_1>
  <env_var_2>: <value_2>

ワークスペースを開始すると、<env_var_1> および <env_var_2> 環境変数が Dev Workspace コンテナーで使用可能になります。

6.2.1. Git 設定のマウント

以下の手順に従って、Git config ファイルをワークスペースにマウントします。

前提条件

  • クラスターにログインしている。

手順

  1. 新規の OpenShift ConfigMap を準備します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: workspace-userdata-gitconfig-configmap
      namespace: <user_namespace> 1
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /etc/
    data:
      gitconfig: "[user] \n  name = <git_user_name> \n  email = <git_user_email>" 2
    1
    ユーザー namespace。https://<openshift_dev_spaces_fqdn>/api/kubernetes/namespace にアクセスして、OpenShift Dev Spaces ユーザー namespace を name として取得します。
    2
    Git ユーザー名と電子メール。
  2. ConfigMap を適用します。

    $ oc apply -f - <<EOF
    <ConfigMap_prepared_in_step_1>
    EOF

検証

  1. Git プロバイダーがホストする リモート Git リポジトリーの URL を使用して、新しいワークスペースを開始します
  2. ワークスペースが起動したら、tools コンテナーで新しいターミナルを開き、git config --get-regexp user.* を実行します。Git ユーザー名とメールが出力に表示されるはずです。

6.3. 制限された環境でのアーティファクトリーポジトリーの有効化

テクノロジースタックを設定することで、自己署名証明書を使用して、インハウスリポジトリーからアーティファクトを扱うことができます。

6.3.1. Maven

制限された環境で実行される Maven ワークスペースで Maven アーティファクトリーポジトリを有効にできます。

前提条件

  • Maven ワークスペースを実行していない。
  • ユーザー名前空間は <username> -devspaces であり、<username> は OpenShift Dev Spaces ユーザー名です。

手順

  1. <username> -devspaces 名前空間で、TLS 証明書のシークレットを適用します。

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 1
    1
    行の折り返しが無効になっている Base64 エンコーディング。
  2. <username> -devspaces 名前空間で、ConfigMap を適用して settings.xml ファイルを作成します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: settings-xml
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/.m2
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      settings.xml: |
        <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
          <localRepository/>
          <interactiveMode/>
          <offline/>
          <pluginGroups/>
          <servers/>
          <mirrors>
            <mirror>
              <id>redhat-ga-mirror</id>
              <name>Red Hat GA</name>
              <url>https://<maven_artifact_repository_route>/repository/redhat-ga/</url>
              <mirrorOf>redhat-ga</mirrorOf>
            </mirror>
            <mirror>
              <id>maven-central-mirror</id>
              <name>Maven Central</name>
              <url>https://<maven_artifact_repository_route>/repository/maven-central/</url>
              <mirrorOf>maven-central</mirrorOf>
            </mirror>
            <mirror>
              <id>jboss-public-repository-mirror</id>
              <name>JBoss Public Maven Repository</name>
              <url>https://<maven_artifact_repository_route>/repository/jboss-public/</url>
              <mirrorOf>jboss-public-repository</mirrorOf>
            </mirror>
          </mirrors>
          <proxies/>
          <profiles/>
          <activeProfiles/>
        </settings>
  3. オプション: JBoss EAP ベースの devfile を使用する場合は、<username>-devspaces namespace に、同じ内容、別の名前、および /home/jboss/.m2 マウントパスを持つ 2 番目の settings-xml ConfigMap を適用します。
  4. <username> -devspaces 名前空間で、TrustStore 初期化スクリプトの ConfigMap を適用します。

    Java 8

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-truststore
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      init-java8-truststore.sh: |
        #!/usr/bin/env bash
    
        keytool -importcert -noprompt -file /home/user/certs/tls.cer -trustcacerts -keystore ~/.java/current/jre/lib/security/cacerts -storepass changeit

    Java 11

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-truststore
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      init-java11-truststore.sh: |
        #!/usr/bin/env bash
    
        keytool -importcert -noprompt -file /home/user/certs/tls.cer -cacerts -storepass changeit

  5. Maven ワークスペースを開始します。
  6. tools コンテナーで新しいターミナルを開きます。
  7. ~/init-truststore.sh を実行します。

6.3.2. Gradle

制限された環境で実行される Gradle ワークスペースで Gradle アーティファクトリーポジトリを有効にできます。

前提条件

  • Gradle ワークスペースを実行していない。

手順

  1. TLS 証明書のシークレットを適用します。

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 1
    1
    行の折り返しが無効になっている Base64 エンコーディング。
  2. TrustStore 初期化スクリプトに ConfigMap を適用します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-truststore
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      init-truststore.sh: |
        #!/usr/bin/env bash
    
        keytool -importcert -noprompt -file /home/user/certs/tls.cer -cacerts -storepass changeit
  3. Gradleinit スクリプトに ConfigMap を適用します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-gradle
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/.gradle
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      init.gradle: |
        allprojects {
          repositories {
            mavenLocal ()
            maven {
              url "https://<gradle_artifact_repository_route>/repository/maven-public/"
              credentials {
                username "admin"
                password "passwd"
              }
            }
          }
        }
  4. Gradle ワークスペースを開始します。
  5. tools コンテナーで新しいターミナルを開きます。
  6. ~/init-truststore.sh を実行します。

6.3.3. npm

制限された環境で実行される npm ワークスペースで npm アーティファクトリーポジトリを有効にできます。

前提条件

  • npm ワークスペースを実行していない。
警告

環境変数を設定する ConfigMap を適用すると、ワークスペースのブートループが発生する可能性があります。

この動作が発生した場合は、ConfigMap を削除し、devfile を直接編集してください。

手順

  1. TLS 証明書のシークレットを適用します。

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 1
    1
    行の折り返しが無効になっている Base64 エンコーディング。
  2. ConfigMap を適用して、tools コンテナーに次の環境変数を設定します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: disconnected-env
      annotations:
        controller.devfile.io/mount-as: env
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      NODE_EXTRA_CA_CERTS: /home/user/certs/tls.cer
      NPM_CONFIG_REGISTRY: >-
        https://<npm_artifact_repository_route>/repository/npm-all/

6.3.4. Python

制限された環境で実行される Python ワークスペースで Python アーティファクトリーポジトリを有効にできます。

前提条件

  • Python ワークスペースを実行していない。
警告

環境変数を設定する ConfigMap を適用すると、ワークスペースのブートループが発生する可能性があります。

この動作が発生した場合は、ConfigMap を削除し、devfile を直接編集してください。

手順

  1. TLS 証明書のシークレットを適用します。

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 1
    1
    行の折り返しが無効になっている Base64 エンコーディング。
  2. ConfigMap を適用して、tools コンテナーに次の環境変数を設定します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: disconnected-env
      annotations:
        controller.devfile.io/mount-as: env
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      PIP_INDEX_URL: >-
        https://<python_artifact_repository_route>/repository/pypi-all/
      PIP_CERT: /home/user/certs/tls.cer

6.3.5. Go

制限された環境で実行される Go ワークスペースで Go アーティファクトリーポジトリを有効にできます。

前提条件

  • Go ワークスペースを実行していない。
警告

環境変数を設定する ConfigMap を適用すると、ワークスペースのブートループが発生する可能性があります。

この動作が発生した場合は、ConfigMap を削除し、devfile を直接編集してください。

手順

  1. TLS 証明書のシークレットを適用します。

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 1
    1
    行の折り返しが無効になっている Base64 エンコーディング。
  2. ConfigMap を適用して、tools コンテナーに次の環境変数を設定します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: disconnected-env
      annotations:
        controller.devfile.io/mount-as: env
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      GOPROXY: >-
        http://<athens_proxy_route>
      SSL_CERT_FILE: /home/user/certs/tls.cer

6.3.6. NuGet

制限された環境で実行される NuGet ワークスペースで NuGet アーティファクトリーポジトリを有効にできます。

前提条件

  • NuGet ワークスペースを実行していない。
警告

環境変数を設定する ConfigMap を適用すると、ワークスペースのブートループが発生する可能性があります。

この動作が発生した場合は、ConfigMap を削除し、devfile を直接編集してください。

手順

  1. TLS 証明書のシークレットを適用します。

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 1
    1
    行の折り返しが無効になっている Base64 エンコーディング。
  2. ConfigMap を適用して、tools コンテナー内の TLS 証明書ファイルのパスの環境変数を設定します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: disconnected-env
      annotations:
        controller.devfile.io/mount-as: env
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      SSL_CERT_FILE: /home/user/certs/tls.cer
  3. ConfigMap を適用して、nuget.config ファイルを作成します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-nuget
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /projects
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      nuget.config: |
        <?xml version="1.0" encoding="UTF-8"?>
        <configuration>
          <packageSources>
            <add key="nexus2" value="https://<nuget_artifact_repository_route>/repository/nuget-group/"/>
          </packageSources>
          <packageSourceCredentials>
            <nexus2>
                <add key="Username" value="admin" />
                <add key="Password" value="passwd" />
            </nexus2>
          </packageSourceCredentials>
        </configuration>

第7章 ワークスペースの永続ストレージを要求する

OpenShift Dev Spaces ワークスペースとワークスペースデータは一時的なものであり、ワークスペースが停止すると失われます。

ワークスペースが停止している間、ワークスペースの状態を永続ストレージに保持するには、組織の OpenShift Dev Spaces インスタンスの OpenShift クラスター内の Dev Workspace コンテナーに対して Kubernetes 永続ボリューム (PV) をリクエストします。

devfile または Kubernetes PersistentVolumeClaim (PVC) を使用して PV をリクエストできます。

PV の例は、ワークスペースの /projects/ ディレクトリーです。これは、non-ephemeral ワークスペース用にデフォルトでマウントされます。

永続ボリュームにはコストがかかります。永続ボリュームを接続すると、ワークスペースの起動が遅くなります。

警告

ReadWriteOnce PV を使用して別の同時実行ワークスペースを開始すると、失敗する場合があります。

7.1. devfile での永続ストレージのリクエスト

ワークスペースに独自の永続ストレージが必要な場合は、devfile で PersistentVolume (PV) をリクエストすると、OpenShift Dev Spaces が必要な PersistentVolumeClaims を自動的に管理します。

前提条件

  • ワークスペースを開始していない。

手順

  1. devfile に volume コンポーネントを追加します。

    ...
    components:
      ...
      - name: <chosen_volume_name>
        volume:
          size: <requested_volume_size>G
      ...
  2. devfile に該当する containervolumeMount を追加する。

    ...
    components:
      - name: ...
        container:
          ...
          volumeMounts:
            - name: <chosen_volume_name_from_previous_step>
              path: <path_where_to_mount_the_PV>
          ...

例7.1 ワークスペースの PV をコンテナーにプロビジョニングする devfile

ワークスペースが次の devfile で開始されると、cache PV は ./cache コンテナーパスの golang コンテナーにプロビジョニングされます。

schemaVersion: 2.1.0
metadata:
  name: mydevfile
components:
  - name: golang
    container:
      image: golang
      memoryLimit: 512Mi
      mountSources: true
      command: ['sleep', 'infinity']
      volumeMounts:
        - name: cache
          path: /.cache
  - name: cache
    volume:
      size: 2Gi

7.2. PVC での永続ストレージの要求

次の場合は、PersistentVolumeClaim (PVC) を適用して、ワークスペースの PersistentVolume (PV) を要求することができます。

  • プロジェクトのすべての開発者が PV を必要とするわけではありません。
  • PV のライフサイクルは、単一のワークスペースのライフサイクルを超えています。
  • PV に含まれるデータは、ワークスペース間で共有されます。
ヒント

ワークスペースがエフェメラルであり、その devfile に controller.devfile.io/storage-type: ephemeral 属性が含まれている場合でも、PVC を Dev Workspace コンテナーに適用できます。

前提条件

  • ワークスペースを開始していない。
  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。
  • すべての Dev Workspace コンテナーにマウントするために、ユーザープロジェクトに PVC が作成されます。

手順

  1. controller.devfile.io/mount-to-devworkspace: true ラベルを PVC に追加します。

    $ oc label persistentvolumeclaim <PVC_name> \ controller.devfile.io/mount-to-devworkspace=true
  2. オプション: アノテーションを使用して、PVC のマウント方法を設定します。

    表7.1 オプションのアノテーション
    アノテーション説明

    controller.devfile.io/mount-path:

    PVC のマウントパス。

    デフォルトは /tmp/<PVC_name> です。

    controller.devfile.io/read-only:

    'true' または 'false' に設定して、PVC を読み取り専用としてマウントするかどうかを指定します。

    デフォルトは 'false' で、PVC は読み取り/書き込みとしてマウントされます。

例7.2 読み取り専用 PVC のマウント

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: <pvc_name>
  labels:
    controller.devfile.io/mount-to-devworkspace: 'true'
  annotations:
    controller.devfile.io/mount-path: </example/directory> 1
    controller.devfile.io/read-only: 'true'
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi 2
  storageClassName: <storage_class_name> 3
  volumeMode: Filesystem
1
マウントされた PV は、ワークスペースの </example/directory> にあります。
2
要求されたストレージのサイズ値の例。
3
要求で必要な StorageClass の名前。デフォルトの StorageClass を使用する場合は、この行を削除します。

第8章 OpenShift との統合

8.1. OpenShift API を使用したワークスペースの管理

組織の OpenShift クラスターでは、OpenShift Dev Spaces ワークスペースは同じ名前の DevWorkspace カスタムリソースとして表されます。その結果、OpenShift Dev Spaces ダッシュボードに my-workspace という名前のワークスペースがある場合、クラスター上のユーザーのプロジェクトに my-workspace という名前の対応する DevWorkspace カスタムリソースがあります。

クラスター上の各 DevWorkspace カスタムリソースは OpenShift Dev Spaces ワークスペースを表すため、コマンドライン oc などのクライアントで OpenShift API を使用して OpenShift Dev Spaces ワークスペースを管理できます。

DevWorkspace カスタムリソースには、ワークスペース用に複製された Git リポジトリーの devfile から派生した詳細が含まれています。たとえば、devfile は、devfile コマンドとワークスペースコンテナー設定を提供する場合があります。

8.1.1. すべてのワークスペースの一覧表示

ユーザーは、コマンドラインを使用してワークスペースを一覧表示できます。

前提条件

  • クラスター上のプロジェクトで DevWorkspace リソースを get するための権限を持つアクティブな oc セッションです。CLI の使用方法 を参照。
  • クラスター上の関連する OpenShift Dev Spaces ユーザー namespace を把握している。

    ヒント

    https://<openshift_dev_spaces_fqdn>/api/kubernetes/namespace にアクセスして、OpenShift Dev Spaces ユーザー namespace を name として取得できます。

  • クラスターの OpenShift Dev Spaces ユーザー namespace にいる。

    ヒント

    OpenShift では、コマンドライン oc ツールを使用して、現在の namespace を表示したり、namespace に切り替えたり できます。

手順

  • ワークスペースを一覧表示するには、コマンドラインで次のように入力します。

    $ oc get devworkspaces

    例8.1 出力

    NAMESPACE   NAME                 DEVWORKSPACE ID             PHASE     INFO
    user1-dev   spring-petclinic     workspace6d99e9ffb9784491   Running   https://url-to-workspace.com
    user1-dev   golang-example       workspacedf64e4a492cd4701   Stopped   Stopped
    user1-dev   python-hello-world   workspace69c26884bbc141f2   Failed    Container tooling has state CrashLoopBackOff
ヒント

このコマンドに --watch フラグを追加すると、PHASE の変更をライブで表示できます。

注記

クラスターの管理権限を持つユーザーは、--all-namespaces フラグを含めることで、すべての OpenShift Dev Spaces ユーザーからのすべてのワークスペースを一覧表示できます。

8.1.2. ワークスペースの作成

ユースケースで OpenShift Dev Spaces ダッシュボードの使用が許可されていない場合は、カスタムリソースをクラスターに適用することで、OpenShift API を使用してワークスペースを作成できます。

注記

OpenShift Dev Spaces ダッシュボードを使用してワークスペースを作成すると、コマンドラインを使用する場合と比較して、ユーザーエクスペリエンスと設定の利点が向上します。

  • ユーザーとして、クラスターに自動的にログインします。
  • OpenShift クライアントは自動的に動作します。
  • OpenShift Dev Spaces とそのコンポーネントは、ターゲット Git リポジトリーの devfile をクラスター上の DevWorkspace および DevWorkspaceTemplate カスタムリソースに自動的に変換します。
  • ワークスペースへのアクセスは、デフォルトで、ワークスペースの DevWorkspace にある routingClass: che で保護されています。
  • DevWorkspaceOperatorConfig 設定の認識は、OpenShift Dev Spaces によって管理されます。
  • 以下を含む、CheCluster カスタムリソースで指定された spec.devEnvironments の設定の認識:

    • 永続的なストレージストラテジーは devEnvironments.storage で指定されます。
    • デフォルトの IDE は devEnvironments.defaultEditor で指定されます。
    • デフォルトのプラグインは devEnvironments.defaultPlugins で指定されます。
    • コンテナーのビルド設定は devEnvironments.containerBuildConfiguration で指定されます。

前提条件

手順

  1. DevWorkspace カスタムリソースを準備するには、ターゲット Git リポジトリーの devfile の内容をコピーします。

    例8.2 schemaVersion: 2.2.0 の devfile コンテンツをコピー

    components:
      - name: tooling-container
        container:
          image: quay.io/devfile/universal-developer-image:ubi8-latest
    ヒント

    詳細については、devfile v2 のドキュメントを 参照してください。

  2. 前のステップの devfile の内容を spec.template フィールドの下に貼り付けて、DevWorkspace カスタムリソースを作成します。

    例8.3 DevWorkspace カスタムリソース

    kind: DevWorkspace
    apiVersion: workspace.devfile.io/v1alpha2
    metadata:
      name: my-devworkspace1
      namespace: user1-dev2
    spec:
      routingClass: che
      started: true3
      contributions:4
        - name: ide
          uri: https://<openshift_dev_spaces_fqdn>/plugin-registry/v3/plugins/che-incubator/che-code/latest/devfile.yaml
      template:
        projects:5
          - name: my-project-name
            git:
              remotes:
                origin: https://github.com/eclipse-che/che-docs
        components:6
          - name: tooling-container
            container:
              image: quay.io/devfile/universal-developer-image:ubi8-latest
    1
    DevWorkspace カスタムリソースの名前です。これが新しいワークスペースの名前になります。
    2
    新しいワークスペースのターゲットプロジェクトであるユーザー namespace です。
    3
    DevWorkspace カスタムリソースの作成時にワークスペースを開始する必要があるかどうかを決定します。
    4
    プラグインレジストリーからの Microsoft Visual Studio Code - オープンソース IDE devfile への URL 参照 です。
    5
    起動時にワークスペースに複製する Git リポジトリーの詳細です。
    6
    ワークスペースコンテナーやボリュームコンポーネントなどのコンポーネントの一覧です。
  3. DevWorkspace カスタムリソースをクラスターに適用します。

検証

  1. DevWorkspacePHASE ステータスをチェックして、ワークスペースが起動していることを確認します。

    $ oc get devworkspaces -n <user_project> --watch

    例8.4 出力

    NAMESPACE        NAME                  DEVWORKSPACE ID             PHASE      INFO
    user1-dev        my-devworkspace       workspacedf64e4a492cd4701   Starting   Waiting for workspace deployment
  2. ワークスペースが正常に開始されると、oc get devworkspaces コマンドの出力でその PHASE ステータスが Running に変わります。

    例8.5 出力

    NAMESPACE            NAME                  DEVWORKSPACE ID             PHASE      INFO
    user1-dev            my-devworkspace       workspacedf64e4a492cd4701   Running    https://url-to-workspace.com

    次に、次のいずれかのオプションを使用してワークスペースを開くことができます。

    • oc get devworkspaces コマンドの出力の INFO セクションにある URL にアクセスします。
    • OpenShift Dev Spaces ダッシュボードからワークスペースを開きます。

8.1.3. ワークスペースの停止

Devworkspace カスタムリソースの spec.started フィールドを false に設定することで、ワークスペースを停止できます。

前提条件

  • クラスター上のアクティブな oc セッション。CLI の使用方法 を参照。
  • ワークスペース名は把握している。

    ヒント

    $oc get devworkspaces の出力で、関連するワークスペース名を見つけることができます。

  • クラスター上の関連する OpenShift Dev Spaces ユーザー namespace を把握している。

    ヒント

    https://<openshift_dev_spaces_fqdn>/api/kubernetes/namespace にアクセスして、OpenShift Dev Spaces ユーザー namespace を name として取得できます。

  • クラスターの OpenShift Dev Spaces ユーザー namespace にいる。

    ヒント

    OpenShift では、コマンドライン oc ツールを使用して、現在の namespace を表示したり、namespace に切り替えたり できます。

手順

  • 次のコマンドを実行して、ワークスペースを停止します。

    $ oc patch devworkspace <workspace_name> \
    -p '{"spec":{"started":false}}' \
    --type=merge -n <user_namespace> && \
    oc wait --for=jsonpath='{.status.phase}'=Stopped \
    dw/<workspace_name> -n <user_namespace>

8.1.4. 停止したワークスペースの開始

Devworkspace カスタムリソースの spec.started フィールドを true に設定することで、停止したワークスペースを開始できます。

前提条件

  • クラスター上のアクティブな oc セッション。CLI の使用方法 を参照。
  • ワークスペース名は把握している。

    ヒント

    $oc get devworkspaces の出力で、関連するワークスペース名を見つけることができます。

  • クラスター上の関連する OpenShift Dev Spaces ユーザー namespace を把握している。

    ヒント

    https://<openshift_dev_spaces_fqdn>/api/kubernetes/namespace にアクセスして、OpenShift Dev Spaces ユーザー namespace を name として取得できます。

  • クラスターの OpenShift Dev Spaces ユーザー namespace にいる。

    ヒント

    OpenShift では、コマンドライン oc ツールを使用して、現在の namespace を表示したり、namespace に切り替えたり できます。

手順

  • 次のコマンドを実行して、停止したワークスペースを開始します。

    $ oc patch devworkspace <workspace_name> \
    -p '{"spec":{"started":true}}' \
    --type=merge -n <user_namespace> && \
    oc wait --for=jsonpath='{.status.phase}'=Running \
    dw/<workspace_name> -n <user_namespace>

8.1.5. ワークスペースの削除

DevWorkspace カスタムリソースを削除するだけで、ワークスペースを削除できます。

警告

OpenShift Dev Spaces によって作成された場合、DevWorkspace カスタムリソースを削除すると、他のワークスペースリソースも削除されます (たとえば、参照された DevWorkspaceTemplate およびワークスペースごとの PersistentVolumeClaims)

ヒント

可能な限り、OpenShift Dev Spaces ダッシュボードを使用してワークスペースを削除します。

前提条件

  • クラスター上のアクティブな oc セッション。CLI の使用方法 を参照。
  • ワークスペース名は把握している。

    ヒント

    $oc get devworkspaces の出力で、関連するワークスペース名を見つけることができます。

  • クラスター上の関連する OpenShift Dev Spaces ユーザー namespace を把握している。

    ヒント

    https://<openshift_dev_spaces_fqdn>/api/kubernetes/namespace にアクセスして、OpenShift Dev Spaces ユーザー namespace を name として取得できます。

  • クラスターの OpenShift Dev Spaces ユーザー namespace にいる。

    ヒント

    OpenShift では、コマンドライン oc ツールを使用して、現在の namespace を表示したり、namespace に切り替えたり できます。

手順

  • 次のコマンドを実行して、ワークスペースを削除します。

    $ oc delete devworkspace <workspace_name> -n <user_namespace>

8.2. 自動 OpenShift トークン注入

このセクションでは、OpenShift クラスターに対して OpenShift Dev Spaces CLI コマンドを実行できるようにするワークスペースコンテナーに自動的に挿入される OpenShift ユーザートークンの使用方法を説明します。

手順

  1. OpenShift Dev Spaces ダッシュボードを開き、ワークスペースを開始します。
  2. ワークスペースが開始されたら、OpenShift Dev Spaces CLI を含むコンテナーでターミナルを開きます。
  3. OpenShift クラスターに対してコマンドを実行できる OpenShift Dev Spaces CLI コマンドを実行します。CLI は、アプリケーションのデプロイ、クラスターリソースの検査および管理、ならびにログの表示に使用できます。OpenShift ユーザートークンは、コマンドの実行中に使用されます。

    IDE でのトークンインジェクション
警告

自動トークン注入は現在、OpenShift インフラストラクチャーでのみ機能します。

第9章 Dev Spaces のトラブルシューティング

本セクションでは、ユーザーが競合する可能性のある最も頻繁に発生する問題についてのトラブルシューティング手順を説明します。

9.1. Dev Spaces ワークスペースログの表示

OpenShift Dev Spaces ログを表示して、問題が発生した場合にバックグラウンドプロセスをよりよく理解し、デバッグすることができます。

IDE 拡張機能が正しく動作しないか、デバッグが必要です
ログには、エディターによって読み込まれたプラグインが一覧表示されます。
コンテナーのメモリーが不足している
ログには、OOMKilled エラーメッセージが含まれています。コンテナーで実行されているプロセスが、コンテナーで使用できるように設定されているよりも多くのメモリーを要求しようとしました。
プロセスがメモリー不足になる
ログには、OutOfMemoryException などのエラーメッセージが含まれています。コンテナー内のプロセスが、コンテナーが気付かれずにメモリー不足になりました。

9.1.1. CLI のワークスペースログ

OpenShift CLI を使用して、OpenShift Dev Spaces ワークスペースのログを観察できます。

前提条件

  • OpenShift Dev Spaces ワークスペース <workspace_name> が実行されています。
  • OpenShift CLI セッションは、このワークスペースを含む OpenShift プロジェクト <namespace_name> にアクセスできます。

手順

  • <namespace_name> プロジェクトで <workspace_name> ワークスペースを実行している Pod からログを取得します。

    $ oc logs --follow --namespace='<workspace_namespace>' \
      --selector='controller.devfile.io/devworkspace_name=<workspace_name>'

9.1.2. OpenShift コンソールの Workspace ログ

OpenShift コンソールを使用して、OpenShift Dev Spaces ワークスペースのログを観察できます。

手順

  1. OpenShift Dev Spaces ダッシュボードで、Workspaces に移動します。
  2. ワークスペース名をクリックして、ワークスペースの概要ページを表示します。このページには、OpenShift プロジェクト名 <project_name> が表示されます。
  3. 右上の Applications メニューをクリックし、OpenShift コンソールリンクをクリックします。
  4. Administrator パースペクティブで、OpenShift コンソールで次の手順を実行します。
  5. Workloads > Pods をクリックして、アクティブなすべてのワークスペースのリストを表示します。
  6. Project ドロップダウンメニューで、<project_name> プロジェクトを選択して検索を絞り込みます。
  7. ワークスペースを実行する実行中の Pod の名前をクリックします。Details タブには、追加情報を含むすべてのコンテナーのリストが含まれています。
  8. Logs タブに移動します。

9.1.3. エディターの言語サーバーとデバッグアダプターのログ

ワークスペースで実行している Microsoft Visual Studio Code - オープンソースエディターでは、インストールされている言語サーバーとデバッグアダプターエクステンションを設定して、ログを表示できます。

手順

  1. 拡張機能を設定します。File > Preferences > Settings をクリックし、Extensions セクションを展開して拡張機能を検索し、trace.server または同様の設定を verbose に設定します (そのような設定が存在する場合)。詳細な設定については、拡張機能のドキュメントを参照してください。
  2. ViewOutput をクリックし、出力ビューのドロップダウンリストで言語サーバーを選択して、言語サーバーログを表示します。

9.2. 速度の遅いワークスペースのトラブルシューティング

ワークスペースの起動には時間がかかる場合があります。チューニングにより、この起動時間を短縮できる場合があります。オプションによっては、管理者またはユーザーはチューニングを行うことができます。

本セクションでは、ワークスペースをより迅速に起動したり、ワークスペースのランタイムパフォーマンスを改善したりするためのチューニングオプションが複数含まれています。

9.2.1. ワークスペースの起動時間の改善

Image Puller を使用したイメージのキャッシュ

ロール: 管理者

ワークスペースを起動すると、OpenShift はイメージをレジストリーからプルします。ワークスペースには、数多くのコンテナーを含めることができます。つまり OpenShift は、(コンテナーごとに 1 つの) Pod のイメージをプルするため、複数の Pod のイメージをプルすることを意味します。イメージのサイズと帯域幅によっては、これには時間がかかる場合があります。

Image Puller は、各 OpenShift ノードでイメージをキャッシュできるツールです。このため、プル前のイメージにより、起動時間が短縮されます。https://access.redhat.com/documentation/ja-jp/red_hat_openshift_dev_spaces/3.9/html-single/administration_guide/index#administration-guide:caching-images-for-faster-workspace-start を参照してください。

より適切なストレージタイプの選択

ロール: 管理者およびユーザー

すべてのワークスペースには共有ボリュームが割り当てられています。このボリュームはプロジェクトファイルを保存するため、ワークスペースを再起動する際に変更が引き続き利用できるようになります。ストレージによっては、割り当てに数分かかる可能性があり、I/O が遅くなる可能性があります。

オフラインインストール

ロール: 管理者

OpenShift Dev Spaces のコンポーネントは OCI イメージです。Red Hat OpenShift Dev Spaces をオフラインモードでセットアップして、実行時の余分なダウンロードを減らします。これは、最初からすべてを利用できる必要があるためです。https://access.redhat.com/documentation/ja-jp/red_hat_openshift_dev_spaces/3.9/html-single/administration_guide/index#administration-guide:installing-che-in-a-restricted-environment を参照してください。

パブリックエンドポイントの数の縮小

ロール: 管理者

それぞれのエンドポイントについて、OpenShift は OpenShift Route オブジェクトを作成します。基礎となる設定によっては、作成に時間がかかる場合があります。

この問題を回避するには、公開される部分を縮小します。たとえば、コンテナー内でリッスンする新規ポートを自動的に検出し、ローカル IP アドレス (127.0.0.1) を使用してプロセスのトラフィックをリダイレクトする場合、Microsoft Visual Code - Open Source には 3 つのオプションのルートがあります。

エンドポイントの数を減らし、すべてのプラグインのエンドポイントをチェックすることで、ワークスペースの起動が速くなります。

9.2.2. ワークスペースのランタイムパフォーマンスの改善

十分な CPU リソースを提供する

プラグインは CPU リソースを消費します。たとえば、プラグインが IntelliSense 機能を提供する場合、CPU リソースを追加するとパフォーマンスが向上します。

devfile 定義 devfile.yaml の CPU 設定が正しいことを確認します。

components:
  - name: tools
    container:
      image: quay.io/devfile/universal-developer-image:ubi8-latest
      cpuLimit: 4000m 1
      cpuRequest: 1000m 2
1
CPU 制限を指定します。
2
CPU リクエストを指定します
十分なメモリーを提供する

プラグインは CPU およびメモリーリソースを消費します。たとえば、プラグインが IntelliSense 機能を提供する場合、データを収集すると、コンテナーに割り当てられるすべてのメモリーを消費する可能性があります。

コンテナーにより多くのメモリーを提供すると、パフォーマンスが向上します。devfile 定義の devfile.yaml ファイルのメモリー設定が正しいことを確認してください。

components:
  - name: tools
    container:
      image: quay.io/devfile/universal-developer-image:ubi8-latest
      memoryLimit: 6G 1
      memoryRequest: 512Mi 2
1
メモリー制限を指定します
2
メモリーリクエストを指定します

9.3. ネットワーク問題のトラブルシューティング

本セクションでは、ネットワークポリシーに関連する問題を回避したり、解決したりする方法を説明します。OpenShift Dev Spaces には、WebSocket Secure (WSS) 接続の可用性が必要です。セキュアな WebSocket 接続では、不正なプロキシーによる干渉リスクが軽減されるため、機密性および信頼性が強化されます。

前提条件

  • ポート 443 の WebSocket Secure (WSS) 接続がネットワークで利用可能である必要があります。ファイアウォールおよびプロキシーに追加の設定が必要になる場合があります。

手順

  1. ブラウザーが WebSocket プロトコルをサポートすることを確認します。参照: Searching a websocket test
  2. ファイアウォール設定の確認: ポート 443 で WebSocket Secure (WSS) 接続が利用可能である必要があります。
  3. プロキシーサーバー設定の確認: プロキシーがポート 443 で WebSocket Secure (WSS) 接続を送信し、インターセプトします。

9.4. WebView 読み込みエラーのトラブルシューティング

プライベートブラウジングウィンドウで Microsoft Visual Studio Code - オープンソースを使用すると、次のエラーメッセージが表示される場合があります。Error loading webview: Error: Could not register service workers

これは、以下のブラウザーに影響する既知の問題です。

  • Google Chrome のシークレットモード
  • Private Browsing モードの Mozilla Firefox
表9.1 プライベートブラウジングウィンドウでの WebView エラーへの対処
ブラウザー

回避策

Google Chrome

SettingsPrivacy and securityCookies and other site dataAllow all cookies に移動します。

Mozilla Firefox

プライベートブラウジングモードでは、Web ビューはサポートされません。詳細は、この報告バグ を参照してください。

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.