Chienomi

NextCloudの構築・運用と検討

Live With Linux::desktop

序

先日CalDAV/CardDAVの記事を公開したが、そこで「NextCloudを使うほうが無難であり、問題を解決できる」とし、しかしボリュームが大きくなってしまうため、当該記事中での言及は避けた。

しかし、やはりそういう言い方をすると気になってしまうようなので、今回はそのNextCloudの話をする。

実際に検証した結論としては、非常に微妙で、良い選択とは言い難かった。

動機

NextCloudは基本的にはクラウドドライブであり、様々なアプリを追加することはできるものの、これらは原則として共有フォルダという概念の上に成り立っている。 例えばチャット機能やタスク管理機能はあるが、そのような用途にフォーカスして作られているMattermostなどと比べるとバックエンドの仕組みからして筋が悪く使い勝手も悪い。

ところが、プライバシーという観点でも、コストパフォーマンスという観点でも、NextCloudをクラウドストレージとしての利用を期待して使うのは結構微妙である。

それでもNextCloudを使う価値の前提として、そのポピュラーさがある。

NextCloudは同類の中では非常に広く使われているものだ。 このため、アプリのクラウド連携の中にNextCloudが含まれている、ということがよくある。 これによって、利用の幅が他の選択肢よりも広い。

そして大きな点として、この記事のそもそもの話に戻るが、カレンダーや連絡先といった機能は、iCalendar, vCardというフォーマットをファイル共有することによって成り立っており、ファイル共有部分をNextCloudにするということもできる。 ここにNextCloudがポピュラーでサポートされやすいという背景と、CalDAV/CardDAVが死に体であるという事情が合わさって、「スケジュール管理のためにバックエンドとしてNextCloudを使う」というのが普通に考えられる状態だ。

「チーム管理に使う」という話をするのであれば、そんなに良い選択ではない。 そもそも一般的にチーム管理は複数のサービスを組み合わせることが多いと思う。 例えばGoogle WorkspaceとSlack、そしてJiraのように。 MicrosoftならOutlook/Teams/Azure DevOpsなどMicrosoft製のツールだけでやれるかもしれないが。

OSSで自力でやろうとすると、どうしても様々なソフトウェアを組み合わせる必要が出てくる。 こうなるとインテグレーションという観点でもよくないし、コストも管理もつらい。

このため、機能を色々もっているソフトウェアを使うことで幅広く賄おうとしがちなのだが、何がメインで何が付与要素なのかということを見失ったムーブはだいたいうまくいかない。 NextCloudの場合は「対応アプリの多いファイル共有」という意識を持ち、その範囲で使うと良い。 アプリの追加でプロトコル互換性を増加させることもできる。

選択肢

NextCloudプロバイダーを使う

NextCloud公式で紹介されているのがTab.DigitalとGoodCloudだ。

NextCloudを使うのに第三者のプロバイダーを使うことの意義については…… まぁ、各々で考えてほしい。

だが、Tab.Digitalはそもそも登録できないし、GoodCloudはめちゃくちゃ遅いので、実用的かどうかは厳しい。

アプリイメージを使う

NextCloudを使いたい場合の最も無難な選択肢。 アプリイメージがあることころは、アプリの設定方法のガイドとかもあったりするし、そんなに外部に迷惑かかる要素の多いアプリでもないため、それほど問題はないと思う。

自分で組む

導入

NextCloudを完全に知悉したユーザーがこの記事を読むことはないだろうから、前提として「NextCloudを自力できちんと構築するのは大変である」という認識を置く。

もちろん、環境・条件を限定すればコピペで構築することも可能だが、複雑な構成(例えば他のアプリ/サービスと混在させるような構成)だとかなりしんどい上に、メンテナンスも大変。 個人的にはうんざりするレベルに属している。

だから、手動構築するか否かによらず、NextCloudは単独サーバーを推奨したい。

ところが、単独サーバー運用するなら「アプリイメージでいいじゃん」になるのがまた難しい。

個人的には手動構築よりはDockerをおすすめしたい。 AIOはこちら。

複雑な構成を試みるならコミュニティイメージが良いだろう。

