Google GKE へのマルチクラスタのインストール

1. PostgreSQL データベースをセットアップする

CodeCanvas では、CodeCanvas アプリケーションデータ用に PostgreSQL データベースが必要です。

1. PostgreSQL 用 Cloud SQL インスタンス（バージョン 12.2 – 15.12 がサポートされています）をデプロイします。CodeCanvas アプリケーションクラスターからサーバーにアクセスできることを確認してください。

2. CodeCanvas アプリケーション専用のデータベースを作成します。

3. インストールを続行する前に、データベースサーバーが起動して実行されていることを確認してください。

2. オブジェクトストレージを構成する

ユーザーおよびアプリケーションデータを保存するための Google Cloud Storage バケットを作成します。

3. CodeCanvas アプリケーションクラスターを準備する

CodeCanvas アプリケーションクラスターは、CodeCanvas アプリケーションと関連サービスをホストします。CodeCanvas アーキテクチャの詳細

1. GKE クラスタ

   次の要件を満たす CodeCanvas アプリケーション用の GKE クラスターを設定します。

   要件	説明
   Helm	バージョン 3.8.0 以降
   Kubernetes	バージョン 1.29 以降
   クラスターノード	Linux OS (x86_64) を搭載したノードが 4 つ以上。推奨最小リソース: CPU コア 4 個、メモリ 8GB

2. 名前空間

   CodeCanvas アプリケーション専用の名前空間を作成します (NAMESPACE_PLACEHOLDER を名前空間名に置き換えます)。

   kubectl create namespace NAMESPACE_PLACEHOLDER

3. Ingress コントローラー

   GKE セットアップと互換性のある Ingress コントローラーをインストールします。このガイドでは、ingress-nginx(英語) コントローラーを使用します。

4. DNS と TLS を構成する

1. ドメイン名

   CodeCanvas インスタンスのドメイン名を登録します (例: codecanvas.example.com)。

2. DNS ゾーン

   DNS レコードを管理するには、CodeCanvas アプリケーションクラスターに ExternalDNS(英語) をインストールします。

3. TLS 証明書

   暗号化しましょうによって発行された TLS 証明書を管理するには、CodeCanvas アプリケーションクラスターに cert-manager(英語) をインストールします。

4. サブドメイン

   CodeCanvas アプリケーションコンポーネントのサブドメインを設定します。custom.values.yaml の設定では、以下の DNS ドメイン名スキームが想定されています。

   • EXTERNAL_DOMAIN_PLACEHOLDER – メインの管理 UI と REST API を提供する CodeCanvas アプリケーションのメインドメイン。例: codecanvas.example.com

   • computeservice.EXTERNAL_DOMAIN_PLACEHOLDER – compute-service REST API を提供するサブドメイン。これは通常、開発環境 pods のみがアクセスする内部ドメインです。

   • gateway.EXTERNAL_DOMAIN_PLACEHOLDER – gateway-relay サービス（リレーサーバー）を提供します。これは、ユーザーの IDE クライアントがアクセスする外部ドメインです。

5. ワークロード ID の IAM を構成する

CodeCanvas から Google Cloud のストレージバケットとデータベースへのアクセスを設定するには、特定の IAM (Identity and Access Management) 構成が必要です。

1. ワークロード ID

   CodeCanvas アプリケーションクラスターとそのノードに対してワークロード ID 機能を有効にします。

2. Google IAM サービスアカウント

   CodeCanvas アプリケーション専用の別の Google IAM サービスアカウントを作成します。

3. ワークロード ID のロールバインディング

   IAM サービスアカウントを Kubernetes サービスアカウントにバインドします。Google IAM サービスアカウントには roles/iam.workloadIdentityUser ロールが必要です。このロールは、Kubernetes 名前空間と、CodeCanvas アプリケーションの pod を実行する Kubernetes サービスアカウントの両方にバインドする必要があります。これにより、Kubernetes サービスアカウントは Google IAM サービスアカウントの ID を使用して Google Cloud リソースにアクセスできるようになります。

