Xserver VPSを契約して、Mattermostをインストール・運営する手順について

複数のメンバーと進めているプロジェクトの情報共有方法として、2020年からslackを使っていました。

しかし、2022年９月頃から、slackの有料プランの内容が変更され、無料でできることにかなり制限がかかることになりました。

この際「Mattermost」への移行を、関係者で検討してみました。

ちなみに、Mattermostとは、こんなソフトです。

Mattermost (マターモースト) は、オープンソースのセルフホスティング式のチャットサービスである。組織や企業の内部チャットとして設計されており、Slackの代替として売り出されている。MattermostはMattermost, Inc.によって開発と保守が行われている[7]。同社はオープンソース版にはないサポートサービスと追加機能がある商用版を販売することによって利益を得ている。

Mattermost社が運営しているクラウドサービス版と、自分でサーバーを立ち上げ、そこのMattermostを動かす、オンプレミス版があります。

クラウドサービス版は無料で使うこともできますが自由度が制限されており制限を解除するためには毎月課金のような有料となります。後者の方は無料で比較的自由に扱うことができます。

今回は、検討の結果、Mattermostのクラウドサービスではなく、サーバーを用意してオンプレミスで運用することしました。

サーバーとして、今回はXserverのVPSで導入してみたところ、壁にぶち当たったり、多少苦労したので、そのへんのつまずきやすいポイントを、備忘録代わりに、ここにまとめます。

大まかな手順

サーバーを用意
Mattermostをサーバーにインストール

独自ドメインの設定
SSLの設定

SlackデータをMattermostに引っ越し

という手順で進めていきました。

サーバーを用意

今回は、Xserver のサーバーを利用することにしました。

2022年からXserver でVPSサービスが始まり、Mattermostのインストールを簡単に使えそうだったのが決め手です。

過去に、Xserver のレンタルサーバーやドメインサービスを利用していて、システム管理・運用の仕方が平易になっていて、契約者側でサーバー周りの深い知識が無くとも、ある程度のことはできるので、VPSも同じような感じで動かせるだろうと思っていました。（結果的には、そんなには簡単ではなかったので、このブログ記事で手順をまとめています。）

まずは、Xserver VPSを契約します。

Xserverアカウントがない人は作成してから、VPSプランを契約。

Xserverアカウントがある人は、IDでログインして、VPSプランを契約。下のバナーからVPSを申し込みできます。

XserverでVPS申込画面へ — Xserverのサイトに行き、VPS申込画面へ(右上に「お申し込み」ボタン)

料金プランを選択

サーバースペック・契約期間により料金が異なります。

最初は、高スペックでなくとも大丈夫だと思います。表示プランの中ではスペックの低い月額830円(3年契約)を選択しました。

Mattermostをサーバーにインストール

契約画面の選択時に、Mattermostのアプリイメージをインストールします。この作業は、この段階でなくとも、契約後にVPS管理画面で「OS再インストール」でも実行できます。

申し込み画面を下に進むと、「アプリケーション」タブがあるので、そこで「Mattermost」を選択します。それ以外の項目を設定して、「お申し込み内容を確認する」ボタンを押して、次のページへ進みます。

内容確認し、決済等が済むと、そのままサーバーがセットアップされ、Mattermostも同時にインストールされます。

最終的に、VPS管理画面で表示されている、割り当てられたIPアドレス(あるいは指定サーバーアドレスXXX.xvps.ne.jp)で、ブラウザのアドレスバーにURLを叩けば、Mattermostが初期画面が表示されます。

ここまでは、順調に進みます。

この状態で始めてもいいのですが、次に、

・独自ドメイン
・SSL

の設定に進みます。

ここから難易度があがります。FTPやコマンドを打ったりする必要があり、このときはそんなに大変なことになるとは思っていませんでした。。。

独自ドメインの設定

今後の用途として、このMattermostを、いろいろなメンバーとのコラボツールにしたいので、IPアドレスや、XserverドメインのURL(XXX.xvps.ne.jp)ではなく独自のドメインで、Mattermostにアクセスできるようにしたいです。まずは、Xserverドメインでドメインを購入します。

ドメイン設定の変更

Xserver Domainの管理画面で、取得したドメインの設定に進み、「XserverVPS」を選び、次に進んでいきます。

これで、取得したドメインのネームサーバーとして、

ns1.xvps.ne.jp
ns2.xvps.ne.jp
ns3.xvps.ne.jp

が設定されました。

ドメイン設定情報は、すぐには反映されないので、翌日以降で取得したドメインでURLを叩いてみると、こんな画面に。

なぜか、アクセスできません。

IPアドレス/XserverドメインのURL(XXX.xvps.ne.jp)では、Mattermostにアクセスできるので、サーバーの問題ではなく、ドメイン設定の問題だと思われます。

VPSの管理画面から「DNS設定」の画面に行き、

「DNSレコードの追加」で、以下の内容を追記します。

ホスト名：　(購入したドメイン)
種別：　A
内容：　(VPSに割り当てられたIPアドレス)

ホスト名：　(購入したドメインのサブドメイン)
種別：　CNAME
内容：　(VPSに割り当てられたXserverドメインのURL(XXX.xvps.ne.jp))

たとえば「hoge.com」でアクセスしたい場合は、上段の設定。

「mattermost.hoge.com」のように、サブドメイン付きでアクセスしたい場合は、下段の設定になります。

この設定を行ったところ、独自ドメインで、Mattermostにアクセスできるようになりました。

SSLの設定