さらに発展させるならDocker Composeを使いたい。 Docker Composeを使う方法に関してはQiitaにRyota Saitoさんの記事があるが、2つ問題があり

  • この内容だとちゃんと永続化できない
  • データベースのユーザー名に入力する内容が間違っている

ということである。

そこで修正版をここに示す。 私はボリュームは管理のしやすさという観点からMattermostと同じ方式を選択した。

Docker Composeを使う

docker-compose.ymlは次のようになる。

volumes:
  nextcloud:
  db:

services:
  db:
    image: mariadb
    restart: always
    volumes:
      - ${NEXTCLOUD_DB_VOLUME_PATH}:/var/lib/mysql:rw
    environment:
      - MYSQL_ROOT_PASSWORD=${ENV_MYSQL_ROOT_PASSWORD}
      - MYSQL_PASSWORD=${ENV_MYSQL_PASSWORD}
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud
    ports:
      - 8080:80
    links:
      - db
    volumes:
      - ${NEXTCLOUD_APP_VOLUME_PATH}:/var/www/html:rw
      - ${NEXTCLOUD_APP_DATA_VOLUME_PATH}:/var/www/html/data:rw
    restart: always

なるべく出典の内容を残すようにした。dbはもうちょっと名前を固有の感じにしてもいいかもしれない。 ホスト側ポートの8080は、色々なものをホストしている状態だと衝突しやすいため、変更したほうが楽だろう。 .envは次のような感じ。

ENV_MYSQL_ROOT_PASSWORD=ROOT_PASSWORD
ENV_MYSQL_PASSWORD=PASSWORD
NEXTCLOUD_APP_VOLUME_PATH=./volumes/app
NEXTCLOUD_APP_DATA_VOLUME_PATH=./volumes/data
NEXTCLOUD_DB_VOLUME_PATH=./volumes/db

もちろん、パスワードはちゃんと設定すること。

volumesディレクトリを作る。 中のファイルは当然、コンテナ側から作られるのだが、コンテナとホストでユーザーの対応関係がないため、構築時はグローバルにしておくのが良い。

# mkdir volumes
# chmod 777 volumes

一度起動してからはvolumes直下に新たにファイルが作られることはないため、root:root 755で良い。

あとはdocker compose up -dでOK。 停止時はdocker compose downでいいが、基本的にわざわざダウンさせることはあまりないだろう。アップデートのときくらいか。

Nginxの設定は、全部Dockerに投げる形で良い。 Proxy headersは、NextCloudが必要としているものがわからないので、Mattermostからコピった。

DNSを設定すること、certを獲得することについては単に忘れないようにとだけ言っておこう。

upstream nextcloud {
  server 127.0.0.1:8080;
  keepalive 32;
}

proxy_cache_path /var/cache/nginx_nextcloud levels=1:2 keys_zone=nextcloud_cache:10m max_size=3g inactive=120m use_temp_path=off;

server {
  include global/sslcert.conf;
  server_name example.tld;
  access_log /var/log/nginx/nextcloud.log;
  location / {
    return 301 https://example.tld$request_uri;
  }
}

server {
  include global/sslconfig.conf;
  server_name example.tld;

  # Cert
  ssl_certificate /etc/letsencrypt/live/example.tld/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.tld/privkey.pem;
  ssl_trusted_certificate /etc/letsencrypt/live/example.tld/chain.pem;

  access_log /var/log/nginx/nextcloud.log;

  location / {
    client_max_body_size 50M;
    proxy_set_header Connection "";
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Frame-Options SAMEORIGIN;
    proxy_buffers 256 16k;
    proxy_buffer_size 16k;
    proxy_read_timeout 600s;
    proxy_cache nextcloud_cache;
    proxy_cache_revalidate on;
    proxy_cache_min_uses 2;
    proxy_cache_use_stale timeout;
    proxy_cache_lock on;
    proxy_pass http://nextcloud$request_uri;
  }
}

/var/cache/nginx_nextcloudを使っているが、そんなものはないだろうから、作っておくこと。 パーミッションはArchlinuxではhttp:root 700だった。

あとはNginxをリロードすればOK。

これでvolumes/app以下が/var/www/htmlになるため、config/config.phpが触れるようになる。 そこで、overwrite.cli.urlをhttps://にするとともに、

array(
  //...
  'overwriteprotocol' => 'https',
)

