MattermostをGCP無料枠で試す

## Mattermostセットアップメモ
例によってドはまりしたので記録を残す。

### 起こったこと
Slackの例の90日制限。
相変わらず予算は無い。
GCP無料枠でMattermostを使う。

## ハマったこと
1. Mattermostのシステムコンソールでhttpsの設定はしない。
1. opensslのオレオレ証明書作成方法
1. nginxの設定
1. 各種設定ファイル、実行ファイルの場所

## 前提
GCPで適当なVMを起こせるアカウントを作っておく。
クレジットカードの登録が必要なはずだが、これだけなら課金はされない。

## 手順
ツール→Deploymentmanager→デプロイ→Deploy marketplace solution
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/676634/33069cc0-97f4-febb-f0a3-476389cab29b.png)

mattermostで検索
Mattermost Team Edition packaged by Bitnami
を選ぶ。→運用開始
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/676634/82d85382-3538-089a-1649-d7fcd0430a47.png)

無料枠の条件設定
1. つまりus-central1, west1, east1のいずれかであり、
1. e2-micro
1. standard-persistent disk <= 30G
ってこと。
https://cloud.google.com/free/docs/gcp-free-tier/#compute

ネットワーク設定はとりあえずデフォルトである。
HTTPでヒェッってなるがそのまま進める。

以下のように表示されるはずた。
とりあえずアクセスしてみよう。暗号化保護されていないとかでブラウザから警告が出るが、無視する。表示のuser,パスワードでログインできるだろうか。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/676634/eb9050b0-33d8-bd00-42b4-37d304cc25c2.png)

で、ここからハマったところになる。
左上のメニューからシステムコンソールを呼ぶ。
（すでに日本語化している）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/676634/441c506f-2e9d-09cf-7a14-55492e652a7f.png)

以下のWebサーバーからTSLの設定をするのかと思ったが、
こちらで443で受けるような設定をすると、うまくいかない。
mattermostその他がrestartしても起きなくなる。
これでめっちゃ時間が溶けた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/676634/cac918c4-9f72-9bb3-f2d0-dff1f637eb27.png)

結論としては今回のデプロイしたあれこれは、nginxでアクセスを受けて、
内部でmattermostに繋いでいるっぽい。
ので、nginxの設定をいじる必要がある。
マシンにSSH接続する設定があるが、GCPのブラウザSSHでもいいし、
適当な鍵を登録して普通にSSH接続しても良い。22番ポートで入れるはずだ。

じゃあnginxどこにいるのって話だが、以下を見るに、
https://docs.bitnami.com/google/apps/mattermost/administration/create-ssl-certificate-nginx/

```
/opt/bitnami/nginx/
```
あたりに居る。
```
sudo /opt/bitnami/ctlscript.sh stop nginx
```
してから作業する。
ようするにここでオレオレ証明書を作って、それでアクセスすればいいよねって話だろう。
上のページに沿って証明書をつくる、だけではうまくいかなかった。これもドはまり。

うえの記載ではsubjectAltNameとやらが記載されていないので、
相変わらずその証明書ではクロームくんは許してくれない。

以下を参考に、SANつきオレオレ証明書を造る。
https://qiita.com/nis_nagaid_1984/items/b8f87d41ea108d47af61
san.txtに相当する内容はしかし、IPアドレスしか無い。ドメイン名無いよ、なので、
```
subjectAltName = IP:xxx.xxx.xxx.xxx
```
となる。xxxのところはデプロイしたマシンのIPアドレスね。

出来上がったserver.crtを、
```
openssl x509 -text -in server.crt -noout
```
してみて、subjectAltNameが記載されていればたぶんOK

で、この作った証明書どうするのって話だが、nginxの設定ファイルをいじる必要がある。

```
/opt/bitnami/nginx/conf/
```
に色々confファイルが有って、「どれだよ」なるよね。
当初、nginx.confを
```
   # HTTP Server
    server {
        # Port to listen on, can also be set in IP:PORT format
        # listen  80;
        listen 443 ssl;

        include  "/opt/bitnami/nginx/conf/bitnami/*.conf";

        location /status {
            stub_status on;
            access_log   off;
            allow 127.0.0.1;
            deny all;
        }

        ssl_certificate     /opt/bitnami/nginx/conf/server.crt;
        ssl_certificate_key  /opt/bitnami/nginx/conf/server.key;

```
とかしてみたけどだめだった。ここで指定したserver.crtは全く使われない。
じゃあどこだよって話だけど、
```
/opt/bitnami/nginx/conf/server_blocks
```
にある
```
default-https-server-block.conf
mattermost-https-server-block.conf
```
とかだ。

```
unk@buri:/opt/bitnami/nginx/conf/server_blocks$ cat default-https-server-block.conf
# HTTPS Server
server {
    # Port to listen on, can also be set in IP:PORT format
    listen  443 ssl;

    ssl_certificate      /opt/bitnami/nginx/conf/server.crt;
    ssl_certificate_key  /opt/bitnami/nginx/conf/server.key;

    #ssl_certificate      bitnami/certs/server.crt;
    #ssl_certificate_key  bitnami/certs/server.key;

    include  "/opt/bitnami/nginx/conf/bitnami/*.conf";

    location /status {
        stub_status on;
        access_log   off;
        allow 127.0.0.1;
        deny all;
    }
}

```
みたいな修正をして、
```
sudo /opt/bitnami/ctlscript.sh start nginx
```

あとはアクセすする端末に証明書をインストール

ダブルクリック→
証明書インストール→
現在のユーザーに→
次のストアに配置→
参照→
信頼されたルート信頼期間
でインストールされるはず。ブラウザの再起動が必要かもしれない。


そして
```
https://xxx.xxx.xxx.xxx:443/
```
にアクセスして怒られなければOK。

あと、GCPのFireWallルールで、当該デプロイへのポート80での上がりを無効化しておく。
これでHTTPで通信はしないはず。

SMTPの設定とかは、SendGrid使うよりかは、適当なHotmailアカウントを作ってしまったほうがよっぽど楽かもしれない。

## 結論
結局VMを管理し続ける手間が増えた
Slackが使い物にならなくなったが、問題の種類が変わっただけに見える。
うーんこの

## 参考
以下参考にいたしました。
皆様に感謝いたします。

https://www.karelie.net/mattermost-gce-ssl/
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0700
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/deployment_guide/sssd-ldap-domain-ip