はじめに
昨日、ブログのアーキテクチャをひと通り更新したばかりなのに、今朝起きてみるとサーバーの契約が切れており、サイトが丸ごとダウンしていた。しかも、期限切れの通知メールすら届いていなかった。
もともとは契約が切れたら更新しないつもりだったが、いざ切れてみるとサーバーに接続できなくなり、中のデータも取り出せなくなってしまった。幸いなことに、以前からきちんとバックアップする習慣があり、OneDrive に定期的にデータをバックアップしていた。詳しくはこの記事を参照してほしい。
ただ厄介だったのは、バックアップしていたのがデータだけで、デプロイ用の環境変数は保存していなかったことだ。そのせいでいくつか問題が起きたので、記録しておく価値があると思う。
バックエンドのデプロイ
以前のデプロイ記事と同じ手順だ。唯一注意が必要なのは、今回も問題になった .env ファイルの書き方。ALLOWED_ORIGINS にはドメイン名だけを記入すればよく、https://xxu.do のように URL を書いてはいけない。
JWT_SECRET=XXXXXX #随便填写,长度在 16-32 之间
ALLOWED_ORIGINS=xxu.do #这里需要注意的是,仅填写域名即可,不要填写 https://xxu.do,这会导致前端无法连接
ENCRYPT_ENABLE=false
ENCRYPT_KEY=
フロントエンドのデプロイ
今回は GitHub Action で Shiroi をビルドしてリモートサーバーにデプロイする方法を採用した。主にこの記事を参考にしている。
まずサーバー上で以下の操作を行う。
Nodejsとunzipをインストールする
Node.js,npm,pnpm,pm2,sharpをインストールする
npm i -g sharp pm2 pnpm
- サーバーのホームディレクトリに
shiroディレクトリを作成し、.envを新規作成して変数を記入する。
cd && mkdir shiro && cd $_
vi .env
- 続いて必要な環境変数を記入する。シングルドメインなら
NEXT_PUBLIC_API_URLとNEXT_PUBLIC_GATEWAY_URLは以下のように書けばよい。GH_TOKENはここから新規作成でき、権限は repo にチェックを入れればOKだ。
NEXT_PUBLIC_API_URL=http://localhost:2333
NEXT_PUBLIC_GATEWAY_URL=http://localhost:2333
TMDB_API_KEY=
GH_TOKEN=
- プロジェクトを Fork したら、
Settings -> Secrets and variables -> Actions -> Repository secretsに以下を追加する。
HOST: サーバーのアドレスUSER: サーバーのユーザー名PASSWORD: サーバーのパスワードPORT: サーバーの SSH ポートKEY: サーバーの SSH Key(任意。パスワードか Key のどちらか一方でよい)GH_PAT: Shiroi のリポジトリにアクセスできる GitHub Token
なお、GHPAT は先ほどの `GHTOKEN` と同じものを設定して構わない。
Fork したリポジトリの Action で workflow を有効にする。build_hash ファイルを適当に変更すれば workflow が起動する。実行が成功したら、サーバーの
/root/shiroフォルダにビルド済みのファイルができているか確認できる。最初は実行に失敗したが、あとで調べてみると pm2 が入っていないのが原因だった。参考までに。Action を定期実行するには、GitHub で Fork したプロジェクトを開き、
.github/workflows/deploy.ymlを編集して、schedule:と-corn: '0 3 * * *'の2行のコメントを外せばよい。
Nginx リバースプロキシ
シングルドメインの場合の例:
おわりに
今回はフロントエンドのデプロイ方法を新しくしたことで、確かにメモリ使用量が多すぎる問題は解決した。
それから、ひとつ教訓も得られた。.env ファイルは必ずバックアップしておくこと。そうすれば、再デプロイ時の手間がかなり減る。