と追加する。 また、'maintenance_window_start' => 15,とかやっとくといいかもしれない。

初期化では

  • ユーザー名 → 管理者ユーザーのユーザー名
  • パスワード → 管理者ユーザーのパスワード
  • ストレージ → MySQL/MariaDB
  • データベースのユーザー名 → nextcloud
  • データベースのパスワード → ENV_MYSQL_PASSWORDの値
  • データベース名 → nextcloud
  • データベースのアドレス → db:3306

自力ホスティングのクラウドドライブの微妙さ

基本的にクラウドコンピューティングにおいて一番高いのはメモリで、次いでストレージ。 そして、お金で買えないのが帯域である。

クラウドドライブはストレージと帯域をとにかく必要とするものなので、VPSを使って構成するのはものすごく微妙だ。

というのも、普通にクラウドドライブを買ったほうが同じコストでより大容量のディスクと高速なアクセスを手に入れられたりする。 さらに、プライバシーの問題も自分でホストしたNextCloudよりMEGAのほうがいいのでなおさら微妙になりがち。

チーム作業のためにNextCloudを、という考えも、MattermostやRevoltもそうだけれどVPSでそんなにリッチな回線を使えるわけでもない上に、通話関連は計算リソースもだいぶ要求されることになるため、結局外部サービスを使うほうが快適だったりする。

クラウドプライバシー

「自分でホストすれば信頼できて安心」というのは、プライバシー業界(?)では随分と時代遅れな話である。

サーバー自体がクラウドホスティングされているのであれば、ベアメタルでもない限りクラウドプロバイダはデータに対してアクセスが可能である。 利用規約にサーバー上のファイルコンテンツに対する言及があるサービスもかなり多い。 サーバー上のファイルに対して制限を課すということは、実際にするかどうかはともかく、サーバーの中に対して干渉する意思を持っているということだ。

クラウドサービスにおけるプライバシーには段階があり

  • そこにプライバシーがないことが明確になっている
  • プライバシー保護についての説明がない
  • 尊重する旨のふわっとした文言がある
  • プライバシー保護についての具体的な仕組みとルールが開示されている
  • プライバシーの侵害が不可能である旨の説明があるが証明されていない
  • プライバシーの侵害が不可能であることが証明されている

今の時代の前提は、「介在する何者であっても一切信用できない」である。 ユーザーのプライバシー意識はだいたい「ふわっと気にしている(つもりである)」か「極めて厳密に気にしている」のどちらかであり、本当に気にする人にとっては「絶対に侵害されない保障がされないことは、つまり侵害されているということ」という認識である。

これは別に過剰なわけではなく、プライバシー保護に対する基本的な考え方でもある。 プライバシーの問題は行き着くところは対国家などになるため、プライバシーの侵害に用いうる手段はこの世界でとりうるもの全てであると考えられる。 そのため、いかなる第三者であっても干渉できないものだけがプライバシー保護として機能するというわけだ。 PGPなどに至っては、当事者の片側すら干渉できなくなる。

例えばTelegramの通常メッセージ1は、アクセスできる人が限定され、アクセスに特別な手続きが必要であることが明らかにされている。 楽観主義であればこれは十分プライバシーを尊重されていると考えるかもしれないが、プライバシーが保護されていると考えることはできない。

プライバシーを焦点にする場合、クラウドプロバイダはプライバシーの侵害が不可能であることを証明することが要求されるのが今の時代だ。 Wire, Threema, MEGAなどのプライバシーを重視するプロバイダは、このあたりを明らかにしたセキュリティホワイトペーパーを公開している。 また、Sessionはその基盤技術自体にプライバシーの侵害が不可能であるものを用いることで証明している。

この基準から見れば、「自分でホストしている」という程度ではまるで信用できない。 最低限信用できるレベルを構築しようとすると、自宅でホストするなどかなりの手間が必要だ。

このように、基本的にセルフホスト型NextCloudはプライバシー観点でのゲインはかなり微妙だ。 もちろん、少なくともGoogle DriveやDropboxよりは信用できるから良しという判断はありえる。

NextCloudでのカレンダー/連絡先機能

