はじめに
セキュリティの厳しい職場では、SlackやTeamsといった外部クラウドのチャットツールが一切使用できず、コミュニケーション手段がメール・電話・口頭に限定 されてしまうケースがあります。
(特に金融業界に多い印象があります)
- 毎朝メールが3桁溜まっているのが日常
- 曖昧な件名でメールを検索し、会話の流れをなんとか把握する
- メールを打つのが面倒になり、口頭で完結させてしまう
- 結果、言った・言わないが多発する
この状況を打開すべく、余剰のWindows PCを活用したローカルチャット環境 を構築してみます。
サクッと環境を立ち上げて、「チャットってこんなに便利なんだよ!」と職場に啓蒙していきましょう!
社内環境の前提
今回想定している社内環境は以下のとおりです(実際に私が体験した環境です):
-
ホストOS:Windows 限定(Windows Server 含む)
- つまり、ホストOSとしてLinuxが使用できません (
なぜ...) - Windows Updateを必ず適用させたいなどの理由があるのでしょうか
- つまり、ホストOSとしてLinuxが使用できません (
-
社内ネットワークを除きインバウンド通信は一切不可
-
社内DNSとSSL証明書は利用可能
余剰のWindows PCをホストマシンとして使用することを想定しており、今回は個人的な検証として Amazon EC2でWindows環境を再現 します。
ローカルチャットツールの選定
今回は Mattermost を採用します:
- 政府機関・重要インフラ・金融機関などでの採用実績があり、セキュアな環境として上位者に提案しやすい
- 公式サポートが得られるEnterprise版(有償ライセンス)があり、大規模化した際の運用体制へスムーズに移行できる
- 今回は限られたチームでのお試しということで、無償のTeam版を使用します
その他の選択肢としてZulipやRocket.Chatなどがありますが、今回は検証していません。
個人的にMattermostのUIが最も好みだったというのもあります。
最終的な構成
今回はMattermost公式が提供しているDocker Composeでのホスティングを行います。
WSL上にDocker Engineを導入し、Windows Server → WSL → Dockerコンテナという3層構成とします。
MattermostはアプリサーバーとPostgreSQLのデータベースサーバ、Nginxのリバースプロキシサーバといった3つのコンテナで構成されています。
Mattermost公式としては、 DockerおよびWindowsによる本番運用は非推奨 とのことです。
同構成で運用する場合はご注意ください。
Amazon EC2を利用した環境再現
インスタンスの起動
今回のように、EC2上のOSで仮想環境を稼働させる(Windows上でWSLを使用する)場合、 「ネスト化された仮想化」を有効にする 必要があります。
「ネスト化された仮想化」は C8i、M8i、R8i のインスタンスタイプのみ対応 しているので、今回は c8i.xlarge を選択しました。
「ネスト化された仮想化」の詳細は、以下のAWS公式ドキュメントとクラメソさんの記事を参考にしてください。
インスタンスの詳細は以下のとおりです:
- OS:Windows Server 2025
- インスタンスタイプ:
c8i.xlarge - ネットワーク設定:
- セキュリティグループを作成し、RDP(リモートデスクトップ, 3389)、HTTPS(443)、HTTP(80)のインバウンドを、自分のIPアドレス
xxx.xxx.xxx.xxx/32のみ許可
- セキュリティグループを作成し、RDP(リモートデスクトップ, 3389)、HTTPS(443)、HTTP(80)のインバウンドを、自分のIPアドレス
- ストレージサイズ:30GB
- ネスト化された仮想化:有効
リモートデスクトップ環境へアクセス
Windows App などのリモートデスクトップクライアントでEC2にアクセスします:
- PC名:EC2のパブリックIPアドレス
- ユーザー名とパスワード:
- AWSマネジメントコンソールから接続したいEC2を選択し、「接続 → RDPクライアント」で確認できる
WSL2のインストール
ここからの作業はEC2(Windows)上で行います。
PowerShellを起動し、以下のコマンドでWSL2をインストールします:
wsl --install
一度Windowsを再起動し、以下のコマンドでUbuntuをインストールします:
wsl --install -d Ubuntu
Windowsのファイアウォール設定
ホストしたMattermostへアクセスする際、Windows上でHTTPSとHTTPの通信を許可する必要があります。
PowerShellで以下のコマンドを実行し、インバウンドルールを追加します:
# HTTPSのインバウンドを許可
New-NetFirewallRule -DisplayName "Mattermost HTTPS" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow
# HTTPのインバウンドを許可
New-NetFirewallRule -DisplayName "Mattermost HTTP" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
以下のコマンドで追加されたインバウンドルールを確認できます:
Get-NetFirewallRule -DisplayName "Mattermost*" | Select-Object DisplayName, Enabled, Direction, Action
WindowsのIP → WSLのIP への転送設定
WSL上にホストしたMattermostへブラウザでアクセスする場合、この転送設定が必要です。
WSLにログインし、ip a もしくは hostname -I コマンドでIPアドレスを確認します。
その後、WindowsのPowerShellで以下コマンドを実行し、転送設定を行います:
# WSL上のIPアドレスを xxx.xxx.xxx.xxx とする
# HTTPS (443番) の転送設定
netsh interface portproxy add v4tov4 listenport=443 listenaddress=0.0.0.0 connectport=443 connectaddress=xxx.xxx.xxx.xxx
# HTTP (80番) の転送設定
netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=xxx.xxx.xxx.xxx
現在の転送設定は netsh interface portproxy show all で確認できます。
転送設定を削除したい場合は以下のコマンドを実行します:
# 443番の転送ルールを削除
netsh interface portproxy delete v4tov4 listenport=443 listenaddress=0.0.0.0
# 80番の転送ルールを削除
netsh interface portproxy delete v4tov4 listenport=80 listenaddress=0.0.0.0
WSLには、ホスト元と同一のIPアドレスを付与する ミラーモード があり、こちらを使用する方がシンプルです。
なぜかEC2ではミラーモードが設定できなかったので、手動で転送設定を行いました。
Docker Engineのインストール
ここからの作業はWSL上で行います。
以下の公式ガイドを参考に、WSL上にDockerをインストールします。
- パッケージの更新:
sudo apt update
sudo apt upgrade
- GPGキーの追加:
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
- aptリポジトリの追加:
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
- パッケージの再度更新:
sudo apt update
- Docker Engineのインストール:
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
- 最後に以下のコマンドで、Dockerの動作確認をします:
sudo docker run hello-world
Mattermostのホスティング
以下の公式ガイドを参考に、WSL上にMattermostをホストします。
今回は自己署名証明書(オレオレ証明書)を利用したSSL通信とします。
本番環境では社内のSSL証明書および社内DNSが必要になると思います。
同構成で社内利用を実現する場合は、事前に情報システム担当者に確認しておくのが良いでしょう。
- WSL上の任意のディレクトリに、Mattermostのリポジトリをクローンする:
git clone https://github.com/mattermost/docker
cd docker
- リポジトリ内
env.exampleから環境変数ファイル.envを作成し、環境変数を設定する:
cp env.example .env
nano .env
-
.envファイルの変更箇所は以下のとおり(それ以外はデフォルトのまま):
# ドメイン名にEC2のパブリックIPを設定
DOMAIN=xxx.xxx.xxx.xxx
# タイムゾーンを東京に設定
TZ=Asia/Tokyo
# MattermostのイメージをTeam版に設定
MATTERMOST_IMAGE=mattermost-team-edition
# Mattermostのバージョンを最新に設定
MATTERMOST_IMAGE_TAG=latest
-
.envファイルを保存し、以下コマンドでデータ保存用ディレクトリを設定する:
mkdir -p ./volumes/app/mattermost/{config,data,logs,plugins,client/plugins,bleve-indexes}
sudo chown -R 2000:2000 ./volumes/app/mattermost
# 以下のコマンドで権限が設定されたか確認する
ls -la ./volumes/app/mattermost
- 自己署名証明書を作成し配置する:
# EC2のパブリックアドレスを xxx.xxx.xxx.xxx と想定す
# 証明書を格納するディレクトリを作成
mkdir -p ./certs/etc/letsencrypt/live/xxx.xxx.xxx.xxx
# オレオレ証明書(fullchain.pem)と秘密鍵(privkey.pem)を作成(有効期限10年とする場合)
sudo openssl req -nodes -new -x509 \
-keyout ./certs/etc/letsencrypt/live/xxx.xxx.xxx.xxx/privkey.pem \
-out ./certs/etc/letsencrypt/live/xxx.xxx.xxx.xxx/fullchain.pem \
-days 3650 \
-subj "/CN=xxx.xxx.xxx.xxx"
- 再度、
nano .envで環境変数を編集し、証明書のパスを指定する:
# デフォルトのパスはコメントアウト(無効化)する
#CERT_PATH=./volumes/web/cert/cert.pem
#KEY_PATH=./volumes/web/cert/key-no-password.pem
#GITLAB_PKI_CHAIN_PATH=<path_to_your_gitlab_pki>/pki_chain.pem
# こちらのコメントアウトを外して(有効化して)使用する
CERT_PATH=./certs/etc/letsencrypt/live/${DOMAIN}/fullchain.pem
KEY_PATH=./certs/etc/letsencrypt/live/${DOMAIN}/privkey.pem
Mattermostの起動・接続確認
- 以下のコマンドでMattermostを起動します:
sudo docker compose -f docker-compose.yml -f docker-compose.nginx.yml up -d
- クライアントのブラウザで
https://[EC2のパブリックIPアドレス]にアクセスし、Mattermostのログイン画面が表示されたら完了です:
まとめ
今回はWindowsのみの環境でも、Mattermostを使ったローカルチャット環境が構築できることを確認しました。
社内SSL証明書と社内DNSを組み合わせることで、小規模であれば本番運用にも十分耐えうる環境に仕上がるかもしれません。
「うちの会社はセキュリティが厳しいから仕方ない」と諦めていた方も、ぜひ一度試してみてください。



