🦔

Google Cloud Next'22 で発表された Cloud Workstations を試してみた

2022/11/07に公開約15,700字

Cloud Workstations 概要

Cloud Workstationsは、Software Delivery Sheildを構成する製品の1つとして発表された企業向けのマネージド開発環境です。
Google Cloudプロジェクトの特定のVPCネットワーク上にCloud Shellのような環境を構築することで、適切なアクセス制御や固定の外部IPアドレス、VPC ServiceControlsとの連携を実現します。
また、Cloud WorkstationsはCloud Shell Editorと同等のWebブラウザベースのエディタを備えるとともに、Jetbrains Gatewayと連携することで高機能なIDEを提供可能です。
カスタムコンテナを作成することで、任意のツールを導入することも可能になっています。
ただし、Cloud Workstationsは、Amazon Workspacesのようなデスクトップ環境そのものを提供するVDIではなく、あくまで開発環境(IDE)とターミナルを提供する製品です。
この製品がどのような構成になっているか、どのように使うかについて説明していきたいと思います。

リソース構成

Cloud Workstationsは3つのリソースによって構成されています。
クラスタ(cluster)、構成(configuration)、ワークステーション(workstation)の3つです。

リソース名 リソース概要 設定する主な要素
クラスタ Cloud Workstationsの基本設定となるリソース。どのVPCネットワークに接続するか、エンドポイントを公開するかどうかについて設定する。 ・接続先ネットワーク
・エンドポイント(公開/非公開)
構成 クラスタで起動する開発環境(ワークステーション)のテンプレートを設定するリソース。IDEやマシンタイプ等を設定する。 ・開発環境のベースイメージ
・マシンタイプ
・外部IPアドレスの有無
・最小起動数の設定
ワークステーション 実際に起動する環境を設定するリソース。どの構成を使用するかを選択する。ワークステーションの実体はCompute Engineマネージドインスタンスになり、ワークステーション単位でインスタンスが作成される。 ・元となる構成名

アーキテクチャ

Cloud Workstationsのアーキテクチャの公式ドキュメントは以下になります。
https://cloud.google.com/workstations/docs/architecture

アーキテクチャの説明で、ControllerとGatewayというリソースが出てきます。
Controllerはワークステーションを提供するために必要なCompute Engineリソースを管理するための機能で、Gatewayはワークステーションへの接続を管理・制御する機能です。
ただし、これらはユーザーが直接設定するものではなくクラスタを作成すると付随して作成されるリソースになるようです。
よって、Cloud Workstationsを構築する際には気にしなくてよいです。

利用可能リージョン

本記事執筆時点では、下記のリージョンで使用可能です。
残念ながら、2022年11月時点では日本のリージョンで利用できないようです。

  • アメリカ
    • southamerica-west1
    • us-east1
    • us-central1
    • us-west1
  • アジア
    • asia-east1
    • asia-southeast1
  • ヨーロッパ
    • europe-north1
    • europe-southwest1
    • europe-west1
    • europe-west2
    • europe-west3
    • europe-west4

参考

https://cloud.google.com/workstations/docs/locations

課金体系

課金体系は下記のページに記載されています。
https://cloud.google.com/workstations/pricing

課金のキモとなる部分を抜粋します。

  • コントロールプレーン: $0.2/hour ※コントロールプレーン=クラスタ
  • ワークステーション管理: $0.05/vCPU hour ※ワークステーション毎に課金
  • ワークステーションで使用しているvCPU、メモリ、ディスク、ネットワーク課金等のCompute Engine利用料

なお、本記事執筆時点では、Cloud WorkstationsはPublic Previewであり、Preview期間中はコントロールプレーンとワークステーション管理の料金は無料になっています。

ワークステーションの使い方

では、実際に使ってみます。

APIを有効にする

まずはCloud Workstations APIを有効にします。
Google Cloud consoleのナビゲーションメニューから「API とサービス」>「有効な API とサービス」とたどります。
次に、画面上にある「APIとサービスの有効化」をクリックします。

APIとサービスの有効化

APIとサービスを検索する画面が表示されますので、検索テキストボックスに「Cloud Workstations」と入力してEnterを押します。

APIとサービスの有効化

検索結果にCloud Workstations APIが表示されますので、検索結果をクリックして詳細画面を表示し、APIの有効化ボタンをクリックします。

APIとサービスの有効化

APIとサービスの有効化

APIが有効化できたことが確認できたら、次の手順に進みます。

ネットワークとサブネットワークを作成する (任意)

Cloud Workstationsを構築するVPCネットワークとサブネットワークを作成します。
既にあるVPCネットワークを使う場合は、この手順はスキップして問題ありません。
なお、defaultネットワークを使ってもよいですが、あまり推奨はしません。