CalDAVの話でも言及したけれど、Androidでは外部のカレンダーを使うことは禁じられているようなので、当然のようにNextCloudのカレンダー機能も使えない。 WebDAV機能を使ってCalDAVとして同期する以外にないのだ。

結果として、普通にCalDAVやCardDAVを使うのと体験が変わらない…… どころか、CalDAVサーバーみたいに細やかなコントロールができず、サーバーアプリ自体も割と重いので快適性はむしろ低い。

もちろん、見方を変えればCalDAV/CardDAVサーバーとしてNextCloudを立てるのはアリなわけだが、面倒さを考えるとCalDAVだけのためにNextCloudを使うのはなかなか微妙。

Cinnamon/GNOME (GNOME Online Account)

GNOMEはGNOME Online AccountにNextCloudのサポートがある。

これを使うと、

  • カレンダー
  • 連絡先
  • ファイル

の3項目が使えるようになる。

カレンダーはEvolutionのCalDAV機能、連絡先はEvolutionのCardDAV機能である。 ファイルは、gvfsによりNextCloudをマウントできるようになる。 これは(GNOMEの)Nautilusだけでなく、(Cinnamonの)Nemoなどgvfsを扱うアプリ全般で扱える。

ただしファイル機能に関してはかなりもっさりである上に、このgvfs上のファイルを直接変更できないため、大変使いにくい。

NextCloudデスクトップアプリを使う場合はファイルの同期が可能。 ただし、応答性や競合時の処理など、全体的に微妙。

CalDAV/CardDAVを使う場合の大きな違いとして、EvolutionではCalDAV/CardDAVは項目(カレンダーや連絡先など)個別にアカウントを設定する必要があるが、NextCloudを使う場合は全体で1アカウントで良い。 ただし、そのせいかエラーになってしまうとなかなか復帰しない。

また(.well-knownの設定をすれば解決するかもしれないが)、カレンダーはNextCloud側で予定をなにか1つ作っておかないと認識されず、イベントを作れない。

所感

ソロで見た場合微妙すぎる

Androidアプリは実態としてはwebviewであり、使える機能は基本的にファイルサーバーのみ。 そのファイルサーバー機能も使いやすいとは言い難い。 モバイルから見た場合にNextCloudを使うことが体験を大きく改善するかというとそんなこともなく、全体的にとても微妙。

Linuxデスクトップから見た場合も、CalDAV/CardDAVでなくNextCloudを使うということにメリットを感じることができず、ファイルサーバー機能に関しても大変使いづらく、ポジティブな気持ちになれなかった。

ただ、Linuxでのクラウドドライブというと

  • Dropbox - Basicプランにデバイス数制限あり
  • OneDrive - CLIツールのみ
  • BOX - 公式クライアントなし
  • MEGA - 完璧

という感じであり、MEGAのことを考えないならば「Linuxでもちゃんと使えるクラウドストレージプラットフォームが欲しい」という動機は結構成立しそうではある。

ところが、DropboxはPlusにすればデバイス数制限がなくなり、その費用は月払いでも1500円ほど。NextCloud用にサーバーを建てる最低限のコストとあまり変わらず、そう考えるとやっぱり微妙。

なにより、MEGAはLinux上で完璧に動作するため、MEGAと比べてしまうとなにひとつ良いところがないように感じてしまう。 しかも、MEGAはゼロ知識暗号を用いたE2EEになっており、NextCloudを使うよりよほど安全になっている。ちなみに、クライアントソフトウェアはOSS。

そもそもLinuxデスクトップだけで使うならSSHFSでマウントしたほうがよっぽど良いという感じなので、

こうしたことからNextCloudをファイルサーバー目当てで使うことに対するゲインが消費リソースに見合っているように思えない。

アプリ追加によってさらなる機能を追加することもできるが、少なくともLinuxデスクトップクライアントはファイル同期しか機能を持っていないので、アプリの追加はウェブで使うことがありきになる。 じゃあウェブ上にある機能を絶賛できるかというと、基本的にそれを目的として使いたいならそれ用のソフトウェアを使ったほうが良いというものばかりで、結局ストレージ機能に満足していないなら「NextCloudとてもいい」とはならないのが現実だろう。

チームコラボレーションならアリ

