Redeploying MixSpace + Shiroi

Intro

I'd just updated my blog's architecture yesterday, and when I woke up this morning, the server subscription had expired—the site was completely down, and I didn't even get an expiration reminder email.

I'd planned not to renew it after it expired, but once it expired, I couldn't connect to the server anymore, so I couldn't get the data out either. Fortunately, I'd gotten into the habit of backing up the data to OneDrive on a schedule; see this post for details.

The awkward part is that I'd only backed up the data, not the environment variables needed for deployment. That caused a few problems worth recording.

Backend Deployment

The deployment is the same as the previous deployment post. The only thing to watch out for—and the trouble I ran into this time—was writing the .env file. In ALLOWED_ORIGINS, just enter the domain name. Don't enter https://xxu.do.

JWT_SECRET=XXXXXX #随便填写，长度在 16-32 之间
ALLOWED_ORIGINS=xxu.do #这里需要注意的是，仅填写域名即可，不要填写 https://xxu.do，这会导致前端无法连接
ENCRYPT_ENABLE=false
ENCRYPT_KEY=

Frontend Deployment

This time I deployed using the GitHub Action that builds Shiroi and deploys it to a remote server, mainly following this post.

First, do the following on the server:

1. Install Nodejs and 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

2. Install Node.js, npm, pnpm, pm2, and sharp

npm i -g sharp pm2 pnpm 

3. In your server's home directory, create a folder called shiro, then create a .env file and fill in your variables.

cd && mkdir shiro && cd $_
vi .env

4. Then fill in the corresponding environment variables. For a single-domain setup, set NEXT_PUBLIC_API_URL and NEXT_PUBLIC_GATEWAY_URL as shown below. You can create a GH_TOKEN here with the repo scope checked.

NEXT_PUBLIC_API_URL=http://localhost:2333
NEXT_PUBLIC_GATEWAY_URL=http://localhost:2333

TMDB_API_KEY=
GH_TOKEN=

5. After forking the project, add the following under Settings -> Secrets and variables -> Actions -> Repository secrets:

• HOST — server address
• USER — server username
• PASSWORD — server password
• PORT — server SSH port
• KEY — server SSH key (optional; use either the password or the key)
• GH_PAT — a GitHub token with access to the Shiroi repository

GH_PAT can be the same as the GH_TOKEN above.

6. In the Actions tab of the forked repo, enable the workflow. After making any change to the build_hash file, the workflow will trigger. If it runs successfully, check /root/shiro on your server to see whether the built files are there. The first run failed for me; it turned out pm2 wasn't installed—just for reference.

7. For scheduled runs: in your forked GitHub repo, edit .github/workflows/deploy.yml and uncomment the schedule: and -corn: '0 3 * * *' lines.

Nginx Reverse Proxy

A single-domain example:

## 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; 
        }
        ## 简读 render 地址
        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; 
        }
    }

Outro

Switching to this new frontend deployment method did solve the high memory usage problem.

There's also a lesson here: always back up your .env files. That will save you a lot of trouble when you need to redeploy.