Hub Codespace みたいな、GitPod というサービスがある。リポジトリごとに workspace を立ててリモートで開発できるようにするというもの。

https://www.gitpod.io/

これが、Self-hosted で Kubernetes 上に構築できるので、やってみた。

docs には Managed-Kubernetes でやる方法しか載っていないけど、Self-managed なクラスタにも適用できる方法が以下に載っている。

https://github.com/gitpod-io/gitpod/blob/main/install/installer/README.md

(最近、こういう専用のデプロイ CLI を用意するプロダクト増えたけど、IaC やりづらくなるので Operator に統一されてほしい。。。)

デプロイについては割愛。pvc, type: LoadBalancer, cert-manager あたりが構築済みであればシュッと行くと思う。気が向いたら記事にします。

現在、マニフェスト管理リポジトリやプライベートプロジェクトで利用しているが、控えめに言って最高である。

ブラウザ上の code-server が十分よく動くのと、VSCode や JetBrains IntelliJ IDEA などがローカルにインストールされていると、自動的に Remote Development として起動してくれる。ローカルを使っているのと遜色ない開発体験が得られる。

Workspece として利用するコンテナイメージを差し替えたり、自前のものを利用することもできる。例えば、.zshrc や asdf などを最初からインストールしておいたイメージを使うこともできる。非常に便利。

ただうーむと思う点もあり、アーキテクチャが想像よりもかなり複雑であるため、可用性高く運用するのは結構覚悟がいりそうだなと感じた。

デプロイしてみたけど、なんか動いた以上のことはなく、障害が発生したらうまくハンドリングできる自信は今のところない。

簡単にまとめると、DB(MySQL), Private Registry(docker-registry + minio), MessageBus (rabbitmq), Workspace Management (openvsx, 独自開発), 謎プロキシ、といった感じだった。openvsx なんてのを初めて知った。

The・k8s 上に構成するマイクロサービスアプリケーション！という感じなので、構成さえ理解すれば割とすっと運用できるのかもしれない。

結論、しばらく使ってみようかなと思っている。

追記

引き続き便利に使っているが、以下の設定を入れた。

gitpod では、一定期間使用されなかった workspace (リモート開発環境) は停止する。

workspace がサスペンドする際に、git にコミットされていない workspace での変更はオブジェクトストレージにアップロードされる。

inCluster の設定では、クラスタ内に minio が立ってそこにアップロードされるのだが、アップロードに失敗することがよくあった。これは minio の設定のせいっぽい。

アップロードに失敗すると、workspace での変更はすべて破棄され、まっさらな stage に戻ってしまう。特にリトライや workspace の停止処理の停止などはしてくれない。

これでは不便すぎるので、外部オブジェクトストレージを利用することにする。

gcs や s3 (互換 API を含む)がサポートされているので、s3 を設定した。s3FullAccess という大きめな権限を要求される。

挙動を見るに、ユーザーごとにバケットが作成され、その中に workspace の全ファイルが tar にまとまって保存される仕様らしい。

これでひとまず安定するようになった。s3 の重課金が発生しないか注視しながら使うようにする。