つぎに、SSLを設定します。SSLはサーバーとの通信を暗号化するもので、セキュリティ上つけておいた方がよいものです。

なお、ここからの作業は、ファイルの出し入れがあるので、「FileZilla」などのFTPクライアントソフトがあると便利です。

SSLの設定でダメだった手順

Xserver SSLで証明書を取得します。

有料のもありますが、無料で使える「Let's Encrypt」で十分だと思います。

Xserver VPSのマニュアルに「SSL証明書のインストール手順」があり、上で取得した証明書を自分のPCに一度ダウンロードし、サーバーの所定箇所にアップロードする必要があります。

まず、ここで問題発生。

指定されているフォルダが、サーバーにない。

しかも、動いているWebサーバーが「Apache」ではなく、「NGINX」なのでフォルダ構成が異なる形になっている。

いろいろと試したのですが、まったくダメ。

結果的に、この手順はまったく必要ありませんでした。

SSLの設定でウマくできた手順

(1)サーバー上でSSL証明書をインストール

Xserver VPSの管理画面から、「コンソール」を押して、サーバーコンソール画面を表示させ、管理者IDでログインします。(このコンソール画面は、なかなか使いづらいです)

Xserver VPSの管理画面から「コンソール」ボタンを押して、立ち上げます。

Xserver VPSのサーバー上で、「Certbot」という、Let’s Encryptの証明書をインストールできるソフトを動かします。

Certbotでの作業手順は、以下のページが参考になります。ほぼ、そのとおりで行けました。

参考URL) Ubuntu 20.04でLet’s Encryptを使用してNginxを保護する方法

(2)NXINXの設定変更

PC上で空のテキストファイルを作ります。

以下の内容をコピペして、mattermost.confとして保存します。途中にある(独自ドメイン)は、それぞれ入れ替えてください。

upstream backend {
server localhost:8065;
keepalive 32;
}

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

server {
listen 80 default_server;
server_name (独自ドメイン);
return 301 https://$server_name$request_uri;
}

server {
listen 443 ssl http2;
server_name (独自ドメイン);

http2_push_preload on; # Enable HTTP/2 Server Push

ssl on;
ssl_certificate /etc/letsencrypt/live/(独自ドメイン)/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/(独自ドメイン)/privkey.pem;
ssl_session_timeout 1d;

# Enable TLS versions (TLSv1.3 is required upcoming HTTP/3 QUIC).
ssl_protocols TLSv1.2 TLSv1.3;

# Enable TLSv1.3's 0-RTT. Use $ssl_early_data when reverse proxying to
# prevent replay attacks.
#
# @see: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_early_data
ssl_early_data on;

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = six months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

add_header X-Early-Data $tls1_3_early_data;

location ~ /api/v[0-9]+/(users/)?websocket$ {
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
client_max_body_size 50M;
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;
client_body_timeout 60;
send_timeout 300;
lingering_timeout 5;
proxy_connect_timeout 90;
proxy_send_timeout 300;
proxy_read_timeout 90s;
proxy_pass http://backend;
}

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 mattermost_cache;
proxy_cache_revalidate on;
proxy_cache_min_uses 2;
proxy_cache_use_stale timeout;
proxy_cache_lock on;
proxy_http_version 1.1;
proxy_pass http://backend;
}
}

# This block is useful for debugging TLS v1.3. Please feel free to remove this
# and use the `$ssl_early_data` variable exposed by NGINX directly should you
# wish to do so.
map $ssl_early_data $tls1_3_early_data {
"~." $ssl_early_data;
default "";
}

上の「mattermost.conf」ファイルを、

/etc/nginx/sites-available/

にFTPを使ってアップロードします。

コンソールで、以下のコマンドを打ちます。

sudo rm /etc/nginx/sites-enabled/mattermost
sudo ln -s /etc/nginx/sites-available/mattermost.conf /etc/nginx/sites-enabled/mattermost

設定ファイルが問題ないか確認します。

sudo nginx -t

エラー表示(warningは出るかもしれません)されなければ、NGINXを再起動し、次にMattermostも再起動します。

sudo systemctl restart nginx
sudo systemctl restart mattermost

これで、https://(独自ドメイン)で、Mattermostにアクセスできるようになっているはずです。

直近のmattermost.confの内容などは、以下のMattermostの手順ページが参考になります。

参考URL) Configure NGINX as a proxy for Mattermost server

SlackデータをMattermostに移行

今までSlackでのやり取りしていたデータを、Mattermostに移行します。

まずはじめに、さきほど立ち上げたMattermostにアクセスし、システム管理者IDを作成し、受け入れ用のワークプレイスを設定しておきます。

ここで作るシステム管理者IDは、Slackで使っているIDとは別にするといいと思います。下の手順で、slackデータの移行を行うと、SlackのID(メールアドレス)でのユーザーが、Mattermost上に作られます。

基本的に、上の手順のまま、進めていけます。

手順通りに行かない箇所として、「mmctl」コマンドが、そのままではつかえないので

「/opt/mattermost/bin/mmctl」とプログラム場所を含めてコマンドを打つと、実行されます。

NGINXとMattermostの再起動をスケジューリング

ホストサーバーで、たまに障害が起き、運営会社でサーバーの再起動などを行われることがあります。

再起動のあと、Mattermostへのアクセスができないことがあります。

常時サーバー状態を監視するわけにも行かないので、NGINXとMattermostの再起動をcronでスケジューリングしておきます。(止まっても、翌日には再起動されるようになり、無稼働時間を最悪１日にできます。)