A Node online service migration

The original Node service needs to be migrated to a new host, so a new environment and corresponding migration scheme need to be prepared.

Node installation

Manual installation

Download address: https://nodejs.org/en/download/
Select: Linux Binaries (x64) right click Copy download link

# Download it to the machine and put it in the / opt directory [work@40-14-22 opt]$ wget https://nodejs.org/dist/v12.16.2/node-v12.16.2-linux-x64.tar.xz # decompression [work@40-14-22 opt]$ tar -xvf node-v12.16.2-linux-x64.tar.xz # rename [work@40-14-22 opt]$ mv node-v12.16.2-linux-x64 nodejs # Add soft chain to make node and npm commands globally accessible (ROOT permission required) [root@40-14-22 opt]# ln -s /opt/nodejs/bin/node /usr/local/bin/ [root@40-14-22 opt]# node -v v12.16.2 [root@40-14-22 opt]# ln -s /opt/nodejs/bin/npm /usr/local/bin/ [root@40-14-22 opt]# npm -v 6.14.4

Install with NVM

# To install NVM: https://github.com/nvm-sh/nvm wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash # Install Node nvm install v12.16.3

The advantage of using NVM is that Node version can be managed, different Node versions can be flexibly switched on the same machine, and one click installation is more convenient

• nvm install v12.16.3: install the specified version of Node
• nvm use v12.16.2: use the specified version of Node
• nvm ls: view the currently used Node version
• nvm -h: viewing help documents

Operation environment preparation

Install PM2

# Global installation [root@40-14-22 opt]# npm install pm2 -g # If global use is not supported, soft chain needs to be configured [root@40-14-22 bin]# ln -s /opt/nodejs/lib/node_modules/pm2/bin/pm2 /usr/local/bin/

Log segmentation

Official documents: https://www.npmjs.com/package/pm2-logrotate

# Install PM2 logrotate [work@40-14-22 log]$ pm2 install pm2-logrotate # Set more than 1G split pm2 set pm2-logrotate:max_size 1G # Set to save up to 200 log files pm2 set pm2-logrotate:retain 200 # Whether to compress logs through gzip pm2 set pm2-logrotate:compress false pm2 set pm2-logrotate:dateFormat YYYY-MM-DD_HH-mm-ss pm2 set pm2-logrotate:workerInterval 30 # Every night at 23:59:30 pm2 set pm2-logrotate:rotateInterval '30 59 23 * * *' pm2 set pm2-logrotate:rotateModule true

After setting, you can check whether the setting is correct through PM2 conf PM2 logrotate

[work@40-14-22 .pm2]$ pm2 conf pm2-logrotate Module: pm2-logrotate $ pm2 set pm2-logrotate:max_size 1G $ pm2 set pm2-logrotate:retain 200 $ pm2 set pm2-logrotate:compress false $ pm2 set pm2-logrotate:dateFormat YYYY-MM-DD_HH-mm-ss $ pm2 set pm2-logrotate:workerInterval 30 $ pm2 set pm2-logrotate:rotateInterval 0 0 * * * $ pm2 set pm2-logrotate:rotateModule true Module: module-db-v2 $ pm2 set module-db-v2:pm2-logrotate [object Object]

Install Git

git is installed to enable pm2 to pull code from the warehouse and deploy

[root@40-14-22 ~]# yum install git

Copy the public key string of the machine (the content of the. pub file in the current user's. ssh directory) and paste it under the authorization of the public gitlab. The purpose is to allow the machine to pull the private code in the gitlab warehouse

# Generate public key - just press enter [work@40-14-22 .ssh]$ ssh-keygen -t rsa

It is better to use public account instead of personal account

If ssh is not configured, pm2 will prompt the following no permission error when pulling the code

Server credit

Purpose: the deployment machine can access the target machine without secret

Edit authorized under the target machine. ssh directory_ Keys file, paste and save the contents of. pub file under the. ssh directory on the deployment machine

vim Shortcut key: https://www.cnblogs.com/junwen5599/p/9996873.html

Knowledge to the server_ Add public key of Gitlab server in hosts

The following error will be reported when the configuration is missing during deployment

other

View Linux kernel version

[work@37-14-42 log]$ uname -a Linux 37-14-42 2.6.32-573.22.1.el6.x86_64 #1 SMP Wed Mar 23 03:35:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

View centos version

[work@37-14-42 log]$ cat /etc/redhat-release CentOS release 6.5 (Final)

Installing the latest Node12 on centos6 will report the following error

[work@40-31-60 ~]$ node -v node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by node) node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by node) node: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by node) node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by node) node: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by node) node: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by node) node: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by node)

The reason is that the gcc version is too low. Either upgrade gcc or upgrade the system to centos7

It is recommended to upgrade the gcc version on CentOS 6, which is time-consuming and may cause version matching problems. It is better to upgrade the system to CentOS 7 in one step

Migration plan

Test verification

After the server environment is ready, the next step is to deploy the Node service on the new server according to the online deployment process.

At this time, because it is not verified, it is not possible to directly let the external network traffic in; in addition, the online service environment is generally isolated from the company's internal network environment, so how can we request a new service to verify whether the new service is available?

In this case, you can use the deployment machine, which is quite special. You can not only access the gitlab service pull code of the intranet, but also deploy the pulled code to the online environment. You can deploy the machine as a springboard to access the online new Node service, and verify whether the service is available in the Intranet environment.

See this article for details: Solve network isolation practice record through Nginx

Cut flow

After verifying that the service is normal, the next step is to switch traffic. You can use the following two schemes

• Switch the flow of a machine online to a new service
• Cut 10% of online traffic to new services

After the traffic comes in, observe whether the parameters of the server are abnormal, and whether the log monitoring of Node service is abnormal.

Run for a period of time without exception, and then cut 50%, step by step, and finally cut all traffic to the new host.

Finally, service migration is complex, and containerization is a better choice.