k3s上のElido: Helmチャートが展開するもの、しないもの

ElidoはスタックをまるごとKubernetesクラスターにデプロイするHelmチャートを提供しており、この記事では、それを1台のk3sノードで動かす手順を説明します。コマンドの前に、読み進めるべきかを決める部分をお伝えします。Elidoはオープンソースではなく、セルフホスティングは当社が販売する製品ではありません。リポジトリにはライセンスファイルがなく、社外の誰にも、実行や変更のライセンスはありません。このチャートは、当社がリポジトリに置いているデプロイ用のツールで、以下のコマンドは、それと隣にあるランブックによるものです(2026-10-25 閲覧)。Elidoの開発に携わっている方、当社と書面で取り決めがある方、またはプラットフォームの運用に実際に何が必要かを正確に知りたい方は、このガイドをお使いください。

実際にダウンロードできるプロジェクトから選んでいる段階なら、まずセルフホスト型短縮サービスの比較をご覧ください。YOURLS、Shlink、Kutt、Dubを扱っており、ここにある手順は繰り返していません。

このチャートが何であり、何でないか

チャートは deploy/helm/elido にあります。メタデータは elidoapp 組織のGitHubリポジトリを指していますが、2026-10-25 に、認証なしでそのアドレスにリクエストすると404が返ったため、インターネットからクローンできるとは期待しないでください。valuesファイルは ghcr.io/elidoapp からイメージを取得し、そこのコメントはレジストリを公開と書いています。匿名でのプルは確認できなかったため、未検証として扱ってください。

チャートはまだ若くもあります。バージョンは0.1.0で、自身の説明は対象を「大きめのVM上の単一リージョンのk3sクラスター」としています。Kubernetesのチャートに付いてくると思われがちなものがいくつか欠けており、この記事の以前の版は、その一部を誤って説明していました。

• 高可用性はありません。すべてのステートフルセットは、1つのレプリカで動きます。
• バックアップジョブはありません。ランブックにその旨が書かれており、Velero、k8up、またはプロバイダーのスナップショットを使うよう案内しています。
• 監視オブジェクト、ダッシュボード、オートスケーラーはありません。
• マルチリージョンのエッジはありません。プリセットは、リダイレクトを1つのフリートにまとめます。

規制当局や自社のポリシーがそれらを必要とするなら、自分で追加する作業を見込んでください。

セルフホスト用プリセットが展開するもの

values-selfhost.yaml は、4コア、8 GBのホストに収まるよう、すべてを絞り込みます。各アプリケーションのワークロードを1レプリカずつ動かします。api-core、analytics-api、click-ingester、url-scanner、notification、bio-renderer、billing、ダッシュボード(web)、マーケティングサイト、そしてすべてのホストに応答する1つの edge フリートです。サインアップとセッションは、IDサービスが処理します。

その背後には、永続ボリューム付きの6つのステートフルセットがあります。Postgres(プリセットでは20Gi)、Redis(2Gi)、クリックイベント用の列指向ストア(30Gi)、イベントバス(10Gi)、オブジェクトストレージ(20Gi)、検索インデックス(5Gi)です。ここでのRedisは、クラスターではなく、append-only永続化を持つ単一インスタンスです。ドメイン管理、Webhook配信、検索インデックス作成など、以前は独立していたいくつかのサービスは、現在 api-core の内部で動いており、そのためワークロードの一覧が、古いドキュメントより短くなっています。

前提条件

ランブックが求めるのは、Kubernetes 1.27以降、Helm 3.13以降、そしてクラスターを指す kubectl です。また、ダッシュボード、API、リダイレクト、バイオ用のホスト名のDNSレコード、クラスターから到達できるSMTPリレー、クラス caddy のIngressコントローラーも必要です。

k3sにはTraefikが同梱されており、これからインストールするコントローラーと80番と443番ポートを奪い合います。k3sのインストール時に無効にしてください。

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik" sh -
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $UID ~/.kube/config
kubectl get nodes   # should show Ready

インストールを手順ごとに

名前空間を作成し、シークレットを生成します。スクリプトは、データベースのパスワード、IDサービスのCookieと暗号キー、スラッグの難読化キー、APIキーのペッパーにランダムな値を生成し、SMTPとLiqPayにはプレースホルダーを作成します。すでに存在するシークレットは、--rotate を渡さない限りスキップします。

kubectl create namespace elido
./deploy/helm/elido/scripts/bootstrap-secrets.sh elido

スクリプトは最後にPostgresのパスワードを表示します。保存してください。次に、誰かがサインアップする前に、SMTPのプレースホルダーを置き換えます。決済を受け付けるなら、elido-liqpay にも同じ方法が使えます。