ここでは、VPCネットワークとしてcloud-workstationsネットワークを作成し、asia-east1リージョンにcloud-workstationsサブネットワークを作成しました。
なお、サブネットワーク作成時に「限定公開の Google アクセス」は有効にしておいた方がよいようです。
ワークステーション起動時にGoogle CloudからコンテナをPullする処理があるため、後述する構成の設定でワークステーションのパブリックIPアドレスを省略する場合、「限定公開の Google アクセス」が有効になっていないとワークステーション用のコンテナをPullすることができませんでした。
ワークステーションにパブリックIPアドレスを付与する構成にする場合は「限定公開の Google アクセス」の有効化は必須ではありません。

クラスタを作成する

Cloud Workstationsクラスタを作成するVPCネットワークが決まったら、クラスタを作成します。
Google Cloud consoleのナビゲーションメニューで「Cloud Workstations」をクリックします。

画面遷移後、おそらく「CREATE CONFIGURATION」のボタンが表示されていると思いますが、先にクラスタを作成しておきたいので、左メニューから「クラスタ」をクリックします。

クラスタ作成画面

この画面で、「+作成」をクリックします。(CREATE CLUSTERボタンを押しても同じ結果になります。)

クラスタ作成画面

クラスタ作成画面になります。
最初に、「クラスタ名」「リージョン」を設定します。
クラスタ名は分かりやすければ何でもよいです。ここでは「cluster-test」としました。デフォルト値として「cluster-*******」というランダムなサフィックスの入った名前が入っているので、それをそのまま使っても良いです。ただ、ちょっと管理上分かりにくくなるかなと思います。
リージョンは、ワークステーションを作成したいリージョンを選択します。事前に作成したVPCサブネットワークのリージョンと同じである必要があります。
入力したら、Networkingをクリックします。

クラスタ作成画面

Networkingをクリックすると、ネットワーク設定の詳細設定が展開されます。
クラスタタイプで「Public cluster」と「Private cluster」を選択する項目がありますが、インターネットからアクセスして使う場合は「Public cluster」を選択しましょう。
「Private cluster」はVPN等で内部ネットワークからのみアクセスさせたい場合に使用する設定になります。こちらを選択すると、インターネットからワークステーションを使う事はできなくなります。
Networkの設定では、クラスタを配置したいVPCネットワークとサブネットワークを選択します。ここでは、事前に作成していたcloud-workstationsネットワークとcloud-workstationsサブネットワークを選択します。
設定できたら、「作成」ボタンを押します。

クラスタ作成画面

「作成」ボタンを押すと、クラスタ一覧の画面に遷移します。クラスタの初期化に20分ほどかかりますので、しばらく待ちましょう。

クラスタ作成画面

20分程度経過すると、ステータスがREADYになります。

クラスタ作成画面

構成を作成する

クラスタの初期化が完了したら、次は構成を作成します。
Cloud Workstationsの左メニューの「構成」をクリックします。

構成作成画面

次に、画面上部の「+作成」をクリックします。(CREATE CONFIGURATIONボタンを押しても同じ結果になります。)

構成作成画面

構成作成画面に遷移します。
最初に、構成名を入力します。デフォルトで「config-********」というランダムなサフィックスの名前が入っていますが、この構成名は分かりやすい名称を付けた方がよいです。
特に、この後選択するイメージ名(Cloud Code IDEか、Jetbrains IDEのツール名)を付けておくと、ワークステーションを作るときに分かりやすいです。
ここでは、後ほどCloud Code IDEを選択するため「config-code-ide」という名称にしました。
次に、構成を設定するクラスタを選択します。先ほど作成した「cluster-test」クラスタを選択します。
「Quick start workstations」という項目で、事前起動しておくワークステーション用VMの有無を選択できます。Enabledにした場合、事前起動VMを有効にします。
事前起動状態のVMはCompute Engineリソースの課金対象になりますので、コストを最小にしたい場合は、Disabledにします。この記事の検証ではDisabledにしました。
「Quick start workstations」をEnabledにした場合、「Quick start pool size」で事前起動VM数を設定することができます。
設定できたら「続行」ボタンを押します。

構成作成画面

ワークステーションVMの設定項目が表示されます。ここでは、VMのマシンタイプやネットワーク関連の設定を行います。
「マシンタイプ」と「Auto-sleep」の項目を設定します。
マシンタイプは、ワークステーションを実行するVMのスペックになります。デフォルトはe2-standard-4(4vCPU,8GB memory)が選択されています。最小スペックの場合はe2-standard-2(2vCPU,4GB memory)になるようです。ここでは、コスト最小化のためe2-standard-2を選択しました。
Auto-sleepは、未使用状態が続いた場合にVMを自動停止する機能です。30分、1時間、2時間、4時間から選択でき、デフォルトは2時間になっています。ここではコスト最小化のため30分を選択しました。
上記選択後、Advanced optionsをクリックします。

