Here is how to do NUXT deployment

First we have to add the nuxt.config.js configuration



Why is the host step 0.0.0.0

Reference here

https://blog.csdn.net/ttx_lau…

https://blog.csdn.net/u012814…

https://blog.csdn.net/enzocha…

First of all, preparation: First of all, execute our NUXT project: NPM run start starts a production web server locally to see if there is any problem with it and then put.nuxt and static, Nuxt. Config. Js, package. Json, package. Json, package – lock. Json packaged compressed into a zip file

Second, prepare a Linux server:

Here I amhttps://console.ucloud.cn/B: I bought it here.



Then configure external firewall 3000 to open to the public (the port where we deploy the service).

Then we download an Xshell 6 to connect to our Linux server and

Xshell is simple to use

Download the node

https://www.cnblogs.com/ruir/…

This is where node must be installed and node and NPM environment variables configured (version depends on your own needs).

Then change the NPM source address or download CNPM or NRM to set the image.

Foreign source addresses are too slow

Then set the NPM global download package environment variable issue

NPM global download package environment variable issue resolved

Then, if you find it inconvenient to upload files in Xshell 6, you can use XFTP to connect to the server. Then, we will create a new folder on the server and put the zip package into it and unzip it.

Then perform the operation NPM install –production to download the production dependencies in this folder

Finally, execute NPM run start

We should be able to access it through our server’s extranet IP and the port we deployed. For example, is my http://106.75.104.214:3000/

But this time as soon as we Ctrl + C the service is over

We then manage our services through PM2

First download NPM I pm2 -g to download as a global dependency

Then pm2 start NPM — start to start our current NPM script and pass in the start parameter

And then PM2 list and then we can see

Our NPM term has been managed, so I’ve stopped the NPM term here

This would have done the normal deployment, but it would have been too cumbersome if we had to do this manually every deployment. Let’s look at the CICD continuous integration deployment here.

Here we use git Actions. For example the main yml configuration explain https://coldstone.fun/post/20… You can also search for more explanations.

First of all:

  1. The developer sets the generation token in the setting of his own GitHub
  2. Then add the token to the project’s secrets
  3. Configure the GitHub execution script
  4. Create the. Github /workflows directory at the project root
  5. Download the Main. yml channel Workflows directory
  6. Modify the configuration
  7. Configure the PM2 profile
  8. Submit the updates
  9. View automatic deployment status













This will be used later in main.yml

Then generate main.yml in the project.github /workflows

main.yml

Name: Publish And Deploy Demo on: push: tags: - 'v*' tag: - 'v*' Runs-on: Ubuntu-latest steps: # name: Checkout uses: Actions /checkout@master # Download the commitId code for this tag # Pack build-name: Build uses: actions/ shard-run: npm install - run: npm run build - run: Tar-zcvf release.tgz.nuxt static nuxt.config.js package.json package-lock.json pm2. Config. json # Download dependency packages based on this tag # Release -name: Create Release id: create_release uses: actions/create-release@master env: GITHUB_TOKEN: ${{secrets. Token}} # create TOKEN with: tag_name: ${{github. Ref}}} release_name: Release ${{github. Ref}} draft: false prerelease: false # Upload Release ${{github. Ref}} draft: false prerelease: false # Upload Release Asset ID: upload-release-asset uses: actions/upload-release-asset@master env: GITHUB_TOKEN: ${{ secrets.TOKEN }} with: upload_url: ${{ steps.create_release.outputs.upload_url }} asset_path: ./release.tgz asset_name: Release. TGZ asset_content_type: application/x-tgz # -name: Deploy uses: appleboy/ssh-action@master with: host: ${{secrets. Host}} # username: ${{secrets. Username}} # password: ${{secrets. ${{secrets. Port}} # PORT number # then # enter the corresponding directory # download compressed TGZ to the server # unzip # download project to generate dependencies # then manage by PM2 start script: | cd /root/realworld-nuxtjs wget https://github.com/544076724/nuxt-test/releases/latest/download/release.tgz -O release.tgz tar zxvf release.tgz npm install --production pm2 reload pm2.config.json

The last thing I’m going to do here is create the RealWorld-nuxtjs directory on the server and then put the code in there.

Then create PM2.config. json in the project root directory

{
  "apps": [
    {
      "name": "RealWorld",
      "script": "npm",
      "args": "start"
    }
  ]
}

Finally, we submit the code to the repository. According to our main.yml configuration, normal push will not trigger a build. Only push tags starting with V will trigger the build process

Operation of the label

Then we git tag-a “tag content <v0.1.0>” -m”

Then push git push origin v0.1.0 push

Then we go to our GitHub repository and we can see it



These labels

You can see that in the actions



Build the tag for this submission



Click again to see the execution process

If any step fails there will be a failure message X

Through here

We can see the version of the release that we sent

And the associated TGZ package

Finally, we go to our PM2 list on the server



We can see the RealWorld process that we managed.

PM2 Reload and PM2 Restart are different. As opposed to restart, which kills and restarts the process, reload achieves a 0-second-downtime reload. Restart = Restart + Start Reload = Restart = Restart + Start Reload = Reload = Restart = Restart + Start Reload = Reload = Restart = Restart + Start Reload = Reload = Reload = Restart = Restart + Start Reload = Reload = Reload = Restart = Restart + Start Reload = Reload

Each subsequent action is to generate a different tag and submit it, and our automatic build is complete.