4. ストレージバケットへのアクセス

   Google IAM サービスアカウントに、Google Storage バケットにアクセスする権限を持つ事前定義済みロールまたはカスタムロールがあることを確認します。

   • storage.multipartUploads.abort

   • storage.multipartUploads.create

   • storage.multipartUploads.list

   • storage.multipartUploads.listParts

   • storage.objects.create

   • storage.objects.delete

   • storage.objects.get

   • storage.objects.list

   • storage.objects.restore

   • storage.objects.update

   • iam.serviceAccounts.signBlob

6. （オプション）SMTP サーバーを構成する

CodeCanvas は、ユーザー作成時の招待リンク、メール認証、その他の通知など、様々なメールをユーザーに送信するために SMTP サーバーを使用します。この機能を有効にするには、CodeCanvas アプリケーションクラスターからアクセスできる SMTP サーバーを用意してください。

1. custom.values.yaml ファイルを作成する

custom.values.yaml ファイルを作成し、以下のスニペットをコピーしてください。プレースホルダーは次の手順で実際の値に置き換えます。

2. Google IAM サービスアカウントの割り当て

custom.values.yaml の CODECANVAS_GSA_EMAIL を Google IAM サービスアカウントのメールアドレスに置き換えます。

3. 外部ドメインを指定

custom.values.yaml では、EXTERNAL_DOMAIN_PLACEHOLDER を CodeCanvas インスタンスに登録したドメイン名に置き換えます。

4. cert-manager を設定する

custom.values.yaml では、CERT_MANAGER_NAME_PLACEHOLDER をクラスターで使用されている cert-manager(英語) の名前に置き換えます。

5. データベース設定を指定する

CodeCanvas をインストールすると、外部の PostgreSQL データベースを使用することになります。任意の PostgreSQL データベースを使用できますが、Cloud SQL for PostgreSQL の使用をおすすめします。

6. オブジェクトストレージ設定を指定する

CodeCanvas をインストールすると、外部オブジェクトストレージの使用が想定されます。以下の手順は Google Storage に適用されます。

7. マスターシークレットを作成する

CodeCanvas アプリケーションは、ユーザーシークレット（外部サービスへの認証情報など）を暗号化された形式でデータベースに保存します。これらのデータの暗号化と復号には、マスターシークレットが使用されます。

マスターシークレットは、任意の Base64 エンコード文字列にすることができます。例: openssl を使用してランダムな文字列を生成できます。

1. マスターシークレットを生成するには、以下を実行します。

   openssl rand -base64 32

2. custom.values.yaml で、MASTER_SECRET_PLACEHOLDER を生成された値に置き換えます。

8. システム管理者アカウントを構成する

システム管理者アカウントは、インストール後に CodeCanvas へのログインと設定に使用されます。認証情報は手動で入力することも、システムによって自動生成することもできます。

1. 管理者アカウントを手動で設定するには、custom.values.yaml で次の行を置き換えます。

   • 必要な管理者資格情報を持つ ADMIN_USERNAME_PLACEHOLDER および ADMIN_PASSWORD_PLACEHOLDER

   • CodeCanvas からの管理者通知を受信するためのメールアドレスを持つ ADMIN_EMAIL_PLACEHOLDER

あるいは、custom.values.yaml から localAdministrator.username と localAdministrator.password のセクションを削除することもできます。この場合、デフォルトのユーザー名は admin になり、インストール時にランダムなパスワードが生成されます（チャートのデプロイ後に表示されます）。ただし、ADMIN_EMAIL_PLACEHOLDER の代わりにメールアドレスを指定する必要があります。

9. Ingress クラスを指定する

custom.values.yaml で、INGRESS_CLASS_PLACEHOLDER を、CodeCanvas アプリケーションクラスターに使用される Ingress クラスに置き換えます。

10. CodeCanvas pod の Kubernetes サービスアカウントを指定する

アプリケーションクラスタに Workload Identity を設定し、サービスアカウント名を Helm リリース名とは別のものにしたいとします。この場合、CodeCanvas Helm チャートによって作成される Kubernetes サービスアカウントに特定の名前を指定する必要があります。これを行うには、custom.values.yaml で CODECANVAS_KSA_NAME を希望の名前に置き換えます。

