ワークスペース

フラグ: セルフマネージドGitLabでは、デフォルトでこの機能が利用可能です。この機能を隠すには、管理者がremote_development_feature_flagという機能フラグを無効にします。GitLab.comでは、この機能は利用可能です。この機能はまだ本番環境では使用できません。

caution
この機能はベータ版であり、予告なく変更される場合があります。フィードバックを残すには、フィードバックイシューをご覧ください。

ワークスペースはGitLabのコードのための仮想サンドボックス環境です。ワークスペースを使用して、GitLabプロジェクトのための隔離された開発環境を作成・管理することができます。これらの環境は、異なるプロジェクトが互いに干渉しないことを保証します。

各ワークスペースには、依存関係、ライブラリ、ツールが含まれており、各プロジェクト固有のニーズに合わせてカスタマイズすることができます。ワークスペースはAMD64アーキテクチャを使用します。

ワークスペースとプロジェクト

ワークスペースはプロジェクトにスコープされます。ワークスペースを作成するときは、以下の手順を実行する必要があります：

  • ワークスペースを特定のプロジェクトに割り当てます。
  • .devfile.yaml ファイルのあるプロジェクトを選択します。

ワークスペースは、現在のユーザーに与えられた権限に基づいて GitLab API とやり取りすることができます。

プロジェクトからワークスペースを開いて管理

GitLab 16.2 で導入されました。

ファイルやリポジトリのファイルリストからワークスペースを開くには：

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 右上の「編集」を選択します。
  3. ドロップダウンリストの [ワークスペース] で、ワークスペースを選択します。

ドロップダウン リストから、以下も可能です：

  • 既存のワークスペースを再起動、停止、または終了します。
  • 新しいワークスペースを作成します。

ワークスペースに関連付けられたデータの削除

ワークスペースに関連付けられているプロジェクト、エージェント、ユーザー、またはトークンを削除する場合：

  • ユーザ インタフェースからワークスペースが削除されます。
  • Kubernetesクラスターでは、実行中のワークスペースリソースは孤児となり、自動的に削除されません。

孤児化したリソースをクリーンアップするには、管理者がKubernetesでワークスペースを手動で削除する必要があります。

イシュー 414384はこの動作を変更することを提案しています。

Devfile

devfileは、GitLabプロジェクトに必要なツール、言語、ランタイム、その他のコンポーネントを指定して開発環境を定義するファイルです。

ワークスペースはdevfileをビルトインでサポートしています。GitLab設定ファイルでプロジェクトのdevfileを指定することができます。devfileは、定義された仕様で開発環境を自動的に設定するために使用されます。

こうすることで、使用するマシンやプラットフォームに関係なく、一貫した再現性のある開発環境を作ることができます。

関連するスキーマ・プロパティ

GitLab はdevfile 2.2.0ではcontainer とvolume コンポーネントのみをサポートしています。container コンポーネントを使用して、devfileワークスペースの実行環境としてコンテナイメージを定義します。ベースイメージ、依存関係、その他の設定を指定できます。

これらのプロパティのみがcontainer コンポーネントの GitLab 実装に関連します：

プロパティ定義
imageワークスペースに使用するコンテナ・イメージの名前。
memoryRequestコンテナが使用できる最小メモリ量。
memoryLimitコンテナが使用できるメモリの最大量。
cpuRequestコンテナが使用できるCPUの最小量。
cpuLimitコンテナが使用できるCPUの最大量。
envコンテナで使用する環境変数。
endpointsコンテナから公開するポートマッピング。
volumeMountsコンテナにマウントするストレージボリューム。

設定例

以下はdevfileの設定例です：

schemaVersion: 2.2.0
components:
  - name: tooling-container
    attributes:
      gl/inject-editor: true
    container:
      image: registry.gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/debian-bullseye-ruby-3.2-node-18.12:rubygems-3.4-git-2.33-lfs-2.9-yarn-1.22-graphicsmagick-1.3.36-gitlab-workspaces
      env:
        - name: KEY
          value: VALUE
      endpoints:
      - name: http-3000
        targetPort: 3000

詳しくはdevfileのドキュメントをご覧ください。その他の例については、examples projectsを参照してください。

このコンテナ・イメージはデモ用です。独自のコンテナ・イメージを使用するには、任意のユーザー ID を参照してください。

Web IDE

ワークスペースはデフォルトで Web IDE にバンドルされています。Web IDE はワークスペースで使用できる唯一のコードエディターです。

Web IDEはGitLab VS Codeフォークを利用しています。詳しくはWeb IDEをご覧ください。

非公開リポジトリ

GitLab はワークスペースに認証情報を注入しないため、非公開リポジトリ用のワークスペースを作成することはできません。ワークスペースを作成できるのは、devfile を持つ公開リポジトリだけです。

ワークスペースから、任意のリポジトリを手動でクローンできます。

クラスターでのポッドの相互作用

ワークスペースはKubernetesクラスタ内のポッドとして実行されます。GitLabはポッド同士の相互作用の仕方に制限を課していません。

この要件のため、この機能をクラスター内の他のコンテナから分離したいと思うかもしれません。

ネットワークアクセスとワークスペース作成者権限

Kubernetesコントロールプレーンへのネットワークアクセスを制限するのはクライアントの責任であり、GitLabはAPIを制御できません。

ワークスペース作成者だけがワークスペースとそのワークスペースで公開されているエンドポイントにアクセスできます。ワークスペース作成者は、OAuthによるユーザー認証後にのみワークスペースへのアクセスが許可されます。

コンピュートリソースとボリュームストレージ

ワークスペースを停止すると、そのワークスペースの計算リソースはゼロにスケールダウンされます。ただし、ワークスペース用にプロビジョニングされたボリュームはまだ存在します。

プロビジョニングされたボリュームを削除するには、ワークスペースを終了する必要があります。

任意のユーザーID

任意のLinuxユーザーIDで実行できる独自のコンテナイメージを提供できます。

GitLabがコンテナイメージのLinuxユーザーIDを予測することはできません。GitLabはコンテナ内のファイルの作成、更新、削除にLinuxルートグループID権限を使用します。Kubernetesクラスタが使用するコンテナランタイムは、すべてのコンテナがデフォルトのLinuxグループID0を持つようにする必要があります。

任意のユーザーIDをサポートしないコンテナイメージを使用している場合、ワークスペース内のファイルを作成、更新、または削除することはできません。任意のユーザーIDをサポートするコンテナイメージを作成するには、任意のユーザーIDをサポートするカスタムワークススペースイメージの作成を参照してください。

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