Google Cloud Next'22 で発表された Cloud Workstations を試してみた
こんにちは。クラウドエースの阿部です。
この記事では Google Cloud Next'22 で発表された Cloud Workstations について説明します。
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のアーキテクチャの公式ドキュメントは以下になります。
アーキテクチャの説明で、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
参考
課金体系
課金体系は下記のページに記載されています。
課金のキモとなる部分を抜粋します。
- コントロールプレーン: $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とサービスを検索する画面が表示されますので、検索テキストボックスに「Cloud Workstations」と入力してEnterを押します。
検索結果にCloud Workstations 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-a
とasia-east1-b
をランダムに選択して起動する。 - ブートディスクはSSDタイプの50GBで作成される。
- ブートディスクは終了時に削除され、次回起動時は初期化された状態でアタッチされるため
/home
ディレクトリ以外に保存したデータは揮発する。 - データディスクは「構成」で設定した通りにVM毎に作成され、
/home
ディレクトリにマウントされる。データディスクはワークステーションが終了しても保持される。 - データディスクはリージョン永続ディスクとして作成され、VMインスタンスが
asia-east1-a
、asia-east1-b
のどちらで起動しても問題無いようになっていた。 - アクセスすると必ず
user
ユーザーになるため、1つのワークステーションで複数人がアクセスしても権限分離は行われない。(そのため、1ユーザー1ワークステーションで提供するのがよさそう) - 停止状態でワークステーションのIDEやSSHにアクセスしても自動起動しないため、Google Cloud consoleからSTART操作を行う必要がある。 (Cloud Shellは自動起動するのでちょっと残念……)
アクセス制御の方法
アクセス制御したい場合、ワークステーション単位で設定することが可能です。
まず、アクセス許可したいユーザーにプロジェクトのIAMページで「Cloud Workstations オペレーションの閲覧者」(roles/workstations.operationViewer
)を付与します。
次に、ワークステーションの一覧からアクセスを許可したいワークステーションのIAM設定を開きます。
IAM設定で、許可したいGoogleアカウントを入力し、「Cloud Workstations User」(roles/workstations.user
)を選択し、「保存」ボタンを押します。
これで、特定のユーザーのワークステーションを使わせることが可能です。
なお、ワークステーションに設定するロールは、ドキュメントだと 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をインストールします。下記サイトから、インストール用のパッケージファイルをダウンロードして実行すれば導入できます。(詳細は割愛します。)
Jetbrains Gatewayを起動すると以下のような画面が表示されます。
Google Cloudの「Install」をクリックします。すると、Cloud Workstationsのプラグインがインストールされます。
以下のように「Cloud Workstations (Preview)」が表示されますので、「Connect to Google Cloud」ボタンを押します。
初回は「Sign In」ボタンの画面が表示されますので、Googleアカウントにサインインします。
Googleアカウントのアクセス許可画面に遷移します。
Googleアカウントのアクセススコープ画面で、許可を求められます。
このとき、「Google Cloud のデータ参照・・・(略)」は必ず有効にします。これが有効になっていないとJetbrains Gatewayからワークステーションにアクセスできませんでした。
アクセススコープの許可を行うと、Jetbrains Gatewayの画面に戻ります。
Connect to Cloud Workstationsで、Cloud WorkstationsがあるプロジェクトIDを選択します。
「Workstation:」のところはアクセスさせたいワークステーションを選択します。
選択できたら、「Next」ボタンを押します。そうすると、ワークステーションへのアクセスを開始します。
ちなみに、ワークステーションの起動を忘れていると「Failed to start workstation.」というエラーが表示されます。
アクセスできると、以下のようにIDE versionとリモートホストの開始ディレクトリを選択する画面が表示されます。
IDE versionはワークステーションにインストールされているツールに依存するため変更はできません。
リモートホストは適切なパスを入力します。特にこだわりがなければ /home/user
を入力すればよいです。
入力できたら「Connect」ボタンを押します。
接続できると、ライセンス認証画面になります。
残念ながら、Cloud Workstations側でオンデマンドラインセスを付与してくれるわけではなさそうです。
ライセンスを有効化すると、無事IntelliJ IDEAが表示されます。
使い勝手はローカル実行のIntelliJと遜色ありません。
まとめ
ちょっと触ってみた感じでは、Cloud Workstationsは高級なCloud Shellという感じでした。
こう書いてしまうと価格が割と気になりますが、オペレーションを行う踏み台サーバ等の代替として考えると十分以上の機能を持っていると思います。
特に、踏み台サーバだと複数のユーザーが1つのサーバを共有するケースだとデータ管理の面でトラブルが起きやすく、1人1台だと管理が煩雑になりがちです。
Cloud Workstationsは、1人1台の安全な踏み台サーバとして運用するのであれば有用だと思います。
また、開発環境としてみてもクローズドな環境を用意したいケース、例えばGitHub Enterpriseを運用していてgit clone
を許可する端末を限定したい場合等でCloud Workstationsのみ許可して開発させるといった使い方が考えられます。(アイディアレベルですが)
しかし、停止状態のワークステーションの自動起動ができないことや、ワークステーションクラスタの作成手順がやや分かりにくい等、幾つかの点において今ひとつという状況です。
Preview段階ということもあり、これから使い勝手は向上していくと考えれば、可能性が大いにありそうなプロダクトだと思います。
Preview期間中、課金が安い内に是非試してみてはいかがでしょうか。
Discussion