Redeploy MixSpace+Shiroi

Intro#

Yesterday, I just updated the structure of the blog, and this morning I woke up to find that the server had expired, causing the website to go down directly, without even an expiration reminder email.

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, as detailed in this article.

But awkwardly, I only backed up the data before and did not back up the deployment 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 the domain name should be filled in, do not fill in https://xxu.do.

JWT_SECRET=XXXXXX # Fill in arbitrarily, 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 prevent the frontend from connecting
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 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, with the permission checked for repo.

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 consistent with the above GH_TOKEN.

In the Actions of the forked repository, enable the workflow; modifying the build_hash file arbitrarily will trigger the workflow. If it runs successfully, you can check if there are built files in your server's /root/shiro folder; initially, it 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 -corn: '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 this 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