Discourse installation on Azure not reachable

サポート インストール
9

このトピックを再度持ち上げるのは気が引けますが、まだ関連性があります。Discourse としてのインストールは完璧に完了し、すべて問題なさそうですが、ポート 80 と 443 が外部から到達できません。

更新: 基本インストール は、Azure の Ubuntu Server 上でそのまま動作します。

2 回目に私が異なって行ったことは以下の通りです：

  1. VM の作成後、discourse-setup を実行した際、プロセスを中断しませんでした。そのため、すべてが一度に実行されました。

    1 回目はスワップ領域がないことに気づき、discourse-setup スクリプトが不足している場合に設定するものの、一度シェルに戻って確認してしまいました。その後、インストールのプロンプトが 基本ガイド と異なっていたため、もう一度中断してしまいました。

    + 驚いたのは Let’s Encrypt の項目で、通知を受け取るためのメールアドレスを求められることでした。HTTPS を手動で設定する必要があると思っていたのです。実際には、スクリプトが Let’s Encrypt の SSL 証明書を使用して Discourse インスタンスを設定してくれます。<c/br>+ もう一つは SMTP のユーザー名とパスワードの項目です。ここを空欄にできたかどうかは未だ確信が持てませんが、管理用メールアドレスとそのアカウントのパスワードを入力しました。

  2. この meta.discourse のスレッド に従って、スワップ領域を手動で設定しました。

    これが原因だったとは思いませんが、念のため記載します。2 回目は、1 回目と同じ手順で行いましたが、(1) スワップを手動で設定し、(2) discourse-setup を中断せずに実行した点が異なります。

    1 回目のインスタンスを救えた可能性もありますが、Discourse のアーキテクチャはまだ謎が多く、HTTP/HTTPS エンドポイントを再起動する方法も確信が持てません。netstat -tulpn の出力を比較すると、1 回目のインスタンスでは関連するすべてのサービスが適切なポートで実行・リッスンしていることがわかります（例：PostgreSQL は 5432、Redis は 6379 など）。ただし、ポート 80 と 443 のエントリが欠落しており、nginx が実行されていないことを示唆しています：

1 回目（失敗）のインスタンス：

$ sudo -s

# docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED        STATUS        PORTS                                                                      NAMES
62396a99737c   local_discourse/app   "/sbin/boot"   14 hours ago   Up 14 hours   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   app

# docker exec -it 62396a99737c bash

(docker)# netstat -tulpn
Active Internet connections (only servers)
Proto Local Address  Foreign Address State   PID/Program name
tcp   127.0.0.1:3000 0.0.0.0:*       LISTEN  -
tcp   0.0.0.0:5432   0.0.0.0:*       LISTEN  -
tcp   0.0.0.0:6379   0.0.0.0:*       LISTEN  -
tcp6  :::5432        :::*            LISTEN  -
tcp6  :::6379        :::*            LISTEN  -

2 回目のインスタンス：

(docker)# netstat -tulpn
Active Internet connections (only servers)
Proto Local Address  Foreign Address  State   PID/Program name
tcp   0.0.0.0:6379   0.0.0.0:*        LISTEN  -
tcp   0.0.0.0:80     0.0.0.0:*        LISTEN  2359/nginx: master
tcp   127.0.0.1:3000 0.0.0.0:*        LISTEN  -
tcp   0.0.0.0:5432   0.0.0.0:*        LISTEN  -
tcp   0.0.0.0:443    0.0.0.0:*        LISTEN  2359/nginx: master
tcp6  :::6379        :::*             LISTEN  -
tcp6  :::5432        :::*             LISTEN  -

今後の自分へのメモ：

  1. 1 回目はポート 80 と 443 のリスナーがないことに気づきましたが、127.0.0.1:3000 のソケット（デフォルトの Rails ソケットだと記憶していました）は確認できました。nginx が実行されていないかもしれないという考えは浮かばず、何らかの理由で Docker のポートマッピングが原因だと疑い、netcat を使って基本的なリダイレクトを行いました：

    Docker 内：nc -l -p 80 -c "nc 127.0.0.1 3000"
    VM 内の Docker 外：nc -zv localhost 80 および curl localhost:80（これで Docker に問題がないことが確認できました）

  2. また、Azure のインバウンドポートルール を疑いましたが、nc -zv が Connection refused を返し続けるのは、ポートは開いているが、相手側でリスナーが動作していないことを意味すると気づきました。（もしポートがブロックされていれば、nc は単にフリーズするはずです。）