はじめに#
昨日、ブログの構造を更新したばかりなのに、今朝起きたらサーバーの契約が切れていて、ウェブサイトがダウンしてしまいました。期限切れの通知メールも届いていませんでした。
本来は契約が切れた後に更新しない予定でしたが、期限切れ後はサーバーに接続できなくなり、データも取り出せなくなりました。幸い、以前から良いバックアップ習慣があり、定期的にデータを 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_PATShiroi リポジトリにアクセスできる 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