構成作成画面

Advanced optionsをクリックすると、ネットワーク関連設定と、セキュリティ設定が表示されます。
Network tagsは、ワークステーションVMにVPCファイアウォールルールで使用できるネットワークタグを設定できます。空欄のままでも問題ありません。未設定の場合でもcloud-workstations-instanceというネットワークタグが設定されます。
Disable public IP addressesは、ワークステーションVMにパブリックIPアドレスを付与するかどうかを選択することができます。チェックを入れるとパブリックIPアドレスは付与されません。
ワークステーションVMに付与されるパブリックIPアドレスはエフェメラル(起動毎に変化するアドレス)であるため、固定のパブリックIPアドレスが必要な場合はDisable public IP addressesにチェックを入れ、VPCネットワークのCloud NATを有効化する必要があります。
Shielded VMの項目は、Compute EngineのShielded VM設定をワークステーションVMでも有効にするかを選択できます。差し支えなければ、これらは全て有効化した方がよいです。デフォルトは全てチェックが外れています。
設定できたら「続行」ボタンを押します。

構成作成画面

ワークステーションのコンテナ設定画面が表示されます。
この画面では、どのIDEがインストールされたイメージを使うか、またはカスタムコンテナイメージを使うかについてと、コンテナ実行に関する設定が行えます。
基本的には「Managed workstation images with preinstalled code editors」を選択し、デフォルトの「Code OSS」(Cloud Shell Editor相当)か、Jetbrains IDEのイメージを選択するとよいでしょう。

Storage settingsでは、ワークステーションのホームディレクトリ(/home)に接続するディスクのディスクタイプとサイズを選択することができます。
デフォルトでは、ディスクタイプが「Standard」、サイズが「200GB」です。200GBはユースケースにもよりますがデフォルトにしてはちょっとサイズが大きめな気がします。
また、ディスクタイプが「Standard」の場合、サイズは「200GB」からしか選べず、より小さい「10GB」や「50GB」等を選びたい場合はディスクタイプを「Balanced」または「SSD」に変更する必要があります。
ここでは、コストを最小にするため「Balanced」「10GB」を選択しました。

構成作成画面

Advanced container optionsでは、コンテナに接続するデータディスクのディレクトリや実行ユーザーのUIDを変更することができます。コンテナ実行時のENTRYPOINTやArguments、環境変数の追加も可能です。
このあたりは、プリセットのコンテナでは変更する必要はなさそうで、カスタムイメージコンテナで運用したい場合に設定する方がよさそうです。
一通り設定の入力が完了したら、画面下部にある「作成」ボタンをクリックします。

構成作成画面

作成ボタンを押すと、Cloud Workstations構成の一覧画面に遷移します。

構成作成画面

数十秒ほど待つと、構成が有効になります。

構成作成画面

ワークステーションを作成する

クラスタと構成の設定が完了したので、最後にワークステーションの作成を行います。
Cloud Workstationsの左メニューの「ワークステーション」をクリックします。

ワークステーション作成画面

次に、画面上部にある「+作成」ボタンをクリックします。

ワークステーション作成画面

ワークステーション作成画面で、ワークステーション名とワークステーションの構成を選択します。
ワークステーション名にはデフォルトで「workstation-********」というランダムサフィックスが含まれた名前が入っています。
ワークステーション名は実際に開発環境にアクセスする際のURLの構成要素になるため、なるべく分かりやすい名前にした方がよいでしょう。
また、ワークステーションの実行内容を決める構成を選択します。
ワークステーションが設定できたら、画面下部にある「作成」ボタンを押します。

ワークステーション作成画面

「作成」ボタンを押すとマイワークステーションの画面に遷移します。
ワークステーションの作成は数秒で完了します。

ワークステーション作成画面

ワークステーションの開発環境(IDE)にアクセスする

これで、ようやくCloud Workstationsで開発環境を使う準備が整いました。
ワークステーションは作成直後は停止状態であるため、起動する必要があります。
マイワークステーションの一覧画面で、起動したいワークステーションの「START」ボタンを押します。

マイワークステーション画面

起動が完了すると、ワークステーションのステータスが「Running」になり、「START」ボタンが「LAUNCH」ボタンに変化します。
この状態で、「LAUNCH」ボタンを押します。

