Redeploy MixSpace+Shiroi

Intro#

Yesterday, I just updated the blog's architecture, and this morning I woke up to find that the server had expired, causing the website to go down directly, without even a reminder email about the expiration.

The plan was not to renew after expiration, and after it expired, I was unable to connect to the server, and the data inside could not be retrieved. Fortunately, I had a good backup habit and regularly backed up the data to OneDrive. For details, see this article.

But awkwardly, I had only backed up the data and not the deployed environment variables, which led to some issues that I think are worth documenting.

Backend Deployment#

Consistent with the previous deployment article, the only thing to note, and the trouble encountered in this deployment, is the writing of the .env file. In ALLOWED_ORIGINS, only fill in the domain name, do not fill in https://xxu.do.

JWT_SECRET=XXXXXX # Fill in randomly, length between 16-32
ALLOWED_ORIGINS=xxu.do # Note that only the domain name should be filled in, do not fill in https://xxu.do, as this will cause the frontend to be unable to connect
ENCRYPT_ENABLE=false
ENCRYPT_KEY=

Frontend Deployment#

The deployment method this time: Using GitHub Action to build Shiroi and then deploy to a remote server, mainly referenced this article.

First, perform the following operations on the server:

Install Nodejs and unzip

# Install unzip
sudo apt update && sudo apt install -y unzip

# Install NVM (Node Version Manager)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
# Reconnect SSH or source .bashrc to take effect

nvm install node
node -v
npm -v

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

npm i -g sharp pm2 pnpm

In your server's home directory, create a directory for shiro, then create a .env file to fill in your variables.

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

Then fill in the corresponding environment variables. For a single domain, NEXT_PUBLIC_API_URL and NEXT_PUBLIC_GATEWAY_URL should be filled in as follows. GH_TOKEN can be created from here, and just check the repo permission.

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

TMDB_API_KEY=
GH_TOKEN=

After forking the project, add the following content in 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, either password or key)
GH_PAT GitHub Token that can access the Shiroi repository

The GH_PAT can be kept the same as the GH_TOKEN above.

In the Actions of the forked repository, enable the workflow; after modifying the build_hash file arbitrarily, the workflow will start. If it runs successfully, you can check if there are built files in your server's /root/shiro folder; it initially failed to run, and the reason was found to be that pm2 was not deployed, for reference.
Action scheduled execution: Go to the GitHub forked project, modify the .github/workflows/deploy.yml file, and uncomment the schedule: and - cron: '0 3 * * *' lines.

Nginx Reverse Proxy#

Example for a single domain:

## 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; # Replace with your domain
        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 address
        location /api/v2 {
            proxy_pass http://127.0.0.1:2333/api/v2; 
        }
        ## Simple read render address
        location /render {
            proxy_pass http://127.0.0.1:2333/render; 
        }
        ## Kami address
        location / {
            proxy_pass http://127.0.0.1:2323; 
        }
        ## Backend address
        location /proxy {
            proxy_pass http://127.0.0.1:2333/proxy;
        }
        location /qaqdmin {
            proxy_pass http://127.0.0.1:2333/proxy/qaqdmin;
        }
        ## RSS address
        location ~* \/(feed|sitemap|atom.xml) {
            proxy_pass http://127.0.0.1:2333/$1; 
        }
    }

Outro#

This time, adopting a new frontend deployment method has indeed solved the problem of excessive memory usage.

Additionally, it brings a lesson: always back up the .env file, as it will avoid many troubles during redeployment.

This article is synchronized and updated to xLog by Mix Space. The original link is https://xxu.do/posts/geek/redeploy-MixSpace%2BShiroi