11. (オプション) Sysbox コンテナーランタイムを構成する

デフォルトでは、CodeCanvas はワーカーコンテナーを --privileged モードで実行します（コンテナーはホストノード上でルート権限を持ちます）。セキュリティ上の理由からこれを回避したい場合は、こちらの説明に従って Sysbox Container Runtime をインストールしてください。

12. ライセンス契約に同意する

custom.values.yaml では、ACCEPTANCE_PLACEHOLDER を true に置き換えて、CodeCanvas ライセンス契約(英語)を明示的に受け入れます。

13. CodeCanvas チャートをインストールする

実行:

ここに:

• NAMESPACE_PLACEHOLDER は Kubernetes の名前空間です

• codecanvas は Helm のリリース名です。必要に応じて変更できます。

1. CodeCanvas pods の状態を確認する

実行:

すべての pods は Running 状態である必要があります。平均して、デプロイから pod がアクティブになるまで約 2 分かかります。

pods が Running でない場合は、次のコマンドを実行して原因を見つけてみてください。

および

2. ドメイン名解決の検証

ドメイン名は Ingress ロードバランサーに解決される必要があります。これは次のコマンドで確認できます。

出力にはエラーが含まれていてはなりません。

3. CodeCanvas アプリケーションを確認する

ブラウザーで CodeCanvas インスタンスを開きます。CodeCanvas にログインする際は、インストール時に提供された管理者の資格情報を使用してください。

1. 開発環境クラスタを準備する

CodeCanvas のインストールでは、複数の開発環境クラスタ（たとえば、異なるリージョンに分散）を使用できます。すべての開発環境クラスタの要件は同じです。