マイワークステーション画面

Code OSS IDEが開き、ワークステーションにアクセスすることができました。

マイワークステーション画面

ワークステーション環境は以下のようなURLでした。※アスタリスクの部分はランダムな文字列

https://80-workstation-code-ide.cluster-****************.cloudworkstations.dev/?authuser=0

アーキテクチャドキュメントによると、IDEはGatewayを経由してアクセスしており、 $WORKSTATION_ID.$CLUSTER_ID.cloudworkstations.dev というサブドメインになると記載されていますので、だいたい合っていると思います。
Code OSSはCloud Shell Editorと同じ操作方法なので、例えば、 Ctrl+Shift+`を押せばTerminalが表示され、コマンドライン操作が可能になります。

ワークステーションにSSHでアクセスする

ワークステーションにアクセスする方法は前述のブラウザベースのIDEの他、SSHによるアクセスも可能になっています。
SSHでアクセスしたい場合、gcloud beta workstations start-tcp-tunnelコマンドを実行し、PC側にSSHポートを転送します。
以下のコマンドを実行すると、PC端末のTCP 2222番ポートが開き、SSHアクセスできるようになります。

gcloud beta workstations start-tcp-tunnel \
  --project=プロジェクトID \
  --cluster=クラスタ名 \
  --config=構成名 \
  --region=クラスタのリージョン \
  ワークステーション名 22 \
  --local-host-port=:2222

その後、以下のコマンドでSSHログインします。

ssh -p 2222 \
-o "UserKnownHostsFile=/dev/null" \
-o "StrictHostKeyChecking=no" \
user@localhost

なお、上記のSSHコマンドはパスワードレスでのアクセスなのでセキュリティ的に安全なのか不安になるかも知れないですが、前提としてgcloud beta workstations start-tcp-tunnelはIAMで許可されたユーザーのみSSHポート転送を許可するコマンドであるため、原理的には安全であるということになっています。

ワークステーションのCompute Engine VMインスタンスの特徴について

ワークステーションを実行しているVMインスタンスは、以下のような特徴がありました。

  • ワークステーションとして起動するCompute Engine インスタンスはコンフィグ名-***** というインスタンス名で作成される。*****の部分はワークステーションの起動毎に変わる。
  • 内部IP,外部IPもワークステーション起動毎に変わる。
  • 検証では asia-east1リージョンにクラスタを作成したが、ワークステーションのVMインスタンスは asia-east1-aasia-east1-bをランダムに選択して起動する。
  • ブートディスクはSSDタイプの50GBで作成される。
  • ブートディスクは終了時に削除され、次回起動時は初期化された状態でアタッチされるため/homeディレクトリ以外に保存したデータは揮発する。
  • データディスクは「構成」で設定した通りにVM毎に作成され、/homeディレクトリにマウントされる。データディスクはワークステーションが終了しても保持される。
  • データディスクはリージョン永続ディスクとして作成され、VMインスタンスがasia-east1-aasia-east1-bのどちらで起動しても問題無いようになっていた。
  • アクセスすると必ずuserユーザーになるため、1つのワークステーションで複数人がアクセスしても権限分離は行われない。(そのため、1ユーザー1ワークステーションで提供するのがよさそう)
  • 停止状態でワークステーションのIDEやSSHにアクセスしても自動起動しないため、Google Cloud consoleからSTART操作を行う必要がある。 (Cloud Shellは自動起動するのでちょっと残念……)

アクセス制御の方法

アクセス制御したい場合、ワークステーション単位で設定することが可能です。
まず、アクセス許可したいユーザーにプロジェクトのIAMページで「Cloud Workstations オペレーションの閲覧者」(roles/workstations.operationViewer)を付与します。
次に、ワークステーションの一覧からアクセスを許可したいワークステーションのIAM設定を開きます。

ワークステーションIAM画面

IAM設定で、許可したいGoogleアカウントを入力し、「Cloud Workstations User」(roles/workstations.user)を選択し、「保存」ボタンを押します。

ワークステーションIAM画面

これで、特定のユーザーのワークステーションを使わせることが可能です。
なお、ワークステーションに設定するロールは、ドキュメントだと roles/workstations.workstationUser と記載されていますが、表示名が「Cloud Workstations ユーザー(非推奨)」と非推奨を示す表示になっています。
検証したところどちらのロールでも問題無くアクセス制御できたのですが、実際どちらを使うのが正しいのかは判断が難しいです。
(IAMロールの表示名を信じるならroles/workstations.userの方かなと思いますが……)

リソース削除時の注意

  • ワークステーションを削除すると、ワークステーションで使用していたデータディスクも削除される。もしデータディスク内のデータが必要な場合は、別途スナップショットを取得する等して退避させておく必要がある。
  • 構成を削除すると、構成から作成したワークステーションも全て削除される。
  • クラスタを削除すると、クラスタから作成した構成、ワークステーションも全て削除される。

運用中のCloud Workstationsを削除する場合は、ユーザーデータの退避等については十分注意した方がよいと思います。

Jetbrains Gatewayを使ってみる

Cloud Workstationsの目玉機能の1つである、Jetbrains Gatewayとの連携を試してみます。
まずは、Jetbrains IDEを使うための構成を設定します。

Cloud Workstationsの設定

設定の方法は概ねCode OSSの場合と同じですが、ワークステーションのCode editors選択時にJetbrains IDEに変更する必要があります。
今回は「IntelliJ IDEA Ultimate」を選択しました。

構成設定画面

ワークステーション作成時に、IntelliJ IDEAの構成で設定します。

ワークステーション設定画面

ワークステーション作成後に、マイワークステーション画面でワークステーションを起動しておきましょう。

Jetbrains Gatewayの導入

Jetbrains Gatewayをインストールします。下記サイトから、インストール用のパッケージファイルをダウンロードして実行すれば導入できます。(詳細は割愛します。)

https://www.jetbrains.com/ja-jp/remote-development/gateway/

Jetbrains Gatewayを起動すると以下のような画面が表示されます。
Google Cloudの「Install」をクリックします。すると、Cloud Workstationsのプラグインがインストールされます。

Jetbrains Gateway画面

以下のように「Cloud Workstations (Preview)」が表示されますので、「Connect to Google Cloud」ボタンを押します。

Jetbrains Gateway画面

初回は「Sign In」ボタンの画面が表示されますので、Googleアカウントにサインインします。
Googleアカウントのアクセス許可画面に遷移します。

Jetbrains Gateway画面

Googleアカウントのアクセススコープ画面で、許可を求められます。
このとき、「Google Cloud のデータ参照・・・(略)」は必ず有効にします。これが有効になっていないとJetbrains Gatewayからワークステーションにアクセスできませんでした。

Googleアカウントログイン画面

アクセススコープの許可を行うと、Jetbrains Gatewayの画面に戻ります。
Connect to Cloud Workstationsで、Cloud WorkstationsがあるプロジェクトIDを選択します。
「Workstation:」のところはアクセスさせたいワークステーションを選択します。
選択できたら、「Next」ボタンを押します。そうすると、ワークステーションへのアクセスを開始します。
ちなみに、ワークステーションの起動を忘れていると「Failed to start workstation.」というエラーが表示されます。

Jetbrains Gateway画面

アクセスできると、以下のようにIDE versionとリモートホストの開始ディレクトリを選択する画面が表示されます。
IDE versionはワークステーションにインストールされているツールに依存するため変更はできません。
リモートホストは適切なパスを入力します。特にこだわりがなければ /home/userを入力すればよいです。
入力できたら「Connect」ボタンを押します。

Jetbrains Gateway画面

接続できると、ライセンス認証画面になります。
残念ながら、Cloud Workstations側でオンデマンドラインセスを付与してくれるわけではなさそうです。

Jetbrains Gateway画面

ライセンスを有効化すると、無事IntelliJ IDEAが表示されます。
使い勝手はローカル実行のIntelliJと遜色ありません。

Jetbrains Gateway画面

まとめ

ちょっと触ってみた感じでは、Cloud Workstationsは高級なCloud Shellという感じでした。
こう書いてしまうと価格が割と気になりますが、オペレーションを行う踏み台サーバ等の代替として考えると十分以上の機能を持っていると思います。
特に、踏み台サーバだと複数のユーザーが1つのサーバを共有するケースだとデータ管理の面でトラブルが起きやすく、1人1台だと管理が煩雑になりがちです。
Cloud Workstationsは、1人1台の安全な踏み台サーバとして運用するのであれば有用だと思います。
また、開発環境としてみてもクローズドな環境を用意したいケース、例えばGitHub Enterpriseを運用していてgit cloneを許可する端末を限定したい場合等でCloud Workstationsのみ許可して開発させるといった使い方が考えられます。(アイディアレベルですが)

しかし、停止状態のワークステーションの自動起動ができないことや、ワークステーションクラスタの作成手順がやや分かりにくい等、幾つかの点において今ひとつという状況です。
Preview段階ということもあり、これから使い勝手は向上していくと考えれば、可能性が大いにありそうなプロダクトだと思います。
Preview期間中、課金が安い内に是非試してみてはいかがでしょうか。

Discussion

ログインするとコメントできます