過去バージョン

本記事は Speckle カテゴリの一部として、Speckle Server の自前ホスティング（セルフホスト）を整理します。SaaS ではなく自社環境でデータを管理したい場合の選択肢です。サーバー全体の構成は アーキテクチャ もあわせて参照してください。

1なぜ自前ホスティングするのか

Speckle はサーバー含めてオープンソースのため、ホスティングされた SaaS を使う代わりに、自社のサーバーやクラウド上に同等の環境を立てられます。主な動機は次のとおりです。

一方で、サーバーの構築・監視・バックアップ・アップデートを自分たちで担う責任が生じます。SaaS と自前のどちらを選ぶかは、データ要件と運用体制のトレードオフです。小規模なチームや試験的な利用ではホスティング済みの SaaS から始め、データの社外保管に制約が出てきた段階でセルフホストへ移行する、という段階的な判断もよく取られます。いきなり本番をセルフホストで組むより、要件が固まってから踏み切るほうが手戻りを抑えられます。

2主な構成要素

これらを個別に立てるのは煩雑なため、コンテナでまとめて起動するのが一般的です。データの実体は オブジェクトモデル のとおり構造化されており、メタデータは DB、巨大な blob はオブジェクトストレージ、という役割分担になります。役割を分けておくことで、たとえば DB は冗長構成にし、ストレージは大容量のディスクへ、といったように構成要素ごとに最適なリソースを割り当てやすくなります。これは規模が大きくなったときの拡張余地にもつながります。

3docker-compose 構成のイメージ

各サービスを docker-compose でまとめて定義する構成が分かりやすい例です。YAML の記号やインデントは崩れやすいので、ここでは概念図として示します（実際の正しい定義は公式の compose ファイルを使ってください）。

services:
  postgres:
    image: postgres
  redis:
    image: redis
  minio:
    image: minio/minio
  speckle-server:
    image: speckle/speckle-server
    depends_on:
      - postgres
      - redis
      - minio
  speckle-frontend:
    image: speckle/speckle-frontend
    ports:
      - "80:8080"

上記はあくまで構成の関係を示すための簡略形で、環境変数・接続文字列・ボリュームなどの実設定は省いています。たとえば DB 接続文字列やバケット設定では & や <・> といった記号が現れることがあり、ファイルに書く際は正しい表記を保つ必要があります（本文中ではそれぞれ &・<・> として表記しています）。

4起動とアクセス

compose ファイルが用意できたら、まとめて起動します。コマンドは概念的に次のとおりです。

docker compose up -d
# 状態確認
docker compose ps
# ログ確認
docker compose logs -f speckle-server

起動後、フロントエンドの URL（例：自社サーバーのホスト名）にブラウザでアクセスし、管理者アカウントを作成します。クライアント側（Connector や SDK）からは、この自前サーバーの URL を接続先として登録します。.NET SDK での接続先指定は .NET SDK を参照してください。

→次に読む