ferdium サーバー自前で立てる前に確かめる3点

ferdium サーバー自前という言葉で検索している人は、たいてい理由がはっきりしている。1台目と2台目でサービスの一覧をそろえたいか、その一覧が他人の運営するサーバーに載っている状態が業務上まずいか、そのどちらかだ。この2つは似て見えるが別の問題で、サーバーを自分で立てて解決するのは後者のほうになる。構築そのものは難しくない。Dockerのイメージが用意されていて、データベースと数個の環境変数を決めれば動く。この記事では、そのサーバーが預かっている中身を先に押さえたうえで、構築の手順と、自前で持つ判断が割に合う条件を順に整理する。

同期されるのは設定であって、ログイン状態ではない

Ferdiumのサーバーは、設定を預かるための同期用サーバーになる。保存されるのはアカウントの情報、サイドバーに並べたサービスの一覧、それらをまとめたワークスペース、そしてサービスごとに付けた設定になる。並び順、表示名の上書き、アイコン、通知の消音、ハイバネーションの対象から外すかどうか、独自のURL。どれも設定の文字列だ。

ここで押さえておきたいのは、2台のMacで一覧がそろっても、ログイン状態はそろわないという点になる。CookieとサイトのローカルストレージはそれぞれのMacの中、アプリが持つ保存領域に置かれている。デスクトップのFerdiumでGmailにログインしても、ノート側のFerdiumは未ログインのままだ。これは公式のサーバーを使っても、自前で立てても変わらない。メッセージの中身もサーバーを通らない。各サービスの画面は、Ferdiumが直接そのサービスから読み込んでいるためだ。

この線引きを知らずに構築すると、期待が外れる形で表に出る。2台目を立ち上げたら、サイドバーには正しい20項目が並び、その1つずつにログイン画面が出る。一覧は届いた。ログインは届いていない。設計上、この先も届かない。

ブラウザ側の同期も、同じ位置に線を引いている。

すべてのデバイスで同じブックマーク、パスワード、その他の設定を使用する 出典: support.google.com

移るのは設定だ。Chromeがそれに加えて運ぶのは保存済みのパスワードであって、ログインしたままの状態そのものではない。Ferdiumには保存済みパスワードに相当する仕組みが無いため、2台目でのログイン操作は毎回手作業になる。

アカウントを作らずに使う道が、本当の比較対象

Ferdiumは、アカウントを作らずに使える。最初の起動でその選択肢を選ぶ形になり、設定はそのMacの中だけに保存される。手動でバックアップを取る方法も公式に案内されている。すでにクラウド側のアカウントで使っている場合も、設定をバックアップしてからログアウトし、アカウント無しの側へ切り替えられる。

Macが1台だけなら、たいていはこちらが正解になる。サービスの一覧はファイルとして置かれていて、Time Machineの対象にすでに入っている。アプリを起動するために、別の何かが動いている必要もない。1台のMacを1台のMacと同期させるためにサーバーを1つ増やすのは、できることを増やさずに依存先だけを増やす形になる。

アカウント無しで足りなくなる場面は2つある。1つ目は、実際に2台以上を使っていて、サービスの一覧が頻繁に変わる場合だ。変えるたびにファイルを手で写す運用は、月に何度も起きると続かない。2つ目は、複数人で同じ社内ツール群を持ちたい場合になる。1人ずつが手順書を見ながら15個の独自サービスを追加していく作業は、人数分そのまま増える。

Dockerで立てるときに決める3つのこと

サーバーはAdonisJSで書かれたアプリケーションで、ferdium-server として公開されている。Dockerのイメージを使う方法と、リポジトリを取得して自分で動かす方法の2通りが案内されている。コンテナ内部の既定のポートは3333番になる。データの置き場所は DATA_DIR が指す場所で、ここが今後の更新をまたいで残り続ける必要がある。

データベースはSQLiteのままでよい

既定はSQLiteで、この規模ではそれが妥当な選択になる。MySQL、MariaDB、Postgresも DB_CONNECTION と、それに対応する DB_HOST、DB_PORT、DB_USER、DB_PASSWORD、DB_DATABASE の指定で使える。ただし個人や少人数で使うなら、どれも要らない。保存される中身は1人あたり数キロバイトの設定テキストで、そのためにデータベースのコンテナを足すと、バックアップの対象が1つから2つに増えるだけになる。

登録は開けたままにしない

インターネットに向けて公開したサーバーで登録を開けたままにすると、身に覚えの無いアカウントが溜まっていく。IS_REGISTRATION_ENABLED でこれを閉じられる。想定されている順序は、いったん開けて必要なアカウントを作り、閉じて再起動する流れになる。Web側の画面については IS_DASHBOARD_ENABLED と IS_CREATION_ENABLED が同じ範囲を扱う。パスワードの再発行をメールで行うには SMTP_HOST から始まる一群の設定が要る。メールを設定していないサーバーは、パスワードを忘れた日にデータベースを直接触ることになる。

自分で動かす方法は見通しがよく、壊れやすい

リポジトリを取得し、依存を入れ、node ace migration:run で移行を流し、npm start で起動する手順も案内されている。何が動いているかは分かりやすい。代わりに、1年後2年後のNodeのバージョンのずれで動かなくなる形の故障が起きやすい。コンテナはその点を固定してくれる。

クライアント側の接続と、Franzからの引っ越し

どのサーバーに接続するかは、Ferdium側の初期設定で決める。公式のサーバーの代わりに、自前のサーバーのURLを入れる欄がある。サーバー側の APP_URL は、クライアントが実際に使う住所と一致させておきたい。リバースプロキシを挟んでHTTPSで公開しているなら、その形のままで入れる。パスワード再発行のリンクがこの値から組み立てられるためだ。