1. GKE クラスタ

   次の要件を満たす開発環境用の GKE クラスターを設定します。

   要件	説明
   Helm	バージョン 3.8.0 以降
   Kubernetes	バージョン 1.29 以降
   クラスターノード	開発環境を実行するのに十分なノード（それぞれ Linux OS（Ubuntu、x86_64）搭載）が必要です。推奨最小リソース: CPU コア 4 個、メモリ 8GB。以下の推奨事項をご確認ください。

   クラスターノードに関する主な推奨事項

   • 一般的なノード要件

     Linux OS (Ubuntu、x86_64)、推奨最小リソース: 4 つの vCPU と 8 GB のメモリ。

   • 自動スケーリングを構成する

     自動スケーリングを使用して、負荷に応じてノード数を調整します。通常の使用状況をカバーするのに十分な最小ノード数から開始し、ピーク時には自動スケーリングによってノードを追加できます。自動スケーリングに関する推奨事項を参照してください。

   • リソースを見積もる

     通常およびピーク時の同時使用率（同時環境の平均数と最大数）を見積もります。例: ピーク時のアクティビティで 20 人の開発者がそれぞれ 2 ～ 3 の開発環境を使用する場合、ピーク時の需要は 60 のアクティブ環境になります。

     合計リソース要件を計算します。例: 一般的な開発環境が 4 つの vCPU と 16 GB のメモリである場合、60 の開発環境では 240 の vCPU と 960 GB のメモリが必要になります。

     重要: Kubernetes は、kubelet、kube-proxy などのシステムタスクのために各ノードのリソースの一部を必要とします。システムタスク用に、ノードごとに約 0.2 vCPU と 1 ～ 2GB のメモリを予約する必要があります。正確な値はインストールによって異なります。実際のノードリソース使用量を確認するには、kubectl describe node <node-name> を実行してください。

   • ノード割り当て戦略を選択する

     • 1 つのノード – 1 つの開発環境

       1 つのノードは 1 つの開発環境（ワーカー、pod）のみをホストします。この例では、60 個の開発環境（たとえば n2-standard-4 （4 つの vCPU、16GB のメモリ））には 60 個の個別ノードが必要になります。

       • (+) オーバープロビジョニングなし: 各ノードは単一の開発環境によって完全に利用されます。

       • (+) フォールトトレランス: ノードに障害が発生した場合、影響を受ける開発環境は 1 つだけです。

       • (-) オーバーヘッドの増加: Kubernetes は各ノードのリソースの一部をシステムタスクに使用します。そのため、この例では各開発環境に 4 つの vCPU と 16GB のメモリが割り当てられますが、開発者が利用できるのは 3.8 つの vCPU と 14 ～ 15GB のメモリのみです。残りの 0.2vCPU と 1 ～ 2GB のメモリは Kubernetes のシステムタスクによって使用され、結果として 60 * (0.2 の vCPU と 1 ～ 2GB = 12vCPU と 60 ～ 120GB のオーバーヘッドが発生します。この問題は、より大きなインスタンスを使用することで解決できます。

       • (-) 起動時間が遅い: オートスケーラーは、新しい開発環境ごとに新しいノードをプロビジョニングする必要があります。

     • 1 つのノード – 複数の開発環境

       1 つのノードで複数の開発環境（ワーカー、pods）をホストします。60 の開発環境（合計 240 個の vCPU、960GB のメモリ）の例では、この負荷を n2-standard-32 （32 個の vCPU、128GB のメモリ）などの 4 ～ 6 個のノードに分割できます。

       • (-) オーバープロビジョニング: 実行されている開発環境の数がノードに対応できる数より少ない場合、リソースが無駄になります。

       • (-) フォールトトレランス: ノードに障害が発生すると、複数の開発環境に影響がおよびます。

       • (+) オーバーヘッドの低減: 複数の開発環境が同じノードを共有するため、Kubernetes システムタスク（ノードあたり 0.2 vCPU と 1 ～ 2GB のメモリ）のオーバーヘッドが削減されます。この例では、4 ～ 6 ノードの場合、オーバーヘッドは 4 – 6 * (0.2 vCPU と 1 ～ 2GB = 0.8 – 1.2 vCPU と 4 ～ 12GB のメモリとなります。「1 ノード – 1 開発環境」戦略の場合の 12 vCPU と 60 ～ 120GB のオーバーヘッドと比較してみてください。

       • (+) 起動時間の短縮: ノードに使用可能なリソースがある場合、新しいノードがプロビジョニングされるのを待たずに、新しいワーカー pods をすぐに起動できます。

       • (+) 潜在的なコスト削減: 少数の大規模インスタンスを使用する方が、多数の小規模インスタンスを使用するよりもコスト効率が高くなる可能性があります。ただし、これはリソース使用量をどれだけ正確に予測できるか、開発環境をノードにどれだけ効率的に配置できるかに依存します。

   • GCP インスタンスタイプを選択する

     GKE インスタンスタイプを比較して選択するには、GCP マシンタイプドキュメントを参照してください。

     e2 インスタンスなど、動的リソース割り当てを行うインスタンスタイプは避けてください。代わりに、n2 や c2 インスタンスなど、コンピューティング最適化またはメモリ最適化されたインスタンスタイプの使用を検討してください。

2. CSI ドライバー

   GKE は、永続ボリュームとスナップショットにデフォルトで pd.csi.storage.gke.io CSI ドライバを使用します。追加のインストールは必要ありません。CodeCanvas の CSI について詳しく見る

3. CSI スナップショットコントローラー

   CSI スナップショットコントローラー(英語)は、Kubernetes のスナップショット操作を実装する CSI ドライバのアドオンです。pd.csi.storage.gke.io CSI ドライバのスナップショットサポートは、GKE ではデフォルトで有効になっています。

4. ストレージクラス

   開発環境で使用される永続ボリュームをプロビジョニングするための Kubernetes StorageClass を作成します。以下の推奨構成を使用することも、パフォーマンスやコストの好みに応じて独自の構成を定義することもできます。推奨構成では、GKE の汎用性に優れた pd-balanced 永続ディスクを使用します。

   開発環境クラスターには複数のストレージクラスを設定できます。インスタンスタイプを作成する際に、利用可能なストレージクラスから選択できます。

   1. storage-class.yaml ファイルを作成し、以下のスニペットをコピーします。

      apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: storageclass.kubernetes.io/is-default-class: "false" name: codecanvas-storage # You can change this name provisioner: pd.csi.storage.gke.io allowVolumeExpansion: true mountOptions: - debug parameters: type: pd-balanced reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer

   2. 構成をクラスターに適用します。

      kubectl apply -f storage-class.yaml

5. ボリュームスナップショットクラス

   Kubernetes VolumeSnapshotClass を作成して、開発環境で使用される永続ボリュームのスナップショットサポートを有効にします。以下の推奨ボリュームスナップショットクラス構成をご利用いただけます。

   開発環境クラスターには複数のボリュームスナップショットクラスを設定できます。インスタンスタイプを作成する際に、利用可能なクラスから選択できます。

   1. snapshot-class.yaml ファイルを作成し、以下のスニペットをコピーします。

      apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: annotations: snapshot.storage.kubernetes.io/is-default-class: "true" name: codecanvas-volume-snapshot # You can change this name driver: pd.csi.storage.gke.io deletionPolicy: Delete

   2. 構成をクラスターに適用します。

      kubectl apply -f snapshot-class.yaml

2. （オプション）リレーサーバーをインストールする

CodeCanvas インスタンスで JetBrains IDE を使用する予定の場合は、少なくとも 1 つのリレーサーバーを設定する必要があります。これにより、ローカルマシン上の JetBrains クライアントとリモート IDE バックエンド間の接続が可能になります。

最適なユーザーエクスペリエンスを実現するには、レイテンシを最小限に抑えるために、リレーサーバーを開発環境クラスターの近くにデプロイする必要があります (例: 開発環境クラスター自体または同じリージョン内)。

リレーサーバーのインストール方法に関する指示に従ってください。

3. （オプション）移動サーバーをインストールする

ユーザーが SSH 経由で開発環境に接続できるようにする場合（例: VS Code/Cursor、リモートの開発環境またはターミナルアクセスを使用）、踏み台サーバーを設定する必要があります。それ以外の場合、この手順はオプションです。

最適なユーザーエクスペリエンスを実現するには、レイテンシを最小限に抑えるために、踏み台サーバーを開発環境クラスターの近くにデプロイする必要があります (例: 開発環境クラスター自体または同じリージョン内)。

踏み台サーバーのインストール方法に関する指示に従ってください。

4. 開発環境クラスタを接続する

1. ヘッダーナビゲーションで管理を選択し、サイドバーメニューでコンピューティングプラットフォームを選択します。

2. 新規接続をクリックします。

   

3. この接続に名前を指定し、その他の設定を指定します。

   • Kubernetes 名前空間 – 開発環境が稼働している Kubernetes 名前空間。名前空間はすでに存在する場合もありますが、そうでない場合は接続時に作成されます。

   • リレーサーバーと移動サーバー – 前の手順で作成したサーバー。

   • ここで、ニーズに応じて pod YAML テンプレートを変更することもできます。この設定やその他のコンピューティングプラットフォーム設定について詳しく

4. 保存をクリックすると、接続がリストに追加されます。接続はまだアクティブではないことに注意してください。

   

5. 接続名をクリックすると詳細が開きます。

6. 接続の詳細ページには、開発環境クラスターに CodeCanvas オペレーターをインストールするために使用するスニペットが表示されます。オペレーターは CodeCanvas アプリケーションと通信し、開発環境クラスター内のワーカー pods を起動 / 停止します。

   1. CodeCanvas アプリケーションとオペレーターが相互に通信するには、キーペアが必要です。公開鍵は CodeCanvas に保存され、秘密鍵はオペレーターによって使用されます。

      キーペアを生成するには、キーを生成するをクリックします。秘密鍵は自動的にスニペットに追加されます。

   2. （オプション）スニペットを更新して、デフォルトのネットワークポリシーを変更します。デフォルトでは、開発環境へのすべての受信トラフィック（開発環境間のトラフィックを含む）がブロックされ、すべての送信トラフィックが許可されます。ネットワークポリシーを変更する方法を学ぶ

   3. スニペットをクリップボードにコピーします。

   4. スニペットを実行して、開発環境クラスターに適用します。スニペットはクラスターを構成し、オペレーターをインストールします。

7. 接続のテストをクリックし、すべてのチェックが成功していることを確認します。