はじめに#
昨日、ブログの構造を更新したばかりなのに、今朝起きたらサーバーの契約が切れていて、ウェブサイトがダウンしてしまいました。期限切れの通知メールも届いていませんでした。
本来は契約が切れた後に更新しない予定でしたが、期限切れ後はサーバーに接続できなくなり、データも取り出せなくなりました。幸い、以前から良いバックアップ習慣があり、定期的にデータを OneDrive にバックアップしていたので、具体的にはこの記事を参照してください。
しかし、困ったことに、以前はデータのみをバックアップしており、デプロイ環境の環境変数をバックアップしていなかったため、いくつかの問題が発生しました。記録しておく価値があると思います。
バックエンドデプロイ#
以前のデプロイに関する記事と同様で、今回のデプロイで注意が必要なのは .env ファイルの記述です。 ALLOWED_ORIGINS
にはドメイン名のみを記入してください。 https://xxu.do は記入しないでください。
JWT_SECRET=XXXXXX #適当に記入、長さは 16-32 の間
ALLOWED_ORIGINS=xxu.do #ここではドメイン名のみを記入してください。 https://xxu.do は記入しないでください。これによりフロントエンドが接続できなくなります。
ENCRYPT_ENABLE=false
ENCRYPT_KEY=
フロントエンドデプロイ#
今回のデプロイ方法:GitHub Action を利用して Shiroi を構築し、リモートサーバーにデプロイする、主にこの記事を参考にしました。
まず、サーバーで以下の操作を行います:
Nodejs
とunzip
をインストールします。
# unzip をインストール
sudo apt update && sudo apt install -y unzip
# NVM (Node Version Manager) をインストール
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
# SSH 接続を再度行うか、source .bashrc を実行して反映させます。
nvm install node
node -v
npm -v
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 にチェックを入れます。
NEXT_PUBLIC_API_URL=http://localhost:2333
NEXT_PUBLIC_GATEWAY_URL=http://localhost:2333
TMDB_API_KEY=
GH_TOKEN=
- プロジェクトをフォークした後、
Settings -> Secrets and variables -> Actions -> Repository secrets
に以下の内容を追加します:
HOST
サーバーアドレスUSER
サーバーユーザー名PASSWORD
サーバーパスワードPORT
サーバー SSH ポートKEY
サーバー SSH Key(オプション、パスワード key のいずれかを選択)GH_PAT
Shiroi リポジトリにアクセスできる Github Token
GH_PAT は上記の GH_TOKEN
と一致させることができます。
-
フォークしたリポジトリの Action で、ワークフローを有効にします;build_hash ファイルを適当に変更するとワークフローが起動します。成功すれば、自分のサーバーの
/root/shiro
フォルダに構築されたファイルがあるか確認できます;最初は実行に失敗しましたが、原因は pm2 がデプロイされていなかったことが判明しましたので、参考にしてください。 -
Action の定期実行:GitHub フォークしたプロジェクトに入り、
.github/workflows/deploy.yml
ファイルを修正し、schedule:
と-corn: '0 3 * * *'
の 2 行のコメントを外します。
Nginx リバースプロキシ#
単一ドメインの例:
## xxu.do
server {
listen 80;
server_name xxu.do;
rewrite ^(.*)$ https://$host$1 permanent;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name xxu.do; # あなたのドメインに置き換えてください
index index.html;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
ssl_certificate /etc/pki/xxu.do/server.crt;
ssl_certificate_key /etc/pki/xxu.do/server.key;
ssl_stapling on;
ssl_session_timeout 1d;
ssl_protocols TLSv1.2 TLSv1.3;
location /socket.io {
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:2333/socket.io;
}
## API アドレス
location /api/v2 {
proxy_pass http://127.0.0.1:2333/api/v2;
}
## 簡易レンダリングアドレス
location /render {
proxy_pass http://127.0.0.1:2333/render;
}
## Kami アドレス
location / {
proxy_pass http://127.0.0.1:2323;
}
## バックエンドアドレス
location /proxy {
proxy_pass http://127.0.0.1:2333/proxy;
}
location /qaqdmin {
proxy_pass http://127.0.0.1:2333/proxy/qaqdmin;
}
## RSS アドレス
location ~* \/(feed|sitemap|atom.xml) {
proxy_pass http://127.0.0.1:2333/$1;
}
}
おわりに#
今回、新しいフロントエンドデプロイ方法を採用したことで、確かにメモリ使用量が高すぎる問題が解決されました。
また、教訓として、必ず .env
ファイルをバックアップすることが重要です。これにより再デプロイ時の多くのトラブルを回避できます。
この記事は Mix Space によって xLog に同期更新されました。元のリンクは https://xxu.do/posts/geek/redeploy-MixSpace%2BShiroi