kubectl -n elido create secret generic elido-smtp \
  --from-literal=host=smtp.example.com \
  --from-literal=port=587 \
  [email protected] \
  --from-literal=pass=YOUR_SMTP_KEY \
  --from-literal=kratos_uri='smtps://postmaster%40your-domain.com:[email protected]:465/?disable_starttls=false' \
  --dry-run=client -o yaml | kubectl apply -f -

オンデマンドTLSを有効にして、Ingressコントローラーをインストールします。

helm repo add caddy https://caddyserver.github.io/charts
helm -n caddy-system upgrade --install caddy caddy/caddy-ingress-controller \
  --create-namespace --set controller.config.onDemandTLS=true

いよいよElido本体をインストールします。image.tag は、選んだリリースに固定してください。ランブックの例は latest を使っていますが、これではアップグレードとロールバックの見通しが悪くなります。

helm -n elido upgrade --install elido ./deploy/helm/elido \
  -f ./deploy/helm/elido/values-selfhost.yaml \
  --set image.tag=YOUR_TAG \
  --set ingress.hosts.dashboard=app.your-domain.com \
  --set ingress.hosts.api=api.your-domain.com \
  --set ingress.hosts.bio=bio.your-domain.com \
  --set 'ingress.hosts.redirect={r.your-domain.com}' \
  --set ingress.hosts.marketing=your-domain.com \
  --set auth.kratos.publicHost=app.your-domain.com
kubectl -n elido get pods -w

マイグレーションは、必要とするサービスではinitコンテナとして、IDサービスではインストール前のジョブとして実行されます。マイグレーションが失敗すると、新しいPodがトラフィックを受けることはありません。

最初のユーザーとカスタムドメイン

https://app.your-domain.com/signup を開いて登録します。IDサービスがアカウントを作成し、api-coreがユーザー行を保存します。この時点では、そのユーザーをオーナーにするものは何もないため、ワークスペースとメンバーシップを手作業で作成します。これは、チャート自身のインストール時のメモが指示していることです。

kubectl -n elido exec -it sts/postgres -- psql -U elido -d elido <<'SQL'
INSERT INTO workspaces (slug, name, plan_tier)
VALUES ('default', 'Default', 'business') RETURNING id;
INSERT INTO workspace_members (workspace_id, user_id, role)
SELECT 1, id, 'owner' FROM users WHERE email = '[email protected]';
SQL

カスタムドメインは、オンデマンドTLSを使います。顧客がダッシュボードで links.brand.com を追加し、EDGE_CNAME_TARGET に設定したホストにCNAMEを向けます(これはapi-coreの変数で、既定ではElido自身のエッジのホスト名になっているため、変更してください)。最初のHTTPSリクエストで、Ingressコントローラーはapi-coreの GET /v1/caddy/ask を呼び出します。200なら証明書が発行され、403ならドメインが検証されていません。デバッグには kubectl -n elido logs deploy/api-core | grep caddy/ask を使います。

バックアップ、アップグレード、ロールバック

バックアップは自分で行います。ランブックの指針は、Postgresのボリューム(data-postgres-0)は毎日、列指向ストア(data-clickhouse-0)は毎週のスナップショットです。クリックデータは、イベントバスの保持期間内であれば、そこから再生できるためです。イベントバスのボリュームにバックアップは不要です。マネージドのPostgresを使うには、postgres.enabled=false に設定し、elido-postgres シークレットの url をそれに向けます。これらに頼る前に、スクラッチ用の名前空間へのリストアを試してください。

アップグレードは、新しいタグを指定した1つのコマンドです。

helm -n elido upgrade elido ./deploy/helm/elido \
  -f ./deploy/helm/elido/values-selfhost.yaml --set image.tag=NEW_TAG

ローリングアップデートは maxSurge: 1 と maxUnavailable: 0 を使い、helm -n elido rollback elido <revision> は、ボリュームやシークレットに触れずに、Deploymentsを元に戻します。サービスごとにレプリカが1つなので、ステートレスでないワークロードでは、短い中断が起こると考えてください。

既知のつまずき

DPOのためにここへ来たのであれば、ホスト型でもすでに足りるかもしれません。主要データはEUにあり、EUデータレジデンシーガイドに、EU外で処理されるものが載っています。自前のリダイレクトを運用する際のレイテンシについては、エッジPOPの記事をご覧ください。

ブログの関連記事

• セルフホスト型URL短縮サービスの比較
• Bitlyの代替サービスと機能差
• リダイレクトのp95を15ms未満にする
• マーケティングツールのEUデータレジデンシー
• エッジPOPとDNSのみのルーティング