考えられるとすれば、「ストレージ容量は必要ないが、マルチユーザーである」というような場合。 マルチユーザー機能を持っているストレージであっても、基本的にマルチユーザー機能は高価なプランである。課金はユーザーあたりであるし、人数が多いと結構なコストだ。 例えば、Google WorkspaceはStarterで816JPY/1u/mで30uGBのストレージ。MEGAの場合はこれを書いている時点で825JPY/1u/mで全体3TBストレージ、最低ユーザー数3だ。 Dropboxは1500JPY/1u/mで3uTBのストレージ、最低ユーザー数は3。

これを仮に、40人のユーザーがいて、ひとり2GB程度のストレージを必要とすると仮定する。 Google Workspaceの場合、32640円で1.2TBのストレージがつく。 MEGAの場合、32986円で3TBのストレージがつく。 Dropboxの場合、60000円で120TBのストレージがつく。

対して、XServerでNextCloudアプリイメージを使うとした場合、4GBプランに200GBストレージを増設すると4950円/月。 ストレージスペースは良くて200GB程度だが、ユーザー数はいくらでも増やせる。 5ユーザーあたりでコストアドが取れる可能性が出てくるため、ユーザー数が多い場合は有力な選択肢になるだろう。

また、Google Workspaceは提供される機能が多いが、MEGAやDropboxにはスケジュール関連機能がなく、Dropboxにはオンラインミーティングやチャットがない。 「スケジュール共有ができるカレンダー」という機能を求めるとハードルは結構高くて、基本的にグループウェア系のソフトウェアが候補になる。しかし、グループウェアを名乗るソフトウェアは何らかの理由で微妙なことが多く、相対的にNextCloudの「無難さ」が増加する。

トークやタスクなどの機能は貧弱なので、他のソフトウェア、もしくはサービスを利用したほうが良いが、それに関してはGoogle Workspaceを利用していてもSlackやJiraを併用するように、不自然なことではない。 チケット管理はTaskよりはDeck。

「競合しない用途」も悪くはない

クラウドストレージやPIMサーバー、コラボレーションツールなどとして見た場合はなかなか難しい部分もあるが、アプリによってはそれとはまた異なった使い方ができるものもある。

個人での利用であればMoney, Map, Health, Diaryなどを使って、レコード&トラッキングに使うことができる。

チームでの利用であれば、Cospand, Formsなど、ちょっとしたことのために外部サービスを使うまでもないようなものが便利。

ただ、NextCloudそのものが結構もっさり動作であるため、快適かというと微妙。パーソナルロギング目的でNextCloudを使うよりは、デスクトップアプリと組み合わせる形で自分なりに構成したほうが使い勝手は良い。

全体的にWordPressみがある

別にPHPだからということではなく、「定番ソフトウェア」ということを下地にして、プラグインで本質的な機能と関係のない機能を盛っていく感じはだいぶWordPressっぽい。

具体的に列挙するのはなかなか難しいが、設定したり使ったりしていて「WordPressっぽいな」と感じる時は多かった。

めんどくささ対決

前の記事ではCalDAV/CardDAVを使おうとすると面倒だから、NextCloudにしてしまえば面倒がなくなるということを言った。 しかし、NextCloudが思った以上に面倒だったため、そうでもないなとなった。

この面倒は種類が違う。

普通にCalDAV/CardDAVサーバーを立てる場合は、CalDAV/CardDAVがどういう技術であるかということや、それを取り巻く環境を理解する必要があり、まともな資料が少ないためまずこの時点でしんどい。

さらに、実装を調べていくと「業界死んでるじゃん……」の気持ちになり、さらにしんどい。 将来性のありそうなプロジェクトを選択するのも大変。どれも将来性なさそうだから。

NextCloudはやりたいことに対して複雑度が高く、要求リソースも大きい。 構築・管理の手間がありすぎて面倒くさい。

アプリイメージを使えば構築の手間はないけど、管理の手間は変わらないため、それでも面倒は面倒だなという感じ。

私の今の状態を基準にすれば、CalDAV/CardDAVについてはだいぶ調べた状態になっているから、サーバー構築からスタートすれば普通にCalDAV/CardDAVサーバーを使うほうが楽にな感じられるが、なにもない状態からスタートすると「調べるの結構大変だったからなぁ」という気持ちになる。