古い系譜からの引っ越し口も用意されている。サーバーは /import という経路を持っていて、FranzまたはFerdiのアカウント情報でログインすると、同じ資格情報のユーザーを作り、そのアカウントの設定とサービスとワークスペースを写す。この経路を使えるかどうかは CONNECT_WITH_FRANZ で決まる。分岐が起きる前からFranzを使っている場合、これが自前のサーバーへ移る最短の道になる。

接続が済めば、1台目で追加したサービスは2台目にも現れ、消せば消える。注意したいのは、サーバーを置いた機械がスリープする構成にした場合になる。サーバーに届かない状態でクライアントが同期しようとすると、原因の分かりにくい表示が出て、サーバーが戻ると自然に解消する。原因を探して時間を使いやすい場所だ。

立てた後に効いてくる、控えと到達性の話

自前で持つ判断で本当に重いのは、構築の手間ではない。最初の勢いが落ちた後の姿のほうになる。ここは壊れた日に考えるのではなく、立てる日に決めておきたい。

控えを取る対象は1つのディレクトリで済む

SQLiteのままなら、状態のすべては DATA_DIR が指すディレクトリに収まっている。そのディレクトリを定期的に別の場所へ写せば、それが控えのすべてになる。戻すときは書き戻してコンテナを起動するだけだ。Postgresに移した場合は、これがデータベースの書き出しに置き換わる。手順としては確立された作業だが、作業であることに変わりはない。既定のデータベースをそのまま使うのが妥当だと言えるのは、この差が理由になる。

もう1つ、覚えておきたい置き場所がレシピのディレクトリになる。ここに置いた独自のレシピはクライアントへ配られるため、公開されているレシピが無い社内ツールを複数人で使う場合に効く。これも状態なので、同じ控えの対象に入れておきたい。

届かない時間があると、原因の分かりにくい不調に見える

スリープする機械にサーバーを置いたり、住所が変わる回線の内側に置いたりすると、同期が時々失敗する。クライアント側の不具合のように見えるが、動作としては正しい。厄介なのは、仕事をしている最中に症状が出て、調べ始めると消えることだ。自宅に置くなら、起きたままの機械と、変わらない到達手段の2つを先に用意したい。

リバースプロキシを挟んで証明書を当てる構成が一般的で、その場合 APP_URL には内部の住所ではなく公開している住所を入れる。ここを間違えても表には出にくい。同期は動き続け、パスワード再発行のメールだけが、誰も開けないリンクを持って届く。

更新をためると、当たりの悪い日が来る

コンテナのイメージを更新すると、新しいイメージの起動時にデータベースの移行が走る。控えが効いてくるのはこの瞬間になる。状態が1つのディレクトリで済む構成にしておく利点は、ここでも出る。何世代も飛ばしてから一気に上げる進め方が、最も面倒な午後を呼びやすい。数か月に1度は様子を見る運用のほうが、2年に1度思い出す運用より軽く済む。

3つの道を並べて比べる

	公式のサーバー	自前のサーバー	アカウント無し
2台で一覧がそろう	そろう	そろう	手でファイルを写す
設定の置き場所	運営側の設備	手元で管理する機械	そのMacの中
ログイン状態の同期	されない	されない	されない
増える維持の手間	無い	コンテナと、その控え	無い
ネットが切れているとき	同期は止まる	同期は止まる	影響なし
複数人で一覧を共有	できる	できる	できない

判断を分けるのは、たいてい「増える維持の手間」の行になる。1人の利便のために動かすコンテナも、更新の対象であり、バックアップの対象であり、止まったことに気づく必要のある対象になる。

サーバーを自前にしても変わらない部分

サーバーを自分で持つと、設定の置き場所が変わる。アプリを開いた後の振る舞いは変わらない。同期の設定のせいだと思われている不便の多くは、実際にはアプリの形のほうから来ている。

画面は1つの窓と1本のサイドバーのままだ。サービスが20個あれば、1時間に何度もその20個を目で追うことになる。この探す動作は、一覧を預かるサーバーを自分で持ったところで速くならない。この分野の製品が窓とサイドバーをどう使い分けているかはFerdiumとの比較に整理してあり、サイドバーの1行ではなくアプリごとに場所を与える考え方はワークスペースで扱っている。

外から届いたリンクの行き先も変わらない。macOSが持てる既定のブラウザは1つで、「仕事のカレンダーから来たリンクは仕事のアカウントで開く」という指定はできない。この制約はこの分野の道具すべてに共通していて、サーバー側のどの設定でも動かせない。リンクの行き先や通知のように、分離ではなく導線を扱う機能はできることにまとまっている。

ログイン状態が機械ごとに分かれる点も、先に見たとおり変わらない。2台目には2台目のログインが要る。

自前で持つ判断が割に合う条件

整理すると、自前のサーバーが効くのは条件がはっきりしている。設定の置き場所を自分の管理下に置く必要があること、または複数人で同じ一覧を配る必要があること。この2つのどちらかに当てはまるなら、SQLiteのまま最小の構成で立てて、必要なアカウントを作った後に登録を閉じる。それで完成する。当てはまらないなら、アカウント無しの構成のほうが手数も故障の余地も少ない。

そのうえで残る不便がどちら側の話なのかは、切り分けておきたい。困っているのが「2台目で同じ一覧が欲しい」ならサーバーの話で終わる。困っているのが「目的の画面にたどり着くまでが遅い」なら、置き場所ではなくアプリごとに独立したワークスペースを与えるような、区切りの単位そのものを動かす形の道具を見る段階になる。1週間、いまの構成のままで「アプリの外に出た回数」と「サイドバーを目で追った回数」を分けて数えると、どちらの問題なのかは自分で判定できる。機能表を先に読むより外しにくい。