ユーザーガイド

手順

1. pod- オーバーライド s 属性を使用して、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_dev_spaces/3.12/html-single/administration_guide/index#administration-guide :configuring-Fuse で定義されている必要なアノテーションをワークスペースに追加します。pod- オーバーライド s 属性を使用すると、ワークスペース Pod の 仕様 内の特定のフィールドをマージできます。

   OpenShift バージョン 4.15 より前のバージョンの場合:

   $ oc patch devworkspace <DevWorkspace_name> \
     --patch '{"spec":{"template":{"attributes":{"pod-overrides":{"metadata":{"annotations":{"io.kubernetes.cri-o.Devices":"/dev/fuse","io.openshift.podman-fuse":""}}}}}}}' \
     --type=merge

   OpenShift バージョン 4.15 以降の場合:

   $ oc patch devworkspace <DevWorkspace_name> \
     --patch '{"spec":{"template":{"attributes":{"pod-overrides":{"metadata":{"annotations":{"io.kubernetes.cri-o.Devices":"/dev/fuse"}}}}}}}' \
     --type=merge

検証手順

1. ワークスペースを起動し、ワークスペースコンテナーで /dev/Fuse が 使用可能であることを確認します。

   $ stat /dev/fuse

手順

1. プロジェクトに /home/user/.config/containers/storage.conf ファイルをマウントする ConfigMap を適用します。

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: fuse-overlay
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
     annotations:
       controller.devfile.io/mount-as: file
       controller.devfile.io/mount-path: /home/user/.config/containers
   data:
     storage.conf: |
       [storage]
       driver = "overlay"
   
       [storage.options.overlay]
       mount_program="/usr/bin/fuse-overlayfs"

検証手順

1. 必要なアノテーションを含むワークスペースを起動し、ストレージドライバーが overlay で あることを確認します。

   $ podman info | grep overlay

   出力例:

   graphDriverName: overlay
     overlay.mount_program:
       Executable: /usr/bin/fuse-overlayfs
       Package: fuse-overlayfs-1.12-1.module+el8.9.0+20326+387084d0.x86_64
         fuse-overlayfs: version 1.12
     Backing Filesystem: overlayfs

手順

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 アクションに送信され、コメントとステータスチェックを行うかどうかをカスタマイズします。

手順

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 が付いています。

検証

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

手順

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. Web ブラウザーで https://<openshift_dev_spaces_fqdn>/api/user/id に移動して、OpenShift Dev Spaces ユーザー ID を取得します。

3. 新しい 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
   stringData:
     token: <Content_of_access_token>
   type: Opaque

   1

   OpenShift Dev Spaces ユーザー ID。

   2

   Git プロバイダー名: github、gitlab、bitbucket-server、または azure-devops。

   3

   Git プロバイダーの URL。

   4

   この行は、Git プロバイダーのユーザー組織である azure-devops のみに適用されます。

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

5. クラスター内の OpenShift Dev Spaces ユーザー namespace に切り替えます。

   ヒント

   OpenShift の場合:

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

     $ oc project

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

     $ oc project <your_user_namespace>

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

   ヒント

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

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

検証

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

手順

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 ユーザー名とメールが出力に表示されるはずです。

手順

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 を実行します。

手順

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 を実行します。

手順

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

   kind: Secret
   apiVersion: v1
   metadata:
     name: tls-cer
     annotations:
       controller.devfile.io/mount-path: /public-certs
       controller.devfile.io/mount-as: file
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
   data:
     nexus.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:
     NPM_CONFIG_REGISTRY: >-
       https://<npm_artifact_repository_route>/repository/npm-all/

手順

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

手順

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

手順

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>

手順

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. DevWorkspace の PHASE ステータスをチェックして、ワークスペースが起動していることを確認します。

   $ 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 ダッシュボードからワークスペースを開きます。

手順

1. Topology ビューを開き、すべてのプロジェクトをリスト表示します。
2. Select an Application 検索フィールドに workspace と入力してすべてのワークスペースをリスト表示します。

3. ワークスペースをクリックして編集します。

   デプロイメントは、円形のボタンで囲まれたグラフィカルな円で表示されます。これらのボタンの 1 つは Edit Source Code です。

   
4. OpenShift Dev Spaces を使用してアプリケーションのコードを編集するには、Edit Source Code ボタンをクリックします。これにより、アプリケーションコンポーネントのクローン作成されたソースコードのあるワークスペースにリダイレクトされます。

手順

1. メイン画面の右上にある 3 x 3 マトリックスアイコンを使用して、Red Hat Applications メニューを開きます。

   ドロップダウンメニューには、利用可能なアプリケーションが表示されます。

   
2. OpenShift Dev Spaces リンクをクリックして、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 タブに移